I doubt GCG’s response time will be that slow. Both Ivan and I are keeping an eye on these things on a daily basis (even the weekends). Also, I personally get an email notification immediately every time a proposal is submitted onchain, so we should be able to react and submit a Referendum Killer immediately.
If the worst case scenario happens, we can react in two ways the way I see it:
Submit Referendum Killer immediately after a malicious referendum has been submitted. Alert the DAO to vote on both (Aye to the Killer, Nay to the malicious proposal).
Submit a Referendum Canceller. If we detect it too late, this origin can cancel the referendum (but without slashing the deposit). This track has a Decision Period of 7 days and 10 minutes Enactment Period.
3. This option has been deleted as it was incorrect.
Kill the referendum with by submitting a referendum with the Whitelisted Caller track that has a very low threshold of passing. I personally think we should refrain from using this approach, but if the chain security really is at stake, the option is there.
Obviously, the bad actor can also vote Nay to these two options and if they have enough tokens, they can probably create a lot of chaos anyway. But it doesn’t make sense to me that a large token holder with so many tokens would be interested in doing something like this. Who would buy say 10-20M CFG tokens, just to compromise the value of their own tokens in worst case?
However, we are open to review the parameters for the Referendum Killer track. Is the consensus to decrease the Decision Period for the Referendum Killer, increase the Enactment Period of the Root and Treasurer track, or do both?
@lucasvo other projects’ setup of Root, Referendum Canceller and Referendum Killer parameters.
Polkadot
Max Deciding
Prepare Period
Decision Period
Confirmation Period
Enactment Period
Root
1
2 hours
28 days
1 day
1 day
Referendum Canceller
1,000
2 hours
7 days
3 hours
10 minutes
Referendum Killer
1,000
2 hours
28 days
3 hours
10 minutes
Kusama
Max Deciding
Prepare Period
Decision Period
Confirmation Period
Enactment Period
Root
1
2 hours
14 days
1 day
1 day
Referendum Canceller
1,000
2 hours
7 days
3 hours
10 minutes
Referendum Killer
1000
1 hour
14 days
3 hours
10 minutes
Moonbeam/Moonriver
Max Deciding
Prepare Period
Decision Period
Confirmation Period
Enactment Period
Root
5
1 day
14 days
1 day
1 day
Referendum Canceller
20
1 hour
14 days
3 hours
10 minutes
Referendum Killer
20
1 hour
14 days
3 hours
10 minutes
Robonomics
Max Deciding
Prepare Period
Decision Period
Confirmation Period
Enactment Period
Root
1
1 day
14 days
1 day
1 day
Referendum Canceller
100
1 hour
7 days
1 hour
10 minutes
Referendum Killer
100
1 hour
7 days
1 hour
10 minutes
Bifrost
Max Deciding
Prepare Period
Decision Period
Confirmation Period
Enactment Period
Root
1
2 hours
14 days
1 day
1 day
Referendum Canceller
1,000
2 hours
7 days
3 hours
10 minutes
Referendum Killer
100
2 hours
7 days
3 hours
10 minutes
EDITED:
If a bad actor has 5M CFG and votes Aye on their own proposal, then it would take 234 hours for it to reach Support on the Root track (assuming no one else votes). Add the 12 hours Confirmation Period and the 1 day Enactment Period to that, so a total of 270 hours for a malicious proposal to pass with that amount of CFG. After those 234 hours, they would also need 65% Approval.
Voting with conviction will not affect the Support, only the Approval.
The Support function for Root is calculated this way as a function of time (hours).
But if token holders vote, the Support would obviously be reached faster, so ironically it would probably be better not to vote on a malicious proposal in order for it to not reach Support faster and give us time to submit a Referendum Killer! It’s very hard to create a worst case/best case scenario as there are many factors in play here.
I will suggest some revised parameters for the Referendum Killer track to better be able to deal with these extreme situations and mitigate the risks.
I think Polkadot’s parameters of having a referendum killer that takes 1/4 of the time than the regular root track is probably a good comparable for this.
I personally think 1/4 of 14 days (3½ days) is too short. We need to keep in mind that the Referendum Killer track also can be used for malicious purposes; a bad actor can submit a referendum to kill a runtime upgrade for example - or an emergency referendum submitted with the Whitelisted Caller track - and slash the deposits for those referenda. So 3½ days could be too short for the DAO to react in a timely manner, if the bad actor has enough tokens and can pass their referendum.
Given that Root already has 12 hour Confirmation Period and 1 day Enactment Period (1½ day combined), maybe 7 days would be an appropriate period of time?
I just noticed that I wrote the wrong Decision Period for the Referendum Killer track on both Polkadot and Kusama - I wrote 7 days for both initially. However, the Decision Period is 28 and 14 days, respectively (i.e. they have the same Decision Period for their Root and Referendum Killer tracks. My apologies for the mistake.
I still have suggested some new parameters for our Referendum Killer track so we can decide which one we feel most comfortable with.
See the initially suggested parameters for the Referendum Killer track here.
Please consider the newly suggested parameters below:
Referendum Killer
Max Deciding
Decision Deposit
Prepare Period
Decision Period
Confirmation Period
Enactment Period
Referendum Killer
20
75,000 CFG
1 hour
7 days
1 hour
10 minutes
Approval (linear): 100% → 70%
Support (reciprocal): 50% → 0.59%
Click here for specification of Approval and Support over time
Hours
Approval (linear)
Support (reciprocal)
Support in CFG
0
100.00 %
50.00 %
200,000,000
1
99.82 %
33.33 %
133,333,333
2
99.64 %
25.00 %
100,000,000
3
99.46 %
20.00 %
80,000,000
24
95.71 %
3.85 %
15,384,615
72
87.14 %
1.35 %
5,405,405
120
78.57 %
0.82 %
3,278,689
168 (7 days)
70.00 %
0.59 %
2,352,941
Support in CFG has been calculated with an Electorate of 400M CFG.
Referendum Killer