OAK-M22 — Rotate-on-Disclosure Discipline

Description

Rotate-on-disclosure discipline is the operational practice of rotating every authority held by a key once a vulnerability touching that key — its derivation procedure, its signer host, the signing software it is used through, or the vendor surface that handles it — is publicly or privately disclosed. The operational unit of rotation is not "the wallet that visibly holds the funds"; it is "the complete set of contracts, vaults, multisigs, role-bearing positions, allowance grants, and dependency-contract authorities for which this key is a signer or admin". M22 is paired with M05 (Authority-Graph Enumeration): M05 produces the inventory of authorities; M22 is the discipline that, on disclosure, every entry in that inventory is acted upon.

From a defender's perspective, M22 addresses the canonical partial-response failure mode: an organisation receives a disclosure, recognises the affected key, moves the visibly-funded balance away from the key — and stops. The residual authority surface (admin role on a deployed vault contract, signer position on a multisig, allowance grant on a token contract, ownership of a proxy-implementation slot) is left intact, and the attacker, now in possession of the key after the cohort exploitation window, reaches the residual surface from the un-rotated authority position. The Wintermute September 2022 case is the canonical example: the Profanity vulnerability had been disclosed by 1inch five days prior with explicit rotation guidance; Wintermute moved ETH out of the directly-exposed Profanity-generated hot wallet but did not revoke the admin authority that the same vanity-address held over the DeFi operations vault; the attacker recovered the private key, called the vault's admin functions, and extracted approximately $160M.

M22's leverage is specifically against the temporal asymmetry between disclosure and exploitation. Once a vulnerability is on the public record, the cohort exploitation window typically opens within hours and saturates within days; the defender's window to rotate all authorities held by an affected key is bounded by the attacker's parallel race to reach those authorities. M22 converts the rotation decision from an ad-hoc judgement under time pressure into a pre-defined operational procedure that triggers automatically on disclosure intake, with the authority-graph from M05 as the work-list.

How it applies

• T1.003 (Renounced-But-Not-Really): the defender-side analogue of the attacker's residual-authority exploitation. A protocol team that publicly renounced ownership but retains EIP-1967 admin-slot authority, AccessControl role authority, or dependency-contract authority is structurally pre-positioned for an M22 failure: when the residual-authority key is disclosed-as-compromised, the renouncement claim does not bound the rotation work. M22 at the protocol layer means: enumerate every authority-bearing role before publishing the renouncement claim, and treat any post-renouncement disclosure of compromise on a residual-authority key as a P0 incident requiring full enumeration-and-rotation.
• T11.001 (Third-Party Signing / Custody Vendor Compromise): the Bybit-Feb-2025 case. M22 at the customer side translates "Safe{Wallet} signing infrastructure compromised" into "every authority held by every key signed through Safe{Wallet} during the vulnerability window must be rotated", which is structurally a much larger operation than "the visibly-affected cold wallet must be moved". Pair with M19 (air-gap signing) for the prevention side and M20 (vendor breach-notification SLA) for the temporal side.
• T11.002 (Wallet-Software Distribution Compromise): the Atomic Wallet June 2023 cohort. End-user customers facing wallet-software-compromise disclosure must rotate every authority held by every key that the compromised wallet handled. For typical end-user wallets the authority graph is small (token allowances, NFT setApprovalForAll grants); for institutional or DAO-treasury users the graph extends to multisig signer positions, governance-role grants, and protocol-deposit positions. M22 at the institutional layer post-T11.002 disclosure is structurally the same workflow as M22 post-T11.001.
• T11.003 (In-Use Multisig Smart-Contract Manipulation): the WazirX-Liminal July 2024 case. Once partial multisig compromise is disclosed, M22 must extend to contract-modification authority held by the multisig itself: the rotation work-list includes pausing modification authority, revoking attacker-controlled signer additions, and (where the multisig design supports it) freezing the contract-modification path pending out-of-band confirmation. M22 here is the governance-level analogue of key rotation.
• T9.004 (Access-Control Misconfiguration): the structural parallel at the smart-contract layer. When a missing-authorisation-check is disclosed, the protocol's M22 response is rotation of the contract — typically via emergency upgrade through the protocol's existing governance / pause / upgrade authority — across every deployed instance affected. The Wintermute parallel at the protocol layer is a protocol that pauses the visibly-affected pool but does not pause the same vulnerable function across other deployed pools sharing the affected codebase.

