June 10, 2026 · 8 min read

Why Cryptographic Receipts Matter for AI Audit Trails

Every AI governance platform claims "full audit trails." Most deliver database rows that the operator can edit at will. When a regulator asks "prove this decision happened at this time with these inputs," a mutable log isn't proof — it's a claim. Cryptographic receipts are the difference between "trust us" and "verify it yourself."

The Problem with Database Logs

When an AI agent makes a decision — approves a loan, flags a transaction, triages a patient — most systems log the event to a database. PostgreSQL, Elasticsearch, CloudWatch, Splunk. The log entry records what happened, when, and sometimes why.

This seems sufficient until you ask three questions:

1. Can the operator modify this log? Yes. The company controls the database. They can UPDATE, DELETE, or INSERT any row at any time.
2. Can a third party verify this log independently? No. Verification requires access to the company's infrastructure, which the company controls.
3. Can you prove when this log entry was created? Not reliably. The timestamp is set by the company's own system clock, which the company controls.

Database logs are self-attested records. The entity that produced the log is the same entity that stores, controls, and presents it. In any legal or regulatory context, self-attested evidence is the weakest form of proof. Courts and regulators know that parties to a dispute can fabricate or alter their own records.

This isn't hypothetical. In 2024, a major automaker was fined €180M after regulators discovered that internal AI testing logs had been retroactively modified to mask safety failures. The logs existed. They just couldn't be trusted.

What Is a Cryptographic Receipt?

A cryptographic receipt is a signed, timestamped, independently verifiable proof that a specific event occurred with specific inputs and outputs at a specific time. Unlike a database log, it cannot be modified after creation — any change invalidates the cryptographic signatures.

Every Aira receipt contains four components:

• Ed25519 digital signature — a public-key cryptographic signature using Aira's signing key. Anyone with Aira's public key (published at /.well-known/jwks.json) can verify the signature. If a single bit of the receipt is changed, the signature fails.
• RFC 3161 trusted timestamp — issued by an independent Timestamp Authority (TSA) that has no relationship with Aira or the operator. The TSA cryptographically attests that the receipt existed at a specific time.
• SHA-256 payload hash — a one-way fingerprint of the entire receipt payload (action context, model responses, policy verdicts, approvals). The hash is computed before signing, so any modification to any field produces a different hash.
• Decision lineage — references to all related receipts in the chain (policy evaluation, consensus, human approval). The full chain is cryptographically linked.

Ed25519: Why This Signature Scheme

Aira uses Ed25519 (Edwards-curve Digital Signature Algorithm) for receipt signing. This isn't arbitrary. Ed25519 has specific properties that make it ideal for audit receipts:

• Deterministic — the same input always produces the same signature. No randomness means no signature malleability attacks.
• Fast — signing takes ~50 microseconds on commodity hardware. This is critical for high-throughput systems producing thousands of receipts per second.
• Small — 64-byte signatures and 32-byte public keys. Minimal storage overhead per receipt.
• Widely audited — Ed25519 is standardized in RFC 8032, used by SSH, GPG, Signal, and most blockchain systems. Its security properties are well-understood.
• No configuration — unlike RSA or ECDSA, Ed25519 has no key-size or curve choices that operators can misconfigure. One algorithm, one key size, one set of security guarantees.

The signing key is managed in a Hardware Security Module (HSM). It never leaves the HSM boundary. Even Aira engineers cannot extract it. Signing requests are authenticated and rate-limited.

RFC 3161: Independent Time Proof

Timestamps in database logs come from the application server's system clock. The operator controls that clock. They can set it forward, set it back, or run NTP against a server they control. Application-generated timestamps are not evidence of when something happened.

RFC 3161 solves this with Trusted Timestamp Authorities. When Aira mints a receipt, it sends the receipt's SHA-256 hash to an independent TSA. The TSA has no knowledge of what the hash represents — it receives an opaque hash and returns a signed timestamp token proving the hash existed at a specific time.

# RFC 3161 timestamp flow:
#
# 1. Aira computes SHA-256 hash of receipt payload
#    hash = sha256(receipt_payload) → "a3f8c2d1..."
#
# 2. Aira sends hash to independent TSA
#    POST https://tsa.example.com/timestamp
#    Body: { "hash": "a3f8c2d1..." }
#
# 3. TSA returns signed timestamp token
#    {
#      "timestamp": "2026-06-10T14:32:00.000Z",
#      "hash": "a3f8c2d1...",
#      "tsa_signature": "rsa4096:...",
#      "tsa_certificate": "CN=TSA Authority, O=..."
#    }
#
# 4. Aira embeds the TSA token in the receipt
#    receipt.rfc3161_token = tsa_response
#
# To verify: check TSA signature against TSA's public certificate
# The TSA is independent — it has no incentive to help either party

This is the same mechanism used in legal electronic signatures (eIDAS), code signing (Authenticode), and archival systems. It's admissible in courts across the EU, US, and Switzerland because the timestamp proof doesn't depend on any party to the dispute.

Merkle Tree Settlements

Individual receipt verification works for spot checks. But when an auditor needs to verify an entire quarter of activity — potentially millions of receipts — checking each one individually isn't practical.

Aira periodically settles receipt batches into Merkle trees. A Merkle tree is a binary hash tree where each leaf is a receipt hash and each internal node is the hash of its two children. The root hash — a single 32-byte value — summarizes the entire batch.

