Smart contract audit service: lessons from a missed exploit

On June 26, 2025, Resupply Finance lost approximately $9.5 million to an exploit that manipulated the exchange rate of a freshly initialized vault. The protocol paused the compromised contract and went into damage-control mode. What made the post-mortem uglier was the footnote: two named firms had reviewed functional code roughly three to four months earlier. Both reports were sitting on the project's website when the attacker walked off with eight figures.

I don't bring this up to pile on a wounded protocol. I bring it up because this is exactly the kind of failure a smart contract audit service is supposed to prevent, and the retail participants reading that "audited" badge on a project's homepage deserve to understand what that badge actually covered — and what it didn't.

This is the gap I want to walk through. Not whether Resupply's auditors were "good" or "bad," but the structural blind spot in how the crypto industry buys, sells, and markets audit reports. If you're sizing up a launchpad project or evaluating a DeFi protocol, the lessons from this incident cut deeper than any individual firm's reputation.

Anatomy of the Exploit: What Actually Happened

Let's follow the money. According to the post-exploit analysis, the attacker targeted a vault initialization step that used an ERC-4626-style share accounting model. The mechanism wasn't exotic. The attacker deposited a small amount, manipulated the share-to-asset ratio through a direct donation to the empty vault, and then exploited the next user's deposit to mint effectively zero shares. The user's funds stayed in the vault as a "donation" to existing shareholders. The attacker withdrew their original stake and collected the victim's principal.

This is the well-documented ERC-4626 inflation attack. OpenZeppelin's own documentation describes the exact vector: an attacker deposit followed by a donation equal to the targeted user deposit, leaving subsequent depositors with nothing. It isn't a sophisticated zero-day. It's a known class of vulnerability that a defi security audit should catch if the deployment assumptions are part of the review scope.

Here is the uncomfortable part. The two firms that reviewed Resupply's code — ChainSecurity and yAudit — signed off on a specific version of the codebase, and the exact reviewed commit is not established in the public post-mortem materials I have seen. The vault initialization deployed at the time of the exploit sat outside the documented deployment-review scope. Code review and deployment validation are different deliverables, and conflating them is how a "passed audit" turns into a $9.5 million incident.

Code Review vs. Deployment Validation: The Scope Gap That Costs Millions

Most retail participants see an audit report as a yes/no signal. The report exists, the badge goes on the website, the project is "safe." I have spent enough time reading these reports to tell you that framing is wrong. An audit is a contract. The body of that contract is the scope letter, the commit hash, and the in-scope contracts. Everything outside that envelope is the project's responsibility, not the auditor's.

A code review covers the codebase at a specific commit. It does not cover what happens when that code is deployed with new parameters, new oracles, new initialization calls, or new governance hooks. Deployment validation is a separate exercise that checks whether what was deployed to mainnet matches what was reviewed and whether the configuration parameters are consistent with the threat model.

An audit covers what was reviewed, when it was reviewed, and what was explicitly excluded. Everything else is marketing.

ChainSecurity's own deployment-validation documentation warns that the assessment cannot uncover every mismatch and that a clean result is not a guarantee of correct setup. yAudit's published Resupply report includes language noting that a review may not identify all potential attacks and that no warranties are provided regarding security. These aren't throwaway legal lines. They are the operative clauses.

Here is the comparison I want every retail participant to internalize:

If your project's "audit" was a code review with no deployment-validation follow-up, you are flying with a partial pre-flight check. That isn't an insult to the auditor. That is the contract.

The ERC-4626 Trap: Why "Standard Compliant" Is Not a Security Claim

I want to spend a moment on ERC-4626 because the Resupply incident is going to repeat across the launchpad ecosystem if protocols don't internalize this. ERC-4626 is the tokenized vault standard. It looks like a turnkey solution. Drop in the standard, get share accounting for free. The problem is that the standard explicitly does not protect you from initialization attacks, rounding loss, or donation-based manipulation.

OpenZeppelin's documentation lays out the inflation attack step by step. An attacker deposits a single unit of the underlying asset into an empty vault, then donates a quantity equal to the next user's intended deposit. Because share accounting uses the ratio of assets to shares, the donation manipulates the share price so that the next user's deposit mints zero shares. Their funds sit in the vault as a "donation" to existing shareholders. The attacker withdraws their original deposit and walks away with the victim's principal. In the documented full-loss example, an attacker deposit of one unit and a donation equal to the user's deposit are sufficient to drive minted shares to zero.

The standard also has a rounding trap. OpenZeppelin notes that deposits round toward zero. If a user receives fewer than one share, their deposit effectively becomes a donation. The documentation suggests requiring a minimum of 100 received shares to cap rounding loss at 1%, and 200 received shares to cap rounding loss at 0.5%. These are mitigations. They are not defaults. A vault that follows ERC-4626 without these mitigations is exposed.

When I evaluate a launchpad project, I treat ERC-4626 compliance as a starting point, not an endpoint. The questions I run through:

• Does the vault use an internal decimals offset or virtual shares to mitigate the inflation attack?
• Is there a minimum deposit or minimum share output enforced on every deposit?
• Has the deployed initialization been verified against the audited code?
• Are there any deposit functions that bypass the standard's share accounting?
• Does the vault use an external price oracle for share valuation, and is that oracle part of the audit scope?

If the answer to any of these is "I don't know" or "the audit covered it," I dig deeper. "The audit covered it" is not a satisfactory answer unless the team can show me the commit hash, the scope letter, and the deployed bytecode.

Reading the Fine Print: What Auditor Disclaimers Actually Mean

