The badge sits on a lot of landing pages. “Audited.” Sometimes it links to a PDF. Sometimes it just links to a logo. People read it and feel safer. That feeling is the problem I want to address, because an audit — a real one — is not a safety certification. It is a structured, time-bounded, scope-defined investigation, and understanding what that means is the first step to actually benefiting from one.
I do this work. What follows is how I actually think about it.
Why the Badge Is Not the Point
The symptoms of audit theater are recognizable: the cheapest possible audit, an “audited by ___” badge added to the website, no remediation visible in the report, scope conveniently excluding the riskiest contracts. The real cost is false confidence — investors and users assume risk has been managed when it hasn’t.
The badge is a signal. The report behind it is the substance. And the process that produced the report is the thing that actually determines whether you got a security review or a stamp.
Let me walk you through the process as we run it.
Phase 1: Scoping
Before any code gets read, we sit down and define the engagement. This is not administrative busywork. Scoping is where the quality of the audit is either set up or sabotaged.
We define objectives and constraints: assets at risk, supported chains, scope boundaries — new contracts only versus integrations — and whether upgrade-path review or formal verification is included. Every one of those decisions has consequences. A scope that excludes the oracle integration saves some time and money on paper, while leaving the most dangerous trust boundary entirely unexamined.
We collect complete documentation: protocol specification, architecture diagrams, flow diagrams for critical operations such as lending lifecycles, liquidations, swaps, and governance proposals, and a threat model if one is available.
We also establish a pinned commit. If no one knows which commit is the audit target, or if deployment is planned from a later branch that is “basically the same,” confidence collapses immediately. This is one of the most common ways teams accidentally market an old audit as if it covers new code.
If the team arrives with no documentation and can’t articulate what the protocol is supposed to do, that is a serious problem. If the team cannot explain what can go wrong, what must never happen, or what the most sensitive assumptions are, auditors have to reverse-engineer the security story from code alone. That burns time and lowers review quality.
Phase 2: Threat Modeling
Once scope is locked, we threat model. This is the adversarial design review that happens before the line-by-line code walk.
Once the scope is set, the team does threat modeling. This means explicitly writing down system assumptions and attacker capabilities. We ask: who is the adversary? What do they want? What do they control? What trust boundaries exist in this system, and which ones are the weakest?
Auditors challenge the design: what happens if your price oracle lies? If a multisig key is compromised? If an external integration misbehaves? By modeling these scenarios up front, design flaws emerge early. In fact, some of the costliest exploits — beyond missing required checks — stem from flawed assumptions about upgrades, incentives, or trust boundaries.
Threat modeling is where you find architecture-level problems that no tool will ever detect. A re-entrancy guard does nothing when the fundamental access control model is broken. Tools find symptoms; threat modeling finds root causes.
Phase 3: Manual Senior Review
This is the core. Everything else in the process is support for this.
Manual review is a senior engineer reading your code with an adversary’s mindset. Not scanning it. Reading it. Understanding the intended behavior, modeling the unintended behavior, and asking, at every non-trivial line: what happens if this assumption is wrong?
Automated tools alone cannot identify complex business logic flaws or economic vulnerabilities. Manual code review is essential for understanding how the contract behaves under real-world conditions.
The things that kill protocols — the logic errors, the subtle state inconsistencies across multi-step interactions, the economic attack paths, the governance manipulation vectors — these do not pattern-match to a detector. High-level logical vulnerabilities that automated tools are fundamentally unable to detect include flawed economic math, incorrect state updates across multiple transactions, or subtle integration risks with external protocols.
Manual review is also where protocol-specific context gets applied. A flag that looks like reentrancy in isolation might be intentional design when the business logic is understood. A function that looks safe in isolation might be catastrophically dangerous when combined with a specific call sequence from another contract. You cannot see that from a static output. You need to understand the system.
The seniority of the person doing this review is not a credential on a bio page. It is the direct determinant of what gets found. This is the most important thing I can tell you about audit quality: who reads the code, and how carefully.
Phase 4: Automated Tooling
We run tools. Three in particular do meaningful work when used well.
Slither — Static Analysis
Slither is a Solidity and Vyper static analysis framework written in Python3. It runs a suite of vulnerability detectors, prints visual information about contract details, and provides an API to easily write custom analyses. Slither enables developers to find vulnerabilities, enhance their code comprehension, and quickly prototype custom analyses.
It works by converting Solidity smart contracts into an intermediate representation called SlithIR. SlithIR uses Static Single Assignment form and a reduced instruction set to ease implementation of analyses while preserving semantic information that would be lost in transforming Solidity to bytecode.
Slither allows for the application of commonly used program analysis techniques like dataflow and taint tracking. Its framework has four main use cases: automated detection of vulnerabilities, automated detection of code optimization opportunities, improvement of the user’s understanding of the contracts, and assistance with code review.
What Slither does well: it is fast, it is thorough on known patterns, and it surfaces things worth investigating. Slither’s proficiency in extracting detailed code syntax and semantic information — including inheritance graphs, function call graphs, and state machine representations — has been well-documented in prior research.
What Slither cannot do: it cannot understand your protocol’s intention. It generates false positives that require human triage. And it will not catch a flaw that emerges from correct-looking code interacting with a system in a way that violates an economic invariant. Automated tools are great, but not enough on their own. It is essential to combine Slither with manual code review, especially for high-value projects.
Echidna — Property-Based Fuzzing
Echidna is a Haskell program designed for fuzzing and property-based testing of Ethereum smart contracts. It uses sophisticated grammar-based fuzzing campaigns based on a contract ABI to falsify user-defined predicates or Solidity assertions.
The key word is “property-based.” Echidna belongs to a specific family of fuzzer: property-based fuzzing heavily inspired by QuickCheck. In contrast to a classic fuzzer that will try to find crashes, Echidna will try to break user-defined invariants. In smart contracts, invariants are Solidity functions that can represent any incorrect or invalid state that the contract can reach.
Echidna automatically generates scenarios in test cases to break user-defined invariants, helping to uncover bugs, logic flaws, and unexpected behaviors. Invariants can be defined as conditions or properties of a smart contract that must always be true, regardless of how the contract is used or which sequence of function calls is executed. Echidna continuously attempts to violate these invariants by exploring edge cases and unexpected interactions.
What this means in practice: I write properties that express things the protocol must never allow — a user’s balance going negative, total withdrawals exceeding total deposits, a paused contract accepting transfers. Then Echidna hammers those properties with millions of randomized call sequences trying to make them fail. When it finds a counterexample, it minimizes the call sequence automatically so I can reproduce and analyze the failure cleanly.
The limitation: Echidna is only as good as the properties you give it. If you do not define an invariant, Echidna cannot violate it. The quality of the fuzzing campaign is bounded by the quality of the property specification, which requires the same protocol understanding that manual review demands.
Foundry — Tests and Invariant Suites
Invariant testing in Foundry takes the concept of property testing further by maintaining contract state across multiple function calls, testing that certain properties remain true throughout complex multi-step interactions. This approach is particularly valuable for testing DeFi protocols where token balances, exchange rates, and other critical metrics must satisfy mathematical relationships regardless of the sequence of operations performed.
Invariant testing lets you declare rules — like “totalSupply always equals balances” — and have Forge hammer your protocol until either the rule breaks or your confidence increases. Invariant tests are stateful fuzz tests that assert rules which must always hold true, even after any sequence of contract calls.
Invariant testing is a powerful technique for uncovering flawed assumptions and incorrect logic in smart contracts. By executing randomized sequences of function calls with fuzzed inputs, it reveals edge cases and failures that often go unnoticed in conventional testing, especially in complex or stateful protocols.
We also use Foundry to write targeted exploit test cases: once we’ve identified a potential vulnerability in manual review, we write a test that actually demonstrates the exploit. A finding without a proof of concept is conjecture. A finding with a passing test that drains a contract is a fact.
Phase 5: Findings Triage by Severity
Raw findings — from manual review, from tool output, from fuzzing — need to be evaluated before they go into a report. Triage is where we determine what is real, what is a false positive, what is already mitigated by design, and how severe the genuine issues are.
These classifications help developers and auditors understand which issues demand immediate fixes and which can be addressed over time: Critical is complete compromise of funds or system control; High is major loss or disruption requiring urgent attention; Medium is limited or situational risk that affects part of the system; Low is minor inefficiencies or best-practice improvements that don’t impact security directly.
Identified findings are categorized based on severity, exploitability, and potential impact. Severity is not just about what could go wrong in theory — it is about the combination of impact and likelihood under realistic conditions. A critical-impact vulnerability that requires an extremely improbable chain of events is rated differently from one that is trivially exploitable.
Professional audit reports categorize issues by severity and provide exploit narratives alongside recommended fixes. Every finding in a Darkwave report includes: what the vulnerability is, how it can be exploited, what the impact is, and a concrete recommendation for remediation.
Informational findings — gas optimizations, code style observations, documentation gaps — also get logged, clearly separated from security findings so the severity table is not diluted.
Phase 6: Formal Report and Signed Attestation
The report is not a summary. It is a reproducible record of the engagement: what was in scope, what commit hash was reviewed, what methodology was applied, what was found, what was fixed during the remediation window, and what remains open with accepted risk.
After the team patches issues, auditors perform a focused retest and issue a final status update showing what was fixed, what changed in scope, and what remains as accepted risk.
We sign the final report. The attestation is a statement that the described methodology was actually followed on the described scope at the described commit. It is not a statement that the code is free of bugs.
That distinction matters enormously. Read on.
What an Audit Cannot Promise
Audits are point-in-time reviews. They examine the code as it exists at a specific moment. If the protocol updates the code after the audit, those changes are not covered. Many exploits happen in code that was modified after the audit.
One of the most significant smart contract audit limitations is this point-in-time nature. Code evolves, dependencies change, and the threat landscape shifts continuously. Between audit completion and deployment, code gets patched, features get added, and integrations get modified.
Audits cannot find every vulnerability. Smart contract security is hard. Even the best auditors miss things. Novel attack vectors emerge constantly. What is considered safe today might be vulnerable tomorrow.
Audits examine individual contracts, but real protocols exist within complex ecosystems of interacting contracts, governance mechanisms, oracle feeds, and economic incentives. Auditors cannot model every interaction a protocol might have with future integrations, parameter changes, or market conditions. This scope constraint becomes dangerous when protocols implement novel mechanisms or operate in rapidly evolving markets.
Audits do not test economic assumptions. They focus on code correctness, not economic viability. A protocol can have perfectly secure code but still fail due to flawed tokenomics or economic attacks.
An audit also does not cover what is out of scope. If we did not review the oracle adapter, we have nothing to say about the oracle adapter. Scope exclusions in a report are not a formality — they are load-bearing information.
I say all of this not to undercut the value of the work. I say it because teams that understand the limits of an audit use them correctly: as one layer of a security program, not as a complete solution. Real-time on-chain monitoring cannot prevent new vulnerabilities, but it shortens detection time during active attacks, compensating for what audits by design cannot cover.
How to Read an Audit Report Critically
If you are reading an audit report as a user, investor, or counterparty, here is what to look for:
Scope definition. What contracts were in scope? What was explicitly excluded? Does the exclusion list conveniently omit the most complex or highest-risk components?
Commit hash. Is the report tied to a specific, verifiable commit? Can you verify that the deployed code matches that commit?
Finding count and distribution. A report with zero critical or high findings is not necessarily a clean bill of health — it may reflect a narrow scope, a shallow review, or a team that writes findings conservatively. Industry data shows that about 71 percent of audits reviewed found at least one critical or high-severity issue. If a report finds nothing significant in a complex DeFi protocol, that deserves scrutiny.
Remediation status. Were findings fixed? Is there a final report that shows resolution? Projects that do not publish audit reports, or publish only a “certificate” without detailed findings, are not taking security seriously.
Proof of concept. For critical and high findings, was an exploit demonstrated? Findings without reproducible demonstrations are harder to evaluate and easier to dismiss.
Methodology disclosure. Ask for audit methodology in writing. A serious firm has one. If a report gives no detail on how the review was conducted — what tools were run, how many hours were spent, who did the review — you have no basis for calibrating its confidence level.
Red Flags in Cheap “Stamp” Audits
Some things in the market being sold as audits are not audits. They are automated tool runs wrapped in a PDF, sold to protocols that need a badge and do not know the difference.
When you get audit quotes, they vary widely. Comparing on price alone is wrong. A quality proposal will outline the scope of the review, methodology, seniority of the auditors, remediation review expectations, and specific exclusions. Significantly lower-than-market prices may indicate missing components such as remediation reviews or senior auditors.
A one-week audit and a four-week audit are not the same product. A complex DeFi protocol with multiple interacting contracts and upgrade mechanisms cannot be meaningfully reviewed in two days by one person. If a quote implies otherwise, that is not a discount. That is a different product.
Watch for:
- No named auditors or demonstrable track record on the firm
- No methodology section — just a tool output reformatted as a report
- Scope that excludes integrations, upgrade logic, or governance contracts
- No remediation review — findings are listed but never verified as fixed
- A “certificate” image with no underlying report
- Turnaround times too short for the codebase size to have received genuine manual attention
- Scope conveniently excluding the riskiest contracts
The purpose of a stamp audit is to produce a marketing asset. The purpose of a real audit is to find vulnerabilities before an attacker does. These are different activities that happen to produce similar-looking PDFs.
The Process Is the Point
The badge means nothing without the process behind it. A real audit is a structured investigation: precise scope, adversarial threat modeling, senior manual review as the core activity, tooling as amplification, rigorous findings triage, a report with proof-of-concept exploits and concrete remediation guidance, a verification pass, and a signed attestation tied to a specific commit.
That process reduces risk. It does not eliminate it. No audit can. Audits examine code under specific assumptions at a fixed moment, but real protocols exist in constantly changing contexts where those assumptions can become invalid without warning.
What I can promise is that we read the code, we understand the protocol, we think like attackers, we document what we find, and we are honest about what the scope cannot cover. That is the job. The badge is just what happens when we do it correctly.
If you are preparing for an audit, understand the scope before it starts. Fix your own tests first. Give your auditors documentation that explains the intent of every critical function. Pin a commit and do not modify it during the review. And read the report — all of it, including the remediation status — before you ship.
The value is in the process. Make sure you’re actually getting one.