The Continuity Vault: An Emergency Succession Registry for ENS DAO’s Critical Keys and Roles

ENS has real assets and real authority sitting behind a small set of hands. That is not a criticism of anyone holding those keys. It is just what happens when an organization grows faster than its continuity planning. The fix is not more trust. It is a tested plan that exists before it is needed. Mechanism: Continuity Vault + Succession Registry 1. Critical role and key inventory Who decides: the DAO ratifies an initial list of roles and access points that would cause real disruption if suddenly unavailable. Who builds it: a small working group of current signers, stewards, and technical contributors. The registry lists, for each critical role or key: • what it controls (multisig, domain, deploy key, admin panel, social account) • who currently holds it • minimum signer or holder threshold required to act • what breaks if this access disappears with no warning • current backup or recovery path, if any 2. Succession plan per entry For each item in the registry, the working group documents an actual handoff procedure. Not a vague “the DAO will figure it out,” but a real sequence: who gets notified, what the replacement process looks like, how long it takes, and who can act in the interim. Some of this is boring and mechanical, like documenting how to add a new multisig signer. Some of it is harder, like agreeing on what counts as “unavailable” and who has standing to trigger a succession event. 3. Scheduled continuity drills A plan nobody has tested is a guess. Twice a year, the working group runs a drill: simulate a key holder going dark and walk through the documented succession process without touching real funds or real access. The drill produces a short public report on what worked, what was slower than expected, and what needs fixing. This is the same instinct behind fire drills. Cheap to run, expensive to skip. 4. Independent review A small independent reviewer group, separate from the current signers, checks that the registry stays accurate and that drills actually happened. Their job is narrow: confirm the inventory is current, confirm drills ran on schedule, and flag registry entries with no real succession plan behind them. 5. Trigger conditions and activation The registry also defines what actually counts as an emergency, so nobody has to improvise that decision under pressure. Example triggers: a signer unreachable past an agreed window, a compromised device, a resignation with no handoff, a lost credential with no backup. Each trigger maps to the pre-agreed succession steps for that role, not a fresh debate in the moment. Adoption path 1. Publish the initial critical role and key inventory within 30 days of approval. 2. Complete succession plans for each entry within 60 days. 3. Run the first continuity drill within 90 days. 4. Run drills twice a year going forward, with public reports after each. 5. Review and update the registry annually or after any real succession event. Requested budget: $95,000 for a 6-month pilot covering inventory work, succession plan drafting, two drill cycles, and independent review. Pilot deliverables: • public critical role and key inventory • documented succession plan for each entry • two completed continuity drills with public reports • independent reviewer process • a public dashboard tracking registry status Why this is not duplicative This is not a security audit and it does not replace one. An audit checks whether a contract or key setup is safe today. This registry checks whether the DAO can survive losing access to that setup without warning. Both matter, and neither covers the other. What would change our mind This proposal is unnecessary if ENS already has a complete, tested, publicly documented succession plan for every critical key and role, with drills on record. If that exists, point to it and fund keeping it current instead. If it does not exist yet, this is the missing plan. Budget logic $95,000 is enough to properly document the inventory, write real succession plans instead of one-line placeholders, and actually run two drills rather than just writing a plan and hoping. It is small next to the cost of losing access to a key system with no backup plan in place. What this looks like in practice Picture a concrete case. A core contributor holds one of four multisig signer keys and also runs the account that manages the DAO’s primary social presence. They go quiet for three weeks during a family emergency. Under the current setup, nobody has a documented answer for what happens next. Does the multisig still function below its threshold. Who has the standing to propose a new signer. Who can post an official statement if something urgent comes up. “Publishing a list of critical access points sounds like a security risk.” The registry documents what each key controls and who holds succession authority, not private key material, seed phrases, or credentials. The same way a company can publish an org chart without publishing everyone’s passwords. “We already trust our signers.” Trust in the people is not the same as trust in the plan. Every signer can be fully trustworthy and the DAO can still have no working answer for what happens if one of them is hit by a bus, loses a hardware wallet, or has a falling out with the rest of the group. “Two drills a year seems like overkill.” Drills catch the gap between what a document says and what actually works. A succession plan that has never been tested tends to fall apart on first contact with an actual emergency, usually because some small dependency was assumed rather than verified. Governance boundaries The independent reviewer group has no authority to change roles, reassign keys, or intervene in day-to-day operations. Their mandate is limited to confirming the registry is accurate and that drills happened on schedule. Any actual succession event still runs through the documented process and, where relevant, existing DAO governance for anything requiring a vote. This keeps the Vault from becoming a shadow governance body. It is a record-keeping and testing function, not a decision-making one. Relationship to existing ENS security work This proposal sits next to any ongoing multisig hardening or key management audits, not in tension with them. A hardened multisig with a strong threshold is still vulnerable to a slow-motion continuity failure if nobody has planned for a signer becoming permanently unavailable. Security work makes the keys harder to steal. This registry makes sure the DAO does not quietly lose functional control of its own keys through simple attrition. Closing frame Trust in a DAO should not depend on nobody ever leaving, getting sick, or disappearing. It should survive the ordinary fact that people’s lives change. A plan that only exists in someone’s head is not a plan. It is a hope.