Sancus

we built a small paid api and gave an ai agent one payment. then we sent the same request one hundred times at once.

the server said yes. the agent received one hundred answers. the blockchain confirmed one payment.

this was a controlled simulation on our own testnet, with our own wallets, our own facilitator, and no third-party money. the point was to reproduce a failure that most people never see: a payment can look valid before it is actually settled.

the x402 security research paper found the same class of problem across real facilitator deployments. fifteen facilitators. forty-nine rule violations. thirty-one previously unknown vulnerabilities. not a broken chain. a broken handoff.

we tried the other doors too. replay the same signature. make a payment expire between checking and execution. submit a transaction that can never succeed. change where the signed request is supposed to go. each time, the lesson was the same: valid is not paid.

that is why sancus exists. it adds a hard stop between "payment verified" and "service delivered". the intent is locked. the settlement is bound to that intent. the on-chain call is limited. the receipt proves what happened.

the next generation of ai agents will not wait for a human to click checkout. they will buy data, compute, tools, and access millions of times a day. when that happens, a small gap in payment logic becomes a very large problem.

the payment model

sancus treats every payment as a signed intent, not just a number in a request. the intent names the payer, recipient, asset, amount, api request, nonce, expiry, and maximum sponsored cost.

# the payment lifecycle 1. authorize client signs the complete payment intent 2. verify facilitator checks every bound field and freshness 3. ticket facilitator returns a short-lived settlement proof 4. settle exact transaction is simulated, bounded, and confirmed 5. deliver server releases the response with a signed receipt

the gap we measured

the x402 security paper examined the handoff between verification and settlement. fifteen facilitators were tested. forty-nine rule violations became thirty-one previously unknown vulnerabilities.

we built our own testnet lab to reproduce the same conditions: our own client, api, wallets, and facilitator. one signature was replayed. one service was released before finality. one failed call still consumed sponsor-paid gas. the experiments were isolated and reproducible.

attack surface

# controlled reproduction cases free shopping service returned before payment settled replay race same authorization accepted concurrently gas abuse attacker forces failed or expensive submissions asset theft execution redirects funds from the sponsor service denial payment completes but delivery fails state drift proof expires between check and execution

the facilitator

the facilitator is the trust-bearing component. it translates a web request into a blockchain action and often pays the fee. sancus gives it a narrow job: verify a bound intent, execute an allow-listed transaction, and return evidence that can be checked later.

no arbitrary calldata. no unbounded gas. no silent recipient changes. no success response before the chain says success.

the receipt

a payment response is not the same thing as proof of delivery. sancus receipts bind the settlement transaction to the resource request and the response hash. the client can verify what was paid for, what was delivered, and which server signed the result.

# receipt shape { "intentHash": "...", "transaction": "0x...", "resourceHash": "...", "deliveredAt": "...", "signature": "..." }

run the simulation

the research harness runs locally or against a testnet. it sends valid and deliberately malformed payloads, records the facilitator response, and compares the result with the chain receipt. the goal is not to claim a breach. the goal is to make the failure visible before real money is involved.

# coming soon git clone https://github.com/sancuslabs/Sancus cd sancus && npm install npm run testnet:lab

roadmap

v0.1 public specification, threat model, and reproduction notes.
next reference facilitator with settlement tickets and gas limits.
then delivery receipts and TypeScript / Python SDKs.
after multi-chain profiles and independent security review.

faq

is sancus a new blockchain. no. it is a security layer compatible with x402 and existing networks.
did we attack a real platform. no. reproduction uses infrastructure and testnet accounts we control.
what does the paper prove. it documents real deployment risks; our lab turns those risks into repeatable tests.
is the token live. yes. verify the official contract address shown above before interacting.
can i inspect the work. yes. the specification, traces, and test vectors are intended to be public.

principles

verified is not settled.
settled is not delivered.
proof must bind the whole event.
execution must be bounded before it is sponsored.
experiments belong on testnet first.
security claims require evidence.

one payment. one hundred answers.