Security audits for high‑stakes Web3 protocols

A security audit helps identify vulnerabilities, broken assumptions, and edge-case failures before they can affect users or locked value. For high-stakes Web3 systems, the risk is rarely limited to simple code bugs: issues can appear in protocol logic, access control, integrations, upgrade paths, economic assumptions, cross-chain flows, or off-chain components. A good audit gives the team an independent review, practical remediation guidance, and a clearer security baseline before launch, upgrade, or major integration.

Yes. We usually start with a short scoping review to understand the codebase, protocol architecture, documentation, integrations, and main risk areas. This helps define what should be included in the audit, what can be excluded, and whether the review needs additional focus on threat modeling, economic assumptions, cross-chain flows, ZK components, or off-chain logic. For large repositories, we can also propose several audit scope options with different budgets, so the team can choose the most practical balance between coverage, timeline, and cost.

Yes, but only as supporting tools. Automated scanners, static analysis, fuzzing, and AI-assisted review can help improve coverage and surface issue drafts faster, but they do not replace manual security work. In practice, AI shifts part of the effort from finding suspicious patterns to validating them, understanding the project’s security model, classifying severity, and producing a report that is accurate and useful for humans. The core of the audit remains senior-led threat modeling, code review, issue validation, remediation guidance, and final human judgement.

No. We can review the full security-critical surface of a Web3 system, not just isolated contracts. Examples include bridge message verification, oracle integrations, relayer logic, multisig and governance permissions, upgrade paths, deployment scripts, custom blockchain nodes and execution environments, indexers, off-chain transaction builders, sequencer assumptions, and interactions between contracts and external systems. For complex protocols, important risks often appear at these boundaries rather than inside a single contract.

Question: How long does a security audit take? Answer: Most security audits take 1 to 3 weeks, depending on codebase size, protocol complexity, documentation quality, and review scope. Focused private reviews can sometimes be completed in less than a week, but public audits usually require at least one week because findings need careful validation, remediation tracking, and precise report wording. Complex systems involving ZK, custom execution environments, virtual machines, cross-chain infrastructure, or novel protocol logic can take significantly longer, sometimes across multiple months. If timelines are tight, we can sometimes accelerate the review by assigning multiple auditors in parallel, but we still scope the audit first so the timeline reflects the actual risk surface.

The cost depends on the codebase size, protocol complexity, review scope, timeline, and whether the audit is private or public. We usually start with a short scoping review, then provide a fixed quote based on the actual risk surface rather than a generic package. Public audits typically cost more than private reviews because findings require additional validation, remediation tracking, and careful report preparation. The cost can also increase for complex DeFi logic, cross-chain systems, ZK components, custom execution environments, threat modeling, or economic security analysis.

While it is theoretically possible for an audit to find zero vulnerabilities, it is uncommon in practice. Across 50+ security reviews, we have only had one audit where no serious issues were found, and even that review produced informational findings and hardening recommendations. A good audit result does not necessarily mean “zero findings”; it means the system was independently reviewed within the agreed scope, material risks were not identified, and any smaller issues or improvement opportunities were clearly documented.

The audit scope is defined before the review starts and usually includes a specific repository, commit hash, contracts or modules, documentation, deployment assumptions, and any integrations that should be reviewed. Depending on the system, the scope may also include protocol logic, upgrade paths, privileged roles, cross-chain components, ZK circuits, custom blockchain nodes and execution environments, off-chain services, or economic assumptions. Anything outside the agreed scope is not treated as reviewed unless we explicitly include it.

Yes, if the audit is scoped as a public engagement. In that case, we prepare a report that can be shared with users, partners, investors, and ecosystem stakeholders. Public reports include validated findings, severity levels, remediation status, and enough technical context for external readers to understand the reviewed scope. Before publication, we coordinate with the client to verify fixes, avoid unnecessary disclosure risk, and make sure the report accurately reflects the final state of the review.

Before the audit starts, finalize the scope, clean up obvious to-dos, remove dead code, and make sure the documentation explains the protocol architecture, intended behavior, trust assumptions, deployment setup, and known limitations. The codebase should be frozen for the audit, with a specific commit hash shared with us. Changes during the review may require re-checking affected parts of the scope, which can add extra work and may affect the timeline or cost, so it is better to complete major refactoring before the audit begins.

We start by understanding the protocol architecture, documentation, threat model, and intended behavior. Then we review the code manually, supported by automated tooling where useful. The audit focuses on vulnerabilities, broken assumptions, access control, upgrade paths, economic edge cases, integration risks, and protocol-specific failure modes. Findings are validated and documented with practical remediation guidance. After the client applies fixes, we review the changes and verify remediation, often through several iterations before the final report.

After the audit, the team reviews the report, prioritizes findings by severity, and applies fixes. We provide remediation guidance and then review the updated codebase to verify whether the issues were properly addressed. This often happens over several iterations, especially for complex findings. For public audits, we update issue statuses after remediation review and prepare the final report for publication.

For remediation review, provide the updated codebase, commit hash, and a short explanation of how each finding was addressed. Ideally, fixes should be submitted as separate pull requests for each issue or group of related issues. This makes review easier, keeps discussion attached to the relevant change, and allows follow-up fixes to be added to the same PR if needed. For public audits, this also reduces ambiguity when updating issue statuses in the final report.

Yes. We can review deployed protocols before an upgrade, integration, migration, governance change, or major liquidity event. In this case, the audit usually focuses on the current deployed state, planned changes, privileged roles, upgrade paths, configuration risks, and interactions with existing users, assets, and external systems. For live protocols, our recommendations take upgrade requirements and operational constraints into account, so remediation can be planned safely without introducing unnecessary disruption.

A private audit is performed for the client’s internal use. The findings, remediation guidance, and final report are shared with the team but are not published unless the client decides otherwise. A public audit follows a similar technical review process, but the final report is prepared for external readers and published after remediation review. Public reports usually require more validation, clearer wording, issue status tracking, and careful coordination with the client, because they become part of the project’s public security record.