Why Token-2022

The Short Answer

Token-2022 is the only token standard on Solana that supports transfer hooks — the mechanism that enables pull-based billing where the recipient (merchant) triggers and validates the transfer from the sender (subscriber). This is architecturally impossible on any EVM chain.

Token-2022 Extensions Used and Why

Transfer Hook — The Billing Engine

Transfer hooks allow a custom program to intercept and validate Token-2022 transfers before they complete. This is the foundation of VelaPay's pull billing model.

Subscriber creates mandate (authorizes merchant to pull)
        ↓
Merchant or Keeper executes pull
        ↓
vela-protocol writes PullApproval PDA
        ↓
Token-2022 transfer_checked CPI
        ↓
vela-transfer-hook validates:
  ├─ Mandate exists and is active?
  ├─ Amount within authorization?
  ├─ Period/stream constraints satisfied?
  ├─ PullApproval nonce matches?
  └─ Mandate type matches (periodic vs stream)?
        ↓
Transfer approved → executes
Transfer denied → reverts with typed error

The transfer hook is deployed as a separate program (vela-transfer-hook) for security isolation. Any bug in the hook either lets merchants steal or blocks legitimate payments. It must be minimal, auditable, and fail-closed.

Upgradeable via dynamic ExtraAccountMetaList (8 slots) so the hook can evolve without redeploying the main protocol.

Transfer Fee — Keeper Incentive

Small fee on each transfer goes to keepers (those who trigger pulls). Uses the built-in 1% transaction fee from our revenue model. Token-2022 transfer fees are native — no custom code needed to collect and distribute.

This is part of the economic model:

• Merchants pay a small fee per pull.
• Keepers are incentivized to execute pulls reliably.
• Revenue flows automatically through Token-2022's fee mechanism.

Non-Transferable — Subscription Credentials

Vela Credentials are Non-Transferable Token-2022 tokens minted to subscribers when they subscribe. They prove an active subscription relationship without exposing billing details.

Key properties:

• Per-merchant (v1.7+): Credentials track the subscriber↔merchant relationship, not the plan tier. Plan switching doesn't require re-minting.
• Cannot be traded or moved between wallets.
• Metadata-bearing: Carry subscription metadata via Metadata Pointer extension.
• Revoked on cancellation: Burned when subscription ends.

Non-transferability is critical because subscription access should not be a tradeable commodity. If credentials were transferable, subscribers could resell access, undermining the merchant's pricing model.

Metadata Pointer — On-Chain Plan Terms

Vela Credentials and Plan accounts store metadata on-chain via the Metadata Pointer extension. This includes:

• Plan tier and features.
• Subscription start date.
• Billing period information.
• Merchant-specific metadata.

Metadata Pointer enables on-chain plan discovery without relying on off-chain indexing. Any observer can read credential metadata directly from the chain.

Confidential Balances (Phase 4+)

Optional future enhancement for enterprise merchants who want payment amounts encrypted on-chain. This is distinct from Arcium MPC — Confidential Balances encrypt at the token level, Arcium encrypts at the computation level.

Currently deprioritized because:

• Arcium MPC provides stronger privacy guarantees for billing data.
• Confidential Balances had a ZK ElGamal proof bug (June 2025 post-mortem).
• Wallet UX for confidential transfers is still rough.

Extension Composition

Token-2022 extensions are composable. A single mint can have:

• Transfer Hook (billing enforcement)
• Transfer Fee (keeper incentive)
• Non-Transferable (credentials)
• Metadata Pointer (plan terms)
• Confidential Balances (future)

This composition is what makes Token-2022 uniquely suited for billing — every extension serves a specific billing need and they work together without conflict.

The EVM Impossibility Argument

Why Pull Billing Cannot Work on Ethereum

On Ethereum (and all EVM chains), gas is paid by the transaction sender. This is a fundamental constraint that prevents pull-based billing:

EVM Model (Push Only):
┌──────────────┐    transaction    ┌──────────────┐
│   Subscriber  │ ───────────────→ │   Merchant    │
│  pays gas     │                  │  receives     │
│  sends token  │                  │               │
└──────────────┘                   └──────────────┘

Subscriber MUST initiate the transfer.
Merchant CANNOT pull funds.

