ERC-4626 vault shares vs assets: check what your balance means
A vault's share balance and its underlying-token estimate describe one position in different units. A redemption preview adds another question: what could come out?
An ERC-4626 vault balance is a number of shares, not automatically the same number of underlying tokens. Identify the vault’s asset, then distinguish a general conversion from a redemption preview and the owner’s redemption limit. These figures answer different questions about one position.
If a wallet shows 100 shares while a protocol screen shows 120 underlying tokens, do not start by assuming either balance is wrong. First check what each number measures. This guide is a read-only way to reconcile an existing holding, not a recommendation to deposit into a vault or redeem it.
Identify the share token and its underlying asset
The ERC-4626 standard defines vault shares as ERC-20 tokens. The vault’s balanceOf(account) counts those shares; its asset() method identifies the underlying token contract. Keep both contract addresses beside the network and the account you are checking.
A familiar ticker is insufficient. Confirm the exact vault deployment through the protocol’s official documentation or a known transaction, reached through a trusted route. Then compare the underlying asset address, not just its name, with the intended token. A copied contract can expose familiar method names without being the vault you meant.
Check the units on both sides. A raw share amount must use the share token’s decimals, while a raw asset output uses the underlying token’s decimals. They need not be identical: OpenZeppelin’s vault guide describes implementations with additional share precision. Our token-decimal guide explains how to recognize an integer that still needs formatting. Do not scale an already formatted amount again.
Choose the figure that answers your question
Use the documented reads for the verified contract rather than multiplying by a rate copied from another vault. The OpenZeppelin API reference separates conversion, preview and limit methods.
| Read | Unit returned | Question answered |
|---|---|---|
balanceOf(account) |
Shares | How many shares does this account hold? |
convertToAssets(shares) |
Underlying assets | What is the general asset equivalent? |
previewRedeem(shares) |
Underlying assets | What is the redemption estimate for these shares? |
maxRedeem(owner) |
Shares | How many shares can this owner currently redeem? |
convertToAssets describes an ideal conversion, excluding fees and actual-exchange slippage. It is not a personalized withdrawal quote. previewRedeem includes withdrawal fees and reflects current conditions, but deliberately ignores redemption limits. For those limits, read maxRedeem for the owner. The standard’s method definitions make these distinctions explicit.
A positive preview is therefore compatible with a smaller limit, or even a zero limit. Nor is a read a reservation of funds: the state can change before a later transaction. Follow the particular vault’s documented withdrawal conditions, including any required request procedure. A vault using an asynchronous extension or a different interface needs its own instructions.
Keep one holding in your comparison
Consider a hypothetical snapshot, with all figures already formatted into human-readable units. An account holds 100 shares. The vault reports 120 underlying tokens through convertToAssets for that share amount and 119 underlying tokens through previewRedeem. Separately, maxRedeem for the account is 40 shares.
The 120-token figure is a general equivalent. The 119-token figure is the preview for all 100 shares, not proof that all 100 can be redeemed now. The 40-share limit is measured in shares and must not be compared as if it were 40 underlying tokens. To examine the permitted share amount, obtain its own preview rather than assuming the full-balance preview applies unchanged.
These numbers are an invented example of labels and scope, not a live vault quote, a fee schedule or a calculation of a particular protocol’s rate. No wallet was queried or transaction executed for it.
Do not add 100 shares and their 120-token equivalent as separate holdings. They describe the same position. If the wallet also holds underlying tokens outside the vault, record that actual wallet balance separately. When comparing fiat totals, check which representation a tracker already counted before adding a protocol value. The broader portfolio reconciliation guide helps separate a missing quantity from a missing price or unsupported position.
Record a consistent snapshot without moving funds
Use an explorer or contract reader you already trust. This procedure describes a documentation-based inspection; it was not tested against a live vault for this article. The primary references were checked on 25 October 2026.
- Confirm the position’s identity. Record the network, account and full vault contract address. Verify that the deployment uses the ERC-4626 interface you intend to inspect.
- Identify the asset and units. Record
asset()and the share and asset decimal scales. Read the account’s share balance, keeping raw integers distinct from formatted quantities. - Choose the relevant read. For an accounting comparison, record
convertToAssetsfor that exact share amount. For a redemption estimate, recordpreviewRedeemand label it as a preview. - Check the owner-specific limit separately. Read
maxRedeem(owner)and the protocol’s withdrawal conditions. Do not replace an unavailable limit with the share balance or treat a positive preview as authorization to redeem. - Align and label the observations. Prefer the same block for balance, conversion, preview and limit. If the reader only provides separate latest-state calls, save their times and note that the snapshot may differ.
- Reconcile one position. Keep its share count, asset equivalent and redemption information together. Mark a failed read unknown, preserve its error, and investigate the account, contract, network or interface before concluding the amount is zero.
No signature, approval, recovery phrase or transfer is needed for these public reads. If a site asks for one just to reveal a balance, stop that flow. A contract response can help explain a display; it does not certify the contract’s safety.
A conversion is not a return or a sale price
An asset equivalent answers how the vault expresses a share amount in its underlying token. It does not establish profit from your original deposit, a market sale price or guaranteed future redemption. Fees, rounding, changes in the vault and the underlying asset’s own price belong in separate records.
Do not generalize this procedure to every receipt token. For example, stETH and wstETH have their own documented accounting and conversion method. A similar-looking balance does not establish ERC-4626 behavior.
Your check is complete when you can name the exact vault and asset, identify the share quantity and snapshot, and explain which screen shows a conversion, a preview or a limit. If an essential read is unavailable, leave that part unverified. Moving the position is a separate decision; it is not required to explain its displayed balance.
Frequently asked questions
Is one ERC-4626 share always one underlying token?
No. Shares and assets are different units, and their conversion depends on the vault. Read the documented conversion for the exact contract and snapshot; do not infer a one-to-one rate from the token name or decimal places.
Does previewRedeem prove I can withdraw that amount now?
No. It estimates the assets returned for a share amount and includes withdrawal fees, but ignores redemption limits. Read the owner's maxRedeem and the vault's actual withdrawal rules separately. State can change before a transaction.
Should I add my shares and their asset equivalent together?
No. When both entries describe the same position, record one holding with its share quantity and asset equivalent. Underlying tokens separately held in your wallet are another balance.