Preconditions
You can check the signer address list and signature threshold of the target multisig wallet via blockchain explorers like Etherscan or the official Safe app.
You have confirmed that the operation of the target multisig protocol (e.g. Gnosis Safe) relies on a specific number of active signers.
When multisig signers stay inactive for a long time, the protocol will not just get stuck on a specific pending transaction — it will hit a state where no new proposal can be submitted at all, eventually escalating to a fatal deadlock.
Multisig accounts rely on quorum to reach consensus and execute transactions. If critical signers are inactive for extended periods, the issue is far more serious than "no one signs the current transaction": no future transaction can gather enough valid signatures. There are 3 main fatal scenarios for a "stuck" multisig, as detailed below.
Step 1: Check if the "Missing Signer Deadlock" Has Been Triggered
[What to do]: Confirm whether the current number of active signers is still higher than the signature threshold.
[How to do it]: Navigate to the "Settings" or "Owners" page of the multisig wallet to view the total number of signers and the set threshold.
Scenario A: Number of inactive signers ≥ (Total signers - Threshold + 1) → Identified as high-risk deadlock. The system can no longer gather enough valid signatures, meaning all proposals, transfers and upgrades are fully locked. For example, for a 3/5 multisig, if 3 signers are long-term inactive, the remaining 2 signers cannot meet the threshold of 3, and all operations will stay in "pending signature" status. Action: The only solution at this stage is to contact the missing signer, or intervene via the pre-configured backup recovery mechanism.
Scenario B: Number of inactive signers < (Total signers - Threshold + 1) → You can still gather valid signatures for now, but every lost active signer raises the requirement for remaining members. Action: Launch a signer rotation or replenishment plan immediately to prevent the situation from worsening.
[Completion Check]: You have accurately calculated the minimum number of active signers required for the multisig to operate normally.
Step 2: Identify "Implicit Lock" — Blocking of Non-Urgent Proposals
[What to do]: Check if signers only cooperate on specific types of transactions, but refuse to sign other critical proposals.
[How to do it]: View the Proposal History of the multisig, count how many regular proposals expired and were voided due to missing signatures in the past 30 days.
Scenario A: Urgent security patches or large transfers can get signatures quickly, but routine parameter adjustments and small fund allocations are put on hold for a long time → Identified as selective inactivity. Signers may only stay responsive to matters related to their own interests. Action: The protocol execution will get stuck on "important but non-urgent" matters, which will damage protocol maintenance efficiency in the long run.
Scenario B: The response rate for all types of proposals is consistently low → This falls into the global inactivity issue described in Step 1.
[Completion Check]: You have determined whether the "inactivity" is global or selective.
High-Risk Warning: Inactive signers can also be exploited by attackers. If a signer is just "too lazy to sign" instead of completely losing access, hackers may induce them to sign malicious proposals via phishing or social engineering. SlowMist Security Team points out that under the multisig mechanism, even if some signers are inactive, there is still a "malicious multisig takeover" risk — attackers can use leaked private keys or social engineering to add their own address as a signer, and seize full control of the multisig.
Step 3: Evaluate Extra Stalls Caused by Nested Multisigs or Modules
[What to do]: Check if the target multisig has another multisig wallet set as its signer (nested structure), or if any custom module (Modules) is enabled.
[How to do it]: Check the "Owners" list in the Safe app to see if it contains contract addresses instead of regular EOA wallet addresses; check the "Modules" tab to see if any custom module is enabled.
Scenario A: Nested multisig exists → A single transaction needs to complete internal signature verification across multiple multisig wallets before it can be submitted on chain. The nested structure makes responsibility tracking and rapid response far more complicated. Action: If any of the nested multisigs goes inactive, the entire signature chain breaks, and recovery difficulty increases exponentially.
Scenario B: A Guard or Module that relies on specific signers for maintenance is enabled, and the corresponding signer goes inactive → Inactivity will break the normal function of the module. Incorrect Guard settings may directly block the multisig's emergency recovery mechanism.
[Completion Check]: You have confirmed whether there is a "multisig nesting" structure or modules that rely on specific signers to operate.
Common Root Causes of Failure
Teams often assume that "signers will show up when needed" but never regularly verify their actual activity. Once signers go missing without pre-configured backup recovery plans (such as timelocks, alternative standby signers), the entire treasury funds or protocol upgrade capability will be frozen directly. Another common misconception is that "a 2/3 multisig is very secure" — but if 2 out of 3 signers lose access, the "security" turns into total immobility.
Post-Verification Check Methods
Check the "Last Active" record of the multisig on Etherscan or Safe App (supported by most tools). Mark a signer as "dormant" if there is no signature record associated with their address for more than 3 consecutive months.
Next Steps After Confirmation
If you confirm that there are long-term inactive signers, evaluate whether you need to pass a multisig proposal to remove the inactive signer and replace them with a new address. For critical protocols, it is recommended to explicitly record the contact information and backup plan for each signer. Verification channels: The "Settings" page of the Safe App and the on-chain Proposal History module.
