← PRODUCT
PRODUCT · PROVE

GateReceiptthe signed Decision Receipt

An Ed25519-signed Decision Receipt on every screening: inputs, list snapshot hashes, policy version, signals.

DECISION RECEIPTinput hasha1b2…9flist snapshotsha256:2b44…coverage9 dimensionspolicybroker-v1.1decisionREVIEWed25519signatureanyoneverifiesintegrity you can prove — not a screenshot
On this page

What it does

Every decision produces a Decision Receipt: a portable record of the inputs hash, the content hashes of the sanctions snapshots used, the coverage matrix, every signal, the policy version, the decision and the timestamp — signed with Ed25519 and stored append-only. Human actions on the case are recorded on the timeline the receipt anchors.

The receipt is the unit everything else in the Prove pillar is built on: replay reads its stored inputs, evidence packs embed it, and the monthly report counts from it.

Why a broker needs it

A screenshot of a dashboard proves nothing. When an examiner asks, a year later, why a deposit was accepted, the answer must be a record that is demonstrably what was produced on that day — not a log that could have been edited. A signature anyone can verify against a published public key makes that a property of the document rather than a promise from a vendor.

How it works

The receipt's fields are serialised as canonical JSON with recursively sorted keys and signed with KYTGate's Ed25519 signing key. To verify: fetch the SPKI public key from /api/v1/receipt-key, remove the signature field, serialise the same way, strip the ed25519: prefix and verify. Every evidence pack ships these instructions inline, and the in-browser verifier runs the same check without uploading anything.

Try it without an account: Decision Receipt verifier (in-browser, no account).

What it does not do

A receipt proves integrity, not correctness: it shows the record is byte-for-byte what was produced, and the coverage matrix inside says what was and was not checked. It is not a timestamp from a third party, and it does not include data you did not send (processor evidence, customer events) — those gaps are visible in it, not filled by it.

API

GET /api/v1/receipt-key
{ "configured": true, "algorithm": "ed25519", "spkiBase64": "MCowBQYDK2VwAyEA…" }

// verify: remove "signature", serialise with recursively sorted keys,
// strip the "ed25519:" prefix, verify against the SPKI key

Full reference: /docs#receipts · OpenAPI 3.1

Try the sandboxRead the API docsRequest early access