Skip to main content
The Keystone is the agentic-payment trust chain: identity, authority, policy, decision, execution, and a single verdict, each a content-addressed reference bound to the one before it. This page shows that chain carried all the way through a real payment: composed, signed, bound to an actual USDC transfer on a public blockchain, and then verified from scratch by an independent checker. We ran it on seven public testnets through the AlgoVoi payment rails. Each settlement is a real on-chain transfer; each Keystone chain is checked by recomputing every reference, verifying the decision signature, and re-scanning the transaction on-chain. On Algorand, Stellar and Solana the keystone decision is written into the transaction itself, so it is visible directly on the block explorer. The Keystone proven over real on-chain settlements

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.
1

passport_ref — who is acting

The agent’s identity. Root of the chain.
2

mandate_ref — what it may spend

Spend authority. Embeds passport_ref.
3

policy_bound_ref — under which policy

The rules in force. Embeds mandate_ref.
4

decision_ref — was it authorised (signed)

The Spend Guardrail verdict, ALLOW, Ed25519 signed and timestamped before the payment. Embeds policy_bound_ref.
5

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.
6

execution_ref — decision bound to the tx

Binds the signed decision to the exact settlement. Embeds decision_ref and the transaction.
7

trust_query_ref — one verdict over the chain

A single reference over all seven parts.

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. Tempo settles in PathUSD and Hedera in native HBAR; the other five settle in USDC.

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 agent passport_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. Every object behind those references, along with the settlement attestation, the transaction and its on-chain verification, is published in the proof pack. An independent verifier that imports nothing from AlgoVoi and uses only SHA-256, RFC 8785 and Ed25519 re-derives every reference and checks every signature: 46 of 46 checks pass in a clean environment.

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.
Save the verifier as verify_4proto.py, then run it against the pack:

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_ref is 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.
  1. Recompute each reference: ref == "sha256:" + SHA-256(JCS(object)).
  2. Verify the decision signature against the published authority key, and confirm it covers the exact decision object.
  3. Recompute execution_ref and confirm it contains the transaction id.
  4. Re-scan the transaction on the public chain and confirm the USDC transfer to the merchant for the decided amount.
  5. Confirm the decision timestamp precedes the settlement block.
No trust in AlgoVoi is required. The chain is open and the two standards it rests on, SHA-256 and RFC 8785, are all you need.