defirisk.co
rubric v1.7.0

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.

Data & output #

Data source
Bridge contract `ValidatorSetUpdated` / `SignerAdded` / `SignerRemoved` events via RPC subscription
Output format
Green / Yellow / Red
Evidence artifact
Event tx hash + event type + new signer set + timestamp
Confidence signal
green = signal not firing; red = signer-set change detected; gray = protocol has no bridge (N/A) or bridge events not monitored

Scored protocols 0 carry this factor#

No protocols have been scored for this factor yet.

Linked hacks no historical incidents linked#

No historical incidents are linked to this factor.
rubric_version v1.7.0factor RD-F-103category 6carried 0critical no