Cover photo

Your Code Audit Passed. You Still Got Hacked. Three Times.

Prisma Finance, Zunami Protocol, and Resolv Labs — Same Ecosystem, Same Pattern, Nobody Learned

Between 2024 and 2026, three stablecoin protocols tied to the Curve Finance ecosystem were exploited in ways that had nothing to do with the quality of their smart contract audits. Prisma Finance lost $12 million through a peripheral migration contract. Zunami Protocol lost $500K when someone called a function named withdrawStuckToken() with the deployer key. Resolv Labs had $80 million in unbacked USR minted because a single off-chain signer had unlimited power with zero on-chain guardrails.

All three protocols had been audited. All three audits covered the core contracts. All three got hacked through something that was either out of scope, an architectural assumption, or an operational security failure. The code was fine. The security was not.

If you manage a DeFi team, run DevSecOps, or are responsible for the security posture of anything that holds other people's money, this article is for you. Three protocols, three hacks, one lesson: audits are necessary but nowhere near sufficient. You need security people, not just security reports.

Three Hacks, One Table

post image

What Actually Happened in Each Case

Prisma Finance — The Forgotten Helper Contract

Prisma's core codebase was forked from Liquity, one of the most reviewed and battle-tested protocols in DeFi. The core contracts were immutable and had been through multiple audits. Then the team deployed MigrateTroveZap — a utility contract designed to help users migrate their positions (troves) from one trove manager to another using flash loans. This contract had delegation approval over users' troves. It accepted arbitrary flashloan callbacks. And it had no input validation on collateral parameters. The root cause was twofold: by directly calling the flashloan() function, an attacker could manipulate other Trove Managers' positions, and the contract allowed a mismatch between collateral in the initial position and the new position. The attacker exploited both, opened a small trove, migrated it through MigrateTroveZap to inherit the remainder of wstETH in the contract, and walked away with 1,282 wstETH. This contract was almost certainly not in the main audit scope. It was a convenience wrapper. It felt too simple to warrant a separate engagement. But it had the keys to the kingdom.

Zunami Protocol — The Admin Key That Shouldn't Have Existed

Zunami's story is darker. The protocol had been hacked three times before — in 2023 alone, a sandwich attack ($49K), a flash loan price manipulation ($260K), and another flash loan attack on Curve pools ($2.1M). Each time, the team promised fixes and better security. Zunami V2 was launched with audits from Nomoi and PeckShield, and the team explicitly stated that "the primary objective of V2 is to ensure security."

Then in May 2025, someone used the Zunami Protocol Deployer Wallet to call withdrawStuckToken() on the UsdtCrvUsdStakeDaoCurve strategy contract. That single function call transferred 296,456 LP tokens — the collateral backing zunUSD and zunETH — straight to the attacker's address. No flash loans, no price manipulation, no clever exploit mechanics. Just an admin call from a privileged key.

Curve Finance founder Michael Egorov commented: "What is worse, admin key existed!" And he was right. The fundamental question isn't whether the deployer key was compromised or whether it was an insider job (the team says they're "considering both scenarios"). The question is why a single EOA had the power to drain all user collateral with one function call, and why nobody flagged this as an unacceptable risk. The protocol's GitHub had no commits for three months before the hack. The domain had expired. Curve gauge rewards dropped to zero right before the exploit. Whether this was a compromise or a rug, the architecture made it trivially easy.

Resolv Labs — The Unlimited Money Printer

Resolv's USR was a yield-bearing stablecoin backed by delta-neutral strategies on ETH. The minting process worked in two steps: a user deposits USDC via a requestSwap function, then an off-chain service with a privileged key (the SERVICE_ROLE) calls completeSwap to decide how much USR to mint. The contract checked the minimum amount but had no maximum. No cap. No ratio to collateral. No oracle validation. Whatever the SERVICE_ROLE key said, that's what got minted.

The SERVICE_ROLE was a single EOA address. The admin role was a multisig — but the role that actually controlled minting was just one private key. The attacker got that key, deposited $200K across two transactions, and minted 80 million unbacked USR. Dumped it on Curve and other DEXs. USR hit $0.025 on Curve within 17 minutes. The attacker walked away with approximately $25 million in ETH.

