x402 on Solana: How the Exact SVM Scheme Settles Without EIP-3009

On EVM chains, x402 settles with an EIP-3009 signature: the agent signs a typed message, and anyone can push it on-chain. Solana has no transferWithAuthorization. So the exact SVM scheme does something structurally different — the agent signs a real transaction with one signature missing, and the facilitator fills the gap.

We have covered the x402 protocol itself and the EIP-3009 primitive underneath it on EVM chains in detail. But llm4agents settles on more than one chain, and the question of how the same HTTP 402 flow lands on Solana — a runtime with no EIP-712 typed data, no ERC-20, and a completely different transaction model — deserves the same treatment. The answer lives in one spec file: scheme_exact_svm.md in the coinbase/x402 repository.

The short version: on Solana, the payment payload is not an authorization object. It is a fully constructed, partially signed Solana transaction, base64-encoded, waiting for exactly one more signature — the facilitator's, as fee payer. That single design choice drives everything else in the spec: the strict instruction layout, the fee-payer safety rules, the memo-based nonce, and the replay window measured in blockhash lifetime instead of validBefore timestamps.

One protocol, two settlement primitives

x402 v2 is deliberately chain-agnostic at the top. Networks are identified with CAIP-2 identifiers — eip155:8453 for Base, solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp for Solana mainnet, solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1 for devnet. The PaymentRequired response, the facilitator's /verify and /settle endpoints, and the SettlementResponse shape are identical across chains. What changes per chain is the scheme implementation: how the client proves it authorizes the payment, and how the facilitator turns that proof into an on-chain transfer.

On EVM, the exact scheme wraps EIP-3009: the client signs an off-chain EIP-712 message (transferWithAuthorization) with a random 32-byte nonce and a validity window, and the facilitator submits it inside its own transaction, paying gas. The client never constructs a transaction at all. The signature is the payment.

On Solana, that primitive does not exist. SPL tokens have no built-in signature-based pull-payment authorization comparable to EIP-3009. What Solana does have — natively, since genesis — is a transaction model where the fee payer is just the first required signer, distinct from the accounts being debited. Any transaction can name a third party as fee payer, and the transaction is only valid once every required signer, fee payer included, has signed. The exact SVM scheme builds directly on this.

The flow: one missing signature

The spec defines a client-driven flow. Condensed to its essential steps:

The client requests a resource. The server responds with PaymentRequired, and inside the requirements' extra field it includes something EVM requirements never carry: feePayer, the public key of the account that will sponsor the transaction fee — typically the facilitator.

{
  "scheme": "exact",
  "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
  "amount": "1000",
  "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
  "payTo": "2wKupLR9q6wXYppw8Gr2NvWxKBUqm4PPJKkQfoxHDBg4",
  "maxTimeoutSeconds": 60,
  "extra": {
    "feePayer": "EwWqGE4ZFKLofuestmU4LDdK7XM1N4ALgdZccwYugwGd",
    "memo": "pi_3abc123def456"  // optional, seller-defined, max 256 bytes
  }
}

The asset is the token mint — here, mainnet USDC (EPjFW...Dt1v). The amount is in atomic units, six decimals for USDC, so "1000" is $0.001. So far this mirrors the EVM shape. The divergence starts with what the client does next.

The client constructs an actual Solana transaction: a TransferChecked of the SPL token from its own token account to the seller's, plus compute-budget instructions, with extra.feePayer declared as the transaction's fee payer. It signs with its own key. The result is a partially signed transaction — valid in every respect except that the fee payer's signature slot is empty. The client base64-encodes it and sends it as the payment payload:

{
  "x402Version": 2,
  "accepted": { /* the PaymentRequirements it is fulfilling */ },
  "payload": {
    "transaction": "AAAAAAAAAAAAA...AAAAAAAAAAAAA="  // base64, partially signed
  }
}

The resource server forwards this to the facilitator's /verify endpoint. The facilitator decodes the transaction, inspects it instruction by instruction against a strict checklist (next section), and returns {"isValid": true} or a typed failure. On /settle, the facilitator adds its own signature as fee payer, submits the now fully signed transaction to Solana, and returns a SettlementResponse with success: true, the base58 transaction signature, the network, and the fee payer's address. The server releases the resource.

