A vault share is a claim measured in another token
An ERC-4626 vault has an underlying asset and a share token. Shares represent a fraction of the vault’s underlying holdings. The tokenized-vault specification standardizes how applications read those quantities and exchange assets for shares. That common interface makes integration easier; it does not tell a reader which strategy, accounting choices or extra restrictions sit behind a particular deployment.
A displayed balance therefore needs a unit. The number of shares an account owns is different from the underlying assets those shares convert into. A change in one conversion result is useful evidence, but a screen that presents it as earned yield has added an explanation that the function call itself did not supply.
A conversion, a transaction preview and an oracle answer different questions
The specification describes convertToAssets and convertToShares as idealized conversions. They exclude fees and do not reflect execution slippage; their estimates are not necessarily a particular user’s exchange outcome. An application can use that distinction to label a portfolio estimate honestly instead of presenting it as a transaction receipt.
For a proposed redemption, previewRedeem is the relevant preview. It estimates the assets returned under current conditions and includes withdrawal fees. The specification’s comparison with the actual redeem operation concerns calls in the same transaction. A preview fetched earlier by an interface does not reserve that result for a later transaction. Owner limits belong in maxRedeem or maxWithdraw, not in the preview’s answer.
An oracle has a different job again: another system may use its answer to make a valuation decision. ERC-4626 explicitly warns that previews can change when onchain conditions change and are not always suitable as price oracles. It permits conversion methods to use more robust approaches, including a time-weighted value. Permission to implement such an approach is not evidence that a particular vault actually does.
A reproducible counterexample: the quote rises without strategy earnings
The OpenZeppelin reference implementation gives us a concrete accounting example. In the inspected Contracts 5.4.0 source, totalAssets reads the underlying token balance. The share-to-asset conversion uses that balance, total share supply and virtual accounting terms. The following calculation applies that published expression; it is not a transaction test or a measurement of a live vault.
Assume 1,000,000 raw asset units, 1,000,000 raw share units and the reference implementation’s default decimal offset of zero. For 1,000 raw shares, the floor-rounded calculation is 1,000 × (1,000,000 + 1) ÷ (1,000,000 + 1), producing 1,000 raw asset units.
Now assume an unsolicited transfer increases the vault’s asset balance to 2,000,000 raw units without changing its share supply. The same calculation becomes floor(1,000 × 2,000,001 ÷ 1,000,001), producing 1,999 raw asset units. The quote increased because the counted balance changed. No strategy earnings are needed to explain this constructed example.
Those inputs deliberately isolate one mechanism. They do not establish an attack, a profit opportunity or a loss for any deployment. An implementation with different accounting or conversion overrides needs a different calculation. Raw units are integer accounting quantities, not dollar prices or a claim about token decimals.
Virtual shares do not answer every integration question
OpenZeppelin’s generated code reference describes donation or inflation risk in empty or nearly empty vaults and explains its virtual-assets and virtual-shares mitigation. The inspected implementation contains those terms in its conversion formula. That is a specific implementation design, not a property the ERC-4626 label automatically gives every vault.
The counterexample also explains why these terms should not be described as freezing the share quote. With the stated inputs, the virtual terms are present and the quote still responds to an increased balance. Whether that response creates an economic problem depends on how a consuming application uses it. A mitigation for one small-vault mechanism does not by itself demonstrate that a downstream oracle route is appropriate.
A compact evidence record for a vault quote
For an interface or integration review, retain the vault and network identity, the underlying asset, the share quantity, the function queried and the observation block. Then identify what totalAssets counts and whether the conversion implementation uses a current balance, custom accounting or another calculation. This record makes a changing number explainable instead of treating its direction as a verdict.
If the screen describes a transaction, pair the matching preview with the relevant owner limit and the actual transaction’s output constraint. If a protocol consumes the value as an oracle, document that separate path: which method is read, what can move its inputs, and what independent bounds or averaging it actually applies. These are review questions derived from the specification’s separation of responsibilities, not a completed assessment of a product.
For a claim of strategy performance, retain evidence explaining the asset change rather than inferring its cause from the share conversion. The worked example shows exactly why that extra step matters. A useful display can state that it is a conversion estimate, identify its observation and leave unverified performance claims unmade.
Scope of this source audit
This article compares the ERC-4626 specification with OpenZeppelin’s published reference accounting and reproduces one integer calculation. It does not review a deployed vault, its strategy, governance, liquidity or a particular oracle integration. It makes no claim that a specific application is vulnerable or suitable for depositing assets.
For the separate question of what a token permission authorizes, see Jepeta’s token-approval guide. Permission scope and vault accounting are different checks; neither replaces an assessment of the whole application.
Jepeta evidence and method
- source audit — Source comparison separates idealized conversion, operation-specific preview, owner limit and downstream oracle responsibility using directly inspected ERC-4626 and OpenZeppelin reference material. This is educational explanation, not original incident reporting. · observed Oct 28, 2026
- calculation — Recomputed the MIT reference conversion with zero decimal offset: 1,000 shares against 1,000,000 assets and shares yields 1,000 asset units; changing only assets to 2,000,000 yields 1,999. Synthetic raw-unit inputs, exact integer rounding, no deployed-contract or profit claim. · observed Oct 28, 2026
Editorial transparency
This article was prepared with AI-assisted tools and an evidence-oriented source review. Citations and limitations are provided below. Documentation comparison is not a hands-on test; historical content is not automatically certified under the later independent editorial review process. Editorial standards and corrections.
Sources
- ERC-4626 specification: conversions, previews and security considerations · primary · verified Oct 28, 2026
- OpenZeppelin Contracts ERC4626 generated API reference · primary · verified Oct 28, 2026
- OpenZeppelin Contracts 5.4.0 official package metadata and distribution · primary · verified Oct 28, 2026
