Veristamp maintains a public, append-only transparency log. Every receipt is committed to this log, making it impossible to backdate or silently delete a receipt.
What the log proves
Section titled “What the log proves”A sealed entry in the log establishes:
- Existence — A receipt with a specific fingerprint existed at the stated time and was signed by Veristamp.
- Inclusion — The receipt was committed to a public Merkle tree. The log operator cannot remove or modify entries without detection.
- Anchoring — The daily epoch root is cross-timestamped by external public timestamp authorities (Apple, DigiCert, etc.), proving the ledger itself cannot be backdated.
How it works
Section titled “How it works”Every 24 hours, all receipts from that day are sealed into a signed Merkle epoch:
- Pending receipts are gathered into a Merkle tree.
- The tree root is signed by Veristamp.
- The root is sent to 4 public timestamp authorities (DigiCert, Apple, GlobalSign, Microsoft). Their signed responses are bundled as
external_proofs. - The epoch bundle is published to
roots.veristamp.in. - The pending pool is cleared.
External anchors vs receipt signatures
Section titled “External anchors vs receipt signatures”The Veristamp Ed25519 signature covers the receipt itself. The external TSA anchors cover the daily epoch root — not individual receipts.
This means: your receipt is signed by Veristamp. The epoch containing your receipt is anchored by public TSAs. These are two separate guarantees that work together.
Public artifacts
Section titled “Public artifacts”All public artifacts are served from roots.veristamp.in:
| Path | Content |
|---|---|
/.well-known/veristamp-roots/current.json | Latest epoch root, signed |
/.well-known/veristamp-roots/2026-06.json | Monthly archive |
/.well-known/veristamp-log/epochs/{epoch_id}.json | Full epoch bundle |
Privacy model
Section titled “Privacy model”The log publishes enough to verify inclusion, but not enough to identify a file. Public epoch bundles contain only:
- Receipt ID
- Issued time
- Key ID
- Receipt signature
- Nonce-bound leaf hash
The raw file hash and nonce are never published. You can prove inclusion using your private receipt combined with the public epoch bundle.
Offline verification
Section titled “Offline verification”Every receipt bundle includes verify.html — a zero-dependency HTML file.
- Double-click
verify.html - Drop your file and
receipt.json - The browser runs local cryptographic checks (SHA-256 and Ed25519) to ensure integrity.
What the web app checks
Section titled “What the web app checks”- File SHA-256 matches the receipt
- Ed25519 signature is valid against the keyring
- (If online) Receipt appears in the correct epoch bundle
- (If online) Leaf hash matches the published record
- (If online) Merkle root is intact (no tampering)
- (If online) Which TSAs anchored the epoch
Verify with shell commands only
Section titled “Verify with shell commands only”If you just want to check the file hash:
$ sha256sum yourfileCompare the output to hash.value in receipt.json. If they match, the file is authentic.
Programmatic verification & Auditing
Section titled “Programmatic verification & Auditing”For advanced users and auditors, the bundled verify.py script serves as a complete reference implementation. This script fetches the correct public epoch based on the receipt time, rebuilds the Merkle tree from scratch to verify its root, and verifies the leaf inclusion.
$ python verify.py receipt.json yourfile --show-anchorsIt will output the exact openssl ts -verify commands needed to cryptographically prove the time anchors against the Root CAs.