ERC-4626 virtual-share offset (OZ ≥4.9)
Balancer (v2 + v3)'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 #
Balancer v3 uses ERC-4626 wrapped tokens as pool assets in Boosted Pools and implements pool LP token accounting via the Vault's ERC20MultiToken system (not a standard ERC-4626 vault itself). For ERC-4626 buffer initialization in v3, the protocol burns minimal initial shares to the zero address as an anti-inflation mechanism — functionally equivalent to the OpenZeppelin >=4.9 virtual-share offset but implemented as a custom pattern in the Balancer v3 Vault, not using OZ's exact implementation. v2 Linear Pools (the deprecated ERC-4626 integration in v2) did not have equivalent virtual-share protections; those pool types are now deprecated following the Nov 2025 exploit. Scored yellow: custom mitigation present in v3 (not OZ >=4.9 specifically), absent in v2 Linear Pools (deprecated).
Sources #
- DocsBalancer v3 Boosted Pool DocumentationBalancer v3 boosted pool docs: ERC-4626 token integrationretrieved 2026-05-05
- Modern DEXes: Balancer V3 ArchitectureMixBytes v3 analysis: 'initial buffer shares including minimal portion to zero address to avoid inflation attacks'retrieved 2026-05-05
- Balancer v3 Monorepobalancer-v3-monorepo: Vault ERC20MultiToken architecture for LP token accountingretrieved 2026-05-05
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 →