Base URL
How it works
The facilitator sits between A2A clients and the Solana network. When a client wants to pay for an agent request:Resource server returns 402
The A2A gateway returns a
402 Payment Required response with payment requirements (amount, token, recipient, facilitator address).Client builds transaction
The client constructs a Solana
VersionedTransaction with an SPL Token TransferChecked instruction. The facilitator’s public key is set as the fee payer.Client signs and sends to facilitator
The client partially signs the transaction (payer signature only) and sends it to
POST /settle along with the payment requirements.Facilitator verifies
The facilitator deserializes the transaction, validates the SPL instructions, checks amounts and recipients, and confirms the fee payer matches.
Endpoints
| Method | Path | Description |
|---|---|---|
GET | /supported | Discover supported payment kinds, extensions, and signer keys |
POST | /verify | Verify a payment payload without settling |
POST | /settle | Verify, co-sign as fee payer, and submit to Solana |
GET | /health | Health check |
x84 extensions
On top of standard x402 SVM exact payments, the facilitator supports three x84-specific settlement modes via theextensions field in the payment payload:
| Extension | ID | Description |
|---|---|---|
| Atomic | x84-atomic | Client submits transaction directly to Solana. Facilitator verifies the on-chain tx signature and receipt PDA. |
| Attestation | x84-attestation | Similar to atomic, but uses an attestation receipt PDA instead of a CPI receipt. |
| Delegated | x84-delegated | Uses a Delegation PDA for budget-based spending. Supports both client-side (delegation PDA reference) and server-side (ed25519 signature with 60s timestamp window) modes. |
Supported assets
Currently the facilitator supports:| Network | Asset | Token |
|---|---|---|
Solana Devnet (solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1) | Gh9ZwEmdLJ8DscKNTkTqPbNwLNNBjuSzaG9Vp2KGtKJr | USDC (devnet) |
GET /supported for the current list of supported kinds, extensions, and signer keys.
Verification rules
The/verify and /settle endpoints enforce these validation rules:
- Deserialization — Transaction must be a valid Solana
VersionedTransaction - Allowed programs — Only SPL Token, ComputeBudget, and Memo programs are permitted
- Transfer instruction — Must contain exactly one
TransferCheckedinstruction - Amount match — Transfer amount must match the payment requirements
- Mint match — Token mint must match the required asset
- Destination match — Transfer destination must match the
payToaddress - Fee payer — Must be the facilitator’s public key (from
/supportedsigners) - Replay prevention — Already-signed transactions are rejected
Idempotency
The/settle endpoint is idempotent. If the same transaction is submitted twice, the second call returns the original settlement result (same transaction signature) without resubmitting.
v1 backward compatibility
ThepaymentPayload field accepts both formats:
- v2 (recommended) — Structured
PaymentPayloadobject withx402Version,accepted,payload, and optionalextensions - v1 (legacy) — Base64-encoded JSON string, automatically normalized to v2 internally