defirisk.co
rubric v1.7.0

Bridge ecrecover checks result ≠ address(0)

Frax Finance'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 #

[★ bridge] FraxFerry uses a batch-hash model: Captain proposes batch hash, Crew validates, First Officer executes. No per-message ecrecover signature is used in the FraxFerry path — transactions are validated by hash comparison, not individual ecrecover calls. Fraxtal OP Stack bridge inherits standard OP Stack dispute game mechanics (not ecrecover-based validator signatures). LayerZero OFT uses DVN attestation (not ecrecover per message). The ecrecover zero-address failure pattern is structurally not applicable to the primary bridge surfaces. Yellow rather than green because FraxFerry source bytecode was not independently verified in this assessment (ToB 2022-11 audit PDF not extractable; batch-hash model confirmed only from docs).

Sources #

  • Audit
    Trail of Bits Fraxlend+FraxFerry 2022 AuditTrail of Bits 2022-11 Fraxlend+FraxFerry audit — covered FraxFerry security (PDF not extractable; listed in profile §8 as completed engagement)retrieved 2026-05-17
  • Docs
    Frax FraxFerry Bridge DocsFraxFerry docs — batch-hash model: 'token hashes must match the proposed batch'; no per-message ecrecover pathretrieved 2026-05-17

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 frax factor RD-F-151 score yellow collected_at 2026-05-16 20:44:31