Receipt Specification v1

• Version: v1
• Stability: Production-compatible
• Determinism guarantee: Same input and policy context MUST produce the same decision and receipt hash.

A receipt is a deterministic, tamper-evident record of a policy evaluation outcome for a financial action request.

• This specification defines what a receipt is.
• This specification defines what a receipt proves.
• This specification defines what a receipt does not prove.

The canonical JSON structure below is normative for Receipt Specification v1.

01{
02  "version": "v1",
03  "timestamp": "ISO-8601",
04  "request": {
05    "action": "string",
06    "token_in": "string",
07    "token_out": "string",
08    "amount": "number",
09    "max_slippage_bps": "number",
10    "ttl_seconds": "number"
11  },
12  "result": {
13    "status": "allowed | denied",
14    "reason": "string",
15    "invariant_checks": ["string"],
16    "receipt_hash": "hex-encoded SHA-256"
17  }
18}

• Implementations MUST produce deterministic outputs for equivalent normalized inputs.
• Implementations MUST NOT introduce randomness into receipt-relevant output fields.
• Implementations MUST NOT mutate receipt-relevant fields based on wall-clock timing.
• Equivalent input MUST produce equivalent decision and equivalent receipt hash.

• The receipt hash MUST be SHA-256 over canonical serialized JSON receipt data.
• The receipt hash MUST be hex-encoded, 64 characters, and lowercase.
• Any mutation of canonical receipt data MUST change the receipt hash, providing tamper evidence.

• The receipt version field is REQUIRED for explicit v1 receipts.
• Missing version MUST be treated as legacy v1 for backward compatibility.
• Unknown version MUST return supported_version=false in verification responses.
• Supported versions for this deployment: v1.

• Ed25519 signatures MAY be produced over the receipt hash.
• Signature encoding SHOULD be base64 for transport interoperability.
• Signatures are outside the core receipt object in this version contract.

• Receipt hash anchoring to external systems MAY be implemented as an out-of-band proof.
• Anchoring MUST NOT modify the core receipt structure defined in this document.

• Deterministic hashing provides reproducible integrity checks.
• Receipt hashes provide tamper evidence for stored and transmitted receipt payloads.
• The ATF receipt system does not custody funds.
• The ATF receipt system does not sign transactions for execution.

• Integration Pattern
• Verify Receipt Utility