# Let's Seal: an open standard for proving a file is unaltered, sealed and dated > Let's Seal publishes the SEAL standard and a reference engine that seals PDFs, media, XML, email and arbitrary files in each format's native signature, anchoring time to Bitcoin. The design is sound and the scope claims are unusually honest, but the repository is at v0.1.0 and the README leaves operational details, including rollback, undocumented. **letsseal/letsseal** — The open standard for proving any file is real, unaltered and sealed - Repository: https://github.com/letsseal/letsseal - Website: https://letsseal.org - Stars: 373 · Forks: 15 - Language: JavaScript - License: Apache-2.0 - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/letsseal-letsseal ## The problem Let's Seal targets: proof that survives the tool that made it Most document signing products produce an artifact that only the vendor's own verifier can check. That is a business model as much as a technical choice: the proof is only as durable as the company that issued it. Let's Seal inverts this. Its README states the goal directly, that a sealed file should be checkable by anyone with any conforming tool, and that verification is free and never needs an account. The standard it publishes, SEAL (Sealed Evidence Anchored to a Ledger), is the actual product. The engine, SDKs and command line tools in this repository are the reference implementation of it. The audience is narrower than the marketing suggests. This is for teams that already handle signed documents or signed artifacts and have felt the pain of vendor lock-in: legal and compliance groups that must keep signed PDFs readable for a decade, media teams that need provenance on images and video, and supply chain engineers who already sign containers and want the same guarantee for ordinary files. It is not aimed at someone who just wants to send a contract for signature once. The hosted app at app.letsseal.org covers that case, and the README treats it as a separate, free front end rather than the core of the project. ## How a seal is made and checked: native formats plus an OpenTimestamps anchor The mechanism is deliberately unoriginal, and that is the point. Let's Seal does not invent a container format. It picks the signature format that already belongs to each file type. A PDF gets a PAdES signature embedded in the file. Images, video and audio get a C2PA manifest embedded in the media. XML gets an enveloped W3C XML-DSig signature. Email gets S/MIME multipart/signed per RFC 8551. Anything else gets a detached CAdES or CMS .sig file over the SHA-256 of the content, and the README notes that in that case the file's bytes never leave the machine. Software artifacts and container images get a signature plus an in-toto or DSSE attestation carrying SBOM or SLSA provenance. Because the proof is native, a sealed PDF is still an ordinary PDF, and a sealed image still renders. Verification therefore does not require Let's Seal at all: the README points at standard validators, including openssl smime -verify for email and openssl cms -verify for detached signatures. That is the strongest architectural decision in the project, because it means the verifying side of the transaction can be a tool the reader already has. The second half of the proof is time. Every seal is anchored to Bitcoin through OpenTimestamps, so the claim that a file existed by a certain date does not rest on trusting Let's Seal's servers. Separately, each seal is written to an append-only transparency log following RFC 6962 with a Bitcoin-anchored root, so the record of what was sealed is itself tamper evident. The README is explicit that a seal establishes exactly three things: the file is unaltered, it existed by a date, and it was sealed by a specific certificate. Where an organisation has proven control of a domain, the seal carries that domain as a machine-checkable identity. ## Installing sealbot and sealing a first file The README lists three ways to seal: the hosted web app, the command line and API, and self-hosting the whole engine under your own certificate authority. The command line tool is called sealbot and the README's badge links it to the npm package of the same name, so the expected install path is npm. The README does not print an install command for it, so run the package through npx or install it globally and then use the two subcommands it documents. Sealing a PDF is one line. The README gives this example: ```bash sealbot seal contract.pdf # seal a PDF or any file ``` The comment in the README is the useful part: the same subcommand accepts a PDF or any other file, and the engine picks the appropriate native signature format for the type it detects. What you should see is a sealed output file. The README's verify example names it contract.sealed.pdf, so a PDF seal is written alongside the original rather than replacing it. Verification is the step that matters, and the README stresses that it runs offline: ```bash sealbot verify contract.sealed.pdf # verify a seal, offline ``` If you would rather not install anything, the reference verifier is a Python script in the spec directory and takes the sealed file plus its OpenTimestamps proof: ```bash python spec/verify.py sealed.pdf sealed.pdf.ots ``` The same seal can be created through the hosted API with an organisation key held in the LETSSEAL_KEY environment variable: ```bash curl -X POST https://app.letsseal.org/api/v1/seal \ -H "Authorization: Bearer $LETSSEAL_KEY" \ -F file=@contract.pdf ``` That endpoint takes a multipart file upload and returns a seal. The README also points at a public verification portal at verify.letsseal.org, where the verdict is presented in plain English and, per the README, subject and signer details stay private until the file itself is uploaded. ## What a seal does not prove, and where the documentation goes quiet The README's most valuable paragraph is its disclaimer. A seal is not notarisation, and it does not assert a person's real-world identity. The identity feature binds an email address that a provider verified at the moment of sealing, and the README calls this a provider verified email, adding that this is exactly what the feature delivers. Anyone expecting a seal to answer the question "who actually signed this" in a legal sense will be disappointed, and should be, because the project says so up front rather than in a footnote. Two other gaps are worth naming. The first is rollback and revocation. The README documents what happens when a byte changes: the signature breaks. It does not document how a seal is invalidated after the fact, what happens when an issuing certificate is revoked, or how the transparency log handles a compromised key. The repository has SECURITY.md and CPS.md, a certification practice statement, which are the places to look, but the README does not answer these questions and neither does the quickstart. The second is operational maturity. The most recent release is v0.1.0, published on 2026-07-23, and the last push to the default branch was on 2026-09-14. A first release with a certification practice statement is an unusual combination: the compliance scaffolding is ahead of the version number, which suggests the project is aiming at regulated users before it has a track record with them. There is also a Rust command line in the repository alongside the JavaScript one, and the README does not explain which is the supported path or whether they are at feature parity. ## Let's Seal compared with Sigstore and a plain PAdES workflow The closest real alternative for the software-artifact half of the problem is Sigstore. Sigstore's model is keyless signing tied to an OIDC identity, with signatures recorded in Rekor, a transparency log, and short-lived certificates from Fulcio. Let's Seal shares the transparency log idea and the topics list on this repository includes sigstore, but the two differ in what they sign and who holds the key. Sigstore is built around ephemeral identities and CI pipelines. Let's Seal is built around a certificate authority you can run yourself, under the ca/ directory, and around file formats that predate software supply chain concerns: PDF, XML, email, media. If your problem is a signed container image, Sigstore is the more established choice. If your problem is a signed contract that must remain verifiable in a standard PDF reader, Sigstore has nothing to offer and Let's Seal does. The other alternative is doing it by hand with OpenSSL and a commercial certificate. That works, and the README effectively admits it by pointing at openssl cms -verify as a valid way to check a detached seal. What you give up by going manual is the timestamp anchor and the transparency log. A CMS signature alone proves integrity and identifies a certificate; it does not prove the file existed at a particular moment without a timestamping authority, and it leaves no public, auditable record of the sealing event. Let's Seal's contribution is assembling those pieces, not inventing any single one of them. ## Licence, self-hosting and the upgrade cost of a first-release standard The repository is Apache-2.0, and there is a NOTICE file at the top level, which is the standard pairing for that licence. Apache-2.0 permits commercial use, modification and redistribution, and it includes an express patent grant, which matters for a project whose whole value is a cryptographic format. It does not give legal advice and it does not make a seal legally binding anywhere; that depends on the jurisdiction and on what the seal is being used to prove. The README's own framing, that the project is run as a public-benefit effort rather than a startup, is a statement of intent rather than a licence term, and it should be read as such. Self-hosting is offered as a first-class option: the README says you can run the whole engine yourself under your own certificate authority, and the repository contains a ca/ directory and a signing-service/ directory consistent with that. The cost of self-hosting is not the software, it is the certificate authority. You become responsible for key custody, for the certification practice statement in CPS.md, and for whatever your auditors require. The upgrade cost is the harder question. The SEAL standard is at version 0.1.0, and the repository carries a CONFORMANCE.md and an IMPLEMENTATIONS.md, which implies the project expects more than one implementation to exist. A standard at that stage can change in ways that invalidate artifacts you have already issued. Since the entire promise of a seal is permanence, that tension is worth taking seriously before you seal anything you intend to keep for years. ## Conclusion Adopt Let's Seal if you need a free, self-hostable way to prove a file is unaltered and existed by a date, and you are willing to run a v0.1.0 project under your own certificate authority. Do not adopt it if you need notarisation or proof of a person's real-world identity, because the README states plainly that a seal does not assert either. Before committing, verify three things yourself: that your target format has a validator you already trust, that the certificate authority under ca/ matches your compliance requirements, and that you can live with the upgrade path of a standard that is still at its first release. ## FAQ ### What does the phrase "let's deal" mean? It is unrelated to this project. Let's Seal is the open standard and reference implementation for proving a file is unaltered, sealed by a known certificate, and in existence by a certain date, and the repository name is letsseal/letsseal. ### How do I install Let's Seal's sealbot command line tool? The README's badge links sealbot to the npm package of the same name, so npm is the distribution channel, but the README does not print an install command. It documents the seal and verify subcommands, for example sealbot seal contract.pdf and sealbot verify contract.sealed.pdf. ### Can I verify a Let's Seal seal without an account or without Let's Seal? Yes. The README states that verifying is always free and never needs an account, and that a seal is written in the file's native format so any standard validator can check it. For a detached seal that means openssl cms -verify, and the reference verifier is the Python script at spec/verify.py. ### Does a Let's Seal seal prove who signed a document? No. The README states that a seal is not notarisation and does not assert a person's real-world identity. The identity feature binds an email that a provider verified at seal time, and the README's own term for that is a provider verified email. ## Sources - [letsseal/letsseal on GitHub](https://github.com/letsseal/letsseal) - [License: Apache-2.0](https://github.com/letsseal/letsseal/blob/main/LICENSE) - [Project website](https://letsseal.org) - [README](https://github.com/letsseal/letsseal/blob/main/README.md) - [Releases](https://github.com/letsseal/letsseal/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/letsseal-letsseal