Dashboard Explorer Docs AAS-2 GitHub
AAS-2 · Proof of delivery · 0.1

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.

Ed25519 SHA-256 Merkle root SPL Memo anchors MIT
The standard

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.

L1

Signature

The verifier reruns the checks and signs the result. Fast, private, and free.

Offline
L2

Two-party

Customer and provider sign the agreement. The provider attests the output and its time.

Offline
L3

Anchored

Three ordered memos on Solana fix the sequence and make the delivery clock public.

On-chain
Verification

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

receipt.jsonSigned L3 receipt
ready
agreement.signed.jsonCustomer and provider signatures
ready
output.product-feed.csv20 records, 4 failed records
ready
report.jsonPrivate detail, committed by hash
ready
Solana mainnet · three memos

Fetches the pinned artifacts from this site and reads the anchor transactions from mainnet.

No verification yet

Choose an input and run the checks. The result lists every step, the core hash, and any anchor slots.

For implementers

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
Scope

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.

AAS-2 · 0.1

Start with a proof you can check.