Why isn't one timestamp anchor enough?

A single external timestamp authority depends on that one authority continuing to exist and remaining trusted; a single blockchain anchor depends on that one chain. Binding the same signed root to both simultaneously means the compromise or disappearance of either anchor still leaves the other sufficient to prove the record's contemporaneity, within that anchor's own assurance level.

What does it mean that the RFC 3161 token is "verified" rather than just stored?

The seal does not simply attach whatever timestamp token the authority returns. A verifier rejects the token unless its message imprint exactly equals the submitted root (or its hash) and its status is granted. Only a token that passes both checks counts as a valid anchor; the generation time is then extracted from the verified token.

Why hybrid Ed25519 plus ML-DSA-65 instead of just one signature scheme?

Ed25519 is a well-understood, widely-deployed classical signature; ML-DSA-65 (FIPS 204, the Dilithium-III parameter set) is a NIST-standardized post-quantum lattice signature. Signing with both, and requiring both to verify independently, means the seal's integrity does not depend on either cryptographic assumption alone remaining unbroken over the record's evidentiary lifetime.

Dual-Independent-Anchor Hybrid Post-Quantum Seal

Executive Summary

A signature proves a record's integrity. It does not, by itself, prove when the record was signed - and an issuer-supplied timestamp is not independent of the issuer. JIL Sovereign's dual-independent-anchor seal, reduced to practice and in live production since June 2026, solves the contemporaneity problem by binding one hybrid post-quantum signature to two anchors that are mutually independent of each other and of the issuer: a verified external RFC 3161 time-stamp token, and a separate public-blockchain attestation obtained via an aggregating timestamp protocol.

The pipeline computes a content hash over a record snapshot, aggregates per-cycle hashes into a Merkle root, and signs the root with a hybrid signature comprising a classical Ed25519 signature and a post-quantum ML-DSA-65 (FIPS 204 / Dilithium-III) signature, both independently verifiable. The same root is then submitted to an external RFC 3161 timestamp authority - the returned token is parsed and verified, confirming a granted status and that the token's message imprint exactly equals the submitted hash, and the authority's generation time is extracted. The root is separately submitted to a public blockchain via an aggregating timestamp protocol, yielding a pending proof that is later upgraded to a confirmed block attestation. Both anchors and both signatures are recorded in one seal record.

Core Innovation: Dual independent anchoring of a single hybrid-post-quantum-signed root - a verified (not merely stored) RFC 3161 token plus a confirmed public-blockchain attestation - verifiable from the seal record and a holder-supplied copy of the record alone, with no access to the issuer's infrastructure required.

Problem Statement

Evidentiary value rests on a specific claim: this record existed, in exactly this state, at exactly this time, and the issuer could not have backdated it. A cryptographic signature addresses integrity but says nothing about time. A timestamp generated by the issuer's own systems is not independent of the issuer and carries no more evidentiary weight than the issuer's word. Existing approaches solve half the problem each: a single external timestamp authority under RFC 3161 depends on that one authority's continued existence and trustworthiness; a single blockchain anchor via OpenTimestamps depends on that one chain and matures slowly. Neither approach composes the two, and neither binds the resulting time-proof under a signature designed to remain durable against a cryptographically-relevant quantum computer.

Hybrid classical-plus-post-quantum signatures (Ed25519 combined with a lattice scheme such as Dilithium/ML-DSA) are a known cryptographic primitive on their own. What is missing from prior art is the specific combination: a verified RFC 3161 token - meaning its message imprint and granted status are actually checked, not merely stored - used together with a separate public-chain anchor, on the same hybrid-signed root, such that either anchor alone remains sufficient proof of contemporaneity if the other becomes unavailable.

Mutually independent timestamp anchors per seal

ML-DSA-65

NIST FIPS 204 post-quantum signature standard used

Jun 2026

Mechanism reduced to practice and shipped to production

Why Existing Approaches Fall Short

