An ERC-4626 vault presents a single, uniform interface for depositing an underlying token and receiving shares, but a friendly function name does not turn an estimate into a guarantee. The standard separates four questions — what the vault counts, what an exchange would produce, how much a specific address can currently transact, and who is authorized to move the tokens — across different methods. Reading one result as if it answered all four is the usual path to a positive preview followed by a failed deposit.
Assets, shares and the managed total
ERC-4626 standardizes vaults that hold a single underlying ERC-20 token. The asset is that underlying token; the share is the vault’s own token, a fractional claim on the underlying holdings. A share balance is not a balance of the underlying asset. The asset() method names the underlying contract, while ERC-20 operations on the vault — balanceOf, totalSupply, transfer — describe shares. One share does not necessarily equal one underlying token.
totalAssets() reports the amount of the underlying asset the vault manages. The specification says it should include compounding from yield and must include fees charged against vault assets. That figure answers an accounting question; it does not say how much a particular owner can withdraw right now.
Choose the operation by the quantity you want fixed
The four exchange methods are not synonyms. deposit fixes the assets supplied and returns shares minted; mint fixes the shares to issue and returns assets required. On exit, withdraw fixes the assets to receive and returns shares burned, while redeem fixes the shares to burn and returns assets received. Each pairs with its own preview and its own capacity method, and mixing them reverses the meaning of the displayed number.
Address roles matter too. The receiver gets newly issued shares on entry or underlying assets on exit; the owner is the address whose shares are burned on exit. The caller submits the operation and may differ from both.
Conversion and preview are different instruments
convertToShares and convertToAssets are idealized conversions. The standard requires them to exclude fees, to show no variation by caller, to ignore slippage, and to round down. They are rough estimates for average valuations. The operation-specific previews answer a narrower question — for example, previewDeposit estimates the shares a deposit would produce while including deposit fees.
Previews describe a simulation at the current block. Their comparisons to real operations refer to calls in the same transaction; a number fetched earlier by a website is not a reservation for a later transaction. Previews also deliberately ignore their matching limits. previewDeposit must act as though the deposit would be accepted even when token approval is missing.
Check capacity and authorization separately
Entry capacity belongs to the receiver: maxDeposit returns an asset amount, maxMint a share amount. Exit capacity belongs to the owner: maxWithdraw returns assets, maxRedeem shares. Comparing values with different units can produce a misleading pass or fail. These methods must factor in global and user-specific limits, must not overstate what would be accepted, and must return zero when the operation is disabled. They assume the user has infinite assets, so a large maximum does not prove a wallet holds the tokens.
A supported deposit flow uses approve then transferFrom on the asset. When another caller exits on an owner’s behalf, the delegated flow uses authority over the vault shares instead. An allowance over the underlying token is not the same authorization object as an allowance over shares.
Rounding and the limits of the label
Rounding favors the vault: round down what a user receives and round up what they must supply. The conversion methods must always round down, which is a separate requirement from the general guidance. These directions do not establish one universal asset-to-share formula, and the specification leaves allocation and accounting details to implementations.
The interface itself is not a safety certificate. The security notes warn that a malicious vault can conform to the interface without conforming to its requirements, and that previews are manipulable and not always safe price oracles. A useful sequence when a deposit fails or an exit is restricted is: identify the contracts and units, name the operation, use its matching preview, check the matching maximum for the right address, then separate balance from allowance. A zero maximum does not by itself diagnose insolvency — it narrows which question still needs an answer.
Adapted from ERC-4626 Vault Shares: Why a Deposit Preview Is Not a Guarantee.