ERC-4626 Vault Shares: Why a Deposit Preview Is Not a Guarantee

A positive previewDeposit result does not mean an ERC-4626 vault will accept your deposit. The function estimates how many vault shares an asset amount would produce under current conditions, but deliberately leaves deposit limits and sufficient token approval outside that answer. A preview can therefore look useful while the transaction you intend to submit remains unavailable.

The practical task is to separate four questions: what does the vault count, what would the exchange produce, how much can this address currently transact, and who has authority to move the tokens? The ERC-4626 tokenized-vault specification assigns those questions to different methods. Reading one result as though it answered all four creates the positive-preview-but-failed-deposit problem.

First identify what the vault counts

ERC-4626 standardizes an interface for vaults with a single underlying ERC-20 token. It distinguishes the asset, meaning that underlying token, from the share, meaning the vault token representing a fractional claim on underlying holdings. A share balance is not itself a balance of the underlying asset.

The vault’s asset() method identifies the underlying token contract. By contrast, ERC-20 operations on the vault, including balanceOf and totalSupply, concern shares. Before interpreting an amount, establish which contract supplied it and whether the number is denominated in assets or shares. One share does not necessarily correspond to one underlying token.

totalAssets() reports the amount of underlying assets managed by the vault. The specification says it should include compounding from yield and must include fees charged against assets in the vault. That managed-asset figure answers an accounting question. It does not, by itself, state how much a particular owner can withdraw immediately.

A familiar token name cannot resolve these distinctions. BTC-Pulse’s guide to how to identify the token contract rather than its ticker explains why display names are insufficient for asset identification. That is a conceptual comparison only, not documentation of ERC-4626 asset support or bridge compatibility. For the vault, the relevant starting point remains its actual asset() result.

Choose the operation by the quantity you want fixed

The four exchange methods are not alternative names for the same instruction. Each fixes one quantity and determines the other. The deposit, mint, withdraw, and redeem definitions establish the following pairings.

If your instruction is “supply this amount of underlying tokens,” deposit is the matching operation. If it is “obtain this number of shares,” mint fixes that share quantity instead. On exit, withdraw specifies the underlying amount you want delivered; redeem specifies the shares you want burned. Choosing the wrong preview can reverse the meaning of the number displayed.

Address roles also matter. The receiver obtains newly issued shares on entry or underlying assets on exit. For withdrawals and redemptions, the owner is the address whose shares are burned. The caller submits the operation and may differ from the owner or receiver. These distinctions determine which address belongs in a capacity query and which authority the execution requires.

Conversion is an accounting estimate, not an execution quote

convertToShares and convertToAssets provide idealized conversions. They must exclude fees, must not vary by caller, and must not reflect slippage or other onchain conditions affecting the actual exchange. Both must round down. The standard describes them as rough estimates intended for applications needing an average valuation rather than an operation-specific result.

Previews answer a narrower operational question. For example, previewDeposit estimates shares for a deposit while including deposit fees. Comparing it with convertToShares can reveal that the operation-specific result is less favorable than the idealized conversion. It does not automatically identify the precise reason. Fees, slippage-related conditions, and implementation details require their own examination.

This distinction also prevents a withdrawal mistake. An asset estimate obtained from a share quantity is not a statement that those assets are currently available to that owner. Conversion concerns value expressed in another unit; capacity concerns an executable amount under limits. Neither a conversion result nor the vault’s aggregate managed assets replaces the relevant owner-specific maximum.

Read previews within their transaction boundary

The specification describes previews as simulations at the current block, given current onchain conditions. Crucially, its comparisons with actual operations refer to calls in the same transaction. A number fetched earlier by a website is not a reservation of that exchange outcome for a later transaction.

For conforming behavior within that stated boundary, deposit should return the same or more shares than previewDeposit. Mint should require the same or fewer assets than previewMint. Withdraw should burn the same or fewer shares than previewWithdraw. Redeem should return the same or more assets than previewRedeem. These directions preserve whether the preview describes an amount received or an amount supplied.

The operation-specific preview requirements also include the relevant deposit or withdrawal fees. That makes previews more useful for their matching operation than a fee-excluding conversion. It does not make them interchangeable: a preview of assets required to mint shares is not a preview of assets received when redeeming those shares.

Previews deliberately disregard their corresponding limits. The deposit preview assumes acceptance even when sufficient token approval is absent; exit previews similarly do not establish that the owner has enough shares or that the exit fits current capacity. Those omissions support composability, but they leave important questions unanswered for a user preparing a transaction.

Nor are previews universally non-reverting. They must not revert because of the specified vault-specific user or global limits, but may revert for other conditions that would also cause their matching operation to revert. “The preview returned a value” and “the transaction will succeed” are therefore different statements, even before considering changes between separate calls.

Check limits and authorization separately

Entry capacity belongs to the receiver: maxDeposit(receiver) returns an asset amount, while maxMint(receiver) returns a share amount. Exit capacity belongs to the owner: maxWithdraw(owner) returns assets, while maxRedeem(owner) returns shares. Comparing values with different units can produce a misleading apparent pass or failure.

These maxima must account for global and user-specific limits and must not overstate the amount accepted; they may underestimate when necessary. The methods must not revert. If deposits or withdrawals are entirely disabled, the corresponding maximum must return zero. A zero capacity result therefore concerns the specified operation and address, not necessarily the existence of a share balance.

Deposit and mint maxima assume the user has infinite assets rather than checking the underlying-token balance. A large maximum cannot establish that your wallet holds the required tokens. Likewise, it cannot replace authorization checks. Capacity, holdings, and permission are separate inputs to understanding whether your intended action is feasible.