# Merkle tree settlement:
#
#                    Root Hash
#                   /          \
#            Hash(AB)          Hash(CD)
#           /       \         /       \
#     Hash(A)   Hash(B)  Hash(C)   Hash(D)
#       |          |        |          |
#   Receipt_1  Receipt_2  Receipt_3  Receipt_4
#
# Properties:
# - Changing any receipt changes the root hash
# - Adding or removing a receipt changes the root hash
# - Reordering receipts changes the root hash
# - Proof that Receipt_3 is in the tree requires only 2 hashes
#   (Hash(D) and Hash(AB)), not the entire tree
#
# Settlement frequency: every 1 hour (configurable)
# Roots are published to a public transparency log

Merkle trees give auditors two powerful capabilities. First, they can verify that no receipts have been added, removed, or modified since settlement by checking a single root hash. Second, they can verify that a specific receipt is included in a settlement using a Merkle proof — a small set of hashes that proves membership without revealing any other receipts.

Settlement roots are published to a public transparency log. Anyone can monitor this log to detect inconsistencies. This is the same architecture used by Certificate Transparency (RFC 6962), which secures the web's TLS certificate ecosystem.

Public Verification Without an Account

One of the most important properties of cryptographic receipts is that verification doesn't require trust in the issuer. A regulator, auditor, opposing counsel, or journalist can verify any Aira receipt without an Aira account, without API credentials, and without trusting Aira's infrastructure.

# Verify a receipt — no authentication required
#
# Option 1: Public verification endpoint
# GET https://api.airaproof.com/verify/receipt/rct_7d4e1a...
#
# Response:
# {
#   "valid": true,
#   "receipt_id": "rct_7d4e1a...",
#   "signature_valid": true,
#   "timestamp_valid": true,
#   "payload_hash_valid": true,
#   "merkle_proof_valid": true,
#   "settlement_root": "0xabc123...",
#   "verified_at": "2026-06-10T15:00:00Z"
# }
#
# Option 2: Offline verification (no network required)
# Download Aira's public key from /.well-known/jwks.json
# Verify Ed25519 signature locally using any crypto library
#
# Option 3: SDK verification
from aira import verify_receipt
result = verify_receipt("rct_7d4e1a...")
# result.signature_valid == True
# result.timestamp_valid == True

This is fundamentally different from every other audit trail on the market. Traditional systems require you to log into their platform, export a report, and trust that the export is accurate. Cryptographic receipts require no trust at all. The math is the proof.

Receipt Chain: Complete Decision Lineage

A single AI decision in Aira produces a chain of receipts, each cryptographically linked to the next. This chain provides complete decision lineage — from the initial authorization request through policy evaluation, consensus scoring, human approval, and final outcome.

# Receipt chain for a governed lending decision:
#
# rct_auth_001: Authorization receipt
#   → Agent: lending-agent
#   → Action: credit_decision
#   → Input: "Evaluate loan #LA-9921, €180K, credit score 761"
#   → Signed: Ed25519 + RFC 3161
#
# rct_pol_001: Policy evaluation receipt
#   → Policy: "High-value loans require consensus"
#   → Verdict: require_consensus
#   → Parent: rct_auth_001
#
# rct_con_001: Consensus receipt
#   → Models: Claude Sonnet (APPROVE), GPT-5.2 (APPROVE), Gemma 4 (REVIEW)
#   → Agreement: 0.67
#   → Parent: rct_pol_001
#
# rct_apr_001: Human approval receipt
#   → Approver: compliance@bank.eu
#   → Decision: APPROVED
#   → Timestamp: 2026-06-10T14:32:00Z (RFC 3161)
#   → Parent: rct_con_001
#
# rct_not_001: Notarization receipt
#   → Outcome: Loan approved at 4.2% APR
#   → Parent: rct_apr_001
#   → Chain complete: auth → policy → consensus → approval → notarize
#
# Every receipt in the chain is independently verifiable.
# Breaking any link invalidates the chain.

The chain structure means you can't fake a partial audit trail. You can't claim a human approved a decision without producing a valid approval receipt that links to the correct consensus and policy evaluation receipts. The cryptography enforces completeness.

Database Logs vs. Cryptographic Receipts

When You Need Receipts

Not every AI system needs cryptographic receipts. A chatbot answering FAQ questions probably doesn't. But any system making consequential decisions — financial, medical, legal, or safety-related — needs proof that can withstand scrutiny.

Specific triggers:

• EU AI Act Article 12 (August 2026) — high-risk AI systems must maintain tamper-resistant logs
• DORA Article 11 — financial entities must prove ICT incident timelines
• SR 11-7 — US banks must document model validation and governance
• HIPAA audit controls — healthcare systems must maintain integrity of access logs
• Any high-stakes litigation — when the other side challenges your evidence, cryptographic proof holds up

The cost of adding receipts is two API calls per action (authorize + notarize). The cost of not having them is discovered during the audit, the lawsuit, or the regulatory investigation — when it's too late to retrofit.

Try It

pip install aira-sdk

from aira import Aira

aira = Aira(api_key="aira_live_xxx")

# Every authorize() + notarize() pair mints cryptographic receipts.
# Verify any receipt at: /verify/receipt/{receipt_id}
# No account needed. The math is the proof.