ERC-4626 vaults: share value and withdrawal ability are different

A wallet showing 100 vault shares does not necessarily contain 100 units of the deposited asset. And a screen valuing those shares at 110 assets does not, by itself, show that 110 assets can be withdrawn now. Those are different questions, with different contract functions intended to answer them.

ERC-4626 makes tokenized vaults easier for applications to integrate. Reading its labels correctly helps distinguish ownership accounting, a transaction estimate and the available exit route.

Start with the unit

ERC-4626 defines a vault interface for one underlying ERC-20 asset. Its share token represents an interest in the vault's underlying holdings. A share balance and an asset balance are therefore separate units. The standard defines asset() to identify the underlying token and totalAssets() to report assets managed by the vault.

The OpenZeppelin API reference shows two ways to enter and two ways to leave. deposit fixes the amount of assets supplied; mint fixes the number of shares obtained. withdraw fixes the asset amount received; redeem fixes the shares surrendered. Confusing those inputs can make a seemingly precise instruction mean the wrong thing.

In a deliberately simplified vault with 1,100 asset units and 1,000 shares, 100 shares represent 110 assets before fees and rounding. If those managed assets instead become 900 with the share count unchanged, the same 100 shares represent 90 assets. This arithmetic illustrates proportional ownership; it does not specify the valuation method or virtual accounting used by a particular implementation.

Conversion, preview and capacity are separate readings

A convertToAssets result is an idealized conversion, excluding transaction fees and actual exchange conditions. previewRedeem estimates assets from redeeming a specified share quantity under current conditions, including applicable withdrawal fees. maxRedeem(owner) addresses the owner's current redemption limit. A preview deliberately does not enforce that limit. These distinctions follow the standard's method definitions.

A positive estimate and a zero maximum can coexist. That is a reason to investigate the restriction, not evidence that the estimate can be cashed out. Conversely, a positive maximum read before submitting a transaction cannot freeze future contract state. For a proposed withdrawal, record the amount, recipient, fees, permissions and limits together, using readings from the same block where possible.

The OpenZeppelin API requires full withdrawals or redemptions to fail when their limits are exceeded. It also notes that some vaults need a separate request before withdrawal. The useful dashboard question is therefore: what operation can this account complete, under which conditions?

Rounding has a direction

Integer arithmetic cannot always represent an exact fraction. The OpenZeppelin v5.4.0 implementation rounds deposit share outputs and redemption asset outputs down. It rounds the asset input needed to mint specified shares, and the shares needed to withdraw specified assets, up. These opposing directions prevent fractions from systematically being paid out at the vault's expense.

Rounding normally occurs at the smallest token units, not whole displayed tokens. Its significance depends on precision and the exchange ratio. The OpenZeppelin vault guide explains how small deposits into poorly protected or nearly empty vaults can receive disproportionately few shares. It describes virtual assets and shares as one implementation defense against donation-based inflation attacks. A familiar interface name does not establish which protections the deployed contract uses.

A request is not a completed withdrawal

ERC-7540 extends the model for asynchronous operations. A redemption can move through pending, claimable and claimed states. For its asynchronous redemption flow, previewRedeem and previewWithdraw must revert, so an application cannot apply the synchronous preview workflow unchanged. The eventual asset amount can differ from the conversion value when the request was made.

That extension provides a useful boundary: a standardized share token can still sit above a delayed asset-return process. Ask which standard and extensions apply, whether a request has become claimable, and what remains to be executed. The broader distinction between tokenized ownership and settlement remains relevant.

Finally, the ERC-4626 label is an interface claim, not a security assessment. The standard's security section warns that malicious contracts can expose the interface without honoring its specification. Check the actual token and vault addresses, documented strategy, withdrawal rules and relevant implementation. Token identity starts with the contract address, and a reported conversion value is only one part of understanding that contract.