RFC 3161 alone: single point of trust and availability in one timestamp authority; no independent second anchor.
OpenTimestamps / blockchain notarization alone: single-chain dependency; matures slowly; no external timestamp-authority cross-check.
Hybrid classical + post-quantum signatures alone: a known signature primitive that proves integrity, not time; not composed with any anchoring scheme.
Prior single-anchor JIL mechanisms (hybrid signing, ledger anchoring individually) each cover one half of the problem; this claim is specifically the dual-anchor combination on one root.

Technical Architecture

Sealing Pipeline

Stage	Operation
1. Content hashing	Compute a content hash over the record snapshot; aggregate per-cycle hashes into a Merkle root.
2. Hybrid signing	Sign the root with a classical Ed25519 signature and a post-quantum ML-DSA-65 signature, each independently verifiable.
3. RFC 3161 submission + verification	Submit the root's hash to an external timestamp authority; parse the returned token; verify granted status and message-imprint match; extract generation time.
4. Public-chain anchoring	Submit the same hash via an aggregating timestamp protocol; obtain a pending proof; upgrade to a confirmed block attestation (block height + block time) once the aggregating transaction confirms.
5. Seal record assembly	Record both signatures, the verified RFC 3161 token, and the confirmed blockchain anchor together in one seal record.

Two Anchors, Independently Sufficient

Compromise or disappearance of either anchor leaves the other sufficient to prove contemporaneity within its own assurance level - the two anchors do not depend on each other's continued availability. In one embodiment, an in-process, independent hash-chained authority co-signs the root as a fallback whenever no external timestamp authority is configured, preserving a chain of evidence even during an anchor outage.

Verification

A verifier, given only the seal record and a holder-supplied copy of the record, recomputes the content hash, verifies both the classical and post-quantum signatures, confirms the RFC 3161 token's imprint-match and granted status, and confirms the public-chain attestation - all without needing any access to the issuer's infrastructure.

Key Custody

Signing keys are derived by domain separation from a single master secret, sourced by a priority order (mounted secret, then key-management service, then environment variable, then default), with the source itself exposed through a provenance interface so a relying party can confirm the seal authority is not running on an unconfigured default key.

Extended by Claim 29: the same dual-independent-anchor mechanism described here is applied, in Claim 29, specifically to a blockchain's own block-finality certificates - decoupling a chain's finality proof from the chain's own operator and validators.

Prior Art Differentiation

Approach	Verified RFC 3161 token	Independent chain anchor	Post-quantum signature	Verify without issuer infra
RFC 3161 alone	Stored, not always verified	No	No	Partial
OpenTimestamps alone	No	Yes	No	Yes
Hybrid PQ signature alone	No	No	Yes	Yes
JIL Sovereign	Yes, imprint + status checked	Yes, confirmed block anchor	Yes, Ed25519 + ML-DSA-65	Yes

No prior art combines a verified RFC 3161 token with a public-chain anchor as two independent anchors on the same hybrid-post-quantum-signed root, verifiable from the seal body plus a holder-supplied record. The inventive step is the dual independent anchoring itself, together with the rule that a timestamp token only counts as an anchor once its imprint matches and its status is confirmed granted.

Patent Claim

Independent Claim 28: A method of producing an evidentiary seal, comprising: computing a Merkle root over one or more record content hashes; producing a hybrid signature over the root comprising a classical elliptic-curve signature and a post-quantum lattice signature; obtaining from an external timestamp authority a time-stamp token over the root and verifying the token by confirming a granted status and that a message imprint in the token equals the root or a hash thereof, and extracting a generation time therefrom; obtaining from a public blockchain, via an aggregating timestamp protocol, a confirmed anchor of the root carrying a block identifier and block time; and recording the hybrid signature, the verified timestamp token, and the confirmed blockchain anchor in a seal record verifiable from the seal record and a separately held copy of the record, without access to the issuing party's infrastructure.