The open standard · Version 1

SEAL, Sealed Evidence, Anchored to a Ledger.

The open standard for proving any file is real. One sealed artifact, one way to check it, verifiable by anyone, forever. Seal with any conforming tool; anyone can verify it with any other.

SSealed

A PAdES signature over every byte, chaining to a published root.

PAdES · X.509

EEvidence

The proof travels inside the file. Everything needed to verify is right there.

SHA-256

AAnchored

The file's fingerprint, timestamped the moment it existed.

OpenTimestamps

LLedger

Written to the blockchain, a public clock no one owns.

Public ledger

Two independent parts, a seal (integrity + which certificate issued it) and an anchor (when it existed), plus one convention for referencing a proof (/d/<sha256>). Everything needed to verify travels with the proof itself.

The guarantee

Open to verify. Open to implement. Impossible to lock up.

Verify independently

Verification stands on the published root, public standards, a public transparency log, and a public ledger. Everything a verifier needs travels with the proof.

Implement freely

Any tool may seal or verify to the standard, free and open to everyone. A standard PAdES/X.509 validator plus the stock OpenTimestamps client is enough.

Integrity and time

SEAL proves a document is unaltered and existed by a date. That’s the guarantee, complete, and permanent. Who sealed it is attribution by channel, and the standard is precise about the difference.

How anyone verifies a SEAL proof

Two checks, both independent of us

The seal, integrity + issuer

Validate the signature in the artifact’s format-native form, PAdES in a PDF, C2PA in an image, XML-DSig in XML, S/MIME in email, or a detached CAdES sidecar for anything else. Four facts have to hold: the bytes are intact, the signature is valid, the certificate chains to the pinned SEAL root (trusted), and the signature covers the artifactcompletely for its format. A valid signature from a certificate chaining elsewhere is a forgery vector, reported as unrecognised, never authentic.

Pinned root SHA-256: 02:68:6D:EE:20:67:31:C4:59:C1:7A:9F:58:36:7B:0B:0B:BA:5D:24:C6:85:D8:6D:1F:74:49:86:2D:C0:FE:BE · root of trust

The anchor, time

Verify the .otsproof against the public ledger with the stock client, no Let’s Seal server involved:

ots verify sealed.pdf.ots

Authentic = intact ∧ valid ∧ trusted ∧ complete.

All four, every time. A pass from any subset would accept a document whose bytes moved after sealing, or one that had content added afterwards. The anchor then adds independent proof of when it existed, and the revocation list is consulted where it can be reached.

What SEAL is

A published standard, open to everyone

SEAL is a published, versioned standard for a document proof: a PAdES/X.509 signature over the whole file, an OpenTimestamps anchor on Bitcoin, pinned to a public root. One self-contained artifact, one way to check it, the way the OpenAPI Specification or a sitemap is a standard anyone can implement without asking permission.

Let’s Seal is the project and the free network; SEALis the open standard it publishes. Seal a document through Let’s Seal and it conforms to SEAL, and so does anything anyone else builds to it.

Reference

Reference implementation: a standalone verifier (spec/verify.py) and the Apache-2.0 signing service. Verifying a SEAL proof needs a standard PAdES validator plus ots verify. That is the entire dependency list.