sha256:b1f97888e86de0…3645e52
A receipt that stands on its own.
Turn an agent delivery into a signed, reproducible record. The checks are published, so you can rerun them in the browser or on your own machine, confirm the signature, and place the delivery in time without asking the provider.
The same receipt at three evidence levels.
An agreement chooses the level it needs. The format stays the same. The level sets what the receipt can prove without asking anyone to trust the provider.
Signature
The verifier reruns the checks and signs the result. Fast, private, and free.
OfflineTwo-party
Customer and provider sign the agreement. The provider attests the output and its time.
OfflineAnchored
Three ordered memos on Solana fix the sequence and make the delivery clock public.
On-chainCheck a receipt in the open.
Run the published mainnet proof, or verify a receipt you were given. Every hash is recomputed and, at L3, the memos are read from Solana. The endpoint does not write the receipt to a database.
A pinned example delivery anchored on Solana mainnet on 2 November 2026. The anchor is real. The product data is a test fixture, included so the check can be rerun byte for byte.
Fetches the pinned artifacts from this site and reads the anchor transactions from mainnet.
Upload the receipt and agreement as JSON, and the delivered file exactly as it arrived.
Files are sent only for this request. No account, wallet, or payment.
Choose an input and run the checks. The result lists every step, the core hash, and any anchor slots.
The format is small on purpose.
The reference implementation is one way to do it, not the definition. Anything that produces the same hashes from the same public data conforms.
Issue
Sign a delivery locally with a key you control. The report stays with you.
node aas2.js verify \
--agreement … --output … \
--key verifier.pem
Read the spec
Verify
One stateless endpoint. Send a receipt, an agreement, and the delivered bytes.
POST /api/aas2-verify
{ receipt, agreement,
output, cluster }
Verify independently
Identify
Every receipt carries the signing key. The published registry names it and states its status.
GET /.well-known/
equxi-verifier.json
Run a real delivery
What a receipt proves.
AAS-2 is deliberately narrow. It proves that a delivery matches an agreement, not that the content is true.
Proven
- The delivered bytes match the format and rules the agreement named.
- The receipt was signed by the key it carries, under the receipt domain.
- At L3, the three memos exist in order on Solana and the clock is public.
Not proven
- That the content is accurate or useful.
- That a failed check is a legal breach.
- That the verifier itself is honest. v0.1 trusts the signing key, and the registry makes it identifiable.
Draft 0.1. The version stays 0.x until an implementation written by someone else reproduces the pinned hashes, a verifier key rotation has been exercised, and the governance review is complete. The pinned fixtures are the contract.