A wallet can display a positive previewDeposit result and the deposit can still fail a few blocks later. ERC-4626 preview methods simulate an exchange; they do not reserve one. previewDeposit answers a narrow question — roughly how many vault shares an amount of assets would produce under current conditions — while leaving deposit limits and token approval outside the answer. Reading the number correctly means separating what it covers from what it does not.
The preview answers an exchange, not an acceptance
ERC-4626 standardizes vaults over a single underlying ERC-20 token and keeps two units apart. The asset is the underlying token; the share is the vault token that represents a claim on pooled holdings. previewDeposit estimates the shares issued for assets supplied, and the specification requires the estimate to be as close to, and no greater than, what a deposit in the same transaction would actually mint. It also requires the method to ignore the limits returned by maxDeposit and to act as though the deposit would be accepted even when the caller has not approved enough tokens.
That isolation is deliberate: the preview must be composable without reverting on vault-specific or user-specific limits. The cost is that a positive result carries no signal about whether the receiver has capacity, whether the wallet holds the assets, or whether spending permission exists.
Conversion and preview are different tools
convertToShares and convertToAssets describe an idealized exchange. The specification requires both to exclude fees, to return the same value for every caller, to ignore slippage, and to round down toward zero. They are rough, average valuations. previewDeposit differs on two axes: it includes deposit fees, and it is specific to the deposit operation rather than an average. Comparing the two can surface an unfavorable exchange, but it will not name the cause, and neither figure certifies that assets are currently available to withdraw.
Capacity and permission are separate checks
Entry capacity belongs to the receiver — maxDeposit(receiver) returns an asset amount and maxMint(receiver) a share amount — while exit capacity belongs to the owner through maxWithdraw(owner) and maxRedeem(owner). These maxima must account for global and user-specific limits, must not overstate what would be accepted, and must return zero when the operation is disabled. The deposit-side maxima also assume the user has infinite assets; the specification forbids them from relying on the underlying token balance. A large maxDeposit therefore does not prove the wallet holds the tokens, and an allowance over the underlying token is a different object from authority over vault shares.
A preview is bound to one transaction
The specification’s guarantee is narrow: deposit should return the same or more shares than previewDeposit when the two run in the same transaction. A number fetched earlier by a website is not a promise for a later transaction, because on-chain conditions — and the fees, limits and balances that feed the preview — change between blocks. Previews may also revert for conditions other than the specified limits, so “the preview returned a value” and “the transaction will succeed” remain different statements.
Diagnose before concluding
A failed deposit with a positive preview usually means one of a few missing pieces, and each needs a different fix. Establish the contracts and units first, name the operation so the matching preview and maximum are used, check the maximum for the correct address, then separate the token balance from the token’s spending allowance. Increasing an allowance will not fix a zero maximum, and available capacity will not supply missing tokens. The interface itself is not a safety certificate: a vault can expose the expected methods while its behavior remains unsuitable, so a preview number only narrows which question is still unanswered.
Source: BTC-Pulse.