Protocol mechanics
Vault shares: why the balance is not the withdrawal amount
At a glance
Vault shares, their estimated underlying assets and the amount currently redeemable are different quantities. Under ERC-4626, a redemption preview includes withdrawal fees but does not check redemption limits. Read the actual vault implementation: neither a conversion estimate nor a familiar method name guarantees that the whole holding can be withdrawn now.
On this page
A vault balance of 100 tokens does not necessarily mean 100 units of its underlying asset. It may count shares in a pool. Even a separate asset estimate does not establish how much you can withdraw now. Read the ownership, conversion and access figures separately.
Name what each number measures
The ERC-4626 specification defines a vault interface for a single underlying ERC-20 asset. Its share tokens represent a claim on the vault's holdings. The vault's balanceOf reports shares; asset identifies the underlying token.
Three other named views answer different questions:
| View | Unit | What it describes |
|---|---|---|
| convertToAssets | Underlying assets | An idealized conversion of a supplied share quantity, excluding fees and execution conditions |
| previewRedeem | Underlying assets | A redemption preview incorporating withdrawal fees, without checking redemption limits |
| maxRedeem | Shares | A limit for the specified owner's redemption under the standard; it can underestimate what is accepted |
A preview is therefore not permission to redeem that amount. These are standard interface meanings, not evidence that every product labeled a vault implements them identically.
Work through one invented snapshot
Assume you own 100 shares in a fictional vault. For this illustration only, every share converts to 1.20 underlying asset units, and a current restriction permits redemption of 40 shares. Assume no fees, no rounding effect, unchanged state and all other requirements satisfied. These are invented inputs, not a live quote, Morpho setting or OpenZeppelin implementation calculation.
| Question | Calculation | Hypothetical result |
|---|---|---|
| What does the whole holding represent at the assumed rate? | 100 × 1.20 | 120 asset units |
| What does the permitted portion represent? | 40 × 1.20 | 48 asset units |
| How many shares remain after that redemption? | 100 − 40 | 60 shares |
120 estimated asset units and 48 units for the permitted portion can coexist without an arithmetic error. The difference comes from the assumed access restriction. The remaining 60 shares are not another withdrawal already completed.
The rate of 1.20 does not establish a 20% return: we have supplied no purchase cost or earlier rate. Nor does the example promise that the remaining shares will be redeemable later.
A ratio is not a safety certificate
OpenZeppelin's implementation guide explains share conversion, rounding, fee customizations and virtual assets and shares. Those details are why a hand-calculated assets-divided-by-shares ratio should not replace the actual implementation's conversion method.
A vault can lose assets; a stable share count does not guarantee stable underlying value. A higher conversion estimate also does not establish liquid assets ready for immediate withdrawal. Contract behavior and available liquidity need separate examination. This article offers no yield forecast or assessment of a particular vault's safety.
Check implementation exceptions before acting
There is a concrete reason to read current product documentation. Morpho's Vault V2 guide says its max functions always return zero and gives a separate procedure for calculating capacity. It identifies available withdrawal liquidity and permission gates as relevant constraints.
That is documented Morpho V2-specific behavior, not a claim that all ERC-4626 vaults report zero. Conversely, a zero from that implementation alone does not establish that every exit route is impossible.
For an existing holding, record the network, vault and underlying asset, share balance, observation time, conversion or preview method, fees, and the implementation's withdrawal restrictions. Confirm the exact route through official documentation; do not infer it from a ticker or a portfolio total. Our bridge review explains token-representation checks; wallet permissions covers a separate authorization question.
Editorial note: CoinFom prepared this explanation with AI-assisted research, writing, translation and review. Sources checked October 21, 2026. No wallet was connected or transaction performed. Educational content, not a recommendation to deposit or redeem. CoinFom may earn referral commissions elsewhere; this article contains no signup link. See About, editorial policy and corrections.