ERC-4626 Vault Security Audit Checklist

ERC-4626 is the tokenized vault standard. A vault takes an underlying ERC-20 asset, holds or deploys it to earn yield, and issues shares that represent a claim on the growing pool. The interface looks small, just deposit, mint, withdraw, and redeem plus some preview and accounting helpers, but almost the entire risk surface lives in one number: the share price, which is total assets divided by total shares. Anything that can bend that number in an attacker's favor is where the money leaks.

This checklist walks the vault one concern at a time, from that share price outward. Each item is something to confirm during a review, written so you can hand it to an auditor who is new to vaults. If you want a refresher on the interface and its RWA framing first, our ERC-4626 standard breakdown covers the 17 functions and the rounding rules in detail.

Treat this as a floor, not a ceiling. A real engagement still needs manual review, property tests and fuzzing against the actual math, and a threat model built around the specific yield source and token. The point of the list is to make sure none of the well-known vault failure modes slip through.

How a vault works

Here is the whole idea in one picture. Users hand assets to the vault and get shares. The vault tracks how many shares exist and how many assets it controls, and the ratio between those two numbers is the price of a share. Assets may sit idle or get deployed to a strategy that returns them with yield.

Everything else in this checklist is really one question asked from different angles: can someone make the share price lie, even for a single block, and profit from the gap.

Before you start

A vault is only as trustworthy as the yield source behind it and the token in front of it. Get both clear before reading a line of the vault.

Spec and yield model understood. You have the whitepaper, doc, or description, and you know where yield comes from, how often it lands, and whether it can ever go negative. If the material is thin, ask for more before starting.
Share price inputs mapped. You know every source that feeds totalAssets, idle balance, deployed strategy value, oracle or NAV feeds, and every path that changes totalSupply.
Rounding noted per function. You have written down which way each of the four operations rounds, so you can check the code against it rather than from memory.
Tokens and integrations listed. You know the underlying token's decimals and quirks, and which external protocols the vault touches.

The share price and totalAssets

totalAssets is the heart of the vault. It is the valuation oracle the whole system prices against, so anything that can move it without a matching change in shares moves the price for everyone.

totalAssets counts only what backs the shares. It reflects the real assets the vault controls, no more and no less. It does not double count, and it does not include assets that belong to someone else.
Strategy positions are valued, not assumed. If assets are deployed, their value comes from converting the actual position, not from a stored number that can drift out of date.
A donation cannot move the price for free. Sending tokens straight to the vault should not let an attacker change the share price in a way that harms other holders. Check how direct transfers are accounted for.
Meta vault accounting is correct. If this vault holds shares of another vault, totalAssets values those shares by what they can actually redeem for, and a direct deposit into the inner vault cannot shift this vault's share price.
Conversions are consistent. convertToShares and convertToAssets are exact inverses within rounding, so there is no precision gap to arbitrage between them.

Inflation and donation attacks

This is the signature ERC-4626 bug. When a vault is nearly empty, a first depositor can take one share, donate a large amount to spike the price, and make the next depositor's shares round down to almost nothing.

A real defense is in place. The vault uses virtual shares and assets, a decimal offset, dead shares, or a meaningful seeded first deposit. Confirm which one, and that it actually blunts the attack rather than just looking like it does.
The cold start is handled. The first deposit into an empty vault cannot be gamed, and conversions behave sanely when supply is zero.
The attack was actually tested. There is a test that donates into a fresh vault and shows a later depositor still gets a fair share.
Direct inflows are controlled where needed. For higher-value or regulated vaults, consider whether unsolicited donations should be limited or checkpointed rather than silently counted.

Rounding direction

Every conversion has to round in the vault's favor, never the caller's. Get one direction backwards and value leaks out one wei at a time, or a whole deposit rounds to zero shares.

All four directions match the standard. Deposit rounds shares down, mint rounds assets up, withdraw rounds shares up, redeem rounds assets down. Anything else favors the user and drains the vault over time.
Multiply before divide. Calculations do the multiplication first and use a safe full-precision helper, so intermediate steps do not round to zero.
Small amounts cannot round to a free withdrawal. A tiny withdrawal or redemption cannot burn zero shares while still moving assets, and a tiny repayment or deposit cannot skip a state change it should trigger.
Fees do not break the rounding. If the vault charges a fee, the fee math keeps the rounding in the vault's favor and stays consistent between preview and execution.

EIP-4626 compliance

Integrators trust the standard's guarantees. If the preview and max functions lie, lending markets and aggregators built on top of the vault inherit the bug.

