ERC-4626 virtual-share offset (OZ ≥4.9)
OpenEden's assessment for RD-F-074 — scored red on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
OpenEdenVaultV4Impl.sol uses custom ERC-4626-style share accounting WITHOUT the OpenZeppelin >= 4.9 virtual-share offset. The _convertToShares function is: assets.mulDiv(tbillDecimalScaleFactor, tbillUsdcRate()) — a pure rate-based formula with no virtual offset added to totalSupply or totalAssets. totalAssets() computes (totalSupply() * tbillUsdcRate()) / tbillDecimalScaleFactor with no virtual shares added. V5Impl.sol initializer sets tbillDecimalScaleFactor = 10 ** _underlying.decimals() (6 for USDC) but mints ZERO initial shares (no dead-shares seed). This means on an empty vault, an attacker who can donate USDC directly to the vault contract before the first legitimate deposit can inflate the share price, causing subsequent depositors to receive fewer shares than expected (rounding down to zero for small deposits). The TBILL vault is NOT ERC-4626 OZ >= 4.9 compliant in this regard. Mitigating context: (1) All depositors must be KYC whitelisted — non-whitelisted parties cannot call
Sources #
- GitHubOpenEdenVaultV4Impl.sol — _convertToShares, _convertToAssets, totalAssets: no virtual offsethttps://raw.githubusercontent.com/OpenEdenHQ/openeden.vault.audit/main/contracts/OpenEdenVaultV4Impl.solretrieved 2026-05-16
- OpenEdenVaultV5Impl.sol — initializer: tbillDecimalScaleFactor = 10**decimals, no dead shares mintedhttps://raw.githubusercontent.com/OpenEdenHQ/openeden.vault.audit/main/contracts/OpenEdenVaultV5Impl.solretrieved 2026-05-16
- Hacken Nov-2024 V4Impl audit: 7 findings, none for ERC-4626 virtual offset or inflation attackhttps://hacken.io/audits/openeden/sca-openeden-vault-nov2024/retrieved 2026-05-16
Methodology #
Determine whether ERC-4626 vaults use OpenZeppelin ≥4.9 virtual-share offset pattern to prevent first-depositor share-inflation.
See the full factor methodology and distribution across all protocols →