Multi-mechanism witnessing

Why one mechanism is never enough

A startup selling into EU banking ends up in eIDAS. Selling into US healthcare ends up in HIPAA and maybe NIST. Selling into UK government ends up in the UK Trust Services List. Selling into open-source supply chain ends up in Sigstore. The framework you need is the framework your customer’s auditor picks — and you don’t get to know which one in advance.

Vitrified witnesses every batch root in parallel through all of them, so the answer to “can you prove this under framework X” is always yes.

The six mechanisms

• eIDAS qualified timestamps — pooled qualified trust service providers (QTSPs). Verifies against the EU Trust Services List with the official EU DSS validator.
• RFC 3161 timestamps — pooled free public TSAs. Verifies with openssl ts -verify.
• Sigstore Rekor — public transparency log inclusion. Verifies with rekor-cli or cosign verify.
• Bitcoin via OpenTimestamps — anchored into the Bitcoin chain. Verifies with the ots client against Bitcoin block headers.
• EVM L2 anchoring — anchored on a public EVM rollup (Base / Arbitrum / Ethereum). Verifies with any web3 client.
• DSSE envelope — Vitrified’s own signed envelope. Verifies with any DSSE-compliant tool against Vitrified’s published key.

Pool, not single vendor

Each mechanism with multiple providers (QTSPs, RFC 3161 TSAs, EVM networks) runs as a pool. One vendor going down, getting suspended from the LOTL, or changing terms in a way we don’t accept does not interrupt service — the pool’s other providers continue. Stamps issued by a vendor later removed from a trust list remain valid: qualified at issuance is a permanent property under eIDAS.