About the registry
What we certify, how, and the disclosure rule that shapes everything on this site.
Method
Hooks are enumerated from on-chain Initialize events, analyzed by a closed prover, and emit a re-checkable witness. That witness is then re-validated by the open-source MIT tarski-verify-veric checker. A hook is published here only if that independent re-check returns PASS.
The boundary is deliberate: you trust the public property statement and the open checker — not the prover, not veric, not this website. Every cert links the exact bytecode it pins, its witness, and a one-line command to re-derive the result yourself.
Trust flavours
A PASS is not monolithic. Each cert carries an explicit trust flavour — the basis on which the PASS rests. The three form a total order of strength, and we never blend, average, round up, or hide them. Every row shows its actual flavour; there is no aggregate or portfolio flavour.
Strongest. The open checker re-derives the whole conclusion from the witness, against a semantics the bytecode conforms to. Nothing is assumed.
Middle. Obtained mechanically (no human judgement) but resting on an explicit declared assumption recorded in the cert — e.g. an out-of-scope delegatecall target.
Weakest. A sound PASS produced under a documented degradation (e.g. a widened over-approximation of an unbounded loop). The property holds, but on a materially weaker basis than conformance.
Disclosure policy
We publish only hooks we can prove safe against the cork-class property. We do not publish findings. A hook that is not listed has not been certified — that could mean it was not yet checked, could not be certified at any flavour, or is in coordinated disclosure. We never say which.
Absence from this registry is not a statement about a hook’s safety. There is no list of failing hooks, no count of what we checked, and no way to read a finding off this site by elimination.
Building something on v4 and want to reach us? Contact security@veric.audit.