RAVENStoring Raven receipts
Raven produces signed receipts. The caller decides where to store them — local, database, object storage, decentralized, or agent memory. Raven does not require a storage provider, does not require Walrus or Harbor, and works fully without any storage at all.
Why store receipts?
A receipt is the audit trail for an agent action: it proves what Raven said, at which slot, under which engine version, before your agent traded, listed, recommended, or settled. Stored receipts also enable deterministic recall — "have I checked this mint before?" — without spending another verification.
What exactly to store
The full schema is machine-readable at /receipt-schema.json. Required core: the unmodified rawResponse plus mint, program, verdict, findingCodes, coverageGaps, observedSlot, engineVersion, keyId, replayHash, officialAttestationHash, signature, createdAt, source.
Raw receipt vs derived explanation
The raw receipt is truth; explanations are derived. Store derivedExplanation separately and never let it replace, edit, or summarize away the raw fields — especially coverageGaps. A policy decision (proceed/block/escalate) is also derived and must never upgrade the verdict.
Namespaces
Agents won't keep one giant history. Suggested formats: raven/{project}/{agent}/{environment} · raven/{customer}/{bot}/{chain} · raven/{mintAddress}/{engineVersion}. Full policy: /receipt-memory-policy.md.
Deterministic lookup
Recall by mintAddress, tokenProgramAddress, replayHash, observedSlot, engineVersion, keyId — never fuzzy semantic search over receipts. Check for a valid stored receipt before calling Raven again.
Optional backends
Adapter types (all documented-only, none implemented or required): /receipt-storage-adapters.json. Decentralized options including Walrus/Harbor are listed as optional FUTURE adapters — no production integration exists, and any live adapter with credentials must run server-to-server, never in a browser.
What Raven does not store by default
The hosted verifier keeps a sanitized Quality Ledger entry (verdict, mint, latency — never keys or caller context). Raven does not store your receipts for you; persistence is the caller's choice and responsibility.
What should never be stored
API keys, private keys, bearer tokens, seed phrases, signing keys. Receipts contain none of these. Keep credentials out of receipt memory entirely.
Verify a stored receipt later
Before using any stored receipt: match keyId against your independently pinned key (/pubkey is a cross-check), recompute replayHash, verify the ed25519 signature. Old receipts verify against the key that signed them (/key-policy.json). Unverifiable = unusable: discard and rerun.
If a storage key leaks
Storage credentials are the caller's domain: revoke/rotate the leaked credential at the provider, re-encrypt if applicable, and re-verify restored receipts against the pinned key afterward. Raven hosted API keys follow the delegate key policy — revoke one key without rotating everything.
Staleness
Stored receipts age. Re-verify when the receipt exceeds your policy window, before high-risk or material actions, when the prior receipt lacked pool/metadata evidence, at delayed-execution time, or after engine-version changes. Defaults: pre-trade/spend/listing = re-verify immediately. Full rules: /decision-policy.html.