Signed Receipts

Every request emits an ED25519-signed, hash-chained receipt — tamper-evident audit evidence for compliance.

Every request through the gateway produces a receipt: a canonical record of what happened — who called, which model, what it cost, and which policy checks ran — cryptographically signed and chained to the receipt before it. The result is an audit trail where tampering with any single record is detectable.

Observability tools can tell you what they observed. Because Wardin sits in the request path and signs what it enforced, a receipt is evidence, not telemetry.

What a receipt contains

Field	Description
request_id	Unique ID of the request
tenant_id	Your organization
actor	The user/key the request is attributed to
provider / model	Who served it and with what
prompt_tokens / completion_tokens	Token usage
cost_usd	Actual cost committed for the request
checks	Ordered list of policy decisions ({name, result}) — budget, allowlist, guardrails, PII
ts	Timestamp (RFC 3339, UTC, millisecond precision)

How the chain works

1. The receipt’s fields are serialized in a fixed canonical order.
2. this_hash = sha256(canonical_receipt || prev_hash) — each receipt’s hash incorporates the previous receipt’s hash.
3. this_hash is signed with the gateway’s ED25519 key.

Changing any field of any historical receipt changes its hash, which breaks every subsequent link in the chain. Verification re-derives the hashes from stored fields and checks the signature — nothing is taken on trust.

Chaining and signing happen in an asynchronous writer, off the response path. Receipts add zero latency to your LLM requests, and the chain only advances after the receipt is durably stored.

Where to see receipts

• INGRESS — click any request in the live stream to open its receipt drawer (with RECEIPT | TRACE tabs).
• EVIDENCE — chain statistics, a sample verified receipt, and the compliance-framework view.

Verifying programmatically

# List recent receipts (newest first, cursor pagination)
curl "https://api.wardin.ai/v1/receipts?limit=25" \
  -H "Authorization: Bearer wardin_sk_ADMIN_KEY"

# Fetch one receipt and verify its hash + ED25519 signature
curl "https://api.wardin.ai/v1/receipts/RECEIPT_UUID" \
  -H "Authorization: Bearer wardin_sk_ADMIN_KEY"
# → { ..., "verified": true }

# Verify a contiguous range of the chain — reports the first broken link, if any
curl "https://api.wardin.ai/v1/receipts/_/verify-chain?from=1&to=100" \
  -H "Authorization: Bearer wardin_sk_ADMIN_KEY"

verified: true means the stored hash equals sha256(canonical || prev_hash) and the ED25519 signature over that hash is valid. Receipts are tenant-scoped — you can only read your own.

Verify your first receipt

If you completed the in-product onboarding wizard, its last step already shows you your first receipt — this is how to confirm it yourself, and how to check any receipt afterward:

1. Open INGRESS and click the row for your first request (or any request) — the receipt drawer opens with RECEIPT | TRACE tabs.
2. The RECEIPT tab shows a VERIFIED ✓ or UNVERIFIED ✕ badge. VERIFIED means Wardin recomputed sha256(canonical || prev_hash) from the stored fields and confirmed the ED25519 signature over it matches — nothing is taken on trust.
3. To verify programmatically instead, fetch the same receipt by ID (see below) and check its verified field, or run verify-chain over a range that includes it.

Marking a receipt as reviewed in the wizard/checklist only records that you looked — the cryptographic verification behind the VERIFIED badge happens on every fetch, independent of who’s watching.

Why this matters for compliance

Frameworks like the EU AI Act and NIST AI RMF ask for evidence that governance controls actually ran — not a dashboard screenshot. A hash-chained, signed record of every enforcement decision (including blocks: over-budget 429s, allowlist 403s, guardrail rejections) is exactly that artifact, exportable and independently verifiable.