Bridge signer-set change proposed/executed
A real-time signals factor in the v1.7.0 rubric. Measured per protocol on a rt cadence.
Methodology how we score #
**What this measures** This real-time signal fires when a bridge's validator or signer set has a change proposed or executed — including new signer additions, existing signer removals, threshold modifications, or key rotation events. The signal is generated by monitoring bridge contract events for signer-management function calls (addSigner, removeSigner, setThreshold, replaceOwner) against known bridge contract addresses. Category 6 context: signer-set changes on bridges are high-consequence events — a malicious signer addition can immediately enable fraudulent message signing, while a threshold reduction can enable single-point compromise.
**Why it matters** Bridge signer compromise is responsible for over $413M in losses in the database (Harmony Bridge $100M, Radiant Capital II $53M, plus related bridge incidents). Harmony Bridge operated with a 2-of-5 multisig where signer set composition was a critical security parameter. The Drift Protocol Security Council threshold reduction (3/5 to 2/5) six days before the $285M exploit is the clearest documented example of a signer-set change as a pre-exploit signal. RD-F-182 (Security-Council threshold reduction) is a specific variant of this broader signal class that applies to protocol Security Councils. Any unexpected bridge signer-set change warrants immediate elevated scrutiny.
**Green / Yellow / Red** Green is the baseline when no bridge signer-set changes have been proposed or executed in the trailing 30 days, or when a documented scheduled key rotation is underway with proper governance disclosure. Yellow fires when a signer addition or removal is executed following governance disclosure and within an expected rotation window. Red fires when a signer-set change — particularly a threshold reduction — is executed without prior governance disclosure, or when a new signer is added from an address with no prior verifiable identity association with the protocol.
**Common gray cases** Gray applies when the bridge does not emit standard signer-management events in a monitorable format (e.g., custom bridge architecture without event emission), or when the protocol uses an off-chain committee model for bridge validation with no on-chain signer representation.
**Notable historical examples** No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for #
Detect whether a bridge validator or signer-set change has been proposed or executed.