# Equitable Stakeholder Vote
## Background
The basis for this exploration stems from a thought concerning a vote determined via economic unit (SOL in this case) while representative of PoS and "security" of the network (and an easy proxy for voting in governance), this economic unit is severely limited in total scope of all economics which facilitate a healthy, functioning network. Having an misrepresented vote can lead to a lack of representative vote amongst parties who may not have the free capital allocated in such configuration and may undercut the viability of a simple vote via stake.

> stake holder != stakeholder (at least not always)

In plain terms, a dApp with 10s of millions raised may be using that capital to operate, and they may be producing incredible economic viability for the chain, but may not be able to stake for a vote.

Or RPC operators may run significant infrastructure supporting large swaths of the network, but again may not have the capital to allocate to represent their value within the governance.

Total value locked in PoS Securing the network while of large value, derives this value from the utilities provided on chain. This is one metric which carries heavy weight (as it should), however total volume traded is another, total NFT market cap, another. All which point as proxy to the underlying, but not necessarily 100% reflective. Therefore these aspects should be considered when governance is appropriate.

With the above stated, considering alternatives and complexity arising from different vote primitives, it is a challenge facing all on chain governance. Identifying certain characteristics of healthy network governance should be weighted heavily. Metrics such as participation are easily identified, others like representation may not be so easily surfaced.

## Summary
To attempt to create a more equitable representation of vote without impacting vote allocation, the following is proposed:

- An SIMD identifies the stakeholders impacted by the proposal. These are categorical representation of those existing within or on top of the network.

> For example RPC operators or dApps

- Once the categories are defined, there is a percentage representation of the quorum vote (to later be used in quantity) recommended in the SIMD.

> For example if quorum is determined to be 40% of stake weight then if a category is assigned 1% it is then required to have AT LEAST that number of votes from casting to reach categorical quorum.

- In aggregate the percentage when summed should be no more than 50%.

> In this case if there are three stakeholders impacted by the proposal (RPC operators, Solana Labs, dApps) their percentages should add up to less than 50% of quorum.

- For a proposal to pass, the number of votes tagged as a categorical representation of stake need to meet or exceed the categorical percent defined from quorum.

> If you have a 40% quorum of 313M stake that is 125.2M, if RPCs have 10% (as they are most impacted, in this case) then to pass the proposal the vote needs at least 12.52M to be tagged with RPC operators category. When voting the validators (voters) can categorically assign their vote to one of the categories or split evenly, or vote uncategorized. This is just a surface layer to indicate to those delegated to the validator, that the validator is acting in good faith as a representative of the broader community.

Each vote has categorical representation of a vote quantity to reach "representative quorum". A SIMD should contain information pertenant to a vote, this will require broad categorization of stakeholder (or agreed upon categories) with a weight of quorom vote as a percent accounting for assigned weight to each category. This is not a perfect system, but an adaptable one.

| |
| :-: |
| 
*Example of what the visual representation of casting a vote may look like*|

Example:

SIMD 23
Replace RPC Method getAccounts

Stakeholders (Weight 24%):
RPC Operators (0.025)
dApps (0.025)
NFTs (0.0075)
Standards (0.0075)
Solana Labs (0.10)
Validators (0.075)

Abstract: ....

When a vote is finally called (to be discussed **when**) those weights are automatically assigned to the quorum vote and the totals are calculated, which at the time of vote the voter (in this case stake weight delegated to a validator, the validator is voting) has the option (not requirement) to allocate any configuration of a percentage of voting weight to a category. But where the quorum is not only a % of stake, but also matching the categorical weight.

| |
| :-: |
| 
*Example of the % of the weight of quorum vote with a 24% allocation strategy.*|

| |
| :-: |
| 
*Example of actual votes cast representing each category*|

This in theory should encourage and facilitate communications with the groups listed and their communications and concerns should be afforded a representation without allocating vote to them directly. It doesnt add additional compexity to the action of a vote outside of the categorization, quorum, and input from the SIMD.

## Proposed Metrics
Initial proposed weights and metrics:
- **Categorization Weight** - `10% < X <50%` Weight of total quorum vote assigned to and the sum of categories
- **Initial Categories** - `RPC, dApps, Solana Labs` Broadly categorized stakeholders within the ecosystem
- **Quorum** - `40%` The amount of stake required for proposal to meet threshold.
- **Passing Vote** - `66%` The amount of stake voting for a proposal to be approved (note the opposite is true as well)

Who votes? The validators with a vote cast in representation of Stakeholders within the ecosystem of Solana
What is voted on? TBD
How is the vote cast? TBD

## Proposed Implementation
Creation of cNFT with record of vote minted to validator identity where the vote details are imposed within the cNFT so the collection is associated with the proposal SIMD as well as the on-chain vote.