METHODOLOGY
Informed by formal methods. Grounded in practice. Focused on what breaks in the real world.
Security analysis is only as good as the questions it asks. Our methodology starts from a different premise: not "have we seen this bug before?" but "how could this system fail?"
Formal reasoning, not pattern-matching.
Most commercial audit firms operate by reviewing code against libraries of known vulnerability types — reentrancy, integer overflow, access control issues, and so on. A useful baseline, but it is not sufficient.
Known vulnerability databases contain bugs that have already been found and disclosed. They say nothing about novel failure modes: the bugs that have not yet been encountered in the wild, the edge cases that emerge from the specific interaction of this protocol's incentives, architecture, and assumptions.
Our team's formal methods background gives us a different lens. Formal verification is the discipline of reasoning systematically about whether a system can ever reach a bad state, given all possible inputs and execution paths. We apply this reasoning discipline to every engagement.
In practice, this means:
- We model what the system is supposed to do before reviewing what it actually does.
- We look for structural reasons a system might fail, not just surface-level code patterns.
- We are explicit about what our analysis can and cannot guarantee.
Findings grounded in exploitability, not theoretical edge cases.
Every finding in an audit report includes:
- Severity classification
- Critical, High, Medium, Low, or Informational, based on practical exploitability and potential impact, not theoretical severity alone.
- Description
- A precise explanation of the issue, including the affected code location and the conditions under which it can be triggered.
- Recommendation
- Concrete, actionable remediation guidance.
- Resolution status
- Updated after the remediation review phase to reflect whether each finding has been addressed.
Reports include an executive summary accessible to non-technical stakeholders, followed by the full technical findings.
After the initial report is delivered, we conduct a remediation review: we verify each fix applied by your team and update the finding status accordingly. The final report reflects the state of the codebase after remediation.
Typical engagement timelines range from two to four weeks depending on codebase size and complexity. We discuss timeline during scoping.
Ready to talk about your audit?
Tell us about your protocol, timeline, and scope. We will get back to you within one business day.