Solana Token-2022 Model (Pull Possible):
┌──────────────┐                   ┌──────────────┐
│   Subscriber  │ ← transfer_hook  │   Merchant    │
│  pays token   │    validates     │  or Keeper    │
│  from mandate │                  │  triggers pull│
└──────────────┘                   └──────────────┘

Merchant/Keeper CAN trigger the transfer.
Subscriber's mandate authorizes it.
Transfer hook enforces the rules.

Detailed EVM Limitations

EVM Limitation	Why It Blocks Pull Billing	Solana Solution
Gas paid by sender	Subscriber must initiate every transaction	Transfer hook allows recipient to trigger
ERC-20 approvals are unlimited (unless ERC-3009)	No scoped authorization — either trust the merchant fully or don't	Mandate PDAs with explicit amount, period, and pull limits
No transfer hooks	No way to intercept and validate a transfer in-flight	Token-2022 transfer hooks run synchronously during transfer_checked
12+ second finality	Too slow for real-time billing decisions	~400ms finality on Solana
High gas costs	Micro-transactions and streaming are economically infeasible	Sub-cent transaction fees on Solana
No composable token extensions	Each feature requires a separate contract	Token-2022 extensions compose on a single mint

The Approval Problem on EVM

ERC-20 approve() gives the spender an allowance, but:

• It's a blunt instrument — you approve a maximum amount, not a billing schedule.
• increaseAllowance / decreaseAllowance are optional and not standard.
• The subscriber must remember to revoke approvals (security risk).
• There's no on-chain concept of "billing period" or "pull frequency".

ERC-3009 (transfer with authorization) helps but still requires the subscriber to sign each transfer. It doesn't enable automated recurring billing where the merchant initiates.

Why This is Architectural, Not Implementation

The gas-sender-pays constraint is baked into the EVM at the protocol level. It cannot be fixed with a clever smart contract. Every "recurring payments on Ethereum" solution either:

1. Requires the subscriber to initiate every payment (push, not pull).
2. Uses a centralized relay that the subscriber trusts (defeats the purpose of on-chain billing).
3. Uses meta-transactions with a gas tank (adds complexity, trust, and centralization).

None of these approaches match what VelaPay achieves with Token-2022 transfer hooks.

Why Solana for Billing

Reason 1: Transfer Hooks (Impossible on EVM)

Token-2022 transfer hooks are the only mechanism on any major chain that enables recipient-triggered, programmatically validated transfers. This is the foundational primitive for pull billing.

Reason 2: Sub-Cent Fees

At $0.00025 per transaction (standard Solana fee), micro-transactions and streaming payments are economically viable. On Ethereum, a single transfer costs $1-50 in gas, making per-second streaming and usage-based billing with small amounts impractical.

This enables:

• Streaming mandates: Rate-per-second billing where each settlement might be cents.
• Usage-based billing: Small per-unit charges that would be eaten by ETH gas.
• Agent mandates: AI agents making many small purchases that need low overhead.

Reason 3: Arcium MPC (Solana-Native)

Arcium's encrypted compute is Solana-native. The MXE network integrates with Solana's account model and transaction flow. On EVM, privacy solutions are limited to TEE-based approaches or complex ZK circuits that can't match Arcium's generality.

Reason 4: Speed (~400ms Finality)

Billing decisions need fast confirmation. On Ethereum, a transfer takes 12+ minutes for finality (after checkpoint epochs). On Solana, a transfer confirms in ~400ms. This matters for:

• Real-time streaming settlement.
• Instant subscription confirmation.
• Responsive checkout UX.
• Keeper network efficiency (fast retry on failed pulls).

Reason 5: Composability with the Solana Ecosystem

VelaPay composes with existing Solana infrastructure:

• Squads: Multi-sig treasury management for merchants who need team billing.
• Jupiter: Token routing for multi-currency billing (swap before pull).
• Circle (USDC/PYUSD): Stablecoin rails for predictable billing amounts.
• Helius: RPC, webhooks, and DAS for event indexing and credential queries.
• Token-2022 ecosystem: Every Token-2022 extension is available for billing innovation.

Composability Story

How VelaPay Composes with Other Solana Protocols

                    ┌─────────────┐
                    │   Jupiter    │  Token routing for
                    │   (swap)    │  multi-currency billing
                    └──────┬──────┘
                           │
