BIP21-Compliant Alternatives To Switching Everything Back On Immediately

I was asked following my post on the ratification proposal what I would do instead of having AGAINST mean turning everything back on straight away with no plan.

I wanted to open up discussions on alternative ways of resolving an against vote without clogging up the thread.

Lets start with BIP21, as voted here: Snapshot

BIP21 Clause 8 states:

The actions of the operations multi-sig signers must then be ratified with a DAO vote. The signers must provide a short report that describes the motivation behind any actions taken, and publish it to Discourse in a timely manner. The DAO will then vote to uphold or reverse the decision via the normal process.


  1. It is the operations multi-sig signers’ actions that must be ratified with a DAO vote. Nothing else.
  2. The DAO votes to uphold or reverse the decision to take action via the normal process.
  3. “the normal process” is open to interpretation, but is not specific. For example, when an action is taken for the first time “the normal process” for resolution may not yet be established.

The decision is not necessarily the same as the action. The decision was made through an internal vote.

The action, as defined in the Stage 1 Proposal at the time of writing is:

  1. Deposits were disabled across the protocol. This measure prevents users from participating in liquidity provision while the protocol is in a stressed state.
  2. Withdrawals from V2.1 require migration to v3 first. This measure prevents a complex contract upgrade for the V2.1 system that would have required a longer development process, and increased the likelihood of bugs and unpredictable behavior.
  3. Withdrawals from v3 remain active, with the following modification: BNT compensation is no longer provided at withdrawal. Therefore users may withdraw their pro-rata share of the vault balance in the TKN denomination of their pool token.

BIP21 Does not provide timelines or conditions for action to be taken. In the case of the currently listed proposal, at the time of writing:

If this proposal is not approved, the protective measures will be rolled-back at the conclusion of the vote, without any other protective measures in place.

Note that BIP21 does not explicitly mandate a timeframe, nor explicitly mandate a course of action. At some point the protective measures will probably have to be re-enabled. Regardless, this will still constitute a reversal of the action and decision, but given possible timeframes might not be amenable to the DAO.

So what are our options?

One possible interpretation would be that protective measures could be rolled back in stages, monitored, and withdrawn via vote or BIP21 if further risks to the protocol were identified. This would require the formulation of a plan and possibly a vote. It also wouldn’t actually solve the problems, but would find space for the more harmful features to be resolved before re-enabling.

Another would be that a ratification vote failure could result in a vote to re-enable everything after a proposed plan to bring the protocol back has been voted on - People will know the plan and any projected outcome prior to ratification. It will also create time and space for alternative plans to come forward.

These aren’t the only possible options. Although snapshot uses FOR/AGAINST we don’t have to bind ourselves to binary options. Votes can be chained to facilitate a more nuanced outcome. Bear in mind the two gaps in BIP21 are timeframe and action. As long as eventually the decision is reversed it should be compliant with the letter of BIP21 but I’d like to think that with a DAO vote we should be able to do something that’s in spirit even if it stretches a little. I’d love to hear what others think may be viable.


Instead of:
Against = immediately return to previous state.

Against should be = a planned return to previous state


The point of emergency actions is to perform the action prior to the vote, while still having a vote in place.
In the “normal” process the DAO would first vote to pause the ILP mechanism, then the mechanism would be paused.
This is of course really bad when a time sensitive action must be taken, since by the time the action is performed, it would potentially be too late.
But not all risks are that obvious and in some cases the DAO signers can perform an action that is deemed emergency but turns out not to be so bad, and in that case it would make sense for the DAO to vote to revert that action and then have a discussion about how to improve the process.
My point is that the vote isn’t supposed to include a plan going forward, but simply follow a proper process in which the DAO votes on decisions, even if they are obvious and if without them, user funds/the protocol would be under serious risk.