First-depositor / share-inflation guard
OpenEden's assessment for RD-F-075 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
The vault implements a firstDepositMap[sender] + firstDepositAmt check: first-time depositors must meet a higher minimum deposit threshold. This is semantically a UX guardrail / minimum-size enforcement, NOT a share-inflation attack defense. The firstDepositAmt check prevents a first-time depositor from making an undersized deposit, but it does NOT prevent a pre-existing USDC donation from inflating the exchange rate before a legitimate first depositor arrives. No dead shares are burned at vault deployment. No seed deposit is made by the protocol operator at initialization. The _validateKyc(sender, _receiver) call in the deposit function means only whitelisted addresses can deposit — this is the effective practical guard against external inflation attacks (non-whitelisted attackers cannot execute the second step). Full red is averted by this KYC functional mitigation. The Arbitrum vault at ~$13K TVL is near-empty and represents the highest exposure. Assessment: yellow — a partial guard
Sources #
- GitHubOpenEdenVaultV4Impl.sol — _convertToShares, _convertToAssets, totalAssets: no virtual offsethttps://raw.githubusercontent.com/OpenEdenHQ/openeden.vault.audit/main/contracts/OpenEdenVaultV4Impl.solretrieved 2026-05-16
- OpenEden docs — investor onboarding: KYC whitelist mandatory before deposithttps://docs.openeden.com/tbill/investor-onboardingretrieved 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 the vault has a first-depositor guard (seed deposit on deploy, virtual-share offset, or floor-check).
See the full factor methodology and distribution across all protocols →