The standard requires support for an underlying-token approve/transferFrom deposit flow. That authorization concerns the asset contract. When another caller withdraws or redeems on an owner’s behalf, the supported delegated flow instead uses authority over the owner’s vault shares. The distinction is easier to follow once token allowances and spending permissions are understood: approving spending changes permission, not necessarily token ownership immediately.

Consequently, an allowance over the underlying token is not the same authorization object as an allowance over vault shares. Record the token contract, owner, and spender rather than relying on a single “approved” label. A caller can have permission to act without being allowed to bypass the vault’s limits; permission does not override capacity.

A wallet may present several calls as one action. BTC-Pulse’s explanation of programmable wallet authorization describes how approval and deposit can be batched while retaining implementation and permission risks. That is optional wallet behavior, not an ERC-4626 requirement. A combined interface still needs to distinguish the caller, the share owner, the receiver, and the tokens subject to spending authority.

Understand rounding without assuming a universal exchange formula

Rounding matters because contract arithmetic ultimately produces discrete token amounts. The standard’s security discussion favors the vault when a calculation cannot divide exactly: round down what the user receives and round up what the user must supply. That rationale should be distinguished from the explicit requirement that both conversion methods always round down.

These directions do not establish one universal asset/share formula. The specification intentionally leaves accounting and allocation details to implementations. It also recommends mirroring the underlying token’s decimals where possible rather than guaranteeing identical decimals everywhere. Units must therefore be established before comparing raw integers or human-readable balances.

The security considerations on rounding and preview selection expressly warn that minting and redeeming the same share quantity can involve significantly different asset amounts. Rounding can contribute a small difference; entry or exit fees can create a larger one. Do not treat a mint preview as evidence of what a subsequent redemption would return, or assume that conversion methods erase those differences.

Diagnose a failed deposit or restricted exit

Consider a qualitative hypothetical, not an observed vault: previewDeposit returns a positive share amount, but maxDeposit for the intended receiver returns zero. There is no contradiction. The preview estimates the exchange while ignoring deposit limits; the maximum reports that the receiver currently has no capacity through that operation.

An insufficient underlying-token allowance could be another obstacle, but the positive preview would not have checked it. Increasing an allowance would not resolve a zero maximum. Conversely, available capacity would not supply missing tokens or create spending authority. These are separate branches of the diagnosis, not alternative descriptions of one check.

The same reasoning applies on exit. Owning shares and obtaining an asset estimate from previewRedeem does not establish immediate exit capacity if maxRedeem(owner) is zero. The standard also notes that some implementations require a separate pre-request before withdrawal. It does not specify a universal request process, waiting period, or reason for a restriction.

A read-only diagnostic sequence can organize the evidence before any further transaction is considered:

1. Identify the contracts and units. Separate the underlying token from the vault share token and assets from shares.
2. Name the intended operation. Decide whether the fixed quantity is assets supplied, shares issued, assets received, or shares burned.
3. Use its matching preview. Interpret the result in the correct units and preserve the current-condition, same-transaction boundary.
4. Check the matching maximum. Query the intended receiver for entry or owner for exit, not an arbitrary connected address.
5. Separate balance from allowance. Establish which token must be held and which token’s spending authority matters.
6. Check implementation prerequisites. Look for documented pre-requests or other conditions outside the standardized call.
7. Preserve the timing record. Results obtained under different onchain conditions should not be treated as one synchronized execution assessment.

This sequence narrows the missing question. It does not prove that a particular vault is solvent, compliant, or safe, and a zero maximum alone does not diagnose insolvency. Establishing why capacity is restricted requires implementation-specific evidence rather than an inference from share ownership or a preview display.

Know what the interface cannot certify

Recognizable function names are not a safety certificate. The specification warns about malicious implementations that conform to the interface without conforming to its requirements, and recommends reviewing implementations for ways user deposits could be lost before integration. An interface can expose the expected methods while their behavior remains unsuitable or unsafe.

The standard also leaves the allocation of deposited tokens and accounting details intentionally unspecified. It standardizes how applications interact with vaults, not a particular investment strategy, return, principal guarantee, or exit schedule. Those properties require separate documentation and implementation analysis; they cannot be inferred from the ERC-4626 label.

Previews have a further boundary: because they reflect onchain conditions, the security discussion warns that they can be manipulated and are not always safe price oracles. It permits conversion methods to use designs such as time-weighted averages, but permission to build a robust oracle is not certification that every conversion method is one. A value useful for display is not automatically suitable for another protocol’s financial decisions.

Frequently asked questions and a reusable interpretation checklist

Is one vault share always one underlying token?

No. Shares and assets are different accounting units. Use the appropriate conversion or operation-specific preview for the question being asked, without treating the result as a principal guarantee.

Does a successful preview prove my approval is sufficient?

No. The deposit preview explicitly assumes acceptance regardless of sufficient token approval. Authorization must be examined separately for the relevant token and caller.

Does maxDeposit check how much I own?

No. It assumes infinite assets and must not rely on the underlying-token balance. It reports receiver capacity, not the wallet’s ability to fund that capacity.

Can I substitute previewMint for previewRedeem?

No. One estimates assets required to obtain shares; the other estimates assets received for returning shares. Fees and rounding can make their outputs materially different.

Are vault shares necessarily transferable?

No. Although vaults must implement ERC-20 shares, the specification permits a non-transferable vault to revert on transfer or transferFrom. Do not infer unrestricted transfers merely from the token interface.

Does ERC-4626 specify the investment strategy?

No. Allocation and accounting details remain implementation-specific. Understanding the interface does not replace reviewing what a particular vault does with deposited tokens.

Keep the interpretation sequence explicit: identity → units → operation → matching preview → limits → authorization → implementation boundaries. If a display answers only the preview step, the useful next question is which capacity or permission check remains unanswered—not whether the positive number alone makes the deposit available.