★ Bridge ecrecover checks result ≠ address(0)
Beefy Finance's assessment for RD-F-151 — scored green on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
[★ CRITICAL — GREEN] XERC20Lockbox (0xc6e3d0CAF52E057Fb8950ae9d07aE67602919AcD): NO ecrecover anywhere in the lockbox source — uses ERC-20 deposit/withdraw and xERC-20 mint/burn mechanics only (source confirmed Etherscan). LayerZero v1 bridge adapter: NO ecrecover in message validation path — uses trustedRemoteLookup for message source validation (bytes path comparison per chain), not signature-based verification. The Wormhole-class ecrecover-zero-address bug does not apply to this lockbox+trusted-remote architecture.
Sources #
- DocsBeefy token bridge — validation mechanism descriptionToken bridge docs: 'No ecrecover or Merkle-based verification mentioned; xERC-20 minting/burning as the validation mechanism'retrieved 2026-05-16
- LayerZero v1 adapter — no ecrecover in critical pathLZ bridge adapter — trustedRemoteLookup-based validation; no ecrecover in lzReceive or nonblockingLzReceive pathsretrieved 2026-05-16
- XERC20Lockbox — no ecrecover in sourceXERC20Lockbox 0xc6e3d0CAF52E057Fb8950ae9d07aE67602919AcD — no ecrecover; deposit/withdraw/depositNativeTo functions only; lockbox mechanics confirmedretrieved 2026-05-16
Methodology #
Determine whether the bridge verifier code rejects `ecrecover` returns of `address(0)`.
See the full factor methodology and distribution across all protocols →