★ Bridge ecrecover checks result ≠ address(0)
Midas's assessment for RD-F-151 — scored not_assessed on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
[★ CRITICAL] Not assessed due to protocol opacity. LayerZero OFT adapter contract addresses for mTBILL/mBASIS are not publicly available. Cannot inspect the lzReceive() implementation or DVN verification logic for Midas's specific OFT deployment to check for ecrecover return-zero validation. Axelar ITS uses a fundamentally different authentication pattern (PoS validator signatures via approveMessages(), not raw ecrecover on arbitrary payloads) — the Wormhole-class ecrecover zero-address vulnerability is architecturally less directly applicable to Axelar's gateway, which uses PoS-based multisig validation. The LayerZero surface remains the primary gap. Evidence gap: protocol_opacity (OFT adapter address not disclosed).
Sources #
- URLAxelar ITS DocumentationAxelar ITS architecture: approveMessages() via PoS validator set — different from ecrecover-based patternretrieved 2026-05-16
- Midas Bug Bounty Scope — LinkedInLinkedIn bug-bounty scope 2026-03-24: LayerZero OFT in scope but no contract addresses listedretrieved 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 →