Governance Proposal Deposit Auto-Throttler

Hub Proposals
1

NOTE: There is another post for dealing with governance spam but most of the suggestions were about setting fixed initial-deposit and total-deposit (minimum) amounts. This is an incompatible proposal to use an auto-throttling mechanism.

We already have a self-adjusting inflation rate to target a 2/3 bonding ratio. Using a similar but different algorithm, we can self-adjust the total-deposit (between reasonable minimum and maximum bounds, just like the inflation rate) amount to target something we want.

This proposal is targeting for there to be (on average amortized) N proposals during the governance voting period. N should be low, either 1 or 2, because having too many active proposals at a time can be confusing. Also, we should really take into consideration a rest period after debate, so even if we want 2 maybe 1 is a better choice. The lower the number, the more attention stakers can pay attention to proposals, and allows for the hub governance to focus on top-level issues, and for sub-entities (like a grant program DAO) to focus on encapsulated issues.

This doesn’t preclude the activation of more than N (e.g. 3, 4) proposals at a time during the governance voting period because all it does is adjust the total-deposit amount, and if you pay enough of a total-deposit you should be able to get the hub’s attention, for critical matters even during a spam attack.

Unlike the time-based self-adjustment of the inflation rate, we should probably adjust the rate every time a proposal becomes activated, so as to prevent cheap spam attacks from happening at any time (a security concern if it were to happen at all, without sufficient cost). Well, the total-deposit amount should self-adjust with both time AND activation of proposal, so that if there are no proposals for a long time, the price becomes cheap again.

Similarly, there should be a parallel self-adjusting parameter, the initial-deposit, the amount of deposit needed initially upon submission of the proposal. This is needed to prevent staker UX from being overloaded with spam pending proposals, which is important for discovery and officially starting the conversation. Rather than a % of the total-deposit, methinks it should be independently adjusted, and the creation of a proposal would require checking the initial-deposit minimum, while starting the proposal checks the total-deposit; and in particular that it’s OK and valid for the initial-deposit to even be higher than the total-deposit, even though it seems paradoxical. This could happen when no proposals had been activating for a while, but a spammer suddenly starts spam-creating many pending under-deposited proposals until the initial-deposit becomes temporarily higher than the total-deposit. I guess this algorithm should maybe self-adjust with both time AND creation of proposal. We could target more than the N above (for the initial-deposit) because not everyone is expected to read all of these. Perhaps 4 or 6 per governance voting period, or M per time period T, I don’t know.

It would be good to see some precise forumlae from the community, with maybe a table of case scenarios to describe how many spam created/active proposals we will see at what cost to the spammer.

Side note, I think we should increase the governance voting period too. This way we will feel less stressed about discussions. We can take our time discussing the merits of every statement.

7 Likes
2

What about if we make it more simple and say fix to 1 proposal every month, queue up a line, and to skip the line auction the deposit amount?

1 Like
3

Don’t we want to prevent spam in the line too, for discovery’s sake?
One problem might be that a time-period-fixed-N-auction-throttle isn’t responsive to emergency issues.

1 Like
4

I feel this very limitative, and for software upgrades for example isn’t doable. Let alone with ICS now coming etc we expect to see more proposals.

I like this suggestion from jaekwon.

5

I think we should make a distinction between pure spam proposals like we recently had a problem with and the general usefulness of limiting proposals.

For pure spam, I think a solution like I proposed in the other thread for filtering the proposal list to remove props with >90% NWV is sufficient. The obvious spam reaches 90% very quickly and then is off the list. If somehow a legitimate proposal is NWV’ed to 90%, it still exists and is viewable on a direct link so it has a chance to come back. This solution has already been put in place by Mintscan and seems to have dealt successfully with the obvious spam.

Personally, I think it would be useful to design separate solutions for pure spam vs general improvements.

2 Likes
6

That being said, the proposal here is interesting. But does it create some kind of first mover advantage where proposers are incentivized to get proposals in quickly in a given time period?

2 Likes
7

Hi @jaekwon thanks for sharing these ideas as a potential solution to the proposals spam problem. I think two very different things are spam proposals in the deposit period with little to no financial loss for the malicious actors versus what happened recently in the Cosmos Hub with three spam proposals in the voting period meaning the malicious actors don’t care about losing a large amount of funds.

We see a risk in your proposed solution, because legit proposals may know they would not be vetoed but still may feel risky putting a very high deposit, in contrast malicious actors even though they know their deposit would be burnt they may still do it as happened recently in the Cosmos Hub.

Let’s assume the worst case scenario in your proposed solution, a malicious actor with a large amount of funds for proposals intiial and total deposits who doesn’t care about losing these funds since through the spam proposals they are getting more money than these funds. If the governance voting period is increased and this spammer competes with legit proposals, it is likely the spammer would put proposals on-chain faster since there is no forum discussion and he could outcompete also legit proposals putting the higher total deposit amount. He may even compete for putting pending proposals by putting large initial deposit amounts. And if a spam proposal reaches the voting period when governance period is increased and the deposit for additional proposals is much higher, this maybe more problematic than the current situation since it would be spam proposal and also preventing legit proposals from going to the voting period or even the pending period.

Better than this could be implemented something similar but before a proposal goes on-chain. For example, after the total deposit is submitted but before a proposal goes on chain or is shown in the explorers, there should be a time period of several days for example where a specific and prepared Spam prevention council DAO or DAOs would check if a proposal is legit or spam/malicious. This would prevent the malicious links in spam proposals from reaching the UX of thousands of stakers and some of them potentially being victims. The malicious actors are using Cosmos Hub governance to put their malicious links in front of tens of thousands of stakers, simply increasing the amount of initial or total deposit with an algorithm or other methods seems risky and may not work since we don’t know how much funds these malicious actors have, are willing to lose or how much money they are making from the spam proposals. Maybe Jae’s idea combined with the DAOs filtering as well could be a good solution.

8

Increasing the governance voting period may also have drawbacks, such as delaying decision-making and making it more difficult to respond to emerging issues in a timely manner.

Other than that, I agree with the concept.

9

Is it possible to implement a system where the initial deposit is set at 50%, and governance proposals are limited within a single window by gradually increasing fees?

For example:

  • First proposal requires a deposit of 100 ATOM
  • Second proposal requires a deposit of 200 ATOM (100*2)
  • Third proposal requires a deposit of 400 ATOM (200*2)

Additionally, could we implement an auto-adjustment for the deposit fee based on the USD value? For instance, setting the deposit fee at 5000 USD, and having it automatically adjust the required amount of ATOM.

I am not sure if this is technically feasible, but it would be worth exploring.

10

Hey man, I made a very simple description of a solution that is similar to yours but different in some meaningful ways, care to have a look?

Basically this doesn’t outsource the whole thing to an algorithm. The hub community remains in control but we all agree that governance proposals made on a permission list basis should cost at least double what the most recent scam proposal cost. My big concern here is about normie’s. I do not want normies to be harmed, and if we look at the recent scam proposals that have actually gone to voting, I assume that they are going to voting because scammers are making money off of the hubs very very few normies.

I think that two weeks is long enough to really look at every proposal and I don’t really think that it’s a good idea to increase the length of the voting, but who knows, I’m open to discuss.

1 Like
11

Well so that was my immediate thought, it actually would ensure that spammers are incentivized to keep a proposal live consistently.

My preference here would be to keep things as they are, even though it is annoying with the spam.

The alternative is just various forms of censorship with various trade-offs.

1 Like