Overview
Your AI agent needs to pay for things. APIs cost money. Compute costs money. Data costs money. Every tool your agent uses has a price.
Right now, every API call is a separate blockchain transaction — or you're managing billing accounts and API keys for every service your agent touches. That's slow, expensive, and doesn't scale.
SPX fixes this. You fund your agent once. It pays for any service on the network automatically — no transaction per call, no setup per vendor. Services verify payment instantly. Funds are pre-deposited on-chain, so services know the money exists before doing any work.
How it works
- You fund your agent — deposit USDC and set a spending limit. Your agent gets a payment key that can spend but never withdraw.
- Your agent pays automatically — every API call, your agent authorizes payment in under 1ms. No blockchain transaction. No delay. The service verifies instantly and responds.
- Services collect when ready — whether your agent made 10 payments or 10,000, the service submits one transaction to collect everything.
That's it. Thousands of payments, one transaction.
Two ways to use SPX
Your agent needs to pay for things — give it a funded account and let it work. It pays for APIs, tools, and compute across any service on the network, from a single funding source.
Your service should accept agent payments — add 5 lines of middleware. Agents pay per request. You collect everything in one transaction whenever you want.
Why not existing solutions?
| Per-call on-chain (x402) | Card rails (Stripe) | SPX | |
|---|---|---|---|
| First call | 1 tx, 400ms, $0.00025 | Card auth, $0.30 | Instant, free |
| 10,000 calls | $2.50 in fees | ~$3,000 | $0.00025 total |
| Spending limit | None | Card limit | Hard on-chain cap |
| Multi-vendor | Setup per vendor | Account per vendor | One funding source |
The protocol in 30 seconds
The core idea is simple enough to fit on an index card:
1. Agent pays a service -> sign a 110-byte message with the running total owed
2. Service verifies -> check the Ed25519 signature locally (microseconds)
3. Service collects later -> submit the latest message on-chain, get paid the delta
That's the entire protocol. Three operations. Everything else — spending limits, multi-vendor, pre-funded accounts, freeze controls — falls out of this design naturally.
Why this works: each payment authorization carries a cumulative total, not an individual amount. So the service only ever needs the latest one. Lost messages don't matter. Old messages can't be replayed for more money. And settlement is always one transaction, regardless of how many payments were made.
Why builders should care: the protocol is 110 bytes of Ed25519. No smart contract calls per payment. No state channels. No channel setup or teardown. Any chain that can verify Ed25519 signatures can implement SPX — the reference implementation is a Solana Anchor program, but the protocol itself is chain-agnostic.
The entire voucher format:
SPX_VOUCHER_V1 (14B) | funding_source (32B) | session (8B)
| service (32B) | amount (8B) | cumulative (8B) | nonce (8B)
Read the full protocol design or jump straight to the voucher spec.
Next steps
- Use with agents — fund your agent and start paying for services
- Accept agent payments — add payments to your API in 5 lines
- How the protocol works — the full design, for builders
- Voucher spec — the 110-byte format that makes it all work