Ideation: Hub governance spam (initial idea abandoned)

[jacobgadikian]

Hi everybody tonight I had a call with @jtremback and we discussed a couple of options for dealing with governance spam. The first one is rather immediate and I wanted to bring it directly to the forum because implementing it likely requires a governance proposal in the first place:

The informal team has prepared a pull request that will place minimum deposits on governance proposals.

So the question for the community here is what should the deposit be?

Osmosis currently has a minimum deposit of 400 osmo, which works out to about $400.

Personally I was thinking 100 atoms was reasonable, but we were concerned that that could be too high. That’s about 1,500 to create a governance proposal, and we want governance to be as accessible as possible.

So, the numbers discussed so far have been:

• 10 atoms
• 40 atoms
• 100 atoms

The way that this pull request works is that anything with a lower initial deposit will be rejected. This is basically to kick off the conversation that will drive the eventual implementation of a minimum deposit for governance.

Option 2 which could work later

There was a second option discussed on Twitter, I forget where, and the poster mentioned that a way to fully solve this band problem is to require that every governance proposal has at least one validator approve it, before it becomes visible, I suppose another way would be that only validators can make governance proposals .

Personally, I like this in the sense that it can stop all of the spam .

However, I do not like this because it is not highly democratic .

So we kind of have to weigh the pros and cons of allowing some degree of spam, and allowing anyone to make a governance proposal. Really interested in getting the community opinion here.

Thank you!

Currently, I think that the best place to discuss this is here:

Governance Proposal Deposit Auto-Throttler

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 …

[lexa]

On the Hub, deposits are only burned if something goes into voting period and gets vetoed. We don’t burn deposits for proposals that expire (fail to make it to voting period) or which fail to meet quorum.

I’m not convinced that a minimum initial deposit will be an effective deterrent unless it’s actually burned, like on Osmosis (I think?). But it might slow it down as the wallet waits to recover its funds in 2 weeks though, and I think it’s worth trying just for that.

My inclination would be to stay on the lower end of the range (10-40 ATOM). I’d rather contend with spam than introduce another social step to governance (courting the approval of a validator). I’m 100% against having only validators able to make governance proposals.

For my own learning - what risks are there to this spam aside from people clicking links and falling for scams? How much of a drag on the system is it to have them being stored on the chain as deposit-period proposals? Do they get pruned when they expire?

[Youssef]

@jacobgadikian

There was a second option discussed on Twitter, I forget where, and the poster mentioned that a way to fully solve this band problem is to require that every governance proposal has at least one validator approve it, before it becomes visible, I suppose another way would be that only validators can make governance proposals .

It was me
Against having only validators submit proposals, that’s against the inclusiveness aspect of crypto but definitely for the obligation to have at least one validator as sponsor, which is not the same. The latter implies an ATOM holder is able to submit a proposal as long as he finds a validator to support him while the former means that only validators can post a proposal. Subtle nuance.

I thought the minimum deposit was 250 ATOM as of today? Oni validator passed a proposal a few months ago on that no?

If the minimum deposit is indeed 250 ATOM, then adding the condition of a validator to sponsor the proposal should fix 90% (if not 100%) of the problem.

[Youssef]

In any case we need to find a qualitative criteria (validator sponsor or something else) on top of the minimum deposit to make spams go away.

[Jcook_14]

I believe the initial deposit is the deposit one must make, to initiate the proposal (or I believe this is what @jacobgadikian is recommending here), the rest of the ATOMs being crowdfunded if necessary. This deposit would be a lower token value than the minimum deposit, which is the 250 ATOM. That’s my understanding, however I have never made a proposal and absolutely could and would be happy to stand corrected.

I like this idea of Validator approval for a proposal to go online. I don’t believe it would really affect the inclusiveness of Governance as it stands. An addition could be a larger deposit as well, so that the spam is filtered through either the raising of the deposit and the validator approval. However, in the case of delegators not being able to find a validator willing to sign off on their proposal, there is still an access point if they can find the deposit.

Example of this is,

For a proposal to go on-chain, you need the 250 deposit (40 ATOM initial deposit, 210 minimum to go on chain) + validator sponsorship

Or

For a proposal to go on-chain without validator sponsorship, you’ll need a 500 ATOM minimum deposit (80 ATOM initial, 420 ATOM minimum to go on chain).

This gives delegators a way to on-chain governance without validator gate keeping, if deemed necessary. But also, should take care of spam.

