# Solana Governance Think Tank A community-led effort to explore the topic of on-chain governance on Solana ## Introduction This effort is a community-led exploration of the topic of on-chain governance. We explore the questions of why governance is necessary, what it actually entails, how it might be implemented and who would be participating in it. {% hint style="info" %} As it stands this is a first draft as presented by Michael from Laine and doesn't yet represent a community-formed view. {% endhint %} Primary discussion forum is the Governance Think Tank section of the [Solana Staking Alliance Discord server](https://discord.gg/HP7a87Ub) - please feel free to join it if you're interested in participating. This Gitbook serves as a place to capture the discussions as they evolve and formulate a framework of what the social consensus believes governance should look like. {% hint style="info" %} This effort and output is not binding and does not form a final decision on governance implementation. Any final implementation of a governance structure or process would require a full on-chain stake-weighted vote by validators. {% endhint %} ## Principles This section is a discussion to help evolve a set of principles to act as a foundation for the design of Solana’s governance. It is possible that the principles, or an evolution of them, can have broader future value in the execution of governance. All of Solana’s principles are in support of the mission or purpose, namely to ensure the network flourishes. They are established to better enable a collective effort in support of the operation and development of a fully functioning network. Essentially these principles are those things that the community genuinely believe in and which are in place for a number of reasons: * To anchor our thinking and to be consistent. * To act as a set of checks for each and every decision we make either collectively or individually by asking “Does this meet an individual or group of principles specified in this document?” If the answer is no then there is a very good reason for rejecting or changing the proposal. * To accelerate the way we work. Once we have these principles we can easily check against them. We do not necessarily need to evaluate each and every idea or proposal for change from first principles or against the experience and beliefs of a particular individual or group. Using these principles to evaluate choices should promote consistency and speed. Please feel free to challenge any of the initially proposed principles set out below. ### 1. People and their engagement All stakeholders will be treated with respect. They will be as engaged, in terms of both decision making and doing, as much as they are capable and willing to be. ### 2. Honesty and Integrity There will be honesty and integrity in all our dealings. ### 3. Clear and open multi-way communication All stakeholders will be listened to and clearly communicated with, according to their needs. The least number of simple yet accessible communication channels will be used. ### 4. Value and purpose There will be clarity about our purpose and what is to be achieved, this will be reflected in strategic and operational plans. ### 5. Focus and Alignment The most important aspects of our plans will be prioritized so that we focus on the critical few and not the trivial many. The role every stakeholder plays in these plans will be made sufficiently clear so that all actions are aligned in truly effective collaboration. ### 6. Decentralisation As much decision making will be as decentralised as it is effective to do. Implementation of this will be at a pace and in a manner that is capable of being supported. ### 7. Decision making and use of resources Decisions, including those about making best use of resources (people, assets, funds), will be: * In line with purpose/plans. * At a pace appropriate to the need. The influence an individual entity has on such decisions will be determined through governance. For certain decisions it may be appropriate to delegate to an authorised, capable body such as a technical committee. ### 8. Change and responsiveness Facilitating the navigation of change, change that is either self created or imposed by the challenging operational environment, is a primary purpose of governance. Such navigation depends on: * Having solid plans as a framework from which to move * The ability to take well considered entrepreneurial risks that are researched and judged by people competent to do so. There will be vigilance to ensure actions do not have unintended outcomes. ### 9. Subsidiarity The lowest level of authority capable of addressing an issue shall do so. ### 10. Complexity Essential complexity will be employed where necessary, but simplicity will be adopted wherever possible. ## Scope Initially, this document will begin by exploring some key questions: * Why - why do we need governance * Who - who participates in governance, in which roles * What - what is governance, what areas, actions and policies does it cover * How - how do we implement ## Principles TBD - Suggested in TG chat ## Contributors Contributors, listed alphabetically, are defined as those community members who have submitted PRs to this Gitbook. * Chris / Chainflow * Michael / Laine (also created and maintains the Gitbok) A full list of contributions can be found [here](https://github.com/laine-sa/solana-governance-think-tank/graphs/contributors). # Why Why does Solana need structured on-chain governance ## Status quo Governance on Solana currently does exist in a very "soft" form. Currently (July 2023) only a single validator client exists on Solana ("Labs client"). While a fork in the form of jito-solana exists this is not a standalone client is broadly the same implementation. This allows for a high-velocity development environment, which until now has been needed. However as Solana matures and further clients are developed we require a more methodical and planned approach. With a single client the core contributors of the Labs client can effectively decide on alterations to the protocol, runtime and many underlying tuning parameters. This either happens through a direct change which doesn't break consensus, or via a feature gate, which requires an on-chain activation. A feature gate triggers a hard fork where incompatible older nodes are unable to continue validating the global state. Feature gates are activated via the feature program on-chain, with a private key unique to each feature gate which is owned by the core contributor associated to that feature gate. Activation is managed via a schedule and social consensus. Discussions take place broadly on three our four fora: * SIMD (Solana Improvement Document)[ repository on Github](https://github.com/solana-foundation/solana-improvement-documents) * sRFC (Solana Request for Comments) [category on the Solana forum](https://forum.solana.com/c/srfc/6) * [Solana Tech Discord](https://discord.gg/7pRD5v3MdU) * Private discussions between client teams, e.g. on Slack ### Current on-chain voting A current implementatin of on-chain stake-weighted voting by validators does exist. This is a component of the feature program. However it has several drawbacks: * Validators receive an airdrop of tokens to vote with, the distribution of these tokens is manual and could be manipulated * Validators must use a CLI tool to cast a YES vote * No other vote is possible * This leads to a natural pressure as the only score one can track and lobbied for is "YES" votes, while it also takes away the ability to actively dissent with a change, absence of a YES vote may be an abstention or a NO vote or no vote at all, indicating lack of engagement. * There is no UI, thus while validators are technically capable it is opaque to other users and given the ambiguity between no, abstain and ignorance presents further confusion in interpretating non-votes. * Difficult to maintain a record of past voting by validators (and would only indicate YES or non-participation) ## Resilience and Independence As Solana matures, we seek growing independence from any single entity or actor, as well as resilience to their potential mealfeasance. Combined with a strong and broad stake distribution as well as very active set of validators the time is suitable to seek a transition to stronger on-chain governance. One example of how some groups in the community began this conversation previously is the proposal to increase the minimum stake delegation from 1 lamport to 1 SOL. This is an example of a type of change that should go through a full governance voting process, with a defined central location for debate and subsequent permanent voting record with the ability to dissent or abstain. # What What does governance mean and entail An initial, incomplete list of types of governance decisions that may exist in an L1 environment such as Solana: * Technology * Protocol-altering technical changes * Major * Minor * Parameter updates * Changes to consensus thresholds (ideally these are on-chain parameters), such as supermajority definition, fork switch threshold etc * Upgrade timelines and approvals * Client adoption * Feature activation * [SIMD](https://www.soldev.app/simd) Implementation approval (SIMD published, initial debate finalized, vote on whether to implement) (Possibly move to the "How" section?) * Economics * Inflation and staking rewards changes * Transaction fees (especially once transaction fees have been overhauled and hopefully include on-chain parameters) * Minimum commission * Governance * Adoption of the iniial governance process * Changes to governance itself * Treasury management * Grants (if funding exists) * Community fund spending (if funding exists) * Social * Votes on censure of validator behavior * Terminology/naming of things Initially minor protocol-altering technical changes should likely not fall under governance, e.g. altering the account of a native program or a SYSVAR to accommodate more data as part of a performance or feature enhancement. Major protocol changes as well as economic changes should likely fall under governance. Whether a community fund should or will exist is a further debate. The Solana Foundation administers an ecosystem fund, and there is a case to be made that some portion of this should potentially be made available for administration through governance, e.g. for grants or other development that the community wishes to decide on, independent of the Foundation. ## Current Proposal(s) The following are the leading Phase 1 implementation proposals that have emerged from discussions so far. The goal is to define a scope that is both practically limited and technically achievable, as Phase 1 is intended to the the first implementation phase of this newly defined governance process. ### Proposal A In scope are proposed changes to - * Economics (parameters taken from [Solana Docs](https://docs.solana.com/inflation/terminology)) * Total current supply (SOL) * Inflation rate (%) * Inflation schedule * Effective inflation rate (%) * Staking yield (%) * Total dilution (%) * Adjusted staking yield (%) * Slashing (not currently defined in Solana docs) Additional reference [Basic economic design](https://docs.solana.com/transaction_fees#basic-economic-design). * Consensus (reference [Shinobi Systems PoS and PoH Primer](https://www.shinobi-systems.com/primer.html)) * 67% of stake weight required for consensus * Leader schedule * Selection * Enforcement * Proof of history * Clock specification * Block streaming process ### Proposal B In scope are proposed changes to - * Native programs list taken from [Solana Docs](https://docs.solana.com/developing/runtime-facilities/programs) * System program * Config program * Stake program * Vote program * BPF loader * Ed25519 program * Secp256k1 program * Major feature developments/proposals * Generally intended to be consistent with the emerging [SIMD process](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0001-simd-process.md) * "Major" is TBD, examples given from the existing process, linked in the previous bullet point * Include * A change in format of a RPC API method * Networking interface changes between validators * Compute requirement changes on the runtime * Exclude * Rephrasing, reorganizing, refactoring, or otherwise "changing shape does not change meaning". * Additions that strictly improve objective, numerical quality criteria (warning removal, speedup, better platform coverage, more parallelism, trap more errors, etc.) # Who The stakeholders ## Introduction There are numerous stakeholders to an L1 governance process. These include the teams building the clients, the operators (validators & RPC operators), the token-holders (delegators), as well as all the other projects and teams building on the L1 who may be impacted by governance decisions. It is important to create a forum that allows all stakeholders to be heard and to participate actively, fairly and constructively. At the same time it is important to determine clearly how decisions are made. Solana uses a delegated proof of stake protocol, whereby token-holders delegate the power of their tokens to validators, who use this power to vote on the validity of blocks of transactions. It seems natural that if validators may choose which blocks and thus which transactions are valid (and currently one validator at a time also chooses which transactions even go into blocks), that this same delegated voting power is used for governance. It is however likely still desirable to permit other stakeholders (i.e. anyone) to create governance proposals (with disincentives for abuse), to participate in debate around proposals and to lobby for a particular outcome. ## Key Questions to Answer ### Who votes? Which stakeholders within the Solana community vote? * Client building teams * Infrastructure (validator and RPC) operators * Tokenholders * Dapp developers * Other (TBD) A related question is whether voting requires ownership of SOL. If it does, this requirement by default may define the stakeholder set, e.g. to token holders and validators, if token holders delegate their voting power to validators. If it doesn't, the stakeholder set can be more widely defined, making the question listed below regarding how voting power is assigned all the more important. Do all stakeholders vote on all governance topics defined in the "What" section? ### How is voting power allocated? What mechanism is used to assign voting power to the various stakeholders defined above? * Stake-weighted voting power allocation, e.g. 1 token = 1 vote * Quadratic voting * Other (TBD) ## Current Proposals Note that as of August 10, 2023, conversations seem to be favoring option 1 so far. ### Proposal A - Validators Only #### Description Validators are the only stakeholders who vote. Validator votes are stake-weighted. Those supporting this proposal suggest that stake account holders can express their desired vote outcome by either staying staked to their validator if they agree with their selected validator's voting or delegate away from their selected validator if they disagree with the way that validator votes. There is currently a difference of opinion as to whether there should be a time window within the governance timeline for stake account holders to make this decision or whether the current unstake functionality is sufficient. Detractors have expressed an opinion this is a less inclusive approach than Proposals 2 or 3. ### Proposal B - Validators and Stake Accounts #### Description Validators and stake account owners vote. Validator and stake account votes are stake-weighted. Validator votes on behalf of stake account holders. Stake account holders can override the vote of their validator. This option is similar to how voting works on Cosmos. Those supporting this proposal feel that it is a more inclusive approach than Proposal 1. Detractors question the technical feasibility of allowing such a large number of stake accounts (\~500k) to vote, as well as the value the stake holders will provide through their votes. A potential modification of this proposal is that validators could have the power to allow or deny their delegators the ability to vote. ### Proposal C - Validators, Stake Accounts and Other Stakeholders Validators, stake account holders and other stakeholders, such as RPC operators and Dapp developers vote. Voting power is not distributed via stake weight. This proposal is under development [here](https://hackmd.io/RyGbl7RLQAmDHAZG-6gfMA?utm_source=comment-card\&utm_medium=icon). ## Notes from conversations Debate on Telegram has focused on who should vote, and in particular whether validators are the best group to vote or whether governance should be a separate structure within the network. Some ideas: * Validators vote * Holders vote * Other stakeholders participate in voting too * Hybrid of the above ## Advisory Vote An advisory (non-binding information only) vote has been created [here](https://forum.solana.com/t/vote-first-governance-advisory-vote-by-validators/597) - validators may vote to help inform a stake-weighted consensus on this topic. The CSV file for the distribution of tokens according to stake weight for the initial advisory vote can be downloaded and reviewed here: {% file src="/files/rwvQIV2zVbfOpDq8pVkc" %} # How ## Components There appear to exist requirements for at a number components - * Forum for discussion & debate * UI for creation of proposals and voting * Mechanism for voting result execution ### Discussion Forum A [forum currently exists](https://forum.solana.com/c/gov/11) (recently revived). This seems like a suitable venue to create governance discussions for current and future proposals. ### UI for proposal creation and voting For the actual proposal and voting an existing on-chain program built by Solana Labs exists: spl-governance. A user-friendly UI for this exists on [Realms](https://realms.today/) - all this code is open-source and published on the Solana Labs github account. To enable seamless stake-weighted voting two components would be required: * on-chain view of epoch stakes (efforts are [underway ](https://github.com/solana-foundation/solana-improvement-documents/pull/56)to enable this) and an integration/plugin to Realms to assign DAO weights on this basis * delegation of governance authority from a vote account withdraw authority to a new public key (to ensure validators do not need to use their withdraw authority to interact with the governance UI) ### Voting result mechanism execution Once a vote is taken and the results compiled, it is necessary for an action to be taken, probably on-chain, to reflect the vote result. A mechanism is required to execute this action. ## Lifecycle and timeline The actual lifecycle of a proposal and voting procedure is the area where a lot of customisation and flexibility exist, and where we can harness the learnings from other chains who have experience with governance, e.g. Cosmos. Some of these are touched on in the Practicalities section. * Proposal submitted * Discussion period * Quorum reached or not * Vote * Vote result execution ## Interim Process - Introduction As of September 18, 2023 The discussion over the past two months has resulted in three Why proposals and two What proposals. It's now time to start moving toward making initial decisions. To make these iniial decisions requires an interim process. This interim process with follow the logic of a "minimum viable process". It's purpose is to facilitate these initial decisions. It is expected that this interim process will evolve as discussion moves from the WHo and Why to How. Because of this, it's important that the interim process serves the purpose it's intended to serve, without it getting stuck in a loop of over-engineering. The curent proposal, discussed in a recent [community-led validator call](https://hackmd.io/1DFauFMWTZG37-U7CXhxMg?view#Meeting-Notes-Summary), suggests using the existing feature of governance that exists on chain. It's current implementation includes stakeweighted voting and was orginally intended to activate features. What's needed is a CLI tool to create a feature proposal. A token and distribution schedule will be created for all the validators. The only voting option available through this process will be a "yes". A possible workaround is to send tokens to one address to indicate a "yes" vote and another address to indicate a "no" vote. The logic to do this in the case of choosing one out of three choices, as required by the "Who" vote, is to be determined. ## Interim Process - Timeline ### Step 1 - Proposal submission * Duration - 1 day ### Step 2 - Initial discussion period * Duration - 2 weeks * Date - TBD * Venue * Solana Discussion Forum post ### Step 3 - Voting period * Duration - 1 week * Start / End dates - TBD / TBD * Venue * CLI tool to place votes * Solana Discussion Forum posts to communicate individual votes and reasoning behind them Note that a TBD quorum must be reached for the vote to be considered valid. #### Proposed voting process Tokens for each vote will be created and sent to each validator's identity account. There is an existing SPL CLI for this as part of the feature proposal process. This can be used even if no feature actually exists in the costs. It will cost 4-5 SOL per vote to create and distribute tokens into token accounts for all validators. The current process only has a single "YES" vote option, this will be modified by providing addresses for each option. Balnces will need to be manually monitored. Full detail on how to verify all balances and amounts will be shared. The CLI automatically creates a stake-weighted distribution CSV. The first "informative" vote will be: Who should cast votes in a future governance process? -- Only validators, weighted by stake -- Validators and Delegators, if a delegator votes it overrides that portion of the validator's stake-weight -- Validators & other stake-holders See proposal details [here](https://sg.laine.one/exploration/who#current-proposals). ### Step 4 - Vote result publication * Duration - 1 day * Date - TBD * Venue * Solana Discussion Forum post communicating vote result and back-up informatino ### Next steps, i.e. implementation It is expected that these vote will be adhered to when the more form governance process is defined and adopted. Until then, they will be used as the foundation from which to begin developing the more formalized and longer-term How process. # Lifecycle of a Proposal The specific parameters governing the lifecycle of a proposal should be tunable, and their starting value are up for debate. Below is a graphic showcasing one possible such lifecycle with suggested periods for illustrative purposes:
Currently two existing forums exist in which proposals of sorts are being discussed: * SIMDs * sRFCs The discussions there should likely connect to proposal discussions in some way. Perhaps they can remain in those forums as the primary venue of debate and when they are ready for proposal discussion stage a discussion is created in the governance proposal forum which links to the prior conversations which would be more focused on technical and implementation detail. Some proposals might focus on tuning on-chain parameters, such as the lock & redelegation phase, base fees etc, where the primary venue of debate can be the governance forum. # Delegated governance authority Validators ideally use hardware or cold wallets to manage their withdraw authorities. The withdraw authority is a master key for a vote account and as such must be protected. To participate in on-chain governance a few options exist: * Use the identity key (still a sensitive key that holds funds and lives as a hot wallet on the validator) * Create a new key type `governance authority` to which governance voting authority may be delegated This requires modifications to the VoteProgram and potentially VoteAccount structure/size. It also opens up interesting conversations around governance delegation. E.g. can multiple validators delegate their authority to the same governance authority? Could large insitutional validators such as CEXs delegate their governance authority to a service provider? It may also be of interest to make a delegation limited in time/slots, e.g. the withdraw authority is used to authorize a governance delegation to a public key which expires after a number of slots (could be fixed or defined by the user, e.g. 100k slots). This would invariably mean each vote requires a new delegation from the withdraw authority (which would be a component of the VoteProgram similar to a commission change or withdrawal and relatively harmless, the delegate could then be a hot wallet that is used by the operator to interact with the Realms UI). # Proposal collateral To prevent abuse and spam users creating a proposal could be asked to provide collateral. This concept exists on Cosmos for instance. The collateral would begin at a fixed nominal amount, e.g. 10 SOL, and increase with every active non-resolved proposal that exists, thus creating a disincentive to spam new proposals before older ones are voted upon. The proposer would receive back their full collateral regardless of whether the proposal passes or fails, except where the plurality has voted for ["No with veto"](/practicalities/voting-options-and-slashing), this is a dissenting vote that further wants to slash the collateral of the proposer, to be used for proposals that are extremely bad, harmful or time-wasting. # Voting options & slashing The voting options that should exist at a minimum are * Yes * No * Abstain Additionally an interesting option observed in the Cosmos ecosystem is * No with veto This pertains to [Proposal Collateral](/practicalities/proposal-collateral) and serves as a method of slashing the posted collateral where a proposal is completely wasteful of the DAO's time, or intentionally malicious or otherwise deserving of such slashing. A proposal should require a simple or super majority to pass (needs to be discussed). # Quorum Quorum is a tricky and potentially dangerous topic. Too high and most proposals will fail because quorum is not met, too low and it presents an attack vector. Solana has an unusually engaged validator community, however one must be wary of governance fatigue as well. This relates to the [What](/exploration/what) and ensuring there aren't too frequent and trivial or excessively technical proposals that tire operators and ultimately lead to a decay in participation. It will require some trial to observe a suitable number for a quorum, especially as participation is likely to be heightened initially before tapering off to a sustainable level. A potential initial quorum number might be 50%, with a view of iterating quickly should this prove too high (rather start high and move lower than vice versa). Another concept is not having a quorum at all and requiring a simple or super-majority of stake for all proposals to pass. A simple majority might be sufficient for low-impact changes that might tune performance or make a small change accommodate future development, while a super-majority (2/3rds + 1) would be necessary for proposals impacting economics, consensus, the stake or vote programs, etc. # Vote locking & redelegation Another learning from Cosmos is that token-holders may override the vote of their delegate validator. This means that a validator might hold 1% of stake-weight, but one of their delegators who themselves has delegates 0.1% of stake-weight to this validator could choose to vote differently, thus reducing the validator's vote by 0.1% to 0.9% and adding their 0.1% to a different voting option. While this is an intrigueing concept it also carries some problems with it: it requires constant attention and understanding of delegators, while not penalizing validators for voting against the wishes of their delegators. A proposed alternative option for Solana, supported by the `Redelegate` instruction that will soon become available on Mainnet-Beta: * Once a proposal opens for voting, validators have a fixed time period to vote, e.g. 7 days * During the voting period validators may cast a vote and may amend their already cast vote to a different option * After the voting period ends the validators' votes are locked and a redelgation period exists for another time period, e.g. 3 days * During this period delegators may redelegate their stake, e.g. from a No-voting validator to a Yes-voting one, thereby altering the outcome of the final tally This method incentivises validators to vote wisely and listen to the opinions and wishes of their delegators, while penalizing those who don't. It further encourages good staking choices by delegators who are empowered to support validators who are active in governance and vote well {% hint style="info" %} This method can also incentivise a redelegation from a non-participating validator to a participating one, not purely based on the substance of the vote but simply the participation in governance as a signal of goodness. {% endhint %} # Call Notes Notes from validator and community calls # Community-led call 31 July 2023 *Compiled by Max Sherwood from H2O Nodes:* Governance discussion * The GitBook should distill the core points from the telegram group * Michael’s goal is to have a framework to present at Block 0 * * Some questions for the framework for a discussion (What are the big questions that need to be answered?) * Why do we need governance, who gets to vote, what do we vote on? * * Could discuss each one of these questions, then bring them together into one governance proposal * What works / doesn’t work on other chains? * Where should governance votes happen in relation to the release cycle of a feature? * * Do we vote to implement a feature? Or begin building it? Or to activate it? * How do we vote? People don't want to connect their withdrawal authority to the Realms UI… * * Once we have the mechanics for voting, we should have soft proposals to test out with * The question of “who is voting” will define the mechanics * * Validators, RPC providers, dapp developers…? * Stake is supposed to represent user input (delegation) * In Cosmos, delegators can override the vote of their validator * Every proposal should follow a discussion period * Would be good to bring some network tweaking / parameters / constants onto on-chain governance votes * * I.e. yolo flags * Maybe by this call in August we should have discussed “who should be voting” * * It’s hard though, because we dont have a concrete counterproposal * Chris suggests we put a proposal and see if there’s any pushback * Dapp builders are devs, validators are not necessarily… * “What do we vote on” should follow “who should be voting”