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}.

Receipts waiting to be anchored: 0. Every receipt written so far is covered by a published root. A list that has not grown recently means no new decisions have been recorded, not that the job stopped.
Most recent decision receipt written 2026-11-02 05:50 UTC.
PUBLISHED ROOTS
6
shown here
RECEIPTS IN THOSE ROOTS
67
67 of them in a root a Bitcoin block contains
NEWEST, PUBLISHED
2026-11-03
receipts up to 2026-11-02 05:50 UTC
ALGORITHM
RFC 6962
SHA-256
Batch (day published, UTC)ReceiptsReceipts writtenPublishedExternal timestampMerkle root (SHA-256)
2026-11-0332026-11-02 05:50 UTC2026-11-03 04:20 UTCBitcoin #974,343e130a017a36c4947d403218b22aa0c23b8b13c18c7cdf2bf1b1063e4005a746e
2026-10-2732026-10-26 05:50 UTC2026-10-27 04:20 UTCBitcoin #973,3435b25dabc10dfce9628560350641e8dbc2eadd0e70456fa9349440dd5475fb3f8
2026-10-2032026-10-19 05:50 UTC2026-10-20 04:20 UTCBitcoin #972,2625680006cdcd6b6e64f40a4738c6521069a45c6fb0b44472f7ff03a06e3922bb5
2026-10-1332026-10-12 05:50 UTC2026-10-13 04:20 UTCBitcoin #971,1911feb709cdc7eec71ba9946c9c3b1f0190a641b22477594e877b6050c1c56b1fe
2026-09-2712026-09-26 11:43 UTC2026-09-27 04:20 UTCBitcoin #968,936ba75175574bb5b8637b08d7dcf80b63c5eb62d2f6d60b8efa89c1ff0fdc2090b
2026-09-11542026-09-02 13:08 UTC → 2026-09-11 15:05 UTC2026-09-11 17:36 UTCBitcoin #968,936a8bd1632695505fac272483ac63c91c5865ca404864d880a6c5510d4dd7ab552

Record today’s root somewhere we do not control. That single number is what lets you prove later that we did not rewrite the batch behind it.

External timestamps

A root published only by us is a tamper-evident log, not third-party proof. So every root is also submitted to four independent OpenTimestamps calendar servers, each of which aggregates it with everyone else’s hashes and commits the result to a Bitcoin transaction. The finished proof is a path from our root to a block header: checking it needs Bitcoin’s history and no trust in us, in the calendar, or in any certificate authority.

Submitted is not the same as timestamped, and the table above distinguishes them. A calendar batches submissions, so for an hour or two after publication the proof holds a promise rather than a path, and a row reading “not yet in a block” evidences nothing about time yet. Once the transaction confirms, the row names the Bitcoin block. Each proof is a standard .ots file, downloadable per batch and per calendar, and verified with the reference client against your own node:

ots verify -d <root hex> kytgate-<batch>-<calendar>.ots

KYTGate validates none of this evidence and does not report it as valid. The party being audited should not also be the one declaring its own evidence good. Neither a Bitcoin anchor nor a token from a service that is not an eIDAS-qualified trust provider carries a legal presumption of time under EU law. What they do give you is independent parties confirming that the number existed.

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. You can run both checks yourself. The verifier only saves you the time.

If you do not have a receipt yet, take ours. It is a real receipt in the real format, signed with a key whose private half we publish alongside it. Anyone can mint one, so holding it proves nothing. It shows the mechanism and is not evidence of any decision.

You can also run it on your own machine, against your own copy of the root, with no web page involved. The verifier is published as an open-source package with no dependencies. The algorithm is in one readable file, so you can reimplement it instead of depending on it:

npx kytgate-verify receipt.json --root e130a017a36c4947d403218b22aa0c23b8b13c18c7cdf2bf1b1063e4005a746e

Source and the full algorithm: npmjs.com/package/kytgate-verify. Pass --offline with a key and proof you captured earlier and it never touches the network.

Frequently asked questions

What does an anchor prove?
That a decision receipt already existed, with the content it has now, by the time the root covering it was published, and that nobody has changed it since. A signature cannot settle this, because 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. 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. That is 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. Each root is also submitted to four independent OpenTimestamps calendars and ends up committed to a Bitcoin transaction, so once the row names a block height the timing no longer rests on us at all. Download the .ots file and check it with the reference client against your own node; while a row still reads "not yet in a block", treat that batch 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 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.