First-depositor / share-inflation guard
Concrete'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 #
No seed deposit at vault initialization. No dead-shares burn on deploy. The deposit() function enforces minDepositAmount (from getDepositLimits()) but this prevents zero-value deposits, not first-depositor inflation attacks. The +1 virtual offset from Conversion.sol provides partial mathematical protection: with decimalsOffset=0, the cost to manipulate share price rises with the amount donated but remains economically viable for attackers targeting small/new vaults. ConcreteAsyncVaultImpl (inherits from ConcreteStandardVaultImpl) adds no additional first-depositor guard. Yellow: partial mitigation via +1 offset; no strong first-depositor guard mechanism.
Sources #
- GitHubConcrete Conversion.sol — minimal virtual offsetsrc/lib/Conversion.sol — calcConvertToShares/calcConvertToAssets +1 offset provides minimal protection; decimalsOffset=0 equivalentretrieved 2026-05-17
- Concrete ConcreteAsyncVaultImpl.sol — no first-depositor guardsrc/implementation/ConcreteAsyncVaultImpl.sol — inherits ConcreteStandardVaultImpl; no additional first-depositor guard found; Blueprint-Finance/concrete-earn-v2-bug-bountyretrieved 2026-05-17
- Concrete ConcreteStandardVaultImpl.sol — deposit and _deposit functionssrc/implementation/ConcreteStandardVaultImpl.sol — deposit() function: requires assets >= minDepositAmount but no seed deposit or dead-shares burn on init; _deposit() function: standard mint, no dead-shares; Blueprint-Finance/concrete-earn-v2-bug-bountyretrieved 2026-05-17
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 →