Why it flows through every part
Each reference is"sha256:" + SHA-256(JCS(...)) over the part before it. mandate_ref
embeds passport_ref, policy_bound_ref embeds mandate_ref, decision_ref embeds
policy_bound_ref, and execution_ref embeds both decision_ref and the settlement
itself. A later reference cannot exist unless every earlier part is real and unchanged,
so recomputing the chain is the proof that the settlement passed through each stage in
order, with none skipped or altered.
decision_ref — was it authorised (signed)
The Spend Guardrail verdict, ALLOW, Ed25519 signed and timestamped before the
payment. Embeds
policy_bound_ref.settlement — the money moves
A real USDC transfer to the merchant on a public chain. The gateway’s own
facilitator re-checks it on-chain and returns verified = true.
execution_ref — decision bound to the tx
Binds the signed decision to the exact settlement. Embeds
decision_ref and the
transaction.Seven live settlements
Every row is a real testnet transfer, settled and verified by the AlgoVoi rails. On Algorand, Stellar and Solana the decision reference is carried on-chain, in the note, memo and reference respectively.| Chain | Asset | Transaction | Decision on-chain |
|---|---|---|---|
| Base Sepolia | USDC | 0x7ae7b275…ac6acb | signed decision |
| Arc testnet | USDC (native) | 0x9a75bc27…858e06 | signed decision |
| Tempo testnet | PathUSD | 0x9156044b…5c7d29 | signed decision |
| Algorand testnet | USDC | SEHZ2FUC…LE3Q | in the tx note |
| Stellar testnet | USDC | f11afe33…7bd7f17 | in the tx memo |
| Solana devnet | USDC | 7W5s2Rrz…NhvBS | as the reference |
| Hedera testnet | HBAR (native) | 0.0.7314364…988662 | signed decision |
Four protocols, one receipt
An agent can ask to pay in more than one way. x402, MPP, AP2 and A2A are four agent-payment protocols, each with its own authorisation form. The Keystone sits above all of them: whichever protocol carried the request, the settlement is recorded once, in one shared format, so the four converge on a single settlement reference. We composed and signed the four authorisation chains, then settled one real USDC transfer of 1 USDC through the AlgoVoi rails on Base Sepolia (0x21ce033f…f603e7b, block 43,628,975). Each decision was signed before the settlement block, and the rails re-checked the transfer on-chain and returned verified = true. All four chains share one agentpassport_ref
(sha256:b536bd6d83…b7193d) and bind to one
settlement_ref (sha256:71ae1e76f6…d6279d). Above the settlement, each protocol
keeps a distinct authorisation chain, so the mandate_ref and the final
trust_query_ref differ per protocol.
| Protocol | Authorisation form | mandate_ref | trust_query_ref |
|---|---|---|---|
| x402 | PaymentRequirements | sha256:36423bf4bd…2f303a | 5696b2e75a…b260e0 |
| MPP | payment context | sha256:de7a3c1d5c…f1f6bb | fdf5b51131…a9dc22 |
| AP2 | IntentMandate to CartMandate to PaymentMandate | sha256:e15d82171f…daab0d | f020643919…ddc884 |
| A2A | agent card task with payment request | sha256:5a5b09c830…34ee6d | 4860542db0…e5465e |
Proof pack (JSON)
Download it: every object, reference, signature, the settlement attestation, the
transaction and its on-chain verification. Then run the verifier below against it.
verify_4proto.py, then run it against the pack:
verify_4proto.py — the independent verifier (SHA-256, RFC 8785, Ed25519 only)
verify_4proto.py — the independent verifier (SHA-256, RFC 8785, Ed25519 only)
Two-way binding: why it cannot be faked
A transaction on an explorer proves money moved. It does not, by itself, prove the payment went through the Keystone. The binding runs both directions:- Keystone to transaction.
execution_refis a hash over the signed decision plus the settlement, so the chain commits to that exact transaction. Recompute it and it matches. - Transaction to Keystone. The decision is Ed25519 signed and its timestamp precedes the settlement block, and the on-chain amount, asset, and recipient match the signed decision. So the transaction cannot be re-bound to any other decision, and the decision provably existed before the money moved.
Verify it yourself
Every check is offline and deterministic. It needs only SHA-256, JSON Canonicalisation (RFC 8785), and the public chain.- Recompute each reference:
ref == "sha256:" + SHA-256(JCS(object)). - Verify the decision signature against the published authority key, and confirm it covers the exact decision object.
- Recompute
execution_refand confirm it contains the transaction id. - Re-scan the transaction on the public chain and confirm the USDC transfer to the merchant for the decided amount.
- Confirm the decision timestamp precedes the settlement block.