Wallet Security
Treasury Hot-Wallet Break-Glass Exit Plan
How to switch a treasury hot-wallet out of service under compromise and restore normal operations
Within this package
Treasury Hot-Wallet Break-Glass Exit Plan
A treasury hot-wallet under compromise — emergency break-glass procedure for decommissioning and restoring secure operations
A treasury hot-wallet compromise is the operational equivalent of a fire alarm in a data center. When an attacker gains unauthorized access to signing keys or exploits a protocol vulnerability, every second of delayed response increases the potential loss. The break-glass exit plan is a pre-authorized, high-speed procedure to decommission a compromised hot-wallet, freeze all associated positions, and restore normal treasury operations without relying on the normal multi-signature quorum that may itself be compromised.
When to Pull the Break-Glass
The break-glass procedure should only be triggered when the incident response team confirms a confirmed compromise—not a false positive from routine monitoring. Indicators include:
- Unexpected large-value transfers from the hot-wallet exceeding configured thresholds
- Signatures generated without corresponding transaction requests in the signing log
- Detection of private key leakage through the wallet approval drift detection system
- Simultaneous anomalous activity across multiple chains controlled by the same wallet
The threshold for escalation must be defined in advance: any single transfer exceeding 10% of the treasury balance without a matching internal order, or any signature from a key that was previously rotated, qualifies as a trigger event.
Before activating break-glass mode, review the incident response framework for trigger validation. The decision requires a minimum of two independent confirmations from separate monitoring channels—on-chain analytics, custodial alerts, and internal logging systems. A single signal should never be sufficient to invoke a procedure that can temporarily lock treasury operations.
Pre-Deployment: The Break-Glass Wallet
Every treasury hot-wallet must have a corresponding break-glass wallet that is pre-configured but held offline. This wallet is a separate multi-signature setup with keys distributed across different geographies and hardware security modules. The break-glass wallet does not hold any funds until activated, but its address is pre-approved in all smart contracts, bridge protocols, and exchange whitelists.
The operational key for the break-glass wallet is stored in a sealed envelope within a physical safe, with access logs maintained by the security team. The cryptographic material must be generated through the wallet HSM key management workflow to ensure it meets the same security standards as the primary treasury wallet. A dry-run test of the break-glass activation should be performed quarterly, simulating the full transfer of authority without moving real assets.
Step 1: Kill the Compromised Wallet
The first action is to render the compromised hot-wallet inoperable. Follow this sequence:
- Revoke all approvals — call
revokeAllApprovals()on every connected DeFi protocol. The allowance revoke workflow provides a template for clearing all token allowances across multiple chains simultaneously. - Transfer remaining assets — sweep all funds to a cold storage vault using a pre-signed batch transaction.
- Override governance timelocks — if the wallet holds governance rights, bypass the timelock via the security council module.
- Log the revocation — record every action on-chain and in an immutable audit trail for post-incident review.
If the attacker already controls the wallet, the revocation may fail. In that case, the team must immediately move to Step 2 and isolate downstream systems before the attacker can drain additional assets.
Step 2: Activate the Break-Glass Wallet
The break-glass wallet is brought online by extracting the sealed key material and loading it into a hardened signing environment. This environment must be isolated from the network that the compromised wallet used—different IP range, different hardware, and different custodial provider. The first transaction from the break-glass wallet is to whitelist a set of emergency operator addresses that will handle the post-compromise treasury operations.
All smart contracts and bridge protocols must be updated to recognize the break-glass wallet as the new treasury authority. This is done by calling updateTreasury() or the equivalent function on each contract, using the pre-signed governance messages that were prepared during the setup phase. If the compromised wallet held admin roles in a DAO, the break-glass wallet must be granted those roles through a pre-authorized timelock bypass.
Step 3: Freeze and Reconcile
Once the break-glass wallet is operational, the immediate priority is to freeze all active positions. This includes pausing lending pool deposits, disabling margin trading, and halting automated market-making strategies that the treasury was running. The break-glass wallet should issue a pauseAll() call to the treasury management contract, which stops all non-emergency operations.
| Phase | Action | Timeframe | Responsible |
|---|---|---|---|
| Freeze | Issue pauseAll() on treasury contract |
< 5 minutes | Security engineer |
| Isolate | Remove compromised wallet from all whitelists | < 15 minutes | Smart contract team |
| Scan | Trace all unauthorized transfers across chains | < 2 hours | Forensics analyst |
| Report | Log findings to immutable audit trail | < 24 hours | Compliance officer |
Reconciliation begins by scanning the compromised wallet’s transaction history to identify any unauthorized transfers. The wallet compromise simulated drill playbook provides a structured approach to tracing stolen funds across chains and reporting to law enforcement. All findings must be logged in a tamper-proof audit trail for post-incident analysis.
Step 4: Restore Normal Operations
Restoring normal operations means transitioning from the break-glass wallet to a new, permanent hot-wallet. The break-glass wallet is not intended for long-term use—it is a temporary authority that should be decommissioned within 72 hours. A new hot-wallet is generated using fresh key material, distributed across new HSMs, and subjected to a full security review before being brought online.
The transition plan must include a phased migration: first move low-value assets, then medium-value positions, and finally high-value holdings. Each transfer requires a fresh multi-signature approval from the new wallet’s key holders. The break-glass wallet is then rotated out of service by revoking its own authority through a renounceTreasury() call, leaving only the new hot-wallet as the active treasury operator.
Post-Incident Review
Every break-glass activation must be followed by a formal root cause analysis within 30 days. The review should answer three questions: How did the compromise occur? Why did existing controls fail to prevent it? What changes to the break-glass plan are needed based on this incident? The findings are used to update the procedure and retrain the incident response team.
The break-glass plan itself should be treated as a living document. After any activation, the entire procedure is revised and tested again within two weeks. The incident response framework provides templates for post-mortem documentation and control improvement tracking.
Frequently Asked Questions
How often should the break-glass wallet be tested?
A full dry-run test should be conducted every quarter. The test must simulate the complete activation sequence—from key extraction from the sealed envelope to the pauseAll() call—without moving real assets. Test results are documented and reviewed by the security team within one week.
What happens if the break-glass wallet's key material is corrupted?
If the sealed envelope is damaged or the HSM fails, the security council must convene to authorize a new break-glass wallet generation. This is a manual process that requires a minimum of three of five council members to sign the authorization transaction. The new wallet must be tested and distributed within 48 hours.
Can the break-glass procedure be triggered automatically?
No. The break-glass procedure must always be triggered by a human operator. Automated systems can flag potential compromises and even pre-generate the emergency transaction, but the final activation requires a multi-person approval from the incident response team. This prevents accidental lock-outs from false-positive alerts.
How does the break-glass plan interact with insurance and audit requirements?
Most Web3 insurance policies require a documented break-glass procedure as part of their coverage terms. The plan must be included in the annual security audit scope, and any activation must be reported to the insurer within 72 hours. Failure to maintain an up-to-date break-glass plan can void coverage for hot-wallet losses.
References and Further Reading
The design of this break-glass plan draws from established incident response practices in traditional finance and Web3 security. Refer to the following sources for deeper context:
- https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final — NIST SP 800-53 contingency planning framework
- https://eips.ethereum.org/EIPS/eip-4337 — EIP-4337 account abstraction standard
- https://owasp.org/www-project-smart-contract-top-10/ — OWASP Smart Contract Top 10 key management guidance
- https://blog.trailofbits.com/ — Trail of Bits security research
- https://consensys.io/knowledge-base/ — Consensys knowledge base
Related Articles
FAQ
Frequently Asked Questions
How often should the break-glass wallet be tested
A full dry-run test should be conducted every quarter. The test must simulate the complete activation sequence—from key extraction from the sealed envelope to the `pauseAll()` call—without moving real assets. Test results are documented and reviewed by the security team within one week.
What happens if the break-glass wallet's key material is corrupted
If the sealed envelope is damaged or the HSM fails, the security council must convene to authorize a new break-glass wallet generation. This is a manual process that requires a minimum of three of five council members to sign the authorization transaction. The new wallet must be tested and distributed within 48 hours.
Can the break-glass procedure be triggered automatically
No. The break-glass procedure must always be triggered by a human operator. Automated systems can flag potential compromises and even pre-generate the emergency transaction, but the final activation requires a multi-person approval from the incident response team. This prevents accidental lock-outs from false-positive alerts.
How does the break-glass plan interact with insurance and audit requirements
Most Web3 insurance policies require a documented break-glass procedure as part of their coverage terms. The plan must be included in the annual security audit scope, and any activation must be reported to the insurer within 72 hours. Failure to maintain an up-to-date break-glass plan can void coverage for hot-wallet losses.