★ Reinitializable implementation (no _disableInitializers)
Liquid Collective (LsETH)'s assessment for RD-F-143 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Custom Initializable.sol uses version-counter init(N) pattern — does NOT call _disableInitializers(). Only TLC.1.sol calls _disableInitializers() in its constructor. River.1.sol, Oracle.1.sol, OperatorsRegistry.1.sol, Allowlist.1.sol, CoverageFund.1.sol, Withdraw.1.sol, RedeemManager.1.sol all rely solely on the version-counter pattern. The custom pattern does increment the version after initialization (preventing same-version re-init), but does not lock the bare implementation against direct init calls the OZ way. Under TUPProxy transparent proxy, the admin bypass means impl is callable directly. Yellow not red because the version counter does provide meaningful protection; confirmed exploitability not established.
Sources #
- GitHubTLC.1.sol — _disableInitializers() present in constructor (exception among protocol contracts)liquid-collective/liquid-collective-protocol/blob/main/contracts/src/TLC.1.sol — _disableInitializers() present (only this contract)retrieved 2026-05-17
- Custom Initializable.sol — no _disableInitializers() callliquid-collective/liquid-collective-protocol/blob/main/contracts/src/Initializable.sol — version-counter init(N) pattern, no _disableInitializers()retrieved 2026-05-17
- TUPProxy.sol — transparent proxy with admin bypass pathliquid-collective/liquid-collective-protocol/blob/main/contracts/src/TUPProxy.sol — transparent proxy, admin bypassretrieved 2026-05-17
Methodology #
Determine whether the implementation contract does not call `_disableInitializers()` in its constructor, leaving re-initialization possible.
See the full factor methodology and distribution across all protocols →