Anchoring & receipts
Ananke Labs optionally anchors document integrity proofs to a distributed ledger. This page explains what anchoring means, how receipts work, and what developers need to know.
What anchoring is
Anchoring is the process of writing a cryptographic proof of a document's existence and integrity to a distributed ledger (currently Hedera Hashgraph). This creates a tamper-evident record that the document existed at a specific point in time with specific content.
Anchoring is optional and happens asynchronously after issuance. A document is valid and verifiable immediately after issuance, even before anchoring completes.
How it works
The anchoring flow:
- A document is issued → a content hash is computed
- The hash is batched with other hashes for efficiency
- The batch root hash is written to the ledger
- A receipt is generated containing the inclusion proof
Batching means individual documents are not written to the ledger one-by-one. Instead, multiple document hashes are combined into a Merkle tree, and the root hash is anchored. Each document gets a receipt that proves its inclusion in the batch.
Receipts
A receipt is a proof object that ties a specific document hash to an on-chain anchor. It contains:
- Document hash — the SHA-256 hash of the document content
- Merkle proof — the path from the document hash to the batch root
- Anchor reference — the on-chain transaction ID
- Timestamp — when the anchor was committed
Receipts can be independently verified by anyone with access to the ledger. You do not need to trust Ananke Labs — you can verify the proof yourself.
Developer impact
For most integrations, anchoring is transparent. Documents are verifiable immediately. Anchor status may appear in verification results as an additional field but is not required for the document to be valid.
In local development, anchoring is simulated. The verification flow works the same way but without a real chain transaction.