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 commits the batch root to a named Bitcoin block. Confirming that block against the real chain takes a block header from any source you trust.

All three steps run on your machine. A proof that verifies today keeps verifying, even if TrustNotch has shut down, because it depends only on the bundle, open-source code and standard cryptography. That is a property of the maths, 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.

The trustnotch verifier carries the published keys inside the package, so verification needs no network call. A verifier installed before a rotation needs an update, or the new key passed with --keys, to check receipts signed under the new key. The MCP server reads a pinned key file from TRUSTNOTCH_PUBKEYS_PATH.

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: the proof is checked offline, and the block it names can be confirmed against any copy of the Bitcoin chain.

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 high-risk AI systems to record events automatically over their lifetime, so their behaviour can be traced: risk situations, substantial modifications, and how the system runs in use. Providers and deployers must keep those logs for at least six months. The rules apply from 2 December 2027 (Annex III systems) and 2 August 2028 (Annex I products). The Act does not say how logs must be protected against editing, and that is the gap TrustNotch addresses.

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.

As the evidence layer. Your governance program decides what to record, who reviews it, and how risks are handled. TrustNotch makes the records themselves verifiable: each entry gets a signed receipt and a Bitcoin anchor, and anyone can check it offline with open-source software. It does not replace a governance platform, a risk assessment or legal advice. Read more about AI governance and evidence →

It can support it. Control A.6.2.8 covers recording event logs for AI systems, and TrustNotch produces logs an auditor can verify independently. Certification applies to your organisation's management system, not to tools, so TrustNotch does not make you certified, and no tool can.

Yes, two ways. You can create an account in your browser, confirm your email, and issue your own API key from the dashboard — nothing to request from us — or, if you are an agent, provision a free-tier account and key directly over the TrustNotch API with no form to fill in. Both start on the free tier at 10,000 entries a month, and the quickstart walks through both paths. See plans and pricing →

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.