As one security researcher put it: "The contract worked perfectly. That's the scariest part." The code was correct. The design was the vulnerability.

The Common Pattern

Look at these three incidents side by side and the pattern is impossible to miss.

In every case, the core protocol contracts were audited and held up fine. In every case, the exploit came through a component that was either peripheral to the main codebase (Prisma's MigrateTroveZap), an architectural assumption about key security (Zunami's deployer wallet, Resolv's SERVICE_ROLE), or both. In every case, there were no on-chain guardrails to limit the blast radius when the assumption failed. And in every case, nobody on the team appeared to be asking: "What's the worst that can happen if this component is compromised?"

This is not a code quality problem. This is a security architecture and security operations problem. And it's a problem that code audits, by design, are not meant to solve.

Why Code Audits Don't Catch This

A smart contract audit answers a specific question: "Does this code do what it's supposed to do, and does it have exploitable bugs?" That's a valuable question. But it's not the only question that matters.

Here's what an audit typically does NOT cover:

Article content

An audit firm reviews what you put in front of them. They don't monitor your deployments, they don't review your key management, they don't check whether your DevOps practices are secure, and they don't come back six months later to see what you've changed since the audit. When Prisma deployed MigrateTroveZap after the main audit, no auditor raised an alarm. When Resolv designed a system where one EOA could mint unlimited tokens, the auditor saw code that "worked as specified." When Zunami's development went dormant while user funds sat in strategies guarded by a single key, nobody was watching

What Actually Needs to Happen

The lesson from these three incidents is not "get better audits." The lesson is that audits are one component of a security program, and without the other components, they give you a false sense of security that may be worse than no audit at all.

Here's what a real security program looks like for a DeFi protocol.

1. Hire a security person. Full-time. In-house.

Not a developer who "also does security." Not an auditor on retainer. Someone whose entire job is to think about how your protocol can be attacked. This person maintains the threat model, reviews every deployment, defines access control policies, monitors production, and owns the gap between what was audited and what is running.

The cost of this person is $200-400K/year. The cost of not having them is measured in the tens of millions — and that's just the direct financial loss, not counting the TVL collapse, the reputational destruction, and the potential legal exposure. Prisma's TVL dropped 60%. Zunami's protocol is effectively dead. Resolv's USR may never recover its peg.

2. Conduct security architecture reviews, not just code audits.

Before any code is written, someone should be mapping trust boundaries. Which components have privileged access? What's the blast radius if each one is compromised? Are there on-chain guardrails to limit damage even if off-chain components fail?

For Resolv, this review would have immediately flagged: "A single EOA with unlimited minting power and no on-chain rate limit is a single point of failure that makes the entire protocol's security dependent on one private key." That's not a subtle finding. Any competent security architect would catch it in a design review.

For Zunami, the review would have flagged: "The deployer wallet retains god-mode access to strategy contracts including the ability to withdraw all user collateral via withdrawStuckToken(). This must be migrated to a timelocked multisig or revoked."

For Prisma, the review would have flagged: "MigrateTroveZap has delegation approval over user troves and accepts arbitrary flashloan callbacks without input validation. This needs its own security review before deployment."

3. Gate every deployment with a security review.

No contract goes to mainnet without someone asking: What can this contract do? What trust assumptions does it make? What happens if those assumptions are violated? What's the worst case? Is this in the existing audit scope, and if not, does it need its own review?

This doesn't mean a full external audit for every helper function. It means an internal review by someone who understands the security implications. A 30-minute review of MigrateTroveZap by a security-aware engineer would have caught the input validation issue. A 15-minute review of the SERVICE_ROLE architecture would have flagged the missing mint caps. These are not exotic findings. They're basic security hygiene.

4. Implement on-chain guardrails as defense in depth.

Even if you trust your keys, assume they can be compromised and design accordingly. Add rate limits on privileged operations. Add maximum amounts per transaction and per time window. Add timelocks for large operations. Add oracle checks where applicable. Use multisigs instead of EOAs for any privileged role.

Resolv with a "max 1M USR per mint" cap would have turned a catastrophic exploit into a minor incident. Zunami with a timelock on withdrawStuckToken() would have given the community time to react. Prisma with input validation on the flashloan callback would have prevented the exploit entirely. These are cheap, simple, well-understood engineering practices. The fact that none of these protocols implemented them tells you that nobody with security expertise was reviewing the architecture.

5. Monitor production continuously.

Set up alerting for all privileged operations. Large mints, unexpected admin calls, unusual fund movements. The DeFi community learned about the Resolv exploit from Twitter before the protocol team knew. Zunami's community discovered the hack before the team responded (and the first team response on Discord was "rekt lmfao"). This is not acceptable for systems managing hundreds of millions of dollars.

Real-time monitoring with basic anomaly detection — "a mint just happened that's 500x the deposit amount" or "the deployer wallet just called withdrawStuckToken() for the first time ever" — would have provided early warning and potentially allowed pausing before the damage was done.

6. Treat security as a continuous process, not an event.

The traditional model is: build, audit, deploy, done. The reality is: build, audit, deploy, add feature, deploy helper contract, change access control, rotate keys, add new strategy, integrate with new protocol, and on and on. Every post-audit change is a potential attack surface expansion. If nobody is tracking the delta between "what was audited" and "what is live," you're flying blind.

Maintain a deployment registry. Track audit coverage. Conduct periodic architecture reviews — quarterly at minimum, or whenever the system changes significantly. Re-assess threat models when new components are added. This is not optional overhead. This is basic security operations.

The Organizational Problem

Most DeFi teams are structured as: developers, a product person, maybe a community manager. Security is something that happens once, before launch, when an external firm reviews the code. After that, it's nobody's job.

This is like a bank outsourcing its risk management to an external consultant who visits once a year. Between visits, the bank adds new products, changes its trading systems, gives master keys to individual employees stored on unencrypted laptops, and deploys new customer-facing tools without review. Then when something goes wrong, the bank points to the consultant's report and says: "But we were audited!"

Zunami is the most extreme example. Four exploits across three years. Each time, the team promised better security. The V2 launch was explicitly marketed around security, with multiple audits from reputable firms. And then the protocol got drained by a single admin function call because the deployer wallet retained god-mode access and nobody thought to revoke it — or monitor it, or put it behind a multisig, or add a timelock, or do any of the basic things that a security person on staff would have demanded.

Michael Egorov's comment — "What is worse, admin key existed!" — should be tattooed on the inside of every DeFi founder's eyelids. The admin key existed because nobody whose job was security was in the room when the architecture was designed. The MigrateTroveZap went unreviewed because nobody whose job was security was tracking post-audit deployments. The SERVICE_ROLE was a single EOA because nobody whose job was security was asking "what if this key leaks?"

The Bottom Line

Three protocols. Three stablecoins. Three exploits. All in the Curve ecosystem. All audited. All hacked through the same fundamental gap: the space between what the auditor reviewed and what actually determines the protocol's security.

Code audits catch code bugs. They don't catch architectural flaws, operational security failures, peripheral deployment gaps, or the absence of on-chain guardrails. The DeFi industry has spent millions on audits while spending almost nothing on the security engineering, threat modeling, and continuous monitoring that actually prevents exploits.

If you're running a protocol with real TVL and you don't have a security engineer on staff — someone who reviews every deployment, maintains the threat model, defines access control policy, monitors production, and asks "what if?" every single day — then your next audit report is just a very expensive piece of paper that will look great in your post-mortem.

Hire the person. Build the process. Treat security like what it is: not a checkbox before launch, but an ongoing engineering discipline that requires dedicated people, continuous attention, and the organizational authority to say "no, we don't deploy this until the security questions are answered."

The alternative is being the next entry in the table above.


This article compares three exploits in the Curve ecosystem: Prisma Finance ($12M, March 2024 — unaudited MigrateTroveZap contract), Zunami Protocol ($500K, May 2025 — admin key draining via withdrawStuckToken()), and Resolv Labs ($25M+, March 2026 — single-key signer with unlimited minting power). All three passed code audits. All three were exploited through non-code security failures.