Note what did not happen: the facilitator never constructed a transaction of its own. On EVM, the facilitator wraps the client's authorization in a facilitator-owned transaction. On Solana, the client authored the entire transaction and the facilitator merely co-signed it. The trust question inverts — which is exactly why the verification rules are so strict.

The facilitator's verification checklist

Co-signing an arbitrary transaction as fee payer is dangerous. The transaction the client built could, in principle, do anything: drain an account the facilitator controls, invoke a malicious program, or burn the facilitator's SOL on compute. The spec's answer is to make the transaction shape non-negotiable. Before signing, a facilitator MUST enforce, among others:

Instruction layout. The transaction must contain between three and six instructions, in order: a Compute Budget set compute unit limit, a Compute Budget set compute unit price, a TransferChecked from either the SPL Token or Token-2022 program, and then optionally up to two Lighthouse assertion instructions and/or one SPL Memo instruction. Only those programs are allowed — Lighthouse (L2TEx...A3S95) and Memo (MemoS...fcHr) are the sole optional extras. Anything else in the instruction list is a rejection.

Fee payer isolation. The fee payer's address must not appear in the accounts of any instruction. It must not be the authority of the TransferChecked, and it must not be the source of funds. The facilitator's key pays the fee and does nothing else. This is the rule that makes co-signing safe: a transaction that touches the fee payer's accounts in any capacity never gets the second signature.

Compute bounds. The two compute-budget instructions must be genuine ComputeBudget program calls with the correct discriminators, and the compute unit price must be bounded — the reference implementation caps it at 5 lamports per compute unit. Without this, a hostile client could set an enormous priority fee and drain the sponsor through fees alone.

Destination and amount. The destination of the TransferChecked must equal the Associated Token Account derived from (owner = payTo, mint = asset) under the selected token program — not just any account the client claims belongs to the seller. The transfer amount must equal PaymentRequirements.amount exactly. The source token account must exist; the destination ATA must exist unless the transaction includes a create-ATA instruction for it.

Replay protection without validAfter and validBefore

EIP-3009 carries its replay protection in the signed message: a random nonce the token contract marks as used, plus validAfter/validBefore timestamps. A Solana transaction needs none of that added, because the runtime already provides it: every transaction embeds a recent blockhash, and Solana rejects any transaction whose blockhash has expired — a window of roughly 60 to 90 seconds — as well as any transaction already processed. The partially signed transaction is therefore self-expiring and self-deduplicating at the chain level.

The spec still adds two layers on top. First, the Memo instruction doubles as an application-level identifier: when the seller sets extra.memo (up to 256 UTF-8 bytes — think order or invoice IDs like pi_3abc123def456), the client MUST include exactly one Memo instruction carrying that exact string, and the facilitator MUST verify it. When there is no seller memo, the client MUST include a random nonce of at least 16 bytes, hex-encoded, in the Memo — ensuring two otherwise identical payments produce distinct transactions.

Second, duplicate settlement. Between submission and confirmation there is a window where the same payload could be settled twice by a naive facilitator, producing two success responses for one payment. The spec recommends an in-process cache keyed on the base64 transaction string: reject a settlement whose key is already cached with a duplicate_settlement error, and evict entries after 120 seconds — comfortably past the blockhash lifetime, after which the transaction cannot land on-chain regardless. No database required; the chain itself is the durable dedup layer.

Trade-offs against the EVM path

Neither model is strictly better; they cut the problem differently.

The EVM/EIP-3009 authorization is transport-independent and long-lived: an agent can sign it offline, hand it to any party, and set a validity window hours wide. That flexibility is also its risk surface — we covered the front-running trap that forces receiveWithAuthorization in the EIP-3009 deep dive. The SVM transaction is the opposite: bound to a specific fee payer chosen by the seller, dead in about a minute, and unable to be front-run into a different context because the entire transaction — accounts, amounts, programs — is what the client signed. There is no separate authorization object to misuse.

The costs run the other way too. The tight blockhash window means an SVM payment payload cannot be pre-signed long in advance or queued for later settlement — the agent's key must be online at payment time. The seller must publish a feePayer before the client can even construct the transaction, coupling the 402 response to a specific facilitator in a way the EVM flow avoids. And the facilitator carries a heavier verification burden: parsing and validating raw transaction structure rather than checking a typed signature against known parameters. The spec's rigid three-to-six instruction layout is what keeps that burden tractable.