@lexa you mentioned that you don’t believe a minimum initial deposit would be effective, unless the deposit is burned. But what if these initial deposits of spam, that don’t make it on-chain, get partially or fully slashed? Could this be an effective deterrent? I feel like a slashing a redistribution to delegators or the treasury, is a better option than burning IMO. But a burn would certainly do the job.

[lexa]

I don’t think burning vs slashing makes a difference to the person whose money is being affected. Why would having their money given to delegators or the treasury be a more effective deterrent than having it burned?

Regardless - it feels like picking the right amount for this initial deposit is what makes the difference and the scale starts at “too low to be effective” and goes up to “high enough that it prevents governance participation”. I have no idea what the sweet spot is.

Validator sponsorship to reduce the initial deposit (or total deposit) is an interesting idea. I like that because it preserves multiple ways to access governance and doesn’t give validators a gatekeeping role (you must have a validator in order to propose) so much as a facilitator one (it helps if you have a validator involved).

[LeonoorsCryptoman]

I do like the idea of a time-out period for proposals. So that if they don’t enter voting_period within x days the deposit is automatically burned and the proposal rejected. That would surely keep the tabs clean.

[Jcook_14]

Great point, I agree that there isn’t a difference between burn or redistribution. I guess I just prefer a slash over a burn, and was just mentioning a different way to harm the spammer, but ultimately you’re right, at the end of the day the deposit is still not in the hands of the depositor.

[Ashkan]

I agree with option 1 . It will be so Democratic

[Guinch_Roze]

validator sponsorship is a good idea.

[Damien]

I like the idea of validator sponsorship. We’ve seen recently that more of these ‘spam’ proposals are going live even though the amount to go live is set at 250 ATOMs ($2.5K at time of posting).

We have no idea how much money these malicious actors are making so increasing the value isn’t going to solve the issue IMO. We would need some criteria like @Youssef was mentioning.

Could also think of some sort of Gatekeeping Council that reviews the proposals before it goes live or even some AI / ML type situation where it reads through the text for anything malicious (such as the obvious phishing link).

There’s also the idea similar to what is happening on Polkadot where the Council can cancel a proposal if deemed malicious. You can read more here: Governance · Polkadot Wiki

Just throwing out some ideas that came to mind - hopefully we can resolve this issue soon.

[crainbf]

Why not require a minimum initial deposit of 10 ATOM to make a proposal at all and burn it if it never reaches the 100 ATOM threshold. Feels totally reasonable to require someone to spend that much if they want to have a change effected for the hub.

[jtremback]

Here is what I believe is the best solution:

Governance proposal spam

What it does is just filter the gov/proposals endpoint. There is no value to a spammer submitting spam unless it ends up on this endpoint, because if it’s not on this endpoint it won’t be displayed prominently anywhere on the web. We filter out props that have a very low quorum, or a very high NWV percentage. Props meeting these requirements can still be created and exist, they just don’t show up on gov/proposals.

People on here who know what’s up can just skim to the bottom for the pseudocode.

We can implement this in the gov/proposals endpoint code, as well as providing an option to view it unfiltered. But the default would be filtered. Then, once frontends upgrade, the spam is gone.

[RiccardoM]

Premise

I have been invited directly by @jacobgadikian to add my thughts here, after reporting them on a Twitter thread.

Introducution

I have the previous answers carefuly, and althought I find thwy could work, I also think there might be another way to solve the problem of spam proposals. Instead of setting a per-chain minimum deposit, we could try solving this problem from a social perspective instead of an economic one.

If we were to set a minimum economic requirement, we might inadvertiley block good proposals from ever being created ue to the fact that people might not have that (large) amount of money.
Also, I strongly believe the power of the community and the ability to combine on-line data is far more stronger than an economic disincentive in order to prevent spam proposals.

For this reason I would like to propose the usage of the Desmos profiles features to build a score system that help determine whether a governance proposal was created by a good or bad actor.

Solution description

What is a Desmos profile

A Desmos profile is simply an extension of Cosmos SDK Account interface, that adds some social features. Users having a Desmos profile can link it to other chains (any chain type is supported - Cosmos, EVM, Solana, etc), or to external applications (e.g. Twitter, GitHub, etc) in a completely decentralized and permissionless way.

Building a score system using the Desmos profile

Thank to its ability to be linked to other chains and external apps, the Desmos profile is the perfect feature that could be used to build a user score system.

How this system could work is by simply querying the external chain addresses and applications linked to a profile and then giving each profile a score.

Suppose Alice has a Desmos Profile and has connected to it the following things:

• a Cosmos Hub address
• an Osmosis address
• a Twitter account

