Witnessing

A Vitrified attestation is the binding of a hash to a moment, witnessed through several independent trust mechanisms. This page describes how the witnessing engine works end-to-end.

Submission

You submit a content hash plus structured metadata via the authenticated API or any SDK. The submission's leaf identifier is deterministic: the SHA-256 of the canonicalized submission envelope (see canonicalization for the exact algorithm). Vitrified validates the metadata against the declared schema and enqueues the leaf for the next batch window.

Batching

Submissions are aggregated into Merkle batches at a service-wide cadence (default: one batch per minute, UTC-aligned). The batch root is what Vitrified actually presents to each witnessing mechanism — this means a single witness operation amortizes across every submission in the window.

The Merkle construction is RFC 6962 with SHA-256. The proof bundle returned for any submission includes the audit path from the leaf to the root, so a verifier reconstructs the batch root without trusting Vitrified.

The six mechanisms

Every batch root is submitted in parallel to all six mechanisms. Each produces an independently verifiable trust artifact.

A verifier picks the mechanism that matches their tooling and trust register. A regulated enterprise auditor uses the EU DSS validator. A software supply chain team uses cosign verify. An OSS developer runs the OpenTimestamps client. Each gets a clean pass because each path is conformant on its own terms.

Vendor pools

Each mechanism with multiple providers (QTSPs, RFC 3161 TSAs, EVM networks) runs as a pool with per-batch routing. Practical implications:

• Resilience to single-vendor failure. Any one QTSP being unavailable, suspended from the LOTL, or terminating its service does not interrupt service operation; the pool's other providers continue.
• Resilience to contract changes. Any vendor changing terms in a way Vitrified doesn't accept results in removal from the pool; the service continues with the remaining vendors.
• Validity preservation. Stamps issued by a vendor that is later removed from a trust list remain valid — qualified at issuance is a permanent property under eIDAS; the service simply stops routing new batches to that vendor.

Retry and partial witnessing

Mechanisms occasionally fail or time out independently. The witnessing engine retries each failed mechanism on an exponential backoff schedule until the per-batch deadline. A bundle that lands with fewer than all six mechanisms is delivered with the partial set; subsequent retries that land before the deadline upgrade the bundle in place.

What Vitrified never claims

• Never claims its internal operations are eIDAS-qualified. They aren't. Only the QTSP signature is.
• Never claims a specific witness vendor's brand. Vendor names appear only in DPA sub-processor schedules where compliance disclosure requires.
• Never claims that verification depends on Vitrified. It doesn't.

See also

• Proof bundle — the shape of what you receive.
• Submission policy — foot-gun warnings, validation, retention.
• Verifier CLI — offline bundle verification.