Format versions and long-term verification

In plain language: a bundle belongs to a format version, and that version never changes meaning. Old bundles keep verifying with the same steps, whatever we add later.

2. What can change within format version 1#

Within version 1, changes are additive only:

• new optional members in a bundle, a chain entry or a record body;
• new kinds of record, for new modules; and
• new versions of a single module's record body, marked inside the body when they happen. A body without a version marker is the first version of that body; its next version adds the marker.

None of these affects verification. The signature covers every member present in the bundle, whatever it is called, so a verifier that canonicalizes the whole document, as the steps in Verifying records require, verifies bundles with members it has never seen. Software that reads the fields should ignore members it does not know.

3. What needs a new format version#

Any change to how bundles or chain entries are canonicalized, to the hash function, to the signature scheme, or to the members every bundle must have, requires a new format version. Version 1 bundles stay verifiable for good: we will not reinterpret them, and verifiers must keep accepting them alongside any later version.

Before any bundle is sealed in a new format version, we will publish its description, support it in our verification libraries and on the /verify page, and announce it in the changelog. The move to post-quantum signatures, which we intend to make, described on Post-quantum status, is the change most likely to need one. No post-quantum signature is used in production today.

4. The API#

The API is versioned by its path. Within /api/v1/, changes are additive: new endpoints, new optional request fields and new response fields. A change that would break existing callers gets a new path prefix, and /api/v1/ keeps working alongside it for the notice period set out in Versioning and deprecation. There is no version header and no date-based versioning. The MCP tool list follows the same rule: a tool's published input and output schema changes only additively within a version.

We announce API changes in the changelog. Removing a paid feature is announced by email at least 30 days ahead, as the Terms of Service say.

5. Verification libraries#

The verification libraries follow semantic versioning. A new major version may drop support for an old runtime, but never for an old bundle format or an old published key: every library version verifies every bundle format version that existed when it was released. The verifier runs offline and has no dependency on Intramedial, so a bundle can be checked years later even if the service is gone. There is no fixed support window for library versions; the steps are simple enough that any current version, or your own code, will do.

6. Keeping bundles verifiable for decades#

Three things keep an old bundle verifiable without us:

1. The format is frozen. A version 1 bundle means the same thing in twenty years as it does today.
2. The key is pinned. Store the key set the bundle verified against with the bundle. Retired keys also stay in our published set, as Key management describes.
3. The algorithm is standard. Ed25519, SHA-256 and RFC 8785 have independent implementations in every major language. You do not need our code.

Where an OpenTimestamps anchor has been confirmed for a bundle, the otsProof member lets you check, against the Bitcoin block it names, that the bundle's digest existed by then, without asking us. How anchors work, and what they do not show, is set out in the Record Practice Statement section 5.

For evidence that must outlast a possible future quantum computer, see Post-quantum status.

7. Changes and contact#

We update this page when a version changes. Questions: support@intramedial.com.

EU notices

• Digital Services Act
• EU Data Act
• EU AI Act
• Right of withdrawal

Receipt practices

• Record Practice Statement
• Verifier Terms
• Key management
• Verifying ledger bundles
• Format versions and long-term verification
• Cryptographic agility and post-quantum status
• If Intramedial stops operating

Program terms

• Startup Program Terms
• Nonprofit Program Terms
• Education Program Terms
• Public Sector Program Terms