Governance is a broad term, and for it to be effective on Solana we must be clear on the scope of any governance system that we implement.
Looking at other chains and ecosystems, we see instances where very minute details are determined by governance, for instance.
A proposal for an initial scope for governance on Solana could be:
- Changes to the Stake Program, Stake Pool Program, SPL Token programs (legacy and Token2022), Vote Program, etc
- Changes to sysvars or other on-chain parameters (e.g. slot duration, account and block CU limits, base fees)
- Major* changes impacting the consensus protocol
- Proposals for major changes impacting the economics (including inflation, credits/rewards calculations, functionality or restrictions on stake accounts or vote accounts (also covered by the first point))
- Implementation of any sort of slashing mechanism
- Changes to governance itself
- Appointing committees to delegate certain responsibilities too (such as determining the acceptance/denial of a parrticular scope of proposals/SIMDs)
- Appointing a committee/multisig to hold feature activation keypairs
*Major here would indicate a new feature or functional change, but not a bug or minimal performance fix. A performance fix that requires a large amount of code changes, might be part of governance if this is determined through social consensus/discussion.
What would not be covered by governance?
- Grants (Governance has no treasury at this stage, Foundation grants are theirs to decide)
- Whether or not to activate a feature (other than perhaps through delegation to a committee that holds such keys and makes such determination in accordance with social consensus amongst core contributors as is currently the case)
- Naming or terminology of things
- Whether or not to adopt a particular version of a client
Please provide your comments on these lists, whether you agree or disagree with particular points (with reasons) as well as any additional items you think should be on either list.