FAQ

You don't have to trust us. Every entry can be independently verified with the open-source trustnotch verifier — no connection to TrustNotch required. The verifier checks three things locally:

• The Ed25519 signature in the receipt matches the exact content submitted.
• The Merkle inclusion path recomputes correctly to the batch root.
• The OpenTimestamps proof chains the batch root to a Bitcoin block header.

All three steps run on your machine. A proof that verifies now will verify in ten years, even if TrustNotch has shut down. That is the structural guarantee — not a policy or a promise.

Yes. The trustnotch verifier is published on PyPI (pip install trustnotch) with a read-only public mirror at github.com/trustnotch/trustnotch. You can read exactly what the verifier does and implement the same checks yourself from the RFC 6962 and OpenTimestamps specifications.

Receipts are signed with the key in effect at submission time. TrustNotch never removes a published signing key. When a key is rotated, the new key is added to the public /v1/keys directory and the old one is marked retired but stays published — so any proof signed under it remains valid for verification, offline, even years later. New entries are signed with the current key.

You can also pin a local key file via TRUSTNOTCH_PUBKEYS_PATH so verification never requires a network call at all.

TrustNotch supports per-entry erasure. You can erase the stored payload for any entry — removing it from TrustNotch's servers — while every proof for that entry and every sibling entry continues to verify.

This works because the Merkle tree is built over the hashes of content, not the content itself. Removing a payload from the server doesn't change the hash that was committed to the tree, so no sibling's inclusion proof is affected. This is sometimes described as "crypto-shred by omission."

A GDPR erasure request for a specific user's data can be satisfied without retroactively undermining the integrity of surrounding log entries.

TrustNotch is built and hosted in the EU — Helsinki, Finland. The live API is at api.trustnotch.com.

Bitcoin's blockchain is a public, globally verifiable ledger with no single controller and a well-audited history. Using OpenTimestamps, TrustNotch anchors each batch's Merkle root to a Bitcoin block — establishing that the batch existed before that block was mined. Anyone can verify this anchor without trusting TrustNotch or any other service.

Unlike centralized timestamp authorities, Bitcoin's proof-of-work makes retroactive modification of the block order economically infeasible. The anchor is checkable from the public blockchain, not from a certificate authority's records.

No. The signed receipt is returned immediately at submission time — that is your instant cryptographic commitment to the exact content logged. Bitcoin anchoring is asynchronous: TrustNotch submits batch roots to OpenTimestamps calendar servers, and Bitcoin confirmation accrues over the following hours as blocks are mined.

The receipt alone proves the exact content. The Bitcoin anchor adds a time-bound guarantee rooted in the blockchain. The two complement each other; neither replaces the other.

TrustNotch does not write its own Bitcoin transactions. It submits each batch's Merkle root to public OpenTimestamps calendar servers, which aggregate digests from many users worldwide and commit the combined root in a single periodic Bitcoin transaction — so your batch shares one on-chain transaction with thousands of others rather than getting its own. TrustNotch submits to several calendars for redundancy; once any one of them is mined, the proof upgrades to a confirmed Bitcoin anchor. The only Bitcoin calls TrustNotch makes itself are read-only block lookups used to verify anchors.

Article 12 of the EU AI Act requires providers and operators of high-risk AI systems to ensure those systems automatically record events throughout their operational lifetime — logs sufficient to reconstruct processing and establish accountability. The regulation requires those logs to be tamper-evident.

TrustNotch provides the cryptographic foundations that tamper-evident logging requires: signed receipts, Merkle-batched entries, and Bitcoin-anchored batch roots that can be verified independently of TrustNotch.

Using TrustNotch does not itself guarantee regulatory compliance. What constitutes compliance depends on your specific system, use case, and legal context — always consult legal counsel for your situation. Read more about the regulatory context →

No. TrustNotch handles the tamper-evident logging layer — the cryptographic evidence that entries have not been altered. Whether that logging satisfies your specific obligations under the EU AI Act or any other regulation depends on what you log, how you log it, and the broader context of your system. That assessment requires legal counsel, not a logging service.

Not yet. TrustNotch is currently in early access — there is no self-serve signup. To request an API key and onboarding, reach out at hello@trustnotch.com. Self-serve signup will open publicly in the future.

MCP (Model Context Protocol) is an open standard for connecting AI assistants to external tools and services. TrustNotch's MCP server lets Claude Desktop and other MCP clients submit and verify audit log entries directly — the agent calls submit_log, receives a signed receipt, and can call verify_log later to confirm an entry is intact. See the MCP server page →

Yes. The REST API at api.trustnotch.com accepts HTTP submissions directly — the MCP server is a thin wrapper that calls the same API. You can submit log entries from any HTTP client and verify the resulting proofs with the trustnotch CLI independently of the MCP layer.