Security model
SPX handles real money. This page explains why the protocol is safe by design — and what the known tradeoffs are.
Why the design is safe
Funds are pre-deposited, not pre-locked
Your agent's funding source is funded on-chain before the agent makes any payments. When a service verifies a payment authorization, it can confirm the funding source exists and has a balance. However, funds are not locked per-authorization — the owner can withdraw unsettled funds. Services should collect frequently to minimize exposure.
Authorizations are cryptographically unforgeable
Each payment is an Ed25519-signed message. You can't fake one without the agent's private key. Services verify the signature locally — no RPC call, no blockchain check, microseconds.
The cumulative model prevents double-spending
Each authorization carries a running total. Settling an old authorization can never extract more than the latest total. The nonce increases monotonically — old authorizations are rejected.
authorization(cum: $5, nonce: 3) -- settles $5
authorization(cum: $3, nonce: 2) -- rejected: nonce too low
authorization(cum: $5, nonce: 3) -- rejected: already settled
authorization(cum: $8, nonce: 4) -- settles $3 (delta: $8 - $5)
Append-only counters prevent manipulation
Three values on the funding source only ever increase: deposited, settled, withdrawn. No combination of valid operations can make them decrease. The available balance is always deposited - settled - withdrawn.
Keys are separated by capability
| Key | Can do | Cannot do |
|---|---|---|
| Agent key | Authorize payments | Withdraw, freeze, close, rotate keys |
| Owner key | Withdraw, freeze, close, rotate agent key | Authorize payments |
| Operator key | Update protocol fee, treasury | Touch any funding source |
| Authority key | Rotate operator | Everything else |
If the agent key is compromised: freeze the funding source, rotate the key. Damage is limited to the remaining balance — and freeze is instant.
Session binding prevents cross-session replay
Each authorization includes the funding source's created_at timestamp. If a funding source is closed and re-created at the same address, old authorizations are invalid — the timestamp won't match.
Known tradeoffs
Owner can withdraw before services collect
The owner can withdraw deposited - settled - withdrawn at any time. The contract doesn't know what the agent has authorized off-chain — only what's been collected on-chain. This means the owner could withdraw funds that services are owed but haven't collected yet.
This is the primary counterparty risk in SPX. It's analogous to writing a check — the money was in the account when written, but could be withdrawn before the check clears.
Mitigations:
- Services should collect frequently — don't let uncollected balances grow large
- Services can monitor the funding source balance on-chain and stop serving if it drops too low
- Future protocol work may introduce committed reserves or withdrawal delays (see roadmap)
Fee changes affect pending settlements
The protocol operator can change the fee rate (capped at 10%). A pending settlement could be subject to a different fee than when the work was done.
Mitigation: hard cap of 1,000 basis points (10%) enforced on-chain. Fee changes are public events — services can monitor and adjust.
Off-chain authorizations are invisible on-chain
The blockchain doesn't know what the agent has authorized — only what services have collected. There's a gap between "authorized" and "collected" that represents money owed but not yet claimed.
Implication: the owner can't see exactly how much is committed vs free. The available balance may overstate what's actually spendable if services haven't collected yet.
Implementation status
The reference implementation (Solana Anchor program) has been through an internal security review. All critical and high issues have been fixed:
- Fee calculation uses u128 to prevent overflow
- Treasury account is validated against config
- Token mint is validated on funding source creation
- Agent key rotation invalidates old authorizations
- Fee rate is capped at 10% on-chain
A professional audit is planned before mainnet deployment. See the Solana program for implementation details.
Next: With x402 and MPP