Bridge validator threshold (k-of-M)
A cross-chain & bridge factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score#
What this measures
This factor records the signature threshold required to approve a cross-chain message — expressed as k-of-M where k is the required approvals and M is the total signer set. For LayerZero OFT deployments, this is the DVN approval threshold. The value is read from the bridge contract or OApp configuration. This factor applies only to bridge-touching protocols; non-bridge protocols show this factor as N/A.
Why it matters
The approval threshold determines the actual quorum required to authorise a message. A 3-of-11 multisig sounds more secure than a 2-of-5, but if the 11-signer set uses hardware wallets with documented independent custody while the 2-of-5 uses hot wallets, the absolute threshold is a misleading comparator — context from RD-F-150 (co-hosting) and RD-F-156 (shared custodian) is required. The Kelp DAO incident ($292M, 2026) used a threshold of 1 on a single-DVN LayerZero OFT, reducing the attack surface to a single point of failure. Radiant Capital II ($53M, 2024) used a 3-of-11 threshold that was defeated by nation-state-level key compromise of just three signers.
Green / Yellow / Red
Green is scored when the threshold is at least 5-of-N with N >= 7 and independent signer custody. Yellow is scored when threshold is 3-of-N or higher but with documented custody concerns, or 2-of-N where N >= 5. Red is scored when threshold is 1 (single approver), 2-of-3, or when a LayerZero OFT uses a DVN threshold of 1.
Common gray cases
Gray is applied when threshold configuration is managed off-chain or through an opaque governance layer that cannot be confirmed from on-chain inspection.
Notable historical examples
- Kelp DAO ($292M, 2026): LayerZero DVN threshold of 1; single operator controlled rsETH bridge message approval.
Measurement what to look for#
Read the signature threshold required to approve a cross-chain message (for non-LZ bridges).