Proposition 69 on the Cosmos Hub (https://www.mintscan.io/cosmos/proposals/69) was a highly contested and controversial proposal which serves as a lesson in blockchain governance.
Initially proposed by Billy Rennekamp, the product Lead at Interchain GmbH as a programmable extension to the Cosmos Hub in the form of CosmWasm (WASM for Cosmos SDK based chains) faced serious opposition by one of the Cosmos founders, Jae Kwon, first as a open debate and media opposition. And finally as a bribe to all ATOM holders to vote “No With Veto” in exchange of GNO airdropped tokens so that Jae’s vision for the hub was kept intact. That is, as a uberminimalist hub without any additional plugins.
Unsurprisingly, bribing token holders and possibly validators with new tokens worked wonderfully. As the vote was swiftly tilted in favor of “No With Veto”, even ATOM accounts who originally voted YES. Why? Because after gaining momentum with votes of large validators like Dokia, who by default have 100% of their stakers votes delegated to them, the rest of ATOM token holders would receive no benefit by keeping their YES vote. So the rational thing to do, after seeing that “No With Veto” crossed the 33% mark (threshold required to void said proposal), was to also vote “No With Veto” to also receive a large allocation of the yet-to-be-minted GNO tokens. This happened because YES voters would receive no GNO allocation whereas “No With Veto” voters would receive the largest multiplier in the future allocation.
After that, there is still some voices who believe that implementing CosmWasm on the Cosmos Hub will increase its functionality as a Hub that offers shared security as well as other potential solutions. And there is even the possibility of relaunching the vote due to the dire need of such tools to be available to Cosmos Hub developers. But as of July 2023, the second CosmWasm proposal for the Cosmos Hub has not been made public.
Let’s Talk about the potential solutions to such threat scenarios.
The first obvious solution is the elimination of default delegations to validators who may or may not vote in favor of such Bribedrop. However, this only works if the validator doesn’t hold a significant amount of tokens in question. Just like in the case of Dokia on the Cosmos Hub, this would have made little difference because a large amount of said tokens would still be in possession of Dokia and changing default voting wouldn’t make a difference.
As @TugyTur has mentioned on Twitter, preserving voters privacy is one of many ways of safeguarding the integrity of votes as well as making it harder for bribers to figure out a way to reward certain voters on-chain. The merits and drawbacks of private voting deserves its own analysis but it still remains a great countermeasure against on-chain governance bribes.
Repeating the vote is another low-tech alternative that might happen soon on proposal 69 and it’s also a likely countermeasure scenario for all bribes. In this case, the briber needs to keep bribing with more rewards or threat removing the original reward in order to work. In such case, timing is everything. For instance, in the case of a potential redo of proposal 69. Jae Kwon could potentially threat to remove the GNO airdrop for all accounts if they vote YES on the redo of the vote. However, this threat loses all value once the GNO airdrop has already happened so the briber, in this case Jae and the GNO blockchain, have to up their bribes with fresh value, otherwise the bribe will lose all its value. This is probably the solution without much tech and privacy improvements that could be used repeatedly. Moreover, if the promised bribe is delayed significantly and fails to come after a certain period, considering that it was promised in the future, the threat of losing the bribe becomes less significant because it becomes subject to the disillusionment of the bribed part.
In the concrete example of proposition 69, this could come in the form of a delay of the GNO launch for many years, so people who was initially granted an allocation of the GNO airdrop would not see any value on the promise of an airdrop because it would have come for many years already, which in turn, would decrease the effect on any promise from the bribing part.
As bribes are part of many governance platforms and gauges such as Curve and others, we have to be aware that bribes not only affect the outcome of a certain product over another one but also, can be used to hinder development over ideological reasons. However, there are some ways to avoid the fallout. Likely, even more than the ones explored here.
References taken from frens.army article about prop 69:
• Billy Rennekamp: https://forum.cosmos.network/t/proposal-69-vote-on-chain-include-cosmwasm-in-rho-upgrade/6243/2
• Jae Kwon: https://github.com/gnolang/gno/blob/master/gnoland/docs/peace.md
• Polkachu (validator): https://polkachu.com/blogs/ibc-will-not-make-cosmos-a-hub-thats-great-news
• Adriana from Kalpa Tech: https://twitter.com/adriana_kalpa/status/1521950210515218432
• Gregory Landua from Regen Network: https://twitter.com/gregory_landua/status/1522286822910566402
• Thyborg: https://twitter.com/ThyBorg/status/1522169257219420160
• Medium Article on Proposal #69 by Silver Raven: https://medium.com/@RealSilverRaven/cosmos-atom-prop-69-nice-explained-3f9326b665ab