How an audit actually works.

Your code frozen at one commit, a list of what’s in and out of scope, and a build that works from a clean clone with one command. We also need a plain-English description of what the protocol does and how money moves through it, the invariants you believe always hold, every admin, owner, upgrade or pause key and who holds it, and what you assume about each external dependency such as oracles, bridges, and other protocols. Any change to the code after the freeze is a scope change.

Previous audit reports and how each finding was resolved, known issues and accepted risks so we don’t report them as new, the areas your team is most worried about, your existing test suite and coverage, and one technical contact who can answer questions within 24 hours. Everything here makes the audit faster and the results more accurate.

We also need the chain and network, the deployed addresses or package IDs, the currently deployed version, the diff, and the migration plan. For live protocols, the expected value locked and the tokens held help us size the impact of each finding.

Pricing is a fixed quote based on the size and complexity of your codebase, not an hourly meter. Send us your repo and we’ll return a quote within 24 hours, before any commitment.

It depends on scope. A single contract can take days; a full protocol is typically measured in weeks. You get a firm timeline with your quote. We recommend booking before your code freeze so findings can be fixed before deployment.

Solidity for Ethereum and EVM chains, Rust for Solana (Anchor) and CosmWasm, Move for Aptos and Sui, and Go for Cosmos-SDK chains and infrastructure.

Before your code freeze. We start when the code is frozen at one commit, so booking ahead lets us line up the start with your freeze and leaves time to fix findings and have us verify the fixes before you deploy. We also need your deploy scripts and the configuration you’ll deploy with, since misconfigured constructor arguments, fees, and caps are a common source of issues.

Yes. For an upgrade we review the diff against the currently deployed version, along with the migration plan, and quote it the same way as any other scope. It matters because a grade covers one exact commit and deployment. If your deployed code or admin setup changes, the grade is out of date until we re-review.

Three things. Every finding is backed by proof: a runnable test, and on the Fork tier a working exploit against real on-chain state. Severity is scored with OVSS, an open scoring system you can recompute yourself, rather than a label we choose. And you get a fixed quote within 24 hours, with a re-review of your fixes included.

The audit covers your on-chain code. The dapp review covers everything around it: the frontend, wallet and signing flows, APIs, off-chain services like bots and keepers, and infrastructure, including the traditional web vulnerability classes. Most teams need both, and we scope them together or separately.

We classify your protocol (lending, DEX, vault, bridge, staking, and so on), then build a framework for it: a base checklist that always applies, plus modules for your protocol type. We write a one-page threat model covering the assets that can be stolen or frozen, the actors (users, admins, keepers, attackers with flash loans), and your trust assumptions. Your invariants become tests where they can be tested. You sign off on the framework, the commit hash, and the scope before testing begins, and the framework becomes the table of contents of your report.

Core is a static-analysis scan plus a manual review of your flattened code by a senior researcher. Fork adds testing on a fork of the live network, where we write working exploits against real on-chain state. Core findings are confirmed with a local test or a traced code path; Fork findings are confirmed with an exploit that runs on the fork. Fork is the stronger proof and is added on top of Core.

We merge your contracts and their imports into a single linear source so a reviewer can follow every call path without jumping between files. For each function a user or admin can call, the reviewer works out who can call it and what guards it, what it reads and changes and in what order, which external calls it makes, where money moves, and which assumptions it relies on.

We run established static-analysis tools and our own rules, then merge their output into one list of leads with duplicates removed. A scanner result is never a finding on its own. A human confirms each lead before it goes in your report, and we track which rules produce false positives so they can be fixed or retired.

We deploy exactly the way your scripts do and check the resulting owners, admins, and parameters. We then run your test suite and our own invariant and fuzz tests, and attempt realistic attacks: flash loans, oracle manipulation against real pools, sandwiching, admin key misuse, and upgrade paths. We also test integration edge cases such as tokens with fees or blocklists, paused dependencies, and stale oracles. Every exploit is saved as a runnable test.

Every audit tests all ten categories of the OWASP Smart Contract Top 10 (2026), translated for your chain, and your report shows how each was tested, including “tested, nothing found.” Beyond that list, we test attacks that need real on-chain state, such as cross-protocol composability, bridge message forgery, signature replay, front-running and MEV, and governance manipulation.

No. Forks never broadcast to a real network, and we use test keys and address impersonation only. We never hold real private keys. For anything live, we agree rules of engagement with you first: which systems we may test and at what rate limits.

A confirmed Critical doesn’t wait for the final report. We send it to you with its severity, exploit scenario, and recommended fix as soon as a researcher has confirmed it, so you can start fixing right away. Critical findings that are still open or acknowledged at the end give the audit an F.

You receive each confirmed finding with its severity, an exploit scenario, and a concrete fix. You fix them and send us the patch, and we re-review it and confirm closure. One round of fix re-review is included, so the final grade reflects verified code.

Yes, to help with high-volume work: sorting scanner results, drafting test harnesses and attack tests, and drafting write-ups from confirmed tests. A human reviews all of it. AI never decides a severity, marks a finding as fixed, or sends anything to you without human review.

Only with your written consent, which we collect in the engagement letter. Secrets, private keys, environment files, and personal data are stripped before anything is sent to any AI service. If you decline, we run the same process on a different route. Code for unreleased products under strict NDA uses a more restricted route by default. The route used is recorded in the audit log and disclosed in your report.

On-chain findings are scored with OVSS, the open Onchain Vulnerability Scoring System we publish, which rates each finding from 0.0 to 10.0 from a short vector anyone can recompute. Web2 findings use CVSS 4.0. You can try OVSS yourself with the calculator at /ovss.

Each finding has a severity with its score vector, the OWASP category it falls under, a description, the impact, a runnable proof-of-concept test, and a recommended fix. The report also includes the executive summary, scope and commit hash, the threat model, and a coverage table for the OWASP Top 10.

Yes. The final report is written to be publishable to your community, investors, or shareholders. Whether it goes public is your call. We can agree to hold back anything you want kept private until it’s fixed.

Tell us. Each finding can be disputed with your reasoning, and we’ll re-examine it against the code. Findings you decide to accept as a risk are recorded as acknowledged, and they’re reflected in the report as such.

Yes. Each audit ends with a letter grade from A to F for one exact commit and deployment, built from seven categories: code security, access control and key management, upgradeability and admin power, external dependencies, testing and verification, web2 and operations, and documentation and transparency.

No. Hard caps prevent it: any open or acknowledged Critical finding means an F, and any open or acknowledged High finding caps the grade at C. Findings we verify as fixed on retest don’t count against you.

No. It applies only to the audited commit and deployment. If the deployed code or the admin setup changes, the grade is out of date until we re-review.

Each audit runs in its own isolated environment, and customer code stays on an encrypted disk. It is never committed to shared repositories. At the end of the retention period set in your engagement letter, it’s deleted.

Yes. We can work under your NDA, and the engagement letter also sets out how your code is processed, which AI services (if any) may see it, and how long we retain it. For unreleased products under a strict NDA, we use the more restricted processing route by default.

Only the people working on your audit, and any AI service you’ve consented to in writing, after secrets and personal data are stripped out.