The 0L network currently lacks an official voting mechanism, making it challenging to accurately gauge the preferences and opinions of network participants. While there are various methods to create polls, these approaches may not guarantee the inclusion and proper representation of all community members. We value the input of all network participants, particularly long-term contributors, and recognize the need for a more inclusive voting system.
To address these concerns and foster a greater sense of community involvement, we propose a voting mechanism that serves as a signaling tool for network participants. This system will ensure that the voices of all community members are heard and that their preferences are taken into account during decision-making processes.
We propose an on-chain voting mechanism that serves as a signaling tool for network participants. This system allows every wallet to have a vote, weighted by its age on the network but capped at a predetermined number. Over time, any wallet can hold the same weight as a genesis participant.
The voting mechanism is implemented by utilizing multiple addresses representing the voting options for a specific proposal. Wallets, including community wallets, validators, miners, and basic wallets, would send the smallest possible amount of GAS to the addresses corresponding to their preferred options. Votes would then be counted and weighted to generate a chart that displays the number of votes and their corresponding weights for each option.
As this is a signalling mechanism, there are no strict rules, and any active wallet with more than 1 GAS can participate. The voting weight is determined by the number of epochs passed since the wallet's first transaction, with the weight capped at the median of total epochs passed since the network's genesis.
While more complex variables and rules could be considered, this straightforward approach aims to avoid the need for an extensive agreement process.
In this example, the network has been online for 500 epochs (days), with a total of 10 participants, out of which only 6 are active (having more than 1 GAS and having made a transaction).
The proposal at hand is the v6 upgrade, using Rxc voting outcome, with the proposal address: abc123fff000. The voting options and their respective addresses are:
- Yes: Address abc123fff001
- No: Address abc123fff002
The voting activity of these participants is as follows:
- Wallet 1: First transaction on epoch 1, votes yes
- Wallet 2: First transaction on epoch 2, votes no
- Wallet 3: First transaction on epoch 100, votes yes
- Wallet 4: First transaction on epoch 250, votes no
- Wallet 5: First transaction on epoch 400, votes yes
- Wallet 6: First transaction on epoch 500, votes yes
To count and weigh the votes, we look at each participant's voting weight, which is determined by the number of epochs passed since their first transaction (capped at the median of total epochs passed since genesis).
In this case, the median is 250 epochs, and the voting weights are:
- Wallet 1: 250 (capped)
- Wallet 2: 250 (capped)
- Wallet 3: 250 (capped)
- Wallet 4: 250 (capped)
- Wallet 5: 100
- Wallet 6: 0
Now, we can tally the votes:
- Yes: 250 (Wallet 1) + 250 (Wallet 3) + 100 (Wallet 5) + 0 (Wallet 6) = 600
- No: 250 (Wallet 2) + 250 (Wallet 4) = 500
The weighted votes show that the "Yes" option received 600 points, while the "No" option received 500 points.
- Proposal authors are required to create the relevant addresses
- Voting happens by sending a transaction with any amount to the address of the preferred option
- Only a single vote is counted regardless of how many transactions or amounts were sent
- Voting on both options of a yes/no proposal deems the vote invalid and excludes it from the final count
- A test proposal is live at https://signals.openlibra.space/proposal/1