Methodology
How a review is run
The method is fixed and versioned, so two cycles can be compared and a change of method is visible.
Cadence
When
Reviews run every two months, plus a review on every release. Two events start one: the calendar, and a release. The procedure below is method v1. A cycle marked v0 predates it and is recorded with whatever its own report supports.
- Full review. The whole in-scope codebase, the deployed state, and the release process.
- Differential review. Everything that changed since the last reviewed commit, before the change is scheduled for deployment.
Procedure
What happens in a cycle
- Freeze the target. Record the commit, the toolchain, a pinned block and the exclusions. Conclusions about the source, about the deployed contracts and about off-chain assumptions are kept apart.
- Verify the deployment. Read each implementation address from its proxy at the pinned block and compare live bytecode with a build of the reviewed source.
- Review by component. Separate reviewers take separate components. Every suspected issue goes into a hypothesis ledger, including the ones that are ruled out.
- Prove it. A suspected issue becomes a finding when a test reproduces it. A lead reviewer re-runs the tests and grades each finding by evidence level.
- Run the machines. Static analysis across the full detector set, a stateful invariant fuzzing campaign, and a recurrence check against earlier findings.
- Archive and disclose. Supporting material is retained internally. Once remediation is live and the disclosure delay has passed, the approved findings and their resolutions are published.
Grading
Severity
- Critical
- Direct loss or permanent freezing of user funds, reachable by an unprivileged caller.
- High
- Loss or freezing of funds that needs a realistic precondition, or a privileged key acting outside its stated limits.
- Medium
- Bounded loss, denial of service on a core flow, or a control that can be bypassed.
- Low
- Defects with limited impact, hardening gaps, and process or tooling weaknesses.
- Informational
- Observations that carry no direct risk.
Severity is rated for the design at scale, not for the value at risk on the day of the review.
Grading
Evidence level
- Verified
- Confirmed by the lead reviewer against the code and the chain, or by re-running a proof-of-concept test.
- Reproduced
- A proof-of-concept test written by a component reviewer passes when re-run by the lead.
- Read
- Established by reading the source only. Reported, but flagged as unconfirmed.
Tools, not endorsers
About the AI models
The reviewers are general-purpose frontier language models, named in each cycle record. They are tools that Quantillon operates. Their vendors have no relationship with Quantillon, have not examined the protocol, and endorse nothing on this site.
A model can read every line of a codebase, write and run tests, and never tires. It can also be confidently wrong, share blind spots with other models, and miss what a specialist with protocol-specific experience would see. That is why findings must be reproduced, why the limits of each cycle are published, and why a third-party audit remains the goal.