Quiet ending implementation proposal

Quiet ending implementation proposal

Currently, one of the main problems of the Voting app implementation is that large tokenholders can wait until the last minute to vote on a proposal, flip the outcome, and leave those who haven’t voted yet almost no time to react.

One of the solutions proposed to solve this issue was to implement a quiet ending period. Basically the idea is that the duration of a vote can be extended by X amount of time if the outcome is flipped within Y amount of time before the end of the vote.

That said, bearing in mind the new concept of disputable apps introduced a few months ago along with the Agreement app, we started working on a variation of the current Voting app that we called Disputable Voting app (currently being developed here). Apart from making the Voting app disputable, we wanted to provide a few solutions to other issues like quiet ending.
After a few iterations we came up with the following implementation proposal:

  • Disable the ability to change votes, only allowed when overriding a delegate’s decision
  • Have a configurable quiet ending period and extension values
  • The only constraint is the quiet ending period cannot be longer than the vote duration
  • There must be a snapshot of the outcome of the vote at the moment the quiet ending period starts
  • Said snapshot will be compared against the outcome at the end of the quiet ending period to decide if it must be extended or not
  • Multiple extensions should be allowed

The following illustration shows how the quiet ending period affects the vote duration together with the overrule window 1, the execution delay 2, and the disputable states 3:

The main takeaway from this illustration is that the quiet ending period shouldn’t be affected by any of the other functionalities, except the case when a vote is challenged before the quiet ending period starts. In this case, the quiet ending period is delayed to ensure the desired amount of time is allocated for the normal voting phase. Additionally, the quiet ending extensions — even if there are multiple extensions — are considered as part of the quiet ending period.

To understand the line of thought we went through to support this version of quiet ending — which we’re calling Rolling Snapshot Quiet Ending — we recommend reviewing the following PRs in order:

  1. Initial quiet ending implementation #1205
  2. Fix quiet ending extension limit #1230
  3. Optimize quiet ending extensions #1234

The other Quiet Ending implementations we considered are versions we call Simple Quiet Ending and Rolling Simple Quiet Ending. In Simple Quiet Ending, there is no snapshot and the vote duration can only be extended once. If the vote outcome is flipped during the quiet ending period, the vote duration is simply extended once, and then the vote ends at the predetermined time. This version is most similar to DAOstack’s quiet ending implementation. Rolling Simple Quiet Ending is the same as Simple Quiet Ending except the vote duration could be extended multiple times until the vote outcome no longer flips during the quiet ending period. We prefer the “Rolling” variation so that the basic “quiet ending” expectation — that the vote will be extended if the outcome is flipped during the quiet ending period — is preserved even if the vote has already been extended once already.

One of the main downsides of the Rolling Snapshot Quiet Ending version we have currently implemented is that even if a vote is flipped once during the quiet ending period, voters won’t know if the vote will be extended until the end of the quiet ending period since the vote could flip back and negate the extension logic. The tradeoff we gain is that in cases where a vote outcome flips multiple times during a quiet ending period, the overall vote duration could be shorter when using this version of quiet ending than when using either Simple or Rolling Simple Quiet Ending (because the vote might not actually be extended if the outcome ends up the same at the end of the quiet ending period as it was at the beginning of the quiet ending period).

Since this is one of the most sensitive features we are planning to introduce as part of the Disputable Voting app, we wanted to share the technical details and the thought process we went through with the community to solicit feedback before finalizing our implementation. Feel free to join the conversation, and share your thoughts, concerns, or ideas!


  1. Overrule window: This window of time is related to simple voting delegation. The overrule window states the period of time where token holders can override their delegate’s decision.

  2. Execution delay: This concept was introduced to allow votes to have a window of time before they can be executed in case they were accepted by the voters. It’s optional and can be set to zero if it is not needed.

  3. Disputable states: With the introduction of disputable apps, in order to make the Voting app disputable, we needed to support the app to be paused in case a proposal was challenged by a user.