Ragequitting, Ragequit Delay and How They Work

What is “Ragequit Delay”?

The period of time after a vote passes before the vote can be executed.

For instance, if there is a Ragequit Delay of 24 hours and a vote passes at 11:00 am on Monday, it cannot be executed until 11:00 am Tuesday.

An important factor of Ragequit Delay is that the people who vote yes on a proposal have their tokens locked until the end of the execution delay.

Ragequit*

In Dandelion Voting Instances, and it gives people time to exit our TE Commons if they disagree with a decision to change parameters, before the Parameters are changed. Specific to Dandelion Voting this parameter is also referred to as the *"Ragequit Delay".

For instance, if a Dandelion Voting instance is used to vote to convert all the TEC Hatch DAO’s xDai to HNY, people may want to Ragequit before the proposal is executed. But the people that voted to convert the xDai to HNY would not be able to Ragequit, because their tokens would be locked until the Vote is executed.

Disputable Voting

In Disputable Voting there is no “Ragequit” Mechanism. This is because with the launch of the Augmented Bonding Curve (ABC) participants can leave at any point and tokens will be redeemed based on the “Sell Curve” of the ABC.

So what do we need to talk about in this post?

Why is this important? In the case of Disputable Voting should there be a delay even if the outcome cannot be changed? What information should we use to decide the Ragequit Delay?


Addendums - 20/05/2021

@natesuits -
Relating to choosing parameters:
Implications & Parameter Options
The Ragequit Delay is measured in hours, and you will have the option to set this parameter between 0 and ∞.

The Ragequit delay is important because we want to give token holders enough time to evaluate the implications of a proposal, and to decide whether or not they want to maintain their financial position within the DAO, or to exercise their Ragequit capabilities.
Suggested Range
Since the Ragequit Delay is important for Community Backers, we suggest a range of 1-6 hours for this parameter.

Related Parameters to consider when defining the Ragequit Delay (hours):
Vote Duration (days)
Vote Proposal Buffer (hours)

@divine_comedian -
In the Context of the Hatch DAO
Certain parameters will affect how Ragequitting is handled in the process of the Hatch.
Notably Hatch Tribute (%), Impact Hour Rate and Target/Min Goal in the case of the Backer’s Rage Quit (%).

Backer’s Rage Quit is the percentage of a Backer’s original donation that they will be reimbursed in the event that they decide to Rage Quit during the Hatch process. By setting a higher Hatch Tribute or Impact Hour Rate you’re decreasing the Backer’s Rage Quit percent. Alternatively, by lowering the Hatch Tribute and/or Impact Hour Rate and/or Increasing your Minimum or Target Goal you can increase the Backer’s Rage Quit percent.

1 Like

Smart contracts cannot verify human conditions. The need for humans to verify illicit activity and or safe activity is always a process apart from computable agreements. The responsibility to settle disputes or “catch” bad actions or actors has to be a process controlled by humans. There are several steps in conflict resolution to solve the problem. One method is to utilize vote execution delay as a tool.

Conflict resolution is conceptualized as the methods and processes involved in facilitating the peaceful ending of conflict and retribution. The time involved from which a bad action was committed and solved and the amount of voters involved to settle the dispute can be delayed for due course to properly settle said dispute fairly and objectively.

How long is too long?
If the problem is clearly resolved quickly does the problem still need to be subjected to due process

Can there be a set minimum time for the delay mechanism?
What should that look like?

This will also be based on how many blocks are confirmed by the network to represent the time not actual days or weeks. So the dependency on the network and its block approval time will always be a heavier hand in managing time allocated. Having a delay in general to properly resolve an issue through a voting process based on the token weight of said voter to execute resolution already creates unknown stipulation

How many tokens are a minimum for resolution or max needed?

How many votes does the conflict need?

Can a few token holders be responsible for settling disputes or does this create a hierarchy of conflict managers?

A self appointed court of the few acting in stead governing outcomes. Should the token holders voting constantly change?

Should there be a voting carousel?

This is a ride by the way and everyone needs tokens to enjoy the trip. It was always a challenge for myself at the carnival on what to use my tickets for.? How to properly manage them so I could ride everything I wanted to and play carnie games. I loved trying to out hustle the carnies but unfortunately I ended up just spending too much money trying to prove a point…… What should we do?

1 Like

What is the Ragequit Delay?
The RageQuit Delay describes the required amount of time after a proposal passes for the proposal to be executed.

Implications & Parameter Options
The Ragequit Delay is measured in hours, and you will have the option to set this parameter between 0 and ∞.

The Ragequit delay is important because we want to give token holders enough time to evaluate the implications of a proposal, and to decide whether or not they want to maintain their financial position within the DAO, or to exercise their Ragequit capabilities.

Suggested Range
Since the Ragequit Delay is important for Community Backers, we suggest a range of 1-6 hours for this parameter.

Related Parameters to consider when defining the Ragequit Delay (hours):
Vote Duration (days)
Vote Proposal Buffer (hours)

1 Like