★ Bridge ecrecover checks result ≠ address(0)
Venus Protocol'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] OFT V2 does NOT use ecrecover for message validation. Sender validation uses keccak256(_srcAddress) == keccak256(trustedRemoteLookup[_srcChainId]) in BaseXVSProxyOFT. Classic ecrecover zero-address bug does not apply. However, the analogous failure mode is that the entire trust chain collapses to the single DVN: if the LayerZero DVN is compromised, no cryptographic proof at the contract level prevents forged lzReceive calls. The architecture replaces ecrecover with DVN-layer trust — assessed in F179. Marked yellow (not green) because the trust model substitution creates its own failure mode.
Sources #
- GitHubBaseXVSProxyOFT.sol sourceBaseXVSProxyOFT.sol — trustedRemote keccak check, no ecrecoverretrieved 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 →