A deployed contract cannot be patched on a quiet afternoon. Its code is public, its funds are one transaction away, and a flaw is exploited by whoever reads it first. The audit has to happen before deployment and has to be done by people who read every line.
Two auditors review the code independently and then compare results. Automated analysis and fuzzing support them, but the findings that matter come from understanding what the protocol promises and looking for the state in which the promise breaks. Contracts are one part of the risk: keys, upgrade rights and off-chain components are reviewed with them.
01Scope
What we test
Access control, ownership and privileged functions
Reentrancy, unchecked external calls and callback behaviour
Arithmetic, rounding, precision loss and unit handling
Denial of service: gas limits, unbounded loops, griefing
Deployment scripts, administrative keys and multi-signature setup
02Approach
How the work is done
01
Specification
We establish what the protocol is meant to guarantee. Where no specification exists, we write the invariants down and agree them with you.
02
Independent manual review
Two auditors read the code line by line, separately. Their notes are merged only after both have finished.
03
Automated analysis
Static analysis, fuzzing and invariant tests are run against the agreed properties. Tests written during the audit are handed over.
04
Fix review
Your fixes are reviewed against the original findings. The final report states the commit that was audited and the commit in which each issue was resolved.
Does an audit guarantee that the contract is safe?
No, and nobody can honestly give that guarantee. An audit is a time-boxed review of a specific commit. It reduces risk substantially and documents what was examined. The report says so in plain words.
Which languages and chains do you work with?
Solidity and Vyper on EVM chains are the core of the work. For other languages and virtual machines we confirm during scoping whether we have the right specialists and decline when we do not.
Can the code change during the audit?
The audit is bound to a frozen commit. Changes made during the audit are reviewed as a separate scope, otherwise the report would describe code that no longer exists.
Will you publish the report?
Only if you ask us to. A published report contains the full list of findings with their final status; we do not issue shortened versions that omit issues.