After an exploit, the re-audit isn't enough
The audit covers your patch. It doesn't cover the compensation contract, the migration, or the guardian key you're about to ship on no sleep.
By Alex Cipher — ongoing smart contract security review for small GameFi and DeFi teams.
If you got hit this week, your DMs are already full. Audit firms, incident response shops, a couple of accounts offering to negotiate with the attacker for a cut. You don't have time to read any of it.
So here is the short version of the thing none of those messages will tell you.
You're going to patch, get the fixed code audited, and start shipping again. That audit covers the patch. It covers nothing you ship after it. And the weeks right after an incident are the most dangerous shipping period your protocol will ever go through.
What the re-audit actually buys you
Buy it. I'm not talking you out of it. Just be clear about what it is: a review of a defined scope, at one commit, on one date. It answers a single question. Is the hole closed?
Worth knowing. It's not the question that decides whether you get drained a second time.
Look at what you're actually about to deploy
It's never just the patch. In the weeks after an incident most teams ship some version of all of this:
- A compensation contract. Written fast, holding real money, and usually the first contract of its kind your team has ever deployed. Snapshot at the wrong block and you pay the attacker out of your own recovery fund.
- A migration. New contracts, old balances, and a pile of approvals that get granted in a hurry and revoked later. Sometimes.
- Parameter changes. Caps and limits tightened during the panic, then quietly loosened three months on by someone who wasn't there for the incident and doesn't know why the number was set that way.
- A pause or guardian role, added under pressure. That's a new privileged key on a system that has just proven it can be drained. Who holds it? Is there a timelock on it? Usually not, because a timelock defeats the point of an emergency pause, and that tradeoff almost never gets written down.
- Staged re-entry. Get the ordering wrong and deposits come back online before you've proven withdrawals are solvent.
Every one of those is a contract change. None of them existed when the re-audit was scoped. All of them are being written by people running on no sleep with the entire timeline watching.
Why none of it will get audited
You already know it should be. It won't be, and the reasons are good ones.
Nobody audits a forty-line diff. Scoping the engagement costs more attention than the change is worth, so it ships unreviewed and everyone moves on.
Audits move in weeks. Post-incident changes move in days. By the time a quote lands, the code is live.
And you've just lost money and paid for a re-audit. Going back for a third engagement to cover a parameter change is not a conversation you want to have with whoever signs off on spending right now.
So the changes go out on trust. Not because anyone decided that was acceptable, but because nothing on the menu was shaped like the problem.
What I do instead
One paid onboarding review at the start. I read what you have live now, after the patch, and write down how the system actually works: trust boundaries, who holds which key, where value moves, and the assumptions the whole thing quietly rests on.
After that you send me the diff before you deploy. I read the code you changed and everything that reaches it, against that map. Findings come back severity-rated with a concrete fix for each, in days rather than weeks.
Speed isn't really the point. Context is. Someone who mapped your system last month can tell you that your new fee logic breaks an assumption your withdrawal path depends on. Someone reading a forty-line diff cold can't see that, no matter how good they are. That's the reason this only works as an ongoing arrangement and not as a series of small jobs.
What this doesn't do
It doesn't replace the re-audit. That's the right tool for frozen code at a milestone and I will tell you to get one even while you are paying me.
It also doesn't cover rewriting the module that got exploited. That's a bigger job than reviewing a diff, and I quote it separately before it starts rather than absorbing it and doing a worse job of both. Same goes for new modules and new external integrations. The terms spell out exactly where that line sits.
Why now and not in six months
Most protocols are not broken by something exotic on day one. They're broken by something that entered the codebase after the last time anyone read it properly. A feature. A parameter. An integration. A migration.
The post-incident period packs all four into a few weeks, which makes it both the worst time to be shipping unreviewed and the one moment your team will genuinely agree to change how it works. That window closes. Three months from now the urgency is gone and the habit never formed.
If this is where you are
The onboarding review is $300 to $600, paid once. Ongoing review starts at $300 a month, and I set the real number after I've read your code rather than guessing at it from a form. Full numbers, and how they compare to what audit firms charge, are on the pricing page.
If you're about to start shipping again, that's worth a conversation before the changes go out instead of after. Tell me what you're shipping. Email, a DM, or a call, whichever you'd actually use.