What a seal is
A record on Robinhood Chain, written against the hash of a contract's bytecode, that says three things. A fixed list of checks ran on that bytecode and every one passed, and here is the proof. An auditor read the source and signed an opinion, and here is the signature. That auditor has tokens locked behind this seal, and here is how many.
The name is the old one. A wax seal on a letter proved that the letter was whole and came from whoever owned the ring, and it did that without anyone opening the letter. A seal here proves that the checks ran on this exact code, without the code being shown to anyone but the one auditor.
It is a floor. It is not an audit in the sense of a firm reading every line for a month, and it does not say the code is good. It says what it says, and the section on what a seal cannot see says the rest.
What gets sealed
The keccak256 of the runtime bytecode. Not an address, not the source, not the deployer. A seal therefore follows the code: every contract on the chain with that exact bytecode wears it, and a contract with one byte changed does not. The seal page computes the hash from a deployed address or from bytecode pasted into the tab, and that is the only step that works before the registry is deployed.
The source is needed for the review and for the checks that read structure rather than opcodes. It reaches the auditor through a read-only GitHub grant to one repository, revoked when the review is done. The auditor compiles it and matches the result to the bytecode on the chain, byte for byte outside the metadata hash: if the source does not produce the deployed code, there is no seal, and that is the first thing the zk review decides.
The eight checks
Rule set one. Each is a yes or a no, run on the bytecode inside the proving machine, and the seal stores which ones passed. A seal with fewer than eight is still written, and shows the ones missing.
- 01No hidden mintNo path creates supply after deployment other than the ones declared in the interface.
- 02No owner drainNo function lets one address move balances that are not its own.
- 03Tax under the capIf there is a tax, it is fixed or bounded, and the bound is ten percent.
- 04No blacklistNo function can stop a specific address from selling.
- 05No pause on transferTransfers cannot be switched off after launch.
- 06Not upgradeableNo proxy, no delegatecall to an address that can change.
- 07Sell path clearsA buy followed by a sell completes, from a fresh address, on a fork.
- 08No self-destructNothing can remove the code once it is sealed.
The list is short on purpose. A check has to be something a machine can decide the same way every time, or it cannot be proven, and a check that is proven is worth more than ten that are promised. Rule set two adds checks the same way: published here first, then in the contract, never silently.
The zk review
The checks run inside a zkVM, a machine that executes ordinary code and produces a receipt that the code ran and produced that output. The receipt is small and anyone can verify it, including the registry contract, which does so before writing a seal. The receipt commits to the bytecode hash and to the rule set, so it cannot be reused for other code or claimed to cover other checks.
What the proof does not contain is the source, or the bytecode itself. It proves that the checks ran on something with this hash; the something stays with you. That is the whole point, and it is also the limit: the proof cannot be stronger than the checks that were run.
Privacy inside security
The usual bargain is that safety costs privacy: to be trusted, publish the source. A zk review refuses the bargain. The security check is done in full, on the real bytecode, by a machine whose work is proven; the privacy is kept, because what leaves the review is a hash, eight answers and a signed description, never a line of code.
The line is exact. Private: the source, the repository, its history, and who you are. Public: the bytecode hash, which anyone can recompute from the chain; which checks passed; the auditor's signed review, which describes what the code does without quoting it; and the auditor's key and stake. A review that quotes code is a broken review, and the auditor's stake is what that costs.
The review
A language model reads the source and writes down what it sees: what the contract does, who holds which keys, what looks off. The auditor signs that text and the signature goes in the seal. The review is an opinion. It is not proven and it is labelled as such, on this site and in the registry, in a separate field from the proof, so nobody can present one as the other.
We could have left the review out and kept the seal pure. We kept it because the checks catch the things machines catch, and the review catches some of the things a reader catches, and a seal that shows both, honestly labelled, is more use than one that shows only what can be proven.
Auditors and their stake
An auditor is a key with the platform token locked behind it. To sign a seal the auditor puts part of that stake behind the seal, and it stays locked for as long as the seal stands. The stake is what turns a signature into a promise: the review can be wrong, but being wrong costs money, and the amount is written on the seal.
At launch there is one auditor, run by us, so that the press exists. The registry accepts any key that stakes, and the aim is that ours becomes one among several, because a seal from an auditor who is also the registry is worth less than one from an auditor who is not.
Claims
If a sealed contract is exploited through something a check should have caught, anyone can open a claim against the seal, with the transaction that did the damage. The claim is decided by a vote of the stakers who are not the auditor in question. If it passes, the auditor's stake behind that seal and a share of the cover pool are paid to the holders the exploit hit, in proportion, and the seal is marked as failed rather than deleted, so its history stays readable.
A claim can only be about the checks. A contract that passed all eight and then rugged through something none of them look for is not a failed seal; it is a limit of the list, and the list is public. That distinction is what keeps auditors willing to sign, and it is also why the list has to grow.
The fee
A seal costs a fee, paid in the platform token, set in the registry at deployment and changeable only with a public delay. Where it goes:
- 50%The auditorWhoever ran the press and signed the review. Paid when the seal is written.
- 25%The cover poolHeld with the auditors' stakes. Paid out to holders of a sealed contract that is exploited.
- 15%BuybacksBuys the platform token on the market. What it buys is burned.
- 10%zkCheckWhat the platform earns.
Nothing is minted for anyone. The token has one job in the system, which is to be the thing an auditor can lose, and the fee is the thing that pays them for taking that risk.
What a seal cannot see
Anything not on the list. The eight checks are about the code's shape: what it can do to supply, to balances, to transfers, to itself. They do not see the deployer's intentions, the liquidity, the wallet that holds the tokens, or the pool the contract trades in. A sealed token with all of its supply in one wallet is still sealed.
State. A seal covers bytecode, and bytecode is the same for every contract with that code, so the seal cannot know which address is the owner of this deployment or what the constructor was given. Two deployments of the same sealed code, one honest and one not, wear the same seal.
The review. It is one model's reading, signed by one auditor, and it can miss things and can be wrong. It is there because it helps, not because it is proof, and the seal says which is which.
The vote. Claims are decided by stakers, and stakers can be captured or lazy. The cover pool and the stakes are the size they are, and a large enough exploit is larger than them.
Contracts
The registry is not deployed. Until its address is in the footer of this site, nothing described here exists on the chain, and no code has a seal. The seal page's hash is real; the rest is the design.
When it is: one registry contract holding seals, auditors and stakes, one verifier for the zkVM receipts, and one cover pool. Source verified on Blockscout, addresses on this page and in the footer, and the rule set as a constant in the registry that this page reads rather than restates.