defirisk.co
rubric v1.7.0

Bridge ecrecover checks result ≠ address(0)

M^0'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 #

M^0's Portal.sol and HubPortal.sol do not contain direct ecrecover calls — signature validation is fully delegated to the Wormhole core bridge (0x98f3c9e6E3fAce36bAAd05FE09d375Ef1464288B) via WormholeTransceiver. Wormhole core bridge verifySignatures() includes ecrecover with zero-address check per standard Wormhole implementation. However, WormholeTransceiver implementation source (0x29E5F15fB58C38DbD9b26eca20a80F1E56e0B741) is not verified on Etherscan — M^0-specific transceiver ecrecover path cannot be directly confirmed. Score YELLOW due to indirect evidence via Wormhole's well-audited core bridge.

Sources #

  • Etherscan
    WormholeTransceiver EtherscanWormholeTransceiver proxy 0x0763196A091575adF99e2306E5e90E0Be5154841 — ERC1967Proxy; implementation 0x29E5F15fB58C38DbD9b26eca20a80F1E56e0B741 source not verifiedretrieved 2026-05-16
  • GitHub
    Portal.sol sourcem0-foundation/m-portal main/src/Portal.sol — no direct ecrecover calls; delegates to WormholeTransceiverretrieved 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 →

rubric_version v1.7.0 protocol m0 factor RD-F-151 score yellow collected_at 2026-05-16 09:46:19