Limitations

• Authority-graph completeness is the binding constraint. M22 is only as good as the inventory M05 produces; an authority held by the affected key but not in the inventory is not rotated. Authority-graph enumeration in production systems with many years of operational history is itself a non-trivial engineering exercise; M22 inherits the residual completeness gap.
• Rotation has its own attack surface. The rotation process involves authoritative use of the compromised key (transferring authority away requires the key, in most authority models, to act once more before being revoked). An attacker who has already begun cohort exploitation may be racing the defender's rotation transaction; in some configurations the rotation transaction itself can be front-run, censored, or intercepted at the signer-host layer if the signer host is also compromised. The post-disclosure rotation must use a clean signer path (M19) on a verified destination (M22 + M19 paired).
• Disclosure-intake organisational discipline. M22 requires that disclosure information actually reaches the team responsible for executing the rotation. Disclosures arriving via security-research-team Twitter threads, vendor-side IR channels, or industry threat-intel feeds frequently do not propagate to treasury operations on the same timeline as the cohort exploitation. M20 (vendor breach-notification SLA) and disclosure-intake automation are necessary complements.
• Partial-response is the default human failure mode. Under time pressure, operators tend to address the most visible symptom (the funded wallet) and consider the response complete. M22 must be operationalised as a checklist that requires explicit sign-off on each authority in the inventory, not a verbal "we rotated the keys" assertion. The Wintermute partial response is not a unique failure — it is the modal human response without procedural enforcement.
• Some authorities cannot be rotated. Immutable contract owners, irrevocable signer positions, and certain proxy patterns admit no rotation path. M22 surfaces these as residual-risk items requiring compensating controls (contract pause, treasury withdrawal to an unaffected vault, redeploy of the protocol with a new authority structure). The inventory must distinguish "rotated" from "rotation-impossible, mitigated otherwise".

Reference implementations

• Wintermute as anti-pattern: the canonical case study of M22 failure. The 1inch disclosure on 2022-09-15 with explicit rotation guidance, the partial-response window of approximately five days, and the un-rotated DeFi-vault admin authority that became the extraction surface together define what M22 is designed to prevent. The post-incident industry practice on rotate-on-disclosure has tightened materially in response.
• Profanity-cohort response patterns: the broader cohort of Profanity-generated wallets that experienced extraction in the September 2022 window included multiple operators who responded fully (rotated all authorities held by the affected key) and multiple who responded partially. Fully-responsive operators avoided the cohort exploitation window entirely; partially-responsive operators bore the residual-surface losses.
• DAO emergency-rotation procedures: post-Wintermute, several major DAO treasuries (e.g., the post-Curve-vyper-incident Curve and dependent-protocol responses, the post-WazirX Liminal-customer responses) have published M22-style emergency-rotation runbooks as part of their public security documentation. The runbook approach converts M22 from operator judgement into procedure.
• Custody-vendor SLA integration: custody vendors increasingly offer authority-graph enumeration and bulk-rotation tooling as a paid service tied to their breach-notification SLAs. The combined offering converts M20 + M05 + M22 into a single procurement decision.

Citations

• [1inchprofanity2022] — primary disclosure of the Profanity entropy vulnerability (2022-09-15), with explicit rotation guidance. Anchors the canonical disclosure-window-then-exploitation timeline that M22 is calibrated against.
• [halbornwintermute2022] — Halborn function-level technical post-mortem of the Wintermute vault drain. Documents the un-rotated admin-authority residual surface as the proximate extraction cause.
• [crystalwazirx2024] — WazirX July 2024; canonical T11.003 case where contract-modification authority extension of M22 is load-bearing.
• [radiantpostmortem2024] — Radiant October 2024; multi-laptop compromise where M22 across all signer positions is the post-disclosure response surface.
• [chainalysis2024dprk] — broader OAK-G01 context where rotate-on-disclosure failure recurs across the 2024 cohort.