ERC-4626 virtual-share offset (OZ ≥4.9)
Veda (BoringVault)'s assessment for RD-F-074 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
BoringVault is NOT ERC-4626 — confirmed from GitHub source (enter()/exit() requiresAuth, no ERC-4626 deposit/redeem interface, no totalAssets()). The OZ ≥ 4.9 virtual-share-offset check does not apply directly. Per §6 instruction, assessed on custom-accounting equivalent: share amounts passed to enter() are externally set by MINTER_ROLE (Teller), which computes shares from Accountant exchange rate (depositAmount.mulDivDown(ONE_SHARE, accountant.getRateInQuoteSafe(asset))). The Accountant has allowedExchangeRateChangeUpper/Lower deviation bounds with auto-pause on violation — this provides rate-manipulation protection. However: (a) no virtual-share offset exists, (b) share-price integrity relies on trusted Accountant operator hygiene, (c) the mechanism is architecturally novel and not covered by the ERC-4626 standard guard. Yellow: not_applicable in strict ERC-4626 form, but the custom accounting introduces an equivalent structural question that partially resolves via the Accountant des
Sources #
- GitHubBoringVault.sol — enter/exit functionsBoringVault.sol — enter(address from, ERC20 asset, uint256 assetAmount, address to, uint256 shareAmount) external requiresAuth; no totalAssets(); _mint/_burnretrieved 2026-05-17
- AccountantWithRateProviders.sol — exchange rate boundsAccountantWithRateProviders.sol — allowedExchangeRateChangeUpper/Lower bounds, auto-pause on out-of-bounds, UPDATE_EXCHANGE_RATE_ROLE requiredretrieved 2026-05-17
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 →