★ Bridge ecrecover checks result ≠ address(0)

Lido's assessment for RD-F-151 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.

Evidence summary #

[★ CRITICAL] Lido's bridge contracts do NOT call ecrecover directly. WormholeTransceiver delegates VAA verification to wormhole.parseAndVerifyVM(). Native L2 bridges use CrossDomainMessenger (no ecrecover). Lido doesn't independently check ecrecover != address(0) — trusts Wormhole's return.

Detail #

WormholeTransceiver.sol source: 'wormhole.parseAndVerifyVM(encodedMessage)' pattern confirmed — validation delegated to Wormhole core contract (separately audited). L1ERC20ExtendedTokensBridge: CrossDomainEnabled + onlyFromCrossDomainAccount() modifier — no ecrecover in Lido's code. The F151 risk exists at the Wormhole core layer but Lido doesn't directly control or re-implement that verification. Yellow: delegated trust to an audited external contract, not a raw unchecked ecrecover in Lido's own contracts.

Sources #

GitHub
https://github.com/lidofinance/lido-l2-with-steth/blob/main/contracts/optimism/L1ERC20ExtendedTokensBridge.solretrieved 2026-04-28
GitHub
https://github.com/wormhole-foundation/native-token-transfers/blob/main/evm/src/Transceiver/WormholeTransceiver/WormholeTransceiver.solretrieved 2026-04-28

Methodology #

Determine whether the bridge verifier code rejects `ecrecover` returns of `address(0)`.

See the full factor methodology and distribution across all protocols →

rubric_version v1.7.0 protocol lido factor RD-F-151 score yellow collected_at 2026-04-28 13:58:42