Every legitimate audit report I've ever read includes a disclaimer section. Most retail participants skip it. That is a mistake. The disclaimer is where the auditor tells you, in legal terms, what they are and are not promising.

The standard clauses you will see in any reputable audit report:

• "The review does not identify all potential attacks." True. Audits are time-boxed, scope-bounded, and human-effort-limited. They miss things. The profession is honest about this. Retail should be too.
• "No warranty is provided regarding the security of the code." This is the auditor protecting themselves from litigation when something goes wrong. Read it as a warning, not boilerplate.
• "The review is not a guarantee that the protocol cannot be exploited." Also true. A smart contract vulnerability assessment reduces the probability of an exploit. It does not eliminate it.

These disclaimers aren't lawyers hedging. They are an accurate description of what a defi security audit can and cannot do. When a project markets its audit as a security guarantee, that marketing is overstepping what the auditor actually delivered. The auditor's name is the credibility transfer, but the contract is the scope letter. Treat the marketing the same way you'd treat a seed-round pitch deck — useful for context, never a substitute for the underlying document.

Operational Security: Multisigs, Vesting, and Permission Management

An audit report that focuses on smart-contract logic and ignores operational security is half a review. The Resupply exploit was a logic flaw. Many other exploits are operational — compromised deployer keys, single-signature admin wallets, upgrade authority sitting in a hot wallet. The audit needs to look at these, and the report needs to disclose them.

OpenZeppelin's documentation recommends securing high-privilege administrators under a multisig or governance layer. Safe, the most common multisig infrastructure in the space, defines a threshold as the minimum number of owner confirmations required before a transaction executes. A 2-of-3 multisig is not the same as a 4-of-9 multisig. A 2-of-3 with keys held by three members of the same team is functionally a 1-of-1 with extra steps. These distinctions matter and they almost never appear in marketing material.

A few operational-security items I want every retail participant to verify before committing capital to a launchpad allocation:

• Multisig owner set: How many owners? Are they independent? Where are keys stored? Hardware wallets? Custodial?
• Multisig threshold: What is the confirmation count? Can one compromised key drain funds?
• Upgrade authority: Is there an upgrade pattern in the contracts? Who can trigger upgrades? Is there a timelock?
• Vesting contracts: Team and investor tokens — are they in OpenZeppelin's VestingWallet or a custom implementation? Is duration zero (pure timelock) or longer? Is ownership transfer-restricted, or can unvested tokens be sold?
• AccessManager permissions: If AccessManager is in use, do the target contracts actually use the required restricted modifier, or is the access control decorative?

The OpenZeppelin VestingWallet documentation is worth reading in full. It releases native currency and ERC-20 tokens on a linear schedule. The default duration is configurable. A VestingWallet with duration zero operates as a pure time lock until the configured release time. The documentation also notes that, because the wallet is ownable and ownership can be transferred, unvested tokens can potentially be sold. A vesting schedule is a release mechanism, not an economic non-transferability guarantee. If a project tells you their team tokens are "locked," ask whether the lock is enforced by code or by social convention. The answer changes your risk model.

What I Actually Look For in an Audit Report

I've now read enough audit reports across top crypto audit firms to have a checklist that I run through every time. None of these items are secret. They are sitting in the report that the project is already publishing. The problem is that most retail participants don't read past the front page — the logo, the headline finding count, and the date.

Here's the audit report analysis checklist I use, in order:

1. Commit hash or code version: Every finding should reference a specific commit. If the report doesn't include one, the report is undated. Walk away.

2. Scope letter or in-scope contract list: The report should explicitly list which contracts were reviewed. Anything not on the list was not reviewed.

3. Assessment period: Start date and end date of the review. Anything deployed after the end date is out of scope.

4. Findings table: Open, acknowledged, resolved, mitigated. Read the unresolved findings with the same care you read the resolved ones.

5. Deployment validation: Was the deployed bytecode and on-chain configuration checked against the reviewed code? Was it a separate engagement or part of the same scope?

6. Auditor's disclaimer: Read it. If the report is missing one, that's a red flag about the firm's professionalism.

7. Auditor reputation and methodology: How long has the firm been operating? Have they published methodology documents? Do they have a track record of identifying the kind of vulnerability class relevant to this protocol?

I don't care which firm is on the badge. I care whether the badge was earned through a process that covered the deployed code, with the deployed configuration, at the deployed addresses. Anything less is a partial answer, and a partial answer at the audit stage becomes a full loss at the deployment stage.

Closing: The Badge Is Not the Product

Resupply is going to be one of many similar incidents over the next twelve months. The pattern is well-established. A protocol deploys an audited codebase. A new vault, an oracle upgrade, a parameter change, a fresh initialization. The audit badge sits on the website. The exploit lands on the protocol. The community discovers that the badge was earned on a different commit, against a different deployment, in a different scope envelope.

This isn't a call for cynicism. It's a call for precision. Audits are useful. They catch real bugs, they impose discipline on the development process, and they reduce the probability of a catastrophic exploit. But they are not guarantees, and the industry has spent five years letting marketing language turn a useful tool into an implied warranty. The disclaimer section in every audit report exists for a reason. So does the deployment-validation deliverable that most projects never commission.

When you evaluate a project, treat the audit like a financial statement. Read the scope letter. Verify the commit hash. Check the deployment-validation status. Read the disclaimer. Then decide whether the protocol's risk profile matches the allocation you want to make. If you can't answer those questions from the published material, the project hasn't given you enough information to make an informed decision. That's not an audit problem. That's an information problem, and it's on you to insist on the answer.