Skip to content
TruCore logoTruCore

Trust & Verification

Receipts & Trust

Every ATF decision - allow or deny - produces a tamper-evident receipt. Receipts are the proof layer that makes autonomous agent trading auditable.

What is a Receipt?

A receipt is a deterministic, content-hashed record of an ATF policy decision. When your bot submits a swap intent, ATF evaluates it against configured policies and returns a receipt capturing exactly what was decided and why.

Decision Receipt

Issued on every protect call. Contains the decision (approved/denied), reason codes, a content_hash, and metadata about the intent.

json

{
  "decision": "approved",
  "reasons": [],
  "content_hash": "a1b2c3d4e5f6...64-char-hex-string",
  "hash_version": "1",
  "timestamp_utc": "2026-03-21T00:00:00+00:00",
  "chain_id": "solana",
  "intent_type": "swap"
}

Execution Receipt

Issued when an approved trade is finalized on-chain. Links the ATF decision to the on-chain transaction signature and records the execution outcome.

json

{
  "receipt_id": "rcpt_a1b2c3d4e5f6",
  "intent_id": "aud_x9y8z7w6",
  "tx_signature": "5KtV2f3...on-chain-sig",
  "classification": "swap",
  "decision": "approved",
  "output_amount": 142.37,
  "execution_status": "confirmed",
  "timestamp": 1742544000.0,
  "receipt_hash": "e4f5a6b7c8d9...deterministic-hash"
}

Key Receipt Fields

FieldDescription
content_hashDeterministic SHA-256 hash of the canonical receipt payload. This is the primary verification value.
hash_versionSchema version for the hash algorithm. Currently "1".
decision"approved" or "denied" - the policy evaluation result.
reasonsMachine-readable reason codes explaining why the intent was denied (empty if approved).
receipt_hashDeterministic hash of the full execution receipt (only on finalized executions).
tx_signatureOn-chain transaction signature (only on finalized executions).

What Verification Proves

Verification proves:

  • The receipt was generated by ATF
  • The receipt content has not been modified since issuance
  • The decision matches the original policy evaluation
  • The hash is consistent with the canonical payload

Verification does not prove:

  • That the original policy was correct for your use case
  • That the on-chain transaction executed successfully (use tx_signature for that)
  • That the bot acted on the decision (the bot could ignore ATF)

How to Verify a Receipt

Via API

bash

curl -sS https://api.trucore.xyz/v1/receipts/verify \
  -H "Content-Type: application/json" \
  -d '{"content_hash": "a1b2c3d4e5f6...64-char-hex"}'

json

{
  "valid": true,
  "reason": "receipt_valid",
  "intent_hash_version": "1"
}

Via CLI

atf verify <receipt-id>

Exit code 0 = valid, 1 = invalid or error. The CLI recomputes the hash locally for additional assurance.

Via Web

Visit trucore.xyz/verify or the receipt URL (e.g., https://verify.trucore.xyz/tx/rcpt_...).

Mock vs Real Execution

Mock Execution

The onboarding flow runs in mock mode by default. Policies are evaluated, receipts are generated, but no on-chain transaction is sent. Mock receipts are fully verifiable - they use the same hashing algorithm as production receipts.

Mock receipts do not have a tx_signature field since no on-chain transaction occurred.

Real Execution

Connect a wallet via atf setup, and ATF evaluates real intents against live market data. Approved trades execute on-chain, and the finalization step links the ATF receipt to the on-chain transaction.

Real execution receipts include tx_signature, output_amount, and execution_status.

Why Receipts Matter for Agent Transactions

When AI agents or bots execute financial transactions autonomously, there is no human in the loop to verify each decision. Receipts provide:

  • Accountability - every decision has a verifiable record, even if the agent ran unsupervised for hours
  • Audit trails - link on-chain transactions back to the policy evaluation that approved them
  • Dispute resolution - if something goes wrong, receipts prove what ATF decided and why
  • Compliance - institutions can demonstrate that every agent trade passed policy controls

Request → Protect → Receipt Flow

┌─────────────┐     ┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   Bot /     │     │   ATF       │     │   Policy     │     │   Receipt   │
│   Agent     │────▶│   API       │────▶│   Evaluator  │────▶│   Store     │
└─────────────┘     └──────┬──────┘     └──────────────┘     └──────┬──────┘
      │                    │                                        │
      │  1. Submit intent  │                                        │
      │                    │  2. Evaluate policies                  │
      │                    │  3. Generate receipt                   │
      │◀───────────────────┤  4. Return decision + receipt          │
      │                    │                                        │
      │  5. If approved:   │                                        │
      │     sign & send tx │                                        │
      │                    │                                        │
      │  6. Finalize       │                                        │
      │───────────────────▶│  7. Link tx → receipt                  │
      │                    │──────────────────────────────────────▶  │
      │◀───────────────────┤  8. Return execution receipt           │
      │                    │                                        │
      │  9. Verify receipt │                                        │
      │───────────────────▶│  10. Validate content_hash             │
      │◀───────────────────┤  11. Return {valid: true}              │

Next Steps

Receipt Specification v1 →

Formal RFC-style receipt contract and hash rules.

Verification Guide →

Deep dive into content_hash, --verify, and production patterns.

First Protected Trade →

Hands-on guide to protecting and verifying your first swap.

Receipts Explorer →

Browse public receipt examples and verification artifacts.