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`,
Summary
In
ERC4626.sol, the private_inc()helper exists to perform unchecked+1on denominator values, so that if
totalSupply()ortotalAssets()equalstype(uint256).max, the value wraps to0andfullMulDivreverts withdivision-by-zero rather than an arithmetic overflow panic.
This pattern is applied consistently when
o == 0, but not in theo > 0paths of
convertToAssetsandpreviewMint.Affected lines
convertToAssets(o == 0) — uses_inc()✅convertToAssets(o > 0) — skips_inc(), uses checked arithmeticSame inconsistency exists in
previewMint(o == 0uses_inc,o > 0does not).Consequence
When
o > 0andtotalSupply()is neartype(uint256).max, the expressiontotalSupply() + 10 ** oreverts with an arithmetic overflow panic instead ofproducing a zero denominator that
fullMulDivwould catch as division-by-zero.The revert behavior differs from the
o == 0path, making overflow handlinginconsistent across the two branches.
Question
Is this inconsistency intentional — perhaps to catch
10 ** ooverflows forlarge
_decimalsOffset()values? Or should theo > 0denominator also useunchecked 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".