The content below is based on a long conversation on governance with the Sui validators following the Cetus incident.

Background/Problems

During the Cetus incident, an on-chain vote was implemented and orchestrated by SF/ML.

This raised a series of questions about governance from the current Sui validators:

• Under what circumstances should on-chain votes be called in the future?
• Who has the authority to initiate them?
• How can a community member surface an issue they believe warrants a vote?

Sui validators largely liked the design of the voting mechanism itself (particularly that it concluded quickly, and had early success criteria). They only had a few complaints:

• The acceptance threshold should be 2/3 stake weight, not 1/2 (same as consensus)
• Early on, almost all votes were yeses. If you were a delegate that wanted to vote no, it’s not clear what you should do
• If your validator votes one way and you don’t agree, you have to unstake to switch to a validator you agree with. This adds friction, loses staking revenue, and some validators interpret it as a taxable event

Design Goals

The validators liked the following design goals for a new governance. The high level details were discussed with them, some of the finer points are Sam suggestions. All are up for debate/redesign if they don’t make sense, but hopefully the goals are clear

1. Decentralized Proposal Process

This set of decisions is intended to address the three questions in the section above

• Any participant should be able to put forward a proposal (with some light gates like locking stake to prevent spam, sorting proposals by amount staked to facilitate review)
• A proposal can be in two states: pre-vote, and vote. Proposer decides when to advance from pre-vote to vote
• Once a proposal is in the “vote” state, it must reach 2/3 approval within 2 weeks or it is rejected
• It’s up to validators to decide whether a proposal is worth paying attention to in the vote phase and deciding whether to vote or not
  • Thus, it’s up to the proposer to rally the community and get them to care about a proposal enough to vote (this is not SF’s job, nor it it the validator’s obligation to look at everything). In the case that (e.g.) someone leaks their private key and loses $10, they are welcome to file a proposal, but they will probably struggle to find voters (which feels like a decent equilibrium)
  • In the pre-vote phase, validators and/or stakers can signal support so other validators might know to pay attention (e.g., by pre-voting, pre-votes automatically carry over into actual voting if the vote state is entered)
• The scope of what on-chain governance can and can’t do must be clearly defined, and relationship with the SIP process must be defined. Proposal:
  • SIP process: all technical designs and protocol evolution
  • On-chain governance: one-time out of protocol action, emergencies, incident response
• A vote passing means that core developers, validators, and the Sui community should take reasonable effort to implement the proposal with appropriate urgency

All of the above would likely be packaged into public proposal which we would socialize with the validators, implement, and (somewhat circularly) approve via the newly implemented voting process. Alternatively, we could do a SIP, but the “who decides whether it’s approved” question is awkward.

1. Staker autonomy and flexibility

This set of decisions is designed to address the complaints in the section above

• A validator vote is interpreted as defining the “default” vote for all of their stakers.
• However, individual stakers should be able to vote even if their validator hasn’t voted yet (and if/when the validator votes, the staker preferences is preserved)
• After a validator votes, an individual staker should be able to vote the other way
• Voting should not require unstaking
  • The validators understand that in practice, custodians not supporting the governance scheme means that unstaking will still be required for many folks. Thye are ok with this