Preview matches reality. previewDeposit, previewMint, previewWithdraw, and previewRedeem return exactly what the matching call will produce, fees included, and none of them revert.
Max functions tell the truth. maxDeposit, maxMint, maxWithdraw, and maxRedeem reflect real limits, including any cap or the yield source's own limit, and return zero when the operation is disabled or paused.
Withdraw honors its promise. withdraw returns exactly the requested assets or reverts. It does not quietly deliver less because liquidity, a cap, or the owner's balance falls short.
Convert versus preview is respected. The convert functions give the idealized fee-free rate for quoting, while the preview functions include fees and slippage. They are not used interchangeably.
Delegated flows check allowance. When a caller acts on behalf of an owner, the share allowance is spent correctly, and the right owner is charged.

Accounting, CEI, and reentrancy

The moment between updating balances and moving tokens is where reentrancy lives. A vault that transfers before it settles state, or reads a half-updated price, can be drained.

Checks, effects, interactions is followed. Shares are burned and accounting is updated before assets leave the vault, and on deposit the state reflects reality before any external call that could re-enter.
Read-only reentrancy is considered. No integrator can call back into a view like convertToAssets while the vault is mid-update and read a price that is temporarily wrong.
Cross-function reentrancy is closed. Two functions that share state cannot be interleaved to double count or skip an update, and guards are placed where a callback token or hook makes this possible.
Deposit measures what actually arrived. For any token that might not deliver the full amount, the vault credits the real received balance rather than the requested number.

Non-standard tokens

The standard assumes a plain ERC-20. Real tokens are messier, and each quirk breaks a different assumption in the vault's math.

Fee-on-transfer is handled or excluded. Either the vault credits the amount it truly received, or the design explicitly rules these tokens out.
Rebasing tokens are handled or excluded. A supply that changes on its own does not silently break totalAssets, or the vault documents that such tokens are unsupported.
Callback hooks cannot re-enter. Tokens that call the receiver on transfer cannot use that hook to re-enter a sensitive path.
Decimals are handled correctly. The vault does not assume 18 decimals, handles low-decimal tokens without amplifying rounding, and copes with tokens over 18 decimals.
Transfers use a safe wrapper. Missing return values, tokens that revert on zero-value transfers, and blocklist or pause behavior are all accounted for.

Oracles and price manipulation

If totalAssets or a redemption price reads a value that can move within a block, a flash loan can move it. NAV and price feeds have to be resistant to being pushed for a single transaction.

No manipulable spot read drives value. The vault does not price off an instantaneous pool read or raw balances that a flash loan can distort within a transaction.
Time averaging or a trusted feed is used. Where a market price is needed, it comes from a TWAP or an authoritative signed feed rather than a single-block snapshot.
Feeds are validated. Oracle or NAV reads check for staleness, non-zero and sane values, and on L2 they check sequencer uptime. Signed NAV updates carry a timestamp and a nonce so they cannot be replayed.
Conversions are not exposed as an oracle. The vault's own convert functions are not offered to other protocols as a trustworthy on-chain price mid-transaction.

Yield and reward accounting

Yield has to reach holders in proportion to their shares, and reward bookkeeping has to update at the right moment. Get the ordering wrong and rewards land on stale balances or get erased.

Reward state updates before balances change. Accrual runs before any mint, burn, or transfer, so no one is paid on a balance they no longer hold, and no one is skipped.
Continuous deposits cannot grief rewards. Repeated small deposits cannot deny reward accrual to other stakers, which is a known failure mode with low-decimal reward tokens.
Simple and compound interest are not confused. The vault charges or pays the interest model it claims to, and does not compound something meant to be simple.
Small positions are handled. Tiny holders do not lose all rewards to rounding, and dust rewards cannot be used to reset or extend a distribution period.
Yield cannot go unexpectedly negative. Loss scenarios from the strategy are handled so a bad harvest does not corrupt share accounting.

Strategies and external integrations

Most real vaults deploy assets somewhere. The seams between the vault and the strategy are where accounting quietly goes wrong.

Shares and assets are never mixed up. When the vault calls a strategy, it knows whether the return value is shares or assets and converts before using it. This confusion is one of the most common vault findings.
Deployed amounts are tracked accurately. The recorded deployed balance is updated on both deploy and withdraw, using the actual amount moved rather than the amount requested.
A paused or failing strategy degrades safely. If one strategy is paused or reverts, users can still withdraw from the rest, and the whole vault is not bricked.
Slippage is protected on strategy moves. Deposits into and withdrawals from external pools carry a minimum-out, not a hardcoded zero.
Strategy config is validated. The asset the vault deploys matches what the strategy expects, and adding a strategy grants only the approvals it needs.