What Solana buys in exchange is fast, cheap finality — Solana's own x402 guide pitches the chain on near-instant settlement at fees low enough for true micropayments — and native Token-2022 support, since TransferChecked exists in both token programs. For the walk-up, pay-per-call pattern we mapped in the Bearer vs x402 decision tree, where an agent discovers a resource, pays once, and moves on, a sixty-second payload lifetime is not a limitation. It is the natural shape of the interaction.

Ecosystem state, July 2026

The tooling is current. Coinbase ships @x402/svm, the Apache-2.0 SVM mechanism package for x402 — its latest release, 2.19.0, landed on July 17, 2026, three days before this post. Solana's developer portal maintains a first-party getting-started guide covering both SDK-based integrations (Faremeter's @faremeter/payment-solana) and a dependency-free native implementation, and lists active Solana facilitators including PayAI — which currently covers transaction fees itself — and Corbits. Devnet USDC (4zMMC...ncDU) makes the full flow testable without mainnet funds.

It is also worth placing this in the settlement stack we have been mapping. The exact SVM scheme is how value lands on Solana; CCTP V2 is how USDC moves between Solana and EVM chains when an agent's balance lives on one chain and its counterparty settles on another. x402 gives agents one payment protocol; CAIP-2 networks and per-chain schemes give it multiple settlement rails underneath.

What it means for LLM4Agents

llm4agents advertises Solana as a first-class billing chain alongside EVM networks, and this spec is the piece that makes that claim concrete for the x402 walk-up path. The gateway's EVM settlement rides EIP-3009; a Solana settlement path rides the exact SVM scheme, and the two expose identical surfaces to the agent — same 402 response shape, same /verify and /settle facilitator contract, same SettlementResponse. An agent whose treasury holds SPL USDC can pay for inference the same way an agent on Base does, and the difference stays entirely below the scheme layer.

The verification checklist matters to us in both directions. As a seller, the platform should only trust facilitators that demonstrably enforce the full MUST list — a lax facilitator that co-signs malformed transactions is a refund dispute waiting to happen. If the platform ever runs its own facilitator for Solana settlement, the checklist is the implementation spec: instruction layout, fee payer isolation, compute price bounds, ATA derivation, exact amount. And the extra.memo field maps cleanly onto our billing internals — a seller-defined memo carrying the reservation ID would tie each on-chain transfer to a specific metered request in the reserve → proxy → settle pipeline, giving reconciliation a chain-native join key.

The short payload lifetime is the one operational constraint to design around. A sixty-second window between constructing the payment and settling it is generous for a single API call, but it means Solana-side payments cannot be batched, queued, or pre-authorized the way EIP-3009 authorizations can. For per-request billing that is fine. For anything resembling a spending budget delegated ahead of time, the answer on Solana is not this scheme — it is session-key-style delegation at the wallet layer, the same conclusion we reached for EVM in the account abstraction post.

Staying on the frontier

Concrete steps, in order. First, stand up the exact SVM scheme end-to-end on devnet: @x402/svm client-side, devnet USDC, a facilitator from the Solana guide's list, and verify the full 402 → partially-signed-transaction → settle loop against a staging gateway endpoint. The package is versioned in lockstep with the rest of the x402 SDK, so this also exercises the v2 CAIP-2 surfaces we already support on EVM.

Second, adopt extra.memo in Solana payment requirements from day one, carrying the internal reservation ID. It costs nothing, the spec already obliges clients to echo it and facilitators to verify it, and it turns the Solana ledger into a self-auditing record of every settled request.

Third, build facilitator due diligence into the integration: before trusting any third-party facilitator on Solana, test it with deliberately malformed payloads — extra instructions, a fee payer inserted as transfer authority, an inflated compute unit price, a destination that is not the payTo ATA — and require rejections on every one. The MUST list is only a guarantee if the facilitator actually implements it.

Fourth, track scheme evolution in the coinbase/x402 repo now that the x402 Foundation stewards the protocol. The exact scheme covers fixed-price calls; proposed schemes like upto would cover metered usage — which is precisely the shape of token-based LLM billing. Whichever chain ships a usable metered scheme first becomes the most interesting settlement rail for a gateway that bills by the token, and the SVM transaction model, where the payload is a real transaction with real chain-level expiry, will make that scheme look different on Solana than on EVM. Being early to that difference is the edge.