defirisk.co
rubric v1.7.0

Constructor calls _disableInitializers()

A code & audits factor in the v1.7.0 rubric. Measured per protocol on a s cadence.

Methodology how we score #

**What this measures** This factor verifies that implementation contracts in the protocol's upgradeable proxy architecture call _disableInitializers() in their constructor, following the OpenZeppelin-recommended pattern to prevent direct initialization of the implementation contract itself. When _disableInitializers() is called in the constructor, the implementation contract's initializer is permanently locked at deployment time, preventing any subsequent caller from re-initializing it. The assessment is performed by static analysis of the implementation contract's constructor bytecode.

**Why it matters** The _disableInitializers() constructor call is the defense-in-depth complement to the initializer modifier (assessed by RD-F-022). Even if an initializer modifier is present, a missing _disableInitializers() call in the constructor leaves a narrow race-condition window at deploy time where the implementation can be initialized directly before the proxy is set up. More importantly, it prevents the class of attack where a future OpenZeppelin library upgrade or a missed initializer modifier on a newly added initializer function creates a new unguarded entry point. The pattern was introduced precisely because the modifier alone was insufficient in complex inheritance hierarchies.

**Green / Yellow / Red** Green: all implementation contracts call _disableInitializers() in their constructor, confirmed by bytecode analysis of the deployed implementation. Yellow: the constructor does not call _disableInitializers() but all initialize() functions carry the initializer modifier, reducing -- but not eliminating -- the risk. Red: the constructor omits _disableInitializers() AND any initialize() function is missing the initializer modifier (this overlaps with RD-F-022 Red).

**Common gray cases** This factor is gray for non-upgradeable protocols that do not use proxy patterns, or for protocols whose constructors cannot be inspected (unverified source).

**Notable historical examples** The factor operates as a defense-in-depth check alongside RD-F-022, which captures the more common failure mode.

Measurement what to look for #

Determine whether implementation contract constructors call `_disableInitializers()` to prevent re-initialization of the implementation directly.

Data & output #

Data source
Source search for `_disableInitializers()` in constructor on Etherscan-verified source
Output format
Green / Yellow / Red
Evidence artifact
Source excerpt of constructor body
Confidence signal
green = `_disableInitializers()` present in all implementation constructors; yellow = absent in some non-critical implementations; red = absent in core implementation with live proxied TVL; gray = source unverified or contract is not a proxied implementation

Scored protocols 80 carry this factor #

Protocol RD-F-023
Aave v3 ethereum yellow Across Protocol ethereum yellow Aerodrome Finance base yellow Axelar Network ethereum yellow Babylon Protocol bitcoin not_applicable Balancer (v2 + v3) ethereum not_applicable Beefy Finance ethereum yellow BENQI avalanche yellow BlackRock USD Institutional Digital Liquidity Fund (BUIDL) ethereum gray Cap (cUSD / stcUSD) ethereum green Centrifuge ethereum not_applicable Chainlink CCIP ethereum not_applicable Circle USYC binance yellow Compound V3 (Comet) ethereum green Concrete ethereum green Convex Finance ethereum yellow crvUSD (Curve Stablecoin) ethereum not_applicable Curve Finance ethereum not_applicable deBridge ethereum yellow Dolomite ethereum gray dYdX v4 (dYdX Chain) dydx not_applicable EigenLayer ethereum green Ethena ethereum not_applicable ether.fi ethereum green Euler V2 ethereum green Falcon Finance ethereum yellow Fluid ethereum not_applicable Frax Finance ethereum yellow GMX v2 (GMX Synthetics) arbitrum not_applicable Hyperlane ethereum red Hyperliquid arbitrum yellow Jito solana not_applicable Jupiter solana gray Jupiter Perpetual Exchange solana not_applicable JustLend DAO tron not_applicable Kamino Lend solana not_applicable Kinetiq hyperliquid green Lido ethereum green Liquid Collective (LsETH) ethereum green Liquity V1 + V2 (LUSD / BOLD) ethereum not_applicable Lista DAO bsc yellow Lombard Finance ethereum green M^0 ethereum yellow Maple Finance ethereum yellow Marinade Finance solana not_applicable Meteora solana not_applicable mETH Protocol ethereum yellow Midas ethereum green Morpho V1 (Morpho Blue + MetaMorpho) ethereum not_applicable Multipli ethereum green Ondo Finance ethereum green OpenEden ethereum green Orca solana not_applicable PancakeSwap bsc not_applicable Pendle Finance ethereum yellow Polymarket polygon green QuickSwap polygon gray Raydium solana not_applicable Rocket Pool ethereum not_applicable Sanctum solana not_applicable Save (formerly Solend) solana not_applicable Sky Lending (formerly MakerDAO) ethereum green Spark Protocol ethereum yellow Spiko stellar green Stake DAO ethereum gray StakeWise v3 ethereum green Stargate Finance ethereum not_applicable stHYPE (Valantis Labs) hyperliquid yellow SUNSwap (sun.io) tron not_applicable Superstate ethereum green Sushi (SushiSwap) — v2 + v3 + Trident + BentoBox/Kashi + SushiXSwap ethereum not_applicable Symbiotic ethereum not_applicable Synapse Protocol ethereum yellow Uniswap (v2 + v3) ethereum not_applicable USDD (Decentralized USD) tron not_applicable Usual (USD0 / bUSD0 / USUAL) ethereum yellow Veda (BoringVault) ethereum green Venus Protocol bsc yellow Wormhole ethereum yellow Yearn Finance ethereum not_applicable

Linked hacks no historical incidents linked #

No historical incidents are linked to this factor.
rubric_version v1.7.0 factor RD-F-023 category 1 carried 80 critical no