VOTE! First Governance Advisory Vote by Validators

[laine]

Dear Community,

following discussions in community and validator calls, on this forum and on Discord, I am now initiating a first advisory vote by validators on a key question of governance:

“Who should vote in a Solana Governance DAO”

(Further discussion here and here as well as on Discord here)

Please feel free to share how you voted and why in this thread

Option 1: Validators vote, votes weighted by stake
Option 2: Validators vote & Delegators can override, if a delegator votes it overrides that portion of the validator’s stake
Option 3: Validators, Delegators & Other Stakeholders (identity and weighting to be determined)

Voting takes place through tokens deposited to each validator’s identity account. The token has the address BX4ZwH36vMf8T8A4GQ44SSKb8puhXkn7ymJyGi1Ky2GJ and the supply is equivalent to the total active stake in epoch 515. Each validator identity account receives the number of tokens representing their amount of active stake.

The mint and distribution is done using the SPL Feature Proposal program.

VOTING INSTRUCTIONS

(You will need the spl-token cli tool to vote, it is included in the solana-cli install if you use the installer or install with cargo install spl-token-cli)

To cast your vote you must transfer your tokens to one of four public keys to vote for one of the three options or to abstain:

Option 1: opt1AMNK6g6UxG4N3sFUtfwmM5dKXbJamKCkcr91jai
Option 2: opt2i1BogY7cwfp23hTz92iQcZyqeX1m4fNZcEcMCSL
Option 3: opt3T4MkCfJLFHcScTaNZpWSMDGZqNUZwLGCTHFEPzK
Abstain: ABShtgkUD7UMB7SF9Ur9oLU4XxudnCezjSF8sqqae97c

To vote first verify your token balance matches your active stake (in epoch 515) (replace validator-keypair.json with your identity keypair):

spl-token accounts --owner ~/validator-keypair.json BX4ZwH36vMf8T8A4GQ44SSKb8puhXkn7ymJyGi1Ky2GJ -v

Then to cast your vote (replace OPTION_PUBKEY with the option pubkeys listed above):
spl-token transfer --owner ~/validator-keypair.json BX4ZwH36vMf8T8A4GQ44SSKb8puhXkn7ymJyGi1Ky2GJ ALL <OPTION_PUBKEY>

VOTING PERIOD
We will look at the balances of these accounts on 20 October 2023 at 12:00 GMT to determine the result of the vote, please vote by then, this is in 10 days from now.

TALLYING VOTES

This is an advisory vote, it does not form a binding decision and as such there is no particular threshold that should be met for any action to be taken. At the end time mentioned above the results will be tallied by myself (and anyone else may do so themselves of course) and published in this thread and on sg.laine.one.

The total supply of the voting token equivalent to active stake is 389,207,145.95. Therefore a simple majority would be 194,603,572.975.

To check votes cast for a particular option:
spl-token balance --owner <OPTION_PUBKEY> BX4ZwH36vMf8T8A4GQ44SSKb8puhXkn7ymJyGi1Ky2GJ

ADDITIONAL READING

Summary of discussion on “Who votes” Who - Solana Governance Think Tank
Voting token and supply info: Solscan
CSV File for token distribution by stake: Who - Solana Governance Think Tank
Feature Proposal Program Docs: Feature Proposal Program | Solana Program Library Docs
(we are using this program for its ability to automatically mint a token with the exact active stake and create a distribution to all validators based on stake weight, not to activate an actual on chain feature)

[cfl0ws]

Chainflow’s Vote - Option 3, Validators, Delegators & Other Stakeholders

Inclusivity is one of Chainflow’s four core values. From our perspective, Option 3 is the most inclusive of the three options. This is why we chose it.

The choice represents our well-intentioned and best effort to make a decision to move the Solana governance process forward. We recognize it’s based on incomplete information (as most, if not all decisions are) and made within an evolving process.

We recognize that Option 3 is also probably the most complicated of the three. We feel that these complications can be figured out and handled over time.

Solana governance is in a very early developmental stage. It feels important to keep the process as open and inclusive as possible at this stage.

That said, we are open to supporting a more restrictive option, such as Option 2, in the future, if that trade-off is required to take an incremental step forward. We would weigh this decision against a number of factors if and when that time arrives.

Our experience, however, having participated in governance on many chains over the years, has demonstrated that blockchain decision-making is generally led by engineers. As such, the tendency is to move toward efficiency and simplification. So for us to support Option 2, we would need to see a clear commitment to re-opening the voting process to a more inclusive set of stakeholders in the future.

[zantetsu]

I will be voting for the Validators Vote option.

My reasons are twofold:

1. Validator only voting is the most practical and efficient to implement voting system. A nascent governance system is likely to die outright if saddled with the burden of implementing a complex or impractical voting system. Validator only voting is simple, has been demonstrated already in practice, and has existing infrastructure to support it. In future, after time has passed and a validator only voting system has been used enough times that issues surrounding voting are better understood, other voting systems could be proposed as upgrades to the process. But I think that a staged approach where we take practical, implementable steps first, and then expand to more complex systems if they then appear advantageous later, is the right way.
2. Validators will always have an opportunity to engage their stakers and implement their own governance mechanisms within the body of their own stake. So some validators could implement a pre-governance vote method that allows their stakers to provide input, in a whole variety of ways, each validator choosing whatever works best for their stakers. Some may allow stakers complete control over how the validator votes; others may implement a validator choice with staker override method. Still others might have informal methods based on discussion forum feedback with the validator acting as final arbiter on the decision. This plurality of voting methods will allow validators to compete for stake by providing the best voting experience, and validators can individually move faster on finding better voting methods than the overall ecosystem as a whole making monolithic choices can. In addition, this plurality will allow stakers to choose the voting method that they like best by staking with a validator that provides that method. In short, there is no need for a mandatory ecosystem-wide staker-inclusive voting policy when individual validators can allow whatever policy they want to for their own stakers.

[MCF]

MCF - OPT2 - Validators with Delegator override.

OPT3 - has merit, but would be too complex to implement in reasonable timeframes.

OPT1 - takes power away from the token holders, so that’s a NO from us.

https://twitter.com/MCFvalidator/status/1711830346751267244

[laine]

THE RESULTS ARE IN

With over 170 participants and around 14.3% of stake voting, over 70% has voted for option 1 with option 2 coming in second at 24%.

The absolute number of votes cast (representative of SOL staked):
Validators by stake-weight 39557413.31
Validators & Delegators by stake-weight 13574516.82
Validators, Delegators & Others 2552960.05
Abstain 28300.55898