What is open, and what is not
Open. The matching core, the protocol types, the identifier layer, the public SDK, the API and MCP surfaces, the operations crate, the deny gate, the conformance suite, and both contrast adapters. That is the code that decides what a yes means, what a no looks like, and what we can and cannot see. It is published on this page.
Not source, so not here. Our internal requirements document is not published on this page. It is a specification we write for ourselves, not code that runs, and publishing it would put our own internal working notes on a customer page. The code it describes is all here; you can read what the software does from the software.
Closed. Nothing in the matching path. What is not published here is deployment configuration and operator secrets — key material, host credentials, and the edge configuration. None of it changes the protocol's behaviour; all of it would compromise the operator if published.
This split is the point: you do not have to trust a description of what we do, because the part that does it is here.
Published here, not only in a repository
The source below is served from this site, taken whole from the commit named below. It is not a link to somewhere else that could change later, and it is not a stand-in archive.
- Commit:
278fd4f1e4b582a8ac3d6b0ca93549d0a97491ed - Files published:
117 - Per-file hashes:
source/SHA256SUMS.txt - Tree root:
source/
Checking it yourself
Fetch the tree and verify every file against the published list. If one byte differs, the check fails and says which file.
sha256sum -c SHA256SUMS.txt
To go further and rebuild: build the crates from this published source and compare the resulting library hashes with the ones recorded for this commit. That build reproduces, under a recipe the repository now pins for you — a rust-toolchain.toml fixing the compiler at 1.96.0, the release profile, dependencies vendored and built offline against the published Cargo.lock, CARGO_INCREMENTAL=0, and source paths remapped. Pinning the exact compiler version costs you a one-time toolchain download if you do not already have it; a floating channel would have cost you the ability to reproduce these hashes at all, once the compiler moved. The scripts we ran — one for a plain machine, one for a container — and the hashes from every run are kept as evidence in the repository under evidence/R10/reproduserbar-bygg/.
A build is only reproducible against the same toolchain. The comparison records the compiler version used, so a mismatch tells you whether you are looking at a different toolchain or a different source. We check the comparison is worth anything by trying to break it: changing a single byte of the published source changes the resulting library hash, and building on an older compiler does not produce a different hash so much as refuse to build at all. One warning from doing that: the single changed byte moved only the hash of the library it lived in, and left the other eight untouched, because a dependent library references its dependency rather than embedding it. Compare all nine, or you can perturb the source and still be told everything matches.
What this page does not claim
We still have not compared against production, and the requirement is still unmet. What we set ourselves is to rebuild from this source and match the hash of what is actually running. What runs here is a web server handing you static files; no compiled part of SealRelay runs in production at all. So the comparison has nothing on the other side of it — not a hash that disagrees, but no hash to fetch. We could have quietly reread the requirement as “matches the source we serve”, which it does, and called it met. It is not met. It becomes meetable when a built service is actually deployed, its executable hashed where it runs, and that hash matched against a rebuild of the source published for the same commit.
What we have witnessed, and where it stops. The crate that used to bake its build directory into the binary no longer does, so all nine libraries now build identically wherever you put the source. We have rebuilt them in a second, sealed environment — a different Linux distribution, a different C library, a different build path, no network — and got the same nine hashes, and the same different hash when we perturbed a byte. That is further than “it works on our machine”, and it is short of your machine: a different processor or kernel is still something we expect to work rather than something we have seen work. We are recording all of this rather than quietly leaving it out, because a source page that overstates what it proves is worse than one that admits a gap.
So the claim this page stands behind is the narrow one: the source published here is byte-for-byte the source of the commit named above, and you can check that yourself. Rebuilding it under the pinned recipe gives back the same libraries, in two different environments. Matching a running deployment is not something we have witnessed, because there is not yet a running deployment of anything we compile.