For the vote on MIP-1, stake for the vote was determined by delegated stake, or, if not delegated, the public key’s balance.
There have been alternative proposals, one is to allow any account to “override” it’s delegate’s vote by voting itself directly. Discord
A separate argument has been made that voting should not be passive and only individual accounts should be voted - 1 mina 1 vote. A long discussion begins here: Discord which has been (somewhat reasonably - but please go read discord if you want the full context) summarized by chatgpt as:
- Balance Calculation: The discussion began with questions about how balances are calculated for voting. It was clarified that the balance used in the vote is the sum of delegated balances for accounts that are delegating to the same address. For votes that don’t count, it’s just the balance of the account itself.
- Override Delegated Votes: The idea of allowing votes to override the delegator’s vote was discussed as a potential improvement to the current system. It was suggested that only “real” votes, i.e., votes from the account owners themselves rather than delegated balances, should be counted. However, concerns were raised about the potential for manipulation and the influence of large stakeholders.
- Weighted Voting: The concept of weighting votes by other means, such as considering the size of individual holdings, was debated. It was mentioned that implementing a cap on the influence of validators or considering saturation limits, similar to Cardano’s approach with staking pools, could be explored.
- Role of Delegation: There was a discussion about the role of delegation and whether it undermines the effectiveness of individual votes. Some participants expressed a preference for personal-sized holdings having more influence, while others highlighted that the delegation system allowed the Mina Foundation to delegate voting power to multiple independent block producers.
- Participation and Voting Power: The conversation touched on the participation rate and the influence of different stakeholders. It was noted that while thousands of people casting individual votes might seem significant, their combined voting power would still be outweighed by larger stakeholders, such as staking pools or whales.
- Concerns and Solutions: Various concerns were raised about the current system, including the potential dominance of staking pools, collusion in private voting, and the significance of the Mina Foundation’s stake. Potential solutions discussed included modifying the vote threshold, implementing a dissent campaign, or reevaluating the overall approach to voting.
- Trade-offs and Perspectives: The participants shared different opinions on the ideal voting paradigm. Some favored a one-Mina-one-vote approach, while others believed that the delegated voting system, with the option to override, was more representative and less susceptible to manipulation.
After considering those discussions, I think that the override solution is the best approach - because it allows individual account holders to vote if they desire, but, as Gareth pointed out, leverages the stake of Mina Foundation and O1 Labs to provide a decentralized yet still sizable voting pool of somewhere between 240-360 accounts that can vote with their weight. This mechanism provides a useful counterbalance to the large pools, exchanges, and individual holders.
Even if we can agree to the override mechanism, there remains a question of how to treat accounts that have been abandoned by their block producer through re-delegation. (account A delegates to account B, and then account B delegates to account C.) In the current delegated-weight approach, the balance of account A is disregarded; however, if we introduce overrides, this would allow account B to vote - and it would pick up the stake of account A since it is still delegated to account B.
This may introduce the potential for pools to amplify their vote by identifying stranded stake and asking their delegates to vote directly, in the same direction, to pick up the extra votes. Although it is unlikely to be a significant impact - there are other economic incentives to discourage double delegation in the first place - it may also be reasonable to simply exclude those delegations – so if an account is delegated, but chooses to vote for itself, it votes for itself only, and not for its delegates (their stake remains disenfranchised by the double delegation.)
Another approach would be to always apply the stake - e.g. implement transitive weight voting - so in the scenario above, If only account C voted, it would vote the stake of A + B + C. This would calculate the weight of each account by including not just it’s delegated stake, but recursively the delegated stake of all of it’s (and their) delegates as well.
I propose that the implementation should simply disregard the double-delegated stake, based on the idea that 1) a voter’s actions should not be able to change the total vote count - so one of the approaches needs to be adopted, and 2) abandoning the stake from account A is both simpler, and matches how consensus works. I prefer the solution that is more consistent and simple.
I propose that we direct MF and Granola Systems to alter the On Chain Voting system to:
- enable “override” voting such that an account can always vote it’s own stake directly, and
- to disregard double-delegated stakes in the new method - so that the denominator of total votes cannot change regardless of which combination of accounts votes.
It is awkward to use votes to determine the vote-counting mechanism. If my first assumption is challenged – i.e. if we would like to gather the sense of the community re: eliminating delegated votes entirely, that would require a different voting mechanism to even evaluate the alternative (a 1 mina, 1 vote implementation with no delegation.) Since I am not proposing that, I think it is reasonable to use the current OCV mechanisms to agree to the new voting scheme.