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.
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.
I agree with option 1 . It will be so Democratic
validator sponsorship is a good idea.
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.
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.
Here is what I believe is the best solution:
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.
I have been invited directly by @jacobgadikian to add my thughts here, after reporting them on a Twitter thread.
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.
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
Npast governance proposals:
N * 10
- an Osmosis account that has deposited
Kkind of tokens:
K * 5
- a Twitter account with more than 1000 followers:
So the overall score would be
(N * 10) + (K * 5) + 100
Obviously these things are just examples. The math formula used to determine the score based on various data should be much more thought through.
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.
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.
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.
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.
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)
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.
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.
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.
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.
Validator sponsorship is a good start. One idea to get the proposal to voting period, deposits must come from an active validator wallet.
Hi, I’d like to single out @mintscan for some praise here.
They’re now filtering out proposals that have >90% NWV, and this reduces the incentive to spam/scam.
As soon as the upgrade has completed, Notional and Informal will be looking into additional ways to ensure that there is less visiblity to these scam props.
Thanks to everyone for their feedback here.
If somehow we didn’t notice if there was a spam proposal to vote or we just did not vote at all, would it be interpreted as we don’t participate in governance? Since as validators, participation in governance is important. Thanks.
Auto-adjust the deposit amounts to target a desired amortized rate.
I should say that I no longer favor the solutions here, I’m good to discuss ideas in your thread. Mine is a bit more manual than yours.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.