Access control and admin powers

Vaults concentrate power in a few functions. The audit has to be clear about who can move funds or change the rules, and how that power is contained.

Privileged functions are actually restricted. Setting strategies, fees, caps, and pausing are limited to the intended role, and no fund-moving function is left open by accident.
Harvest cannot be abused. If anyone can trigger a harvest or compound, it cannot be sandwiched or used to shift fees, and any swap it performs is slippage protected.
Admin cannot quietly drain value. A rescue or sweep function cannot pull the underlying asset or reward tokens owed to users, and fee changes sit within sane bounds.
Powerful actions are contained. Fee changes, strategy swaps, and upgrades sit behind a multisig or timelock, and the trust assumptions are stated plainly for depositors.
Deposit caps and allowlists check the right party. A cap or whitelist is enforced against the actual depositor and receiver, not only the immediate caller, so it cannot be bypassed through a second address or a router.

Add-on features

Extra features are where fresh bugs enter a standard that is otherwise well understood. Each one adds attack surface that the base vault never had.

Permit flows resist front-running. A permit signature pulled from the mempool cannot be used to grief the user or redirect funds, and the flow falls back gracefully if the permit is consumed.
Permit2 integration is exact. The amount stored in state matches the amount actually transferred, the witness hash uses proper typed-data encoding, and identifiers are not derived from a signature alone in a way a contract wallet can collide.
Cross-chain shares preserve value. If shares move across chains, the mechanism does not distort share value in transit, validates the source of every message, and uses the correct chain identifiers.
Hooks and callbacks are safe. Any lifecycle hook or callback cannot re-enter, cannot be set to something malicious, and has sensible gas and error handling.

Upgradeability and deployment

If the vault sits behind a proxy, the usual proxy failure modes apply, and a wrong initial configuration can undo perfectly correct code.

Initializers run once. Each upgradeable contract can only be initialized a single time, it was initialized after deployment, and the implementation itself cannot be hijacked.
Storage layout is protected. Upgrades do not reorder or retype existing storage, and reserved gaps guard against future collisions.
The asset is pinned correctly. The underlying asset is set once at deployment and cannot be swapped later through governance.
Deployment config matches intent. Decimals, caps, fees, the strategy wiring, and the upgrade authority are all set as intended, and no test or placeholder values remain.

General smart contract hygiene

The fundamentals still apply, and a vault holding pooled deposits is a bad place to skip them.

External calls are safe. ETH is sent with a call and checked, and all token interactions handle failure correctly.
Events cover every state change. Deposits, withdrawals, fee changes, strategy updates, and admin actions all emit events, since monitoring depends on them.
Casts are safe. Narrowing casts on shares, assets, or timestamps cannot silently truncate and let someone withdraw more than they should.
Slippage is available to users. Entry and exit expose a minimum-shares or minimum-assets parameter so depositors are not forced to accept a sandwiched rate.
The math is fuzzed. Property tests cover zero-supply edges, rebasing and fee-on-transfer tokens, and the round-trip that a deposit followed by an immediate redeem returns roughly what went in, minus fees and rounding.

Defensive defaults worth recommending

Beyond finding bugs, these are the low-cost defaults that close whole classes of vault attacks before they start. Recommend them even when nothing is currently broken.

Virtual offset or dead shares by default. Bake in inflation protection rather than relying on a careful first deposit.
Revert on zero. Deposit and mint revert if shares would be zero, and withdraw and redeem revert if the result would be zero, which shuts down dust and donation tricks.
Enforce a minimum meaningful amount. A small minimum on deposits denies attackers the one-wei transactions that rounding games depend on.
Match decimals sensibly. Require the vault's decimals to be at least the asset's, checked at construction, to prevent precision loss and configuration mistakes.

Where to go from here

Use this list as the structural pass, then dig deeper where a given engagement calls for it. Our interactive Tokenization 101 is the natural companion, showing where ERC-4626 sits as the liquidity vault layer across RWA standards, calling out the audit angle for each, and cataloging the incidents that have actually broken these systems, with share-price inflation among the most common. For the deeper reference, the RWA Development Handbook walks the ERC-4626 interface function by function and shows how vaults connect to the identity, compliance, and settlement layers that real-world assets depend on.