Then, the scoring system could assign her the following scores:

• Cosmos Hub account that has voted to N past governance proposals: N * 10
• an Osmosis account that has deposited K kind of tokens: K * 5
• a Twitter account with more than 1000 followers: 100

So the overall score would be (N * 10) + (K * 5) + 100

Note
Obviously these things are just examples. The math formula used to determine the score based on various data should be much more thought through.

Advantages

By building this score system, we could solve the spam proposal problem not only within the Cosmos Hub, but within the entire IBC world. Since the score is determined using external factors and multiple chain addresses and activities, it’s easy to understand how it can be used by all wallets and explorers very easily.

In order to make it even easier without having wallets and explorers computing this each time, there could also be a kind of API that provides the score for a requested user. Obviously this is not mandatory: since links are stored on the Desmos chain, and anyone can query them, anyone can implement they own scoring system and easily determine whethere a user is malicious or not based on their requirements.

Disadvantages

Since this is someone that is done partially off-chain (computing the score of each user), it should be adopted by all wallets and explorers. If a proposal is made by a user with a too-low score, then it should be hidden by explorers and wallets. Also, users depositing (or voting) a proposal that was made by another user with a too-low score should be warned about the potential risks.

Another risk of this system is censorship of new users: if someone does not have any particular activity on another chains or external social networks, then they might be censored for this. It’s important to take this into consideration when definind the math formula for the user score.

Conclusion

Overall, I think a system like this could help multiple chains to solve the spam proposals quickly and efficiently. It could also be adopted by wallets and explorers quite easily (it would just be some queries and computations).

We at Desmos have a set of tools that are ready to implement all of this, so if anyone is interested in working on this, just DM me on Twitter (@ricmontagnin). I don’t come here often, but I will reply quite quickly there.

[Ghazni_Stakecito]

An alternate solution:
Require a minimum deposit (1-10 ATOM) to make a proposal. When a proposal is made, it remains in an inactive state in the mempool and must not be displayed on any frontends and should not be allocated a proposal number.
To make the proposal active, one must complete the full deposit. If done, the proposal gets a number allocated to it and gets displayed on frontends.
Note : This minimum deposit (1-10 ATOM) should be burned to stop filling the mempool and disrupting the new genuine governance proposals not getting space in mempool. Also the minimum deposit number should be governance controlled so that in case of high spam and disruptions, it can be increased.

To deal with spam proposals which meet the full deposits, I propose that we have a 1-3 day prevoting period where only validators can vote. And if a proposal gets vetoed in this phase, again it doesn’t become active. There is a lot of room for experimentation in this phase to deal with spam while preventing censorship.

[Damien]

This is not a bad idea. However, this will in my opinion make the governance period longer (taking into account the pre-voting phases) and will also make voting a bit more tedious for validators who would have to vote twice on the same proposal essentially (once in pre-voting and once when it goes live)

[Ghazni_Stakecito]

Like I said there is room for experimentation in this phase. For example, we can make it so that if no one votes on a proposal in this phase, it can be seen as a signal that its likely not a scam proposal and can move to onchain voting. Maybe no quorum requirements as well? So this is similar to validator sponsoring a proposal, except you can have arbitrary number of validators sponsoring a proposal or rejecting a proposal as spam. Hopefully atleast 1 of n validators will take the tedious task of voting out every scam proposal.

[Jcook_14]

I think if we have validator sponsors of proposals, then inaction is action on the validators part. They don’t need to deny spam, they only need to accept legitimate proposals. At least that’s my understanding.

[Ghazni_Stakecito]

Ohh yes the inverse is also an option, but in an ideal scenario, these measures will stop the spam proposals and hence taking validators inaction as a signal of legitimacy of a prop gives us the current status quo of no validator being required to sponsor a proposal for it to go for onchain voting.

[Jcook_14]

My preference would be a mixture of the validator sponsorship as a general gatekeeper with a 40 ATOM initial deposit, and a 250 ATOM minimum deposit, with the addition of a heightened initial deposit and minimum deposit (example being 80 ATOM initial and 500 ATOM minimum) to get around the validator gating. This allows for the preferred method to be utilizing a validator sponsor, but in the case that a proposal can’t find a sponsor, they can still find a way to make it on-chain.

I feel like validators probably shouldn’t need to vote out proposals, because that then gives a single or a few rogue validators the power to vote out legitimate proposals. I’m alittle bit too tin foil hat for that haha that’s why I prefer the method of sponsorship and an expensive way around the sponsorship.