CLI › Receipts

Receipts & Verification

Every ATF decision produces a receipt with a deterministic content hash. Verify receipt integrity locally without trusting the server.

Verify a Receipt

The CLI recomputes the content hash from the receipt fields using the same canonical serialization the server used. If the hashes match, integrity is confirmed.

Verify last receipt

npx @trucore/atf@1.5.1 receipts verify --receipt last

Verify specific receipt

npx @trucore/atf@1.5.1 receipts verify --id req_1234567890

Verify from JSON file

npx @trucore/atf@1.5.1 receipts verify --file ./receipt.json

Verification Output

Receipt: req_1234567890
Decision: ALLOWED
Content hash (server):  0xabc123...
Content hash (local):   0xabc123...
Status: ✔ Integrity verified

The local hash matches the server hash.
No client secrets involved. Anyone can reproduce this check.

How Deterministic Verification Works

The receipt payload is serialized in a deterministic, canonical order. Given the same fields, any tool that follows the same encoding will produce the same hash.

When you run receipts verify, the CLI takes the response fields, sorts them canonically, serializes them, and hashes the result. It then compares that hash to the content_hash the server returned.

No secrets, no tokens, no server-side nonces you cannot observe. The receipt is self-contained and fully auditable.

For the full specification of the hash rules, see the Verification reference.

List Receipts

View locally cached receipts from previous simulations.

List receipts

npx @trucore/atf@1.5.1 receipts list

ID                 Decision   Verified   Timestamp
req_1234567890     ALLOWED    ✔          2026-02-27T18:42:11Z
req_0987654321     BLOCKED    ✔          2026-02-27T18:40:05Z
req_5555555555     ALLOWED    ✔          2026-02-27T18:38:22Z

Local Verify Gate

In production, you can use receipt verification as a gate before execution. Only execute transactions where the local hash matches and the decision is ALLOWED.

This gives you a trustless check that the policy engine behaved correctly, without relying on server-side assertions alone.

How the verify gate works in practice:

Your agent or script calls simulate --verify.
The CLI receives the policy decision and receipt from the ATF API.
The CLI recomputes the content hash locally from the receipt fields.
If the local hash matches the server hash and the decision is ALLOWED, the gate passes.
Only then does your script proceed to sign and send.

If verification fails or the decision is BLOCKED, your script should halt. No transaction is sent.

Simulate with verify gate

npx @trucore/atf@1.5.1 simulate --preset swap_small --verify && npx @trucore/atf@1.5.1 tx send --receipt last

Receipt Fields Reference

Every receipt contains these fields. The content hash is computed from the canonical serialization of all non-metadata fields.

Field	Description
request_id	Unique identifier for this simulation request.
decision	ALLOWED or BLOCKED. The deterministic policy outcome.
content_hash	Deterministic hash of the canonical response payload.
timestamp	ISO-8601 UTC timestamp when the decision was issued.
ok	Boolean. True when the request completed without errors.
verified	Boolean. True when the CLI confirmed receipt integrity locally.

For a walkthrough of the full simulate, verify, and execute workflow, see the Simulate, Verify, Execute guide →

Flags

Flag	Description
--receipt last	Verify the most recent receipt.
--id <request_id>	Verify a specific receipt by request ID.
--file <path>	Verify a receipt from a JSON file.
--json	Output results as JSON.