A smart contract audit answers one question — is the code vulnerable? — and leaves several unanswered. Whether the contract does what the disclosure says it does, whether the token economics are sound, whether the logic creates legal obligations the issuer has not accounted for, and whether the risk is described honestly to users: none of those are code-review questions, and all of them cause failures.
We coordinate the technical audit and own the surrounding assurance. Independent security review of the contract logic, combined with review of the economic design, the disclosure and the legal character of what the contract actually does.
The engagement is deliberately not a substitute for a qualified security auditor, and we do not present it as one. It is the layer above: making sure the audit that exists is the right one, that its findings are addressed, and that the surrounding claims are defensible.
- You are about to launch a contract that will hold or route significant value.
- You have an audit report but need its findings assessed and its scope confirmed.
- Your disclosure claims and your contract behaviour may not fully align.
- Token economics or oracle dependency create risk that a code review will not catch.
We coordinate, we do not pretend to audit
Code-level security review requires specialists, and we are not one. We select and brief them, and own the risk, disclosure and economic analysis around the audit.
Code and promise must match
The most damaging failures are not exploits but contracts that do something other than what holders were told. We test the disclosure against the behaviour.
Economics are part of the risk
Incentive design, oracle dependency and governance attack surfaces are risk questions that a line-by-line code review frequently does not address.
- Audit scope definition and independent-auditor selection
- Technical audit coordination and remediation tracking
- Disclosure-versus-behaviour consistency review
- Token economics and incentive-design risk assessment
- Oracle, governance and dependency attack-surface review
- Risk disclosure and user-facing documentation alignment
- 01
Scope the risk
What the contract holds, what it controls and what depends on it — which determines the depth and the focus of the review that is needed.
- 02
Select the auditor
A firm whose specialism matches the contract type, briefed on the specific risks rather than handed a generic engagement.
- 03
Coordinate and track
Managing the review, then tracking findings through to remediation and verification rather than filing the report.
- 04
Review economics and logic
Incentive design, dependencies and governance surfaces assessed for risks that sit outside the code.
- 05
Align disclosure
Checking that what is said publicly matches what the contract does, and closing the gaps before launch.
Audit scope and readiness
Defining what needs auditing, selecting the auditor and preparing the contract for review.
Assurance programme
Technical audit coordination plus economic, disclosure and dependency review through to launch.
Pre-launch risk review
A focused pass on an audited contract ahead of a launch or a significant upgrade.
- Anyone seeking a document that stands in for a genuine technical audit — we will not issue one.
- Projects that will not act on adverse findings, because an unaddressed audit finding is worse than no audit.
No, and we are direct about that. Code-level security review is a specialist discipline and we bring in auditors who do it properly. Our role is to define the scope, select the right firm, coordinate the process and own the wider risk, economic and disclosure analysis around it.
Typically reentrancy, access control, arithmetic, upgrade and authority surfaces, and known vulnerability classes for the language and platform. What it usually does not cover is whether the economics are sound, whether the disclosure is accurate, or whether an oracle dependency creates a failure mode — which is why our engagement sits alongside it.
On every material change to logic, authority or dependencies, and after any incident. A stale audit of a contract that has since been upgraded is not assurance; it is a document about a different program. We treat upgrades as requiring fresh scope.
No. An audit reduces the probability of specific defect classes and produces evidence of diligence. Residual risk always remains, and part of our work is making sure the disclosure and the user-facing documentation describe that honestly rather than implying the code is risk-free.