How anyone can check an Intramedial ledger bundle without us, offline if they want, with the offline verifier, the /verify page or a few lines of their own code, and what each result means.
Last updated November 5, 2026.
A ledger bundle can be checked by anyone who has it and our public key: a counterparty, an auditor, a court. You do not need an Intramedial account, an API key or our agreement, and you do not have to tell us you are doing it. The Verifier Terms say what a valid bundle lets you rely on.
In plain language: take the bundle, take our public key, check the root and the signature. If both match, nobody has changed the bundle since we signed it.
A ledger bundle seals a range of a workspace's audit chain. It carries the hash of each record in the range, a Merkle root over those hashes, and an Ed25519 signature over a small signed core. Every verifier, ours or yours, does the same four things:
sha256 of each record in , in order, and compute the Merkle root. It must equal , and the number of records must equal .Put admission in front of your MCP servers, repositories, SaaS tools and cloud accounts. Every agent gets a lease or a reason – and you keep the lever to stop any of them.
recordsmerkleRootrecordCountbundleId, workspaceId, jurisdiction, scope, rangeStart, rangeEnd, recordCount, merkleRoot, firstRecordId, lastRecordId, snapshotAt) and serialize them in the RFC 8785 canonical JSON form (JCS): object keys sorted, no whitespace, strings and numbers as JSON, UTF-8. The records list, the signature and any anchor proof are not part of the signed core: the root commits to the records.kid equals the bundle's signingKeyId, and check that its jurisdiction matches the bundle's jurisdiction.ed25519Signature, decoded from base64url, over the canonical bytes with that key.| Result | Meaning |
|---|---|
| Valid | The bundle is exactly what Intramedial signed with the named key, and the records it carries are the records the root commits to |
| Root mismatch | The records do not produce the signed merkleRoot. A record was added, removed, reordered or changed after signing |
| Signature invalid | The signature does not match. The signed core was changed after signing, or was never signed by that key |
| Unknown key | The key it names is not in the key set you checked against |
| Malformed | It is not a well-formed bundle, for example a signed member is missing or has the wrong type |
A valid result says nothing about whether what the records describe is true, lawful or complete. A bundle shows what the audit chain held when it was sealed; read the Record Practice Statement to see what the chain does and does not attest.
Anchors are a separate question. If a bundle carries an otsProof, it shows that the bundle's Merkle root was included in a batch entered in an OpenTimestamps proof tied to a Bitcoin block, which fixes a time by which the root existed. Checking that proof is a different step from checking the signature. A bundle with no anchor, or with an anchor that has not yet been confirmed, can still be valid. A valid anchor does not rescue an invalid signature.
Other signed evidence, such as compliance exports and the hash chain of a workspace's enforcement events, is checked with the same offline verifier and follows its own rules. The signed material is described where it is produced, in the documentation.
| Way | Network needed | Status |
|---|---|---|
| The /verify page | Yes: the bundle you submit is checked by our public verification route, which keeps nothing | Available |
intramedial-verify, the offline verifier (@intramedial/verifier), MIT licensed, for the command line and for JavaScript and TypeScript | None, with pinned keys | Source is published in our repository; it is not yet on a package registry |
| Your own code, in any language with SHA-256, Ed25519 and a JCS library | None, with pinned keys | Always possible; see Verify in your own code |
| The bundle export | None: the bundle carries its records and signature | Available through the API and the dashboard |
The status of each library is kept current on SDKs.
Verification needs the network only to fetch our key set. To verify with no network at all, or long after the event:
kid and x of the key you rely on, as Key management explains;kid, in a system you control.The bundle format is designed so that a bundle stays verifiable for good; see Record Format Versions and long-term verification.
The verifier repository includes known-answer examples and tests. Your verifier should accept a genuine bundle and reject the same bundle with any single character changed in a record hash, in a signed member or in the signature.
If a bundle verifies but you believe we did not issue it, or a genuine bundle fails, write to security@intramedial.com with the bundle.
