How the protocol works

SPX has three primitives: a funding source, a payment authorization, and a settlement. Everything else — spending limits, multi-vendor support, pre-funded accounts, freeze controls — emerges from these three things.

The three primitives

Funding source

A pre-funded on-chain account. You deposit tokens, set a spending limit, and assign a payment key to your agent. The agent can authorize payments against this balance but can never withdraw. You can freeze it, top it up, or close it at any time.

One funding source serves every service your agent uses. No per-vendor setup.

Payment authorization

A 110-byte Ed25519-signed message. Your agent creates one per API call. It says: "I authorize a cumulative total of $X to this service."

The key word is cumulative. Each authorization supersedes the previous one. The service only needs the latest.

Settlement

When a service is ready to collect, it submits the latest authorization on-chain. The protocol verifies the signature, computes the difference between what's owed and what's already been collected, and transfers the funds. One transaction, regardless of how many payments were made.

The cumulative model

This is the core insight. Payment authorizations don't represent individual payments — they represent the running total owed to a specific service.

Call 1: agent pays $1    ->  authorization(cumulative: $1,  nonce: 1)
Call 2: agent pays $2    ->  authorization(cumulative: $3,  nonce: 2)
Call 3: agent pays $3    ->  authorization(cumulative: $6,  nonce: 3)
Call 4: agent pays $0.50 ->  authorization(cumulative: $6.50, nonce: 4)

The service only needs authorization #4 to collect $6.50. Lost authorizations don't matter — they're superseded. Old authorizations can't extract more than the latest total. The service can collect at any time — after every call, once an hour, once a day.

If the service already collected $3 from an earlier authorization, the next collection pays the delta: $6.50 - $3 = $3.50.

Why this matters: it decouples the rate of payments from the rate of settlement. Your agent can make 1,000 payments per second. The service settles once per day. The cost is always one transaction.

The full flow

SETUP (once)
  Owner  ->  create funding source, deposit $500 USDC
  Owner  ->  assign agent payment key

PAYMENTS (off-chain, free, under 1ms each)
  Agent  ->  Service A   authorize(cum: $2,    nonce: 1)
  Agent  ->  Service B   authorize(cum: $0.50, nonce: 1)
  Agent  ->  Service A   authorize(cum: $4,    nonce: 2)
  Agent  ->  Service C   authorize(cum: $1,    nonce: 1)
  ...1,847 more payments...
  Agent  ->  Service A   authorize(cum: $150,  nonce: 923)
  Agent  ->  Service B   authorize(cum: $89,   nonce: 612)
  Agent  ->  Service C   authorize(cum: $41,   nonce: 312)

COLLECTION (on-chain, 1 tx each, whenever)
  Service A  ->  collect($150)
  Service B  ->  collect($89)
  Service C  ->  collect($41)

  1,847 payments  ->  3 transactions  |  $0.00075 total cost

Each service collects independently, on their own schedule. No coordination between services or with the agent.

The funding model

SPX separates the payment protocol from the funding source. The authorization format and collection logic are fixed. The funding source is pluggable.

Any on-chain account that can:

Hold tokens
Verify an Ed25519 signature
Track how much each service has collected
Transfer the delta on valid authorization

...is a valid SPX funding source. This means the protocol works with:

The SPX reference program (purpose-built, simplest path)
Multisig vaults (require multiple approvers to fund)
DAO treasuries (governance-controlled spending)
Custom logic with approval flows, time-locks, or spending tiers

The authorization format doesn't change. The collection process doesn't change. Only the funding source is swappable.

Why builders should care

The entire payment protocol is a 110-byte Ed25519 message and a signature check. That's it.

No smart contract calls per payment. The agent signs locally. The service verifies locally. The blockchain is only touched at collection time.

No state channels. No channel open/close. No locked funds per vendor. No both-parties-online requirement.

No coordinator. Services collect independently. No sequencer, no relayer, no batch processor required (though you can add one for convenience).

Chain-agnostic. The protocol works on any chain that supports Ed25519 verification. The reference implementation is Solana, but the design is portable.

Extensible. The funding source is a pluggable component. You can implement custom spending policies, approval flows, multi-party authorization, or time-locked budgets — all without changing the payment protocol.

Security properties

Pre-funded — the money is on-chain before the agent makes a single payment. Services can verify the funding source has balance before doing work. (Note: funds are not locked per-authorization — services should collect frequently.)
Cumulative = replay-safe — replaying an old authorization can't extract more than the latest total.
Nonce = order-safe — each authorization has a strictly increasing nonce. Old ones are rejected.
Append-only = tamper-proof — deposited, collected, and withdrawn amounts only increase. No arithmetic tricks.
Separation of keys — the agent key authorizes payments. Only the owner key can withdraw. Compromised agent key = freeze + rotate, not loss of funds.

Full threat model and audit findings: Security model

Next: Voucher spec

← Add payments to your API Voucher spec →