┌──────────┐    ┌──────────┴──────────┐    ┌──────────┐
│  Circle   │    │    VelaPay          │    │  Squads   │
│  USDC/    │───→│  Transfer Hook      │───→│  Multi-sig│
│  PYUSD    │    │  Mandate System     │    │  Treasury │
└──────────┘    └──────────┬──────────┘    └──────────┘
                           │
                    ┌──────┴──────┐
                    │   Arcium    │  Encrypted billing
                    │   MXE       │  logic + analytics
                    └─────────────┘

VelaPay's transfer hook mandate system becomes a template for other protocols. Any protocol that needs scoped, recurring value transfer can use the same pattern:

• DAO treasury management (recurring budget allocations).
• NFT rental protocols (recurring access fees).
• DeFi protocol fees (recurring management fees).
• AI agent budgets (scoped spending authorizations).

Token-2022 Adoption Constraint

The USDC Problem

As of April 2026, Circle's USDC is still an SPL Token (legacy), not Token-2022. This is the primary adoption constraint for VelaPay:

• USDC (largest stablecoin on Solana): SPL Token — not compatible with VelaPay transfer hooks.
• PYUSD (PayPal): Token-2022 — compatible.
• USDY (Ondo): Token-2022 — compatible.
• New issuers: Most new stablecoin issuers on Solana are choosing Token-2022.

VelaPay's Strategy

1. Target Token-2022 issuers first: PYUSD, USDY, and new issuers are the initial market.
2. Support wrapped USDC: v1.1 introduced wrapped mint flows that allow billing with Token-2022-wrapped USDC.
3. Wait for Circle migration: Circle is expected to migrate USDC to Token-2022. When they do, the entire stablecoin market opens up.
4. Multi-token support (v1.8): TokenConfig PDA registry supports any Token-2022 mint. Adding a new token is an admin operation, not a code change.

Adoption Timeline

Date	Event	Impact
May 2024	Orca integrates Token-2022	First major DEX support — Token-2022 tokens become tradable
Late 2024	Multiple stablecoin issuers adopt Token-2022	PYUSD, USDY, others launch on Token-2022
Feb 2025	Circle begins Token-2022 exploration (rumored)	USDC migration becomes plausible
Early 2026	Token-2022 is the default for new Solana tokens	New issuers start on Token-2022
TBD	Circle migrates USDC to Token-2022	Full stablecoin market opens for VelaPay

When Token-2022 Became Viable

Token-2022 was available in the Solana runtime from late 2023, but it wasn't practically viable for a billing product until:

1. May 2024: Orca integrates Token-2022 — the first major DEX to support it. This meant Token-2022 tokens could be traded, providing liquidity.
2. Late 2024: Multiple stablecoin issuers adopted Token-2022, providing billing-relevant tokens.
3. Early 2025: Transfer hook interface stabilized (spl-transfer-hook-interface 0.10.0), making billing hooks reliable.
4. 2025-2026: Wallet support for Token-2022 improved to the point where subscriber UX is acceptable.

Why Not SPL Token (Legacy)

• No transfer hook support — can't implement pull billing.
• No transfer fee mechanism — can't incentive keepers natively.
• No metadata pointer — can't store plan terms on-chain at the token level.
• No non-transferable extension — can't create subscription credentials.
• Legacy standard being phased out — new tokens use Token-2022.

Why Not ETH/ERC-20

Transfer hooks are architecturally impossible on EVM (see detailed argument above). This is not an implementation gap — it's a protocol-level constraint. Every EVM "recurring payments" solution is fundamentally a workaround that requires either subscriber initiation, centralized relay, or blunt approval mechanisms.

Why Not Other L1s

Chain	Transfer Hook Equivalent	Pull Billing Possible?	Why Not
Ethereum	None	No	Gas-sender-pays constraint
Polygon	None	No	Same EVM limitation
Arbitrum	None	No	Same EVM limitation
Aptos	Move hooks (limited)	Partially	No encrypted compute ecosystem
Sui	Object hooks (limited)	Partially	Different account model, no Arcium equivalent
Cosmos (Noble)	None	No	No token extension framework

Solana's combination of Token-2022 transfer hooks, sub-cent fees, fast finality, and Arcium MPC is unique among all chains. No other chain has all four properties needed for pull-based, privacy-preserving, economically viable recurring billing.