How third-party verification works

To verify a Provetrail record, you rehash its events into a Merkle root, check the cryptographic signature on that root against a published key, and confirm that each claimed outcome is bound to committed evidence. You need the record and the public key, nothing else. No access to the system that produced the record, and no call back to it. The whole check runs client-side.

This post walks through each step and the standards each one reuses. Nothing here is invented; it is assembled from primitives that have been carrying production traffic for years.

Step 1: the published key

Verification starts from identity. The emitter signs with an Ed25519 key, and the corresponding public key is published under a stable key identifier. The sample record on the home page, for instance, is signed by provetrail-conformance-root.

Because the key is public and named, “who emitted this” has a definite answer that anyone can resolve. A record signed by a key you do not recognise is a record you do not accept. This is deliberately the same shape as the identity primitives the rest of the ecosystem uses, so a record can reference an external agent identity rather than minting a private one.

Step 2: the signature

The signature itself is a COSE_Sign1 structure, the CBOR-native signing standard also used by content-provenance and receipt standards in this space. COSE_Sign1 wraps a single signature over a payload, using Ed25519 as the algorithm.

Signing over CBOR rather than JSON is a practical choice. The record’s monotonic sequence numbers are 64-bit integers, and canonical JSON cannot represent integers above 2^53 without a string hack. CBOR encodes them exactly, which matters when those numbers determine the order of the record.

Checking the signature tells you the record was emitted by the key holder and has not been altered since. That is authenticity and integrity, together, in one check.

Step 3: the chain

A single signature over a blob would let you detect that the blob changed. Provetrail chains the events into a Merkle tree and signs the root, using the mechanics from Certificate Transparency (RFC 6962, carried forward in RFC 9162). Certificate Transparency has been protecting the web’s certificate ecosystem with exactly this construction for a decade.

The consequence is fine-grained tamper-evidence. Change one byte of one event and the recomputed root no longer matches the signed root, so verification fails. You are not trusting that the whole record is intact because the last line checks out; every event is committed to the same signed root. This is what the “tamper a byte” button on the home page demonstrates. Flip a byte, and the proof breaks in front of you.

Step 4: governance and ground truth

Integrity and authenticity establish that the record is real and intact. Two further checks establish that the run was governed:

• Governance. Each side-effecting action carries the authorization decision that admitted it. A verifier can confirm that no such action appears without a matching admission, which makes “nothing ran without authorization” a checkable property of the record.
• Ground truth. A claimed success carries a commitment to the check that backs it. A record that asserts an outcome with no bound evidence is rejected. An authorized holder can re-run the check against the committed observation.

In the reference runtime, Flynn, these are reported per tier by flynn spine verify, alongside the integrity check. The browser demo runs the integrity and signature checks; the governance and ground-truth tiers are checked by the full verifier.

Step 5: conformance vectors

A verification standard is only worth as much as the agreement between independent verifiers. Provetrail publishes conformance vectors: valid records a conforming verifier must accept, and malformed or tampered ones it must reject, including a broken chain, a bad signature, a non-monotonic sequence, and a record whose carried bytes disagree with their logical content.

A verifier in any language is conformant if and only if it passes the suite. That is what turns “trust our verifier” into “run yours against the same vectors and see that they agree.” The sample record on the home page is one of these vectors. For what conformance means in full, and which tiers an implementation can reach, see what makes an implementation Provetrail-conformant.

Try it

• Verify in your browser. The home page runs the real verifier client-side against a signed vector. It is the provetrail npm package, its COSE_Sign1 and Merkle checks, with nothing uploaded.
• Verify it yourself. Download the record and run it through your own verifier.
• Read the standard. The spec and reference implementation live in the Provetrail repository.

For the argument behind why a runtime, not a wrapper, should emit these records, see signed versus proven. For the definition and how this fits alongside other standards, see what is verifiable execution provenance.

Last updated: 10 July 2026.