Bridge validator threshold (k-of-M)
Beefy Finance's assessment for RD-F-149 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
LZ v1 per-adapter security model: single LZ Oracle + Relayer pair (both operated by LayerZero Labs — effectively 1-of-2 entities controlled by one operator). Axelar: PoS majority threshold (>2/3). CCIP: DON threshold (multiple Chainlink nodes, exact threshold not public). Canonical Optimism: Ethereum finality. The 4-adapter design means BIFI bridging is not halted if one adapter fails — routing redundancy compensates for per-adapter threshold weakness. Yellow because LZ v1 1/1 single-operator effective threshold per adapter is below safe standards even though compensated by redundancy.
Sources #
- DocsBeefy token bridge — 4-adapter redundancyToken bridge docs: 4 adapter paths — loss of any single path does not halt BIFI bridgingretrieved 2026-05-16
- LayerZero v1 adapter — threshold architectureLZ adapter source — NonblockingLzApp with trustedRemote; LZ v1 security relies on LZ Labs relayer/oracle pair (not user-configurable threshold)retrieved 2026-05-16
Methodology #
Read the signature threshold required to approve a cross-chain message (for non-LZ bridges).
See the full factor methodology and distribution across all protocols →