Verified module
Deterministic seed-and-token traits for replayable Flash editions.
Reproducible build
Everything the catalog records about this release.
The open, unminified files this release was built from. Each digest is the sha256 of the exact file contents.
Every published revision, and the KeelHold instance and object each one lives in.
This module has not been published to a chain yet. Its source is verified all the same: the digests above prove the readable TypeScript reproduces the exact minified bytes, and that proof does not depend on a deployment existing. Revisions appear here, with the address each one lives at, once it is published.
How readable source and onchain bytes stay the same thing.
The readable TypeScript above lives in the linked source repository, and its hashes are recorded in the catalog. The minified build has its own output digest, and the receipt digest commits to the inputs, toolchain, and output together. Changing a source file changes the recorded build. Publication uses those exact verified bytes; the deployment table shows whether that has happened.
Reproducible build means a third party checked out the source at these hashes, ran the build themselves, and produced byte-for-byte the same output digest. Nobody has to trust the publisher's compiler: anyone can repeat the check.
The VERIFIED badge is only shown when that independent check has actually passed. An unverified entry still links its source, but makes no claim.
Verified and deployed are separate facts. Verification is a statement about bytes: this readable source builds to exactly these minified bytes. It is earned before anything is published and it does not expire when nothing ever is. The section above records which revisions have actually reached a chain, and at which addresses, so you can see both answers instead of guessing one from the other.