Why Let's Seal is a standard, built to outlive us
Most tools that promise to prove your documents are real are quietly asking you to trust them, and to keep paying them. We built Let's Seal the other way round, as an open specification that keeps working on its own, on public standards and a public ledger.
The problem with a proof you have to trust
There is a familiar trap with anything that claims to authenticate a document. The proof is only as durable as the company behind it. If the vendor raises its prices, changes its terms, gets acquired, or shuts down, the certificates you relied on can stop verifying, or fall hostage to a subscription. A proof that fails the moment the provider stops answering the phone was only ever a service you were renting, dressed up as evidence.
So Let's Seal is, at heart, a specification that anyone can implement, published under an open licence, resting entirely on standards and a public ledger. We run a friendly hosted version of it, though the hosted version is the least important part. What matters is that the format is open, the code is open, and the proof outlives us.
A specification, published and licensed to reuse
The format has a name and a version number. It is the SEAL specification, version 1.1, and it is published. Version 1 defined the core: a PAdES signature over the document, an OpenTimestamps anchor for the time, and the verification convention that ties them together. Version 1.1 is purely additive. It layers on optional profiles for supply-chain provenance, transparency-log inclusion, and provider-verified identity, while keeping exactly what it takes to conform to Version 1. Everything you sealed under the original spec stays valid, and new capability arrives as profiles you can opt into.
The licences are chosen so that reusing this is genuinely free. The specification itself is CC-BY-4.0, which means you may read it, quote it, translate it, and build on it, owing only attribution. The reference implementation is Apache-2.0, which carries an express patent grant to every implementer. That patent grant matters more than it sounds. It binds us: every implementer keeps the patent rights they need, permanently, including those who adopt long after the format catches on. The door is bolted open.
SEAL is free for anyone to implement, for any purpose, commercial or otherwise. Start today: read the spec and build. If a competitor wants to build a rival sealing tool on the same format tomorrow, we would count that a success, because it would mean the standard is doing its job.
Open all the way down
The whole thing stands on four pillars, and each one puts control in your hands. It is open source, Apache-2.0 on GitHub. It is built on open standards: PAdES signatures, X.509 certificates, SHA-256, and OpenTimestamps, every one of them public and maintained beyond us. It records to an open ledger: the blockchain, plus an append-only transparency log whose root we publish. And it is designed to run yourself, keeping your own keys. Prefer to run everything on your own hardware? The entire system self-hosts, and the recipe is short.
git clone <the repo> cp .env.example .env ./deploy.sh
That is the full deployment. Clone the repository, copy the example environment file, run the deploy script, and you have your own instance of Let's Seal, issuing seals in exactly the same open format. The seals your instance produces verify against the same public standards as ours, because they are the same standards. The whole system is the open one you can read, and everything needed to run it ships in the repository. Prefer to stand on your own? Run your own instance, free.
Verifiable by anyone, forever
Here is the test we hold every design decision to. Both sealing and verifying must run on public standards and a public ledger alone, so the proof stands on its own, outliving the project. This is a constraint we designed the format around, and it is the reason the format looks the way it does.
The minimal dependency for checking a seal is short enough to state in one sentence. You need a standard PAdES and X.509 validator, plus the stock OpenTimestamps client. That is the entire dependency list. Both tools are open, widely available, and maintained by communities independent of us. Even if Let's Seal vanished tomorrow, every seal ever made would stay verifiable with software you can already download today. The proof belongs to the public formats it is written in.
Stewarded for the public good
It helps to say the governance plainly, because vague governance is how open things quietly get enclosed. Let's Seal is stewarded by Experimental Open Works, a home for free, public-benefit infrastructure. The shape of that arrangement is deliberately the same as the one behind Let's Encrypt, which is run by the nonprofit ISRG. The name echoes Let's Encrypt on purpose. It is a promise about what kind of thing this is.
Experimental Open Works runs on public-benefit footing, answerable to its users alone. Sealing is free and verifying is free, permanently, the kind that stays free once you depend on it. The only people to satisfy are the users, so your proofs stay yours to reach.
That is the difference between a product and a standard. A product is something you buy, and it lasts as long as the seller wants it to. A standard is something you build on, and it lasts as long as anyone still uses it. We chose to be the second kind, and we built Let's Seal so the choice holds, even against a future us that might wish otherwise.
Every claim here is something you can check yourself, offline, with tools we do not control. That is the whole point.