A Decentralized Escape Hatch for DAOs


A lot of ink was spilled discussing the bugs and vulnerabilities of The DAO -- an autonomous Ethereum script that came to control about $150m and lost it all to hackers, once black-, and once white-hatted. One of the key lessons to emerge from The DAO's breach was a call for an escape hatch. An escape hatch is simply a mechanism to stop the operation of a smart contract, perhaps revert it to a lower-level safety mode, when something nefarious seems to be taking place.

The problem with an escape hatch, though, is that it may seem to be at odds with the "autonomous" nature of smart contracts. Smart contracts are appealing for various reasons, not the least of which involve their deteministic predictability and certainty. A naively implemented escape hatch, then, seems at odds with these highly desirable properties. This post outlines a simple but effective escape hatch that is completely decentralized, and therefore, in line with the trust assumptions that power DAOs.

Naive Hatches


Technically, the simplest escape hatch could be implemented by having a cryptographic public key embedded in the contract, allowing only a person holding an appropriate secret key to activate the hatch and push the contract into "maintenance mode," from which it could be debugged and restarted, using the same key.

One step up from this kind of a single-person escape hatch would be a smart contract that implements a multisig or a shared secret key. These would allow k-out-of-n parties to override the operation of the main contract.

Both of these approaches are undesirable in a DAO, however, because the parties holding the keys present a point of weakness. They can intervene in the operation of the main DAO for their own gain; they may be coerced; and they might have their credentials stolen and abused. Further, as we found out in The DAO's aftermath, it is difficult to find people who might step up to hold such keys, as it might open them to legal liability for not stopping the operation of the main contract, should that contract violate some law in some jurisdiction.

Consequently, these kinds of hatches are unlikely to be a good fit for a DAO.

A Better Hatch


Yet a simple decentralized escape hatch (DEH) mechanism exists by which attacks of the kind that plagued The DAO could be stopped and reversed in a decentralized fashion.

A DEH comprises three components:

  • A buffer: All money flows out of the main contract go through the DEH contract. The DEH buffers these money flows for a pre-determined and parameterized amount of time, say, 24 hours, before actually executing the send() call that transfers them to their ultimate destination. This delay provides an opportunity to review the operation of the main contract for errors.
  • A trigger: A DEH implements a mechanism by which the money flows in its buffer can be reverted under precisely-specified conditions.
  • An undo log: An associated, application-specific undo log optionally provides a mechanism by which the DEH can specify how to revert certain actions. The undo log can ensure, for instance, that if a transaction in the buffer is reversed, that the funds are sent back to the clients who initiated them, making them whole, instead of unilaterally usurped.

The implementation of the trigger, then, is the sticky point. There are two, mutually complementary, options:

  1. Programmatic invariants can serve as automatic triggers where possible. For instance, an invariant that the number of tokens that have been cashed in equal the amount of ether paid out, properly implemented, would have stopped The DAO attack in its tracks. The weaknesses of invariants, though, are that they are hard to specify, subject to blindspots because they are typically specified by the same people who wrote the smart contract, and, finally, they consume gas (though this is too small a price to pay for stopping a $53M heist).
  2. Crowd-sourced triggers can bring in human supervision and catch issues that are difficult or impossible to specify as an invariant. In a crowd-sourced trigger, a pre-determined quorum can stop the payments in the buffer, keeping control at the hands of the participants, and allowing them to audit their script at runtime for unanticipated misbehaviors.

Note that a DEH does not impact immutability or fungibility in any shape or form. The payments, once passed through the DEH, are final and immutable. The DEH simply adds a delay period during which the contract can stop an operation from taking place.

When does a transaction take place, then? A script with such a Decentralized Escape Hatch always waits for the predefined time before actually sending out money. Payments are tantamount to "side-effects" in traditional distributed systems -- they are buffered and staged for execution, but not made available to clients until they clear the DEH. Anyone who interacts with the script only considers its operations as done after the buffering period of 24 hours.

Can any participant stop the script? No. A crowd-sourced trigger will require a certain quorum to activate the escape hatch, for example 53% of its participants for The DAO, or perhaps a traditional supermajority like 2/3rds, a simple majority at 1/2, or any other fraction deemed suitable for the application at hand.


As the Dapp ecosystem expands, and perhaps through costly trial-and-error, we will undoubtedly discover many useful building blocks for smart contracts. One such general, and exceedingly useful, construct is a Decentralized Escape Hatch (DEH). DEHs are a generalization of the elegant Vault solution (also, here) we have previously built to deter private key thefts in Bitcoin. We hope that they will be used where appropriate in smart contracts.

Share on Google+
Share on Linkedin
Share on Reddit
Share on Tumblr
comments powered by Disqus