Nobody explains the process until you're already inside it.
You've picked a firm, agreed on a price, locked a date. Then the kickoff happens, findings land, fixes get verified, the report ships, and a lot of it catches you off guard.
This is the thing we wish existed when teams first reached out to us. It's written from patterns we've watched repeat across dozens of audits and we think it will be helpful to share this with teams across the entire web3 ecosystem.
Two kinds of patterns show up here: Process patterns, which happen before and during the engagement, and technical patterns, which live in the code. The process mistakes tend to be the expensive ones, and almost all of them are avoidable. The technical ones follow the same logic, once you know what to look for, you can find it yourself before we do. Your report gets shorter and your engineers spend less time defending decisions.
First, the mental model: Don't treat the audit as a black box
Start here, because this one shapes everything else.
The common version goes like this: You pay, the auditors go quiet until the deadline, then a report appears. That model hands you a weaker audit than the one you could have gotten by shifting the way many people treat an audit.
The engagements that produce the sharpest findings share one trait, and it isn't technical. From day one, both sides stay in contact. Developers ask for updates and talk through findings as they surface. Auditors push back on design assumptions. Questions get answered in detail instead of stacking up for a final call.
Two things come out of working this way:
First, fixes happen during the audit instead of after it. When a developer understands a finding the day it shows up, they can fix it while the auditor still holds full context of the original issue and the code around it. That's faster, and the result is cleaner than the batch-fix model where everything waits for the report.
Second, and harder to measure: live conversation produces deeper findings than either side reaches alone. An auditor asking why a component works a certain way, and getting a real answer, surfaces edge cases no tool would catch.
Some of our clients set this expectation at kickoff. Neither side holds back on questions or challenges. The findings go deeper, the fixes come fast, and the outcome is better on every measure.
Teams that run audits this way set the expectation before or on the first call. With that as the backdrop, here are the specific patterns.
Process: Before and during the audit
1. Most teams don't build a threat model
On the kickoff call, one of the first things we do is work through the threat model together.
A threat model is a structured way to think about what can go wrong. Who would attack this? What would they target? What would the damage be? It's a conversation that shapes the whole review.
Teams that show up with even a rough threat model get a better audit because we spend less time on the basics and more on the edge cases that matter.
Remember, the kickoff isn't just onboarding, it is day one of the audit.
2. Cutting days to cut cost, right before launch
When one firm quotes 10 days and another quotes 14, the usual instinct is to push toward 10, and sure, sometimes that's fine. If you're planning several rounds before launch, trimming scope at each round makes sense.
But if you plan to launch right after this audit, cutting scope is moving risk onto yourself. An auditor with fewer days makes the same calls any engineer makes under time pressure: hit the obvious attack surface, move faster through the rest.
The question here is: What do 10 days leave out, and are we okay with that before we go live?
3. Slow fix submissions
After the first report, a clock starts that some teams don't track: AUDITOR CONTEXT. The people who reviewed your code hold context, but only for so long. They are great at what they do, but they are also busy humans who work on multiple projects after your first report is delivered.
When fixes come back within a week, verification is sharp. The auditor reviews the fix with full memory of the original issue, the surrounding code, and what a correct fix looks like.
When fixes show up 3, 4, or 5 weeks later (we've seen it before), that context has to be rebuilt from scratch. Sending fixes fast is one of the best things you can do to improve your remediation report.
4. Reading the report instead of working through it
Teams that read the report and file it get less than teams that treat it as a list of questions from the auditors. Every finding carries context that doesn't always fit in the report. The auditor knows why a given pattern is risky in your specific design. They know which acknowledged findings they'd watch closely if it were their own money.
Asking those questions during the audit builds a kind of security sense in your team. That sense is what stops the next version of the same bug.
5. Nobody asks what happens after the audit
The post-audit surface barely comes up. The final report ships and everyone moves on.
But the report names invariants: assumptions about how the protocol should behave no matter what. You can turn those into fuzz suites. Fuzzing against audit-derived invariants is one of the most effective ongoing security practices there is, and almost nobody does it.
Monitoring is the same story. What gets watched after launch? What sets off an alert? What's the response plan? These belong in the audit conversation.
The audit is only a snapshot.
6. Not running security scans before the audit starts
There are open-source static analysis and AI-assisted tools available right now that reliably catch a specific class of issue: reentrancy patterns, integer overflow in older code, simple access control gaps.
When a codebase shows up without having been run through any of them, we find those issues, document them, and spend precious audit time on them. That time comes straight out of the harder work: logic bugs, cross-contract interactions, economic attacks no tool catches.
You can run most of these tools yourself, and you should. If you'd rather have a security engineer in the loop while it happens, we built a solution called pre-audit for exactly that. With three packages to choose from, finely tuned AI agents scan your entire codebase while one of our engineers ramps up on it. The engineer reads the AI-generated report, clears the false positives and adjusts any inflated or underestimated severity level, then meets with you to walk through what's left and where you want to take it. If you move ahead with a full audit, that $4,000 comes straight off the price.
Clearing the easy issues clears the floor so we can spend time where it matters most. Your report comes back shorter, and what's left means more. A shorter report will look much better to your end-users and investors.
Technical: What we find in the code
Patterns that show up in nearly every engagement.
7. Retroactive fee application
When a protocol has a configurable fee with an admin setter, the correct version settles outstanding fees at the current rate before writing the new value. Almost no team does this.
So changing a fee from 10% to 11% applies the new rate to yield that accrued under the old one. That's a retroactive fee application and it is economically wrong, and in some designs it opens a path for an admin to pull value out of existing positions by timing a fee hike against a large pending yield event.
8. Missing supply == 0 check on share and wrapped tokens
When a share token or wrapped token is set up to represent an underlying asset or strategy, initialization should confirm that existing supply is zero before going further. If it isn't zero, the token is undercollateralized from the first interaction. The backing-to-supply ratio is wrong before a single user has done anything.
This shows up in about half the engagements that involve this pattern. It's a one-line check, and it heads off something that looks like a rugpull vector no matter what the intent was.
9. Contesting severity instead of fixing the issue
Once findings land, some teams spend time arguing a High down to a Medium, or a Medium down to Informational. It's understandable, severity changes how a report reads in public.
What it doesn't change is the risk: A High argued down to Medium and then fixed is exactly as safe as a High accepted and fixed. A Medium talked down to Informational and left alone is still a live bug.
Our take is simple: remediation matters more than the label. Fix the issue and the label is secondary. Leave it unfixed and the label protects no one.
10. Commits submitted between phases
Code lands after scope is locked but before the audit starts, or between the first report and fix verification. Sometimes it's a small optimization. Sometimes it's a whole feature.
The problem is that we scope the work against a specific codebase. Anything added outside that scope either gets reviewed under time we didn't budget for, or doesn't get reviewed at all. Both are worse than holding the change until the engagement closes.
If something has to change mid-audit, tell us. Don't commit it quietly and assume it gets caught.
11. init vs init_if_needed on Anchor ATAs
For teams on Solana with Anchor: using init on an associated token account assumes the account doesn't already exist. If a frontrunner, a prior transaction, or any outside actor already initialized it, the instruction fails.
init_if_needed handles the case where it's already there. The difference is small. The cost is a frontrun vector on account setup that can block real users from initializing their accounts, or let someone bend the setup flow.
This shows up consistently in Anchor codebases, and it's almost always unintentional.
In conclusion
Most audit problems are preventable. The process mistakes cost more than the technical ones, and almost all of them happen before an auditor touches the code. The technical patterns follow the same logic, once you know what they are, you find them yourself.
Show up with a threat model. Send fixes fast. Run your tooling before the engagement starts, and ask questions the day they come up. Plan for what happens after the report ships. Do those things and your audit will be shorter, sharper, and worth more.
Some of the information discussed above may raise questions specific to your design that a general piece can't answer. If you want to talk through where your project stands before an engagement starts, we offer a free 15-minute call with one of our security engineers. Bring your design and we'll tell you where we'd look first.