Your Protocol Got Audited 18 Times. It still Got Hacked. Here's Why.
Audits review your code, but no one looks closely at your team. That’s often where money slips away.
In Q1 2026, Resolv Labs lost $25 million through a compromised AWS key management service, despite having passed 18 separate security audits before the attack. Venus Protocol had also been reviewed by five different firms before attackers exploited a donation attack pattern that security researchers had documented since 2022, and they were not alone.
Across the quarter, six audited protocols lost $37.7 million combined, averaging $6.3 million per incident compared to $4.3 million for unaudited ones.
The audits didn't protect them because the attackers had stopped targeting code entirely.
The Web3 security conversation has been dominated by one idea for years: find a reputable firm, put your smart contracts through a review, get the report, ship it, and call it security. That idea has cost the industry billions, not because audits are useless, but because the industry made them the finish line when they were always just the starting point. Attackers figured that out long before most builders did, and they moved on.
Earlier this year, I worked with a security team on an architecture review. The code was clean and the audit history was solid, but when we started asking different questions, the answers were uncomfortable. Who holds the admin keys? What happens when a signer device gets compromised? What is the offboarding process when a team member leaves? Those questions aren’t in most audit scopes, and that’s exactly where attackers are operating right now.
In Q1 2026, phishing and social engineering accounted for 84% of total losses by dollar value across Web3, while smart contract vulnerabilities (the thing audits are specifically designed to catch) accounted for a declining share and dropped 89% year over year compared to Q1 2025.
The threat hasn’t diminished. It has moved up the stack toward private key management, cloud infrastructure, and the humans on your team.
The Code Was Perfect. The Operation Was the Vulnerability.
On February 21, 2025, Bybit suffered the largest cryptocurrency theft in history, and the most important detail about that day is what didn't cause it. The Safe multisig wasn't broken, the private keys weren't stolen, and the smart contracts performed exactly as written, yet $1.5 billion still left the building in minutes.
Weeks before the theft, attackers had compromised a Safe{Wallet} developer's machine and injected malicious JavaScript into the signing interface. The code functioned completely normally for every other user on the platform but specifically targeted Bybit's signers, so when the team went to approve a routine transfer, they saw a normal transaction, followed their established process, and signed. What they actually signed handed full control of the wallet to the attacker.
The signers weren’t careless, nor did they cut corners; they followed their process exactly as prescribed. The real issue was that their process assumed the interface was always truthful, and there was no operational layer in place to verify that assumption before disaster struck. Without independent transaction verification, out-of-band confirmation, or any mechanism to flag an issue before signatures were collected, a single flaw became catastrophic.
Five months later, on January 31, 2026, Step Finance, a leading dashboard in the Solana ecosystem, lost $40 million after an executive’s laptop was compromised. There was no smart contract bug, flash loan, or oracle manipulation. Instead, the attacker gained admin-level access through the device, with nothing stopping them from reaching the treasury. The protocol’s on-chain systems were not affected, and the contracts worked as intended, but the project still had to shut down. Both incidents show the same pattern: the code worked, but the operation failed. In both cases, an audit would not have found the real problem because it was outside the audit’s scope.
What the Numbers Are Actually Saying
In 2025, operational security failures and access control breakdowns caused $2.12 billion in Web3 losses, compared to $512 million from smart contract vulnerabilities. This represents four times more damage from attack surfaces that typically go unaudited. In Q1 2026, phishing and social engineering resulted in $306 million in losses, smart contract exploits accounted for $86.2 million, and access control failures contributed $71.9 million. The pattern is not fluctuating, it is only hardening.
The Lazarus Group, North Korea's main cyber operations team, is carrying out fake venture capital outreach campaigns, setting up video calls with founders and senior staff before sending follow-up materials that contain malware disguised as investor decks or software updates. Step Finance lost $40 million to this tactic, and Bitrefill suffered an infrastructure breach through the same approach in the same quarter. These methods are not new, and according to Hacken's Q1 2026 report, they still work because most projects have not built the operational defenses needed to stop them.
The data shows an uncomfortable truth: a protocol with a clean audit history and high TVL is not safer than one without. In fact, it is a more appealing target for attackers. They have learned that breaking into the code is the hardest way in, so they look for other ways instead.
What Operational Security Actually Requires
Most teams treat operational security as something to figure out after launch, when the protocol has traction and the budget allows for it. That thinking is precisely why the attack surface keeps expanding. Operational security is not a scaling concern but a launch requirement, and the cost of skipping it is not technical debt. It is the kind of loss that ends projects.
Key management is where most projects are already exposed without knowing it. The breach rarely starts with a sophisticated exploit but with a private key living on the same laptop your developer uses for Slack, email, and late night browsing. Anyone on your team holding signing authority needs a dedicated hardware wallet and a signing device that does nothing else, no extensions, no general browsing, no exceptions. Multi-sig needs to mean something beyond the threshold number, because three signers operating from the same office on the same network with similar device setups is not meaningful separation. It is one coordinated attack away from collapsing entirely.
Signing hygiene is what the Bybit incident actually teaches, and most teams are drawing the wrong lesson from it. The failure wasn't the multi-sig setup, it was that signers trusted what the interface showed them without verifying what they were actually signing underneath. Every transaction above a threshold your team defines needs to be verified through a separate tool on a separate device before a single signature is collected, and that verification needs to confirm the raw transaction data in plain language, not just what the UI is presenting. Any transaction that cannot be fully decoded and confirmed before signing gets rejected, regardless of how routine it looks or how much pressure exists to approve it quickly. That last condition matters more than people think, because the Bybit attackers specifically targeted a routine transfer precisely because routine approvals get less scrutiny.
Most governance gaps live in access control, and the post-mortems prove it consistently. Breaches usually don't happen because of clever exploits but because access was never reviewed after it was granted. Teams treat these reviews as paperwork rather than security work, and that distinction is exactly what attackers rely on. Quarterly access reviews, same-day offboarding, and regular key rotation only work if someone is clearly accountable for making them happen on schedule.
Social engineering is no longer a generic threat that occasional security training addresses adequately. The campaigns targeting Web3 teams right now begin weeks before any message is sent, with attackers mapping your team's structure, access levels, and individual backgrounds through publicly available information. By the time someone on your team receives an outreach, the attacker already knows who holds signing authority, who recently joined, and who is most likely to respond. Every inbound contact from an unknown party needs to be verified through a second independent channel before anyone engages with anything they send. Team members with elevated access should not be able to install outside software without formal review, and your escalation path for suspicious outreach needs to be written down and known by everyone, because the moment someone is deciding in real time whether something feels off is already too late for a policy conversation.
Most projects don't know they have no incident response plan until they need one, and by then the cost of finding out is already compounding by the minute. The first 30 minutes of an active exploit are not the time to figure out who has contract pause authority, which exchanges need immediate notification to freeze attacker addresses, or who is authorized to make the first public statement. Those decisions need to exist in a document that every relevant person has read, knows where to find, and has actually rehearsed under simulated pressure. A tabletop exercise twice a year is not excessive; it is the minimum required to know whether your response plan works or just looks like it does on paper. The difference between a contained incident and a protocol-ending one is almost never about the sophistication of the attack. It is about whether the team knew what to do in that first window and moved without hesitation.
The Security Program, Not the Security Badge
The audit report in your documentation folder is not a security program. It shows what your code looked like at a specific point in time, checked within a set scope by a particular group of people. It does not cover the new team member who joined after the review, the signing device still running its original software configuration, the access permissions left unchanged after your last reorganization, or how your team will actually respond in the first 30 minutes of an active attack. All of that lives in the operational layer, and it is exactly where attackers are operating right now.
The projects surviving in this environment are not the ones with the longest audit history or the most conservative token distribution. They are the ones where security is embedded into how the team works every day rather than referenced during fundraising and forgotten between launches. Continuous monitoring, practiced incident response, dedicated signing infrastructure, and social engineering awareness built into onboarding from day one are not advanced security measures. They are the operational baseline that the current threat landscape demands, and the gap between teams that have built it and teams that haven't is where most of 2026's losses are being recorded.
The question worth sitting with is not whether your protocol has been audited. It is whether the gap between your technical security and your operational security is something an attacker could walk through today, because the data from 2025 and Q1 2026 makes it clear that the gap is exactly where they are looking and exactly where they are winning. The projects that close it now are the ones that will still be operating when the next wave hits, and increasingly the ones that will meet the operational security requirements that MiCA, MAS, and VARA are beginning to enforce. The ones that don't will be in the next quarterly losses report, wondering how it happened despite everything they thought they had in place.