MINIMALCULTTwo things make work between agents trustworthy without a company in the middle: a way to pay that needs no account, and a record of what happened that nobody can rewrite afterwards. At MINIMAL AI these are GRAM-402 and RECEIPTS. Both are open specifications with reference code under MIT; this post walks through them in the order an agent meets them.
One request, one transfer
An agent calls a paid endpoint with no key. The server answers 402 Payment Required in the HTTP shape of
x402 (accepts, X-PAYMENT, X-PAYMENT-RESPONSE) with a TON-native scheme, ton-transfer:
the wallet to pay, the upper bound of the price in nano-GRAM, an invoice id, a secret returned only to this caller, the
exact text comment to put on the transfer, and an expiry. The agent sends a plain wallet transfer with that comment —
any TON wallet can do it, there is no custom contract and no facilitator — and repeats the request with X-PAYMENT
carrying the invoice and the secret. The server finds the transfer on chain, checks the comment, the amount and the
secret, makes sure the transaction has not settled anything before, and answers.
Some details are there because of what went wrong once. The comment is public on chain, so the invoice id alone never
settles: the secret is required, which stops anyone watching the chain from claiming the answer. A transaction settles at
most one invoice, and settlement is idempotent — a lost response or two retrying workers get the first settlement back,
nothing is credited twice. A wallet that deducts the network fee from the value arrives short; the short amount is not
lost, it becomes credit on an account bound to the payer's wallet, and the answer says underpaid with the key to that
credit. Before paying, the agent can read failureTerms: what happens on expiry, underpayment, overpayment, a request that
fails after payment, a retried payment, or the AI being unavailable — and the settlement repeats the SHA-256 of those terms.
The answer carries its receipt
Every answer comes with a record signed by the server's Ed25519 key (published at /.well-known/minimalai.json): the
SHA-256 of the request, the SHA-256 of the response, the model, the route, the time, and for a GRAM-402 request the payment
itself — network, transaction, payer, amount charged. One signature binds the on-chain transfer, the request and the
answer. The record is canonical JSON; its id is the SHA-256 of the record without the signature, so the id is unique per
signed content, and each record links to the previous one by hash. On the Cocoon mainnet the receipt also carries the
attestation evidence of the hardware that computed the answer.
A receipt says what the server saw and signed. It does not say the answer was good: that is what disputes and the
VERIFY service are for, and why the second version of the format carries a
delivery block (executed, delivered, maybe sent, failed, with an acknowledgement from the other side when there is one)
and a distrust block that states what was observed and what was assumed.
Anyone can check it
Paste a record at ai.minimalcult.org/check or run the verifier from the open core offline: it recomputes the canonical form, checks the signature against the published key and the chain link. Once a day the heads of all public chains — receipts, verdicts, disputes, the notary — are folded into one Merkle root, and that root is anchored in four systems that do not depend on us or on each other: OpenTimestamps (Bitcoin), the Ethereum Attestation Service on Base, an RFC 3161 timestamp authority, and the Sigstore Rekor transparency log. The batches and their proofs, with a verification recipe for each, are at /v1/anchors; the live numbers are on the trust index. Rewriting a receipt afterwards would mean breaking several networks at once.