Skip to content

♻️ ERC4626: _inc() pattern not applied consistently in o > 0 denominator paths #1529

@BhariGowda

Description

@BhariGowda

Summary

In ERC4626.sol, the private _inc() helper exists to perform unchecked +1
on denominator values, so that if totalSupply() or totalAssets() equals
type(uint256).max, the value wraps to 0 and fullMulDiv reverts with
division-by-zero rather than an arithmetic overflow panic.

This pattern is applied consistently when o == 0, but not in the o > 0
paths of convertToAssets and previewMint.

Affected lines

convertToAssets (o == 0) — uses _inc()

return FixedPointMathLib.fullMulDiv(shares, totalAssets() + 1, _inc(totalSupply()));

convertToAssets (o > 0) — skips _inc(), uses checked arithmetic ⚠️

return FixedPointMathLib.fullMulDiv(shares, totalAssets() + 1, totalSupply() + 10 ** o);

Same inconsistency exists in previewMint (o == 0 uses _inc, o > 0 does not).

Consequence

When o > 0 and totalSupply() is near type(uint256).max, the expression
totalSupply() + 10 ** o reverts with an arithmetic overflow panic instead of
producing a zero denominator that fullMulDiv would catch as division-by-zero.

The revert behavior differs from the o == 0 path, making overflow handling
inconsistent across the two branches.

Question

Is this inconsistency intentional — perhaps to catch 10 ** o overflows for
large _decimalsOffset() values? Or should the o > 0 denominator also use
unchecked addition for consistency with _inc()?

Happy to submit a PR if this is confirmed as unintentional.

Minor NatSpec fix (bundleable)

Line 330 has a typo: "minter""minted".

/// @dev Returns the maximum amount of the Vault shares that can be minter for `to`,

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions