Receipt architecture / minimal and bank-friendly

Receipt.

A receipt links a signed evidence statement to a verifiable commitment that later sits outside the issuer's unilateral control.

For a bank, the practical architecture should be local-first. Evidence and per-event details remain inside the perimeter. A local append-only log emits inclusion receipts. Only a batch root or signed tree head is externally anchored.

This is SCITT-aligned, not a claim of running a full SCITT Transparency Service. The implementation path is signed statements, Merkle inclusion proofs, COSE-style receipts, external root anchoring and offline verification bundles.

01 / Structure

Minimum viable receipt stack.

Do not rebuild a full SCITT server first. Build the smallest stack that proves the audit bundle against an external commitment.

ComponentRole
Statement builderCreates a signed statement over the evidence package root and source-basis root.
Local append-only logAppends statement hashes and computes Merkle roots and inclusion paths inside the institution.
Receipt emitterProduces leaf hash, inclusion path, tree size, signed root and verification metadata.
External anchor adapterPublishes only signed roots or batch commitments to immutable external storage or a later SCITT target.
Offline verifierLets the auditor verify the package without bank-server access.
02 / Honest weak point

The anchoring cadence defines the manipulation window.

Before a batch root is externally anchored, the institution still controls the local log. A malicious issuer could suppress or rebuild entries inside that unanchored window. Shorter anchoring cadence reduces the window. It does not eliminate the need for operational controls.

This should be stated plainly in the product: maximum unanchored evidence-reconstruction window equals anchoring cadence plus operational delay.

03 / Source basis

Source atoms move under the receipt page.

Source atoms are still important, but they are a mechanism inside the evidence package. They define the legal/source basis the package was built against. They no longer need to carry a top-level page in the market narrative.

04 / What the reviewer gets

The receipt can produce a readable verification report.

The cryptography stays underneath. The deliverable is a report a reviewer can read, save and file: what was committed, when it was receipted, and whether the disclosed package still matches the commitment.

Evidence package verified

Match

The package presented for review matches the sealed commitment. Recompute the package from the disclosed files and manifest to confirm the same result independently.

Package digeste3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
Receipted on4 May 2026
Time of receipt14:31:07 UTC
Statementvalid, Ed25519
Verification resultpackage match

This report attests to integrity and timing of the registered commitment. It does not assert legal correctness, factual truth, completeness, or regulatory acceptance of the underlying evidence.

The receipt is the bridge between private evidence and public verification.

No evidence leaves the institution at issuance. Later, the disclosed package verifies against the external commitment.