GATEATTEST · LIVE
Published anchors for decision receipts
A signed receipt proves KYTGate said it. It does not prove KYTGate said it then — the party holding the key can always sign something later. So once a day every receipt written so far is hashed into an RFC 6962 Merkle tree and the root is published here, unchanged for good. Raw JSON at /api/public/attestations; a single receipt at /api/public/attestations/{receiptId}.
No roots published yet. The first batch is written by the daily job once there are receipts to cover.
Check a receipt
Paste a receipt into the receipt verifier: it checks the Ed25519 signature and then walks the inclusion proof to the published root. Both checks are things you can run yourself — the verifier exists to save time, not to be trusted.
Questions
What does an anchor prove?
That a decision receipt already existed, with exactly the content it has now, by the time the root covering it was published — and that nobody has changed it since. It is the answer to the one question a signature cannot settle: the party that holds the signing key can always sign something later and date it earlier. A published root cannot be recomputed to cover a receipt written after it.
What does an anchor NOT prove?
That the decision was right. The anchor is about time and integrity, not judgement — the reasoning behind a decision is in the receipt itself, its signals and its policy version. It also says nothing about receipts that are not in a batch: a root proves what is in it, never what is missing.
Why should I believe a root that KYTGate published itself?
On its own, only as far as you trust us not to rewrite our own history — which is exactly why the roots are public and never change: anyone who recorded yesterday's root can check today that it is still the same number, and every receipt in that batch is bound to it. A root that has additionally been pinned outside KYTGate shows the external reference in the API response; until then, treat it as our own tamper-evident log rather than third-party proof.
How do I check a receipt myself?
Ask /api/public/attestations/{receiptId} for the inclusion proof, recompute the leaf as SHA-256(0x00 || "kytgate.receipt.v1\n" || canonical receipt JSON without the signature || "\n" || the signature), then fold in each sibling hash with SHA-256(0x01 || left || right) per RFC 6962 and compare the result with the published root. The receipt verifier does all of that for you, but the point is that it does nothing you cannot do yourself.
Do the roots reveal anything about your customers?
No. A root is a hash over receipts belonging to many brokers; a leaf is the SHA-256 of one receipt, and an inclusion proof consists of sibling hashes. None of it can be turned back into an address, a customer or an amount. That is why one shared root per batch is used rather than a root per customer, which would leak how much business each one does.