We have now published specifications for each of the houses in our proposed modular governance upgrade: the Citizens, the Builders, and the Stakers. This specification ties these together into a Voting Module, which brings everyone together to vote on proposals and aggregates the results of each of the houses’ votes. The Voting Module is responsible for enfranchising each of the stakeholder classes in our governance, providing them with the agency to signal their preferences on specific decisions and implementing some of the rules defined in other modules (e.g. only Citizens can vote). It is therefore important for this module to be upgradeable (in keeping with our modular governance thesis) but also to not introduce any unnecessary complexity to the system.
Requirements
- Self-sovereignty, building with our own open-source tech wherever possible, to minimize dependencies on other teams/products to add features.
- Modularity so that we can easily upgrade the voting module in future.
- Users should be able to cast their vote only once and have all of their voting weights, across all houses, be registered simultaneously.
- We don’t want the running tally of a vote to influence voters’ decisions. This may create circular dynamics that undermine the veracity of the 3-dimensional voting signal. Vote results should be hidden until the vote concludes.
- We don’t want to show voting results in progress, but we do need to be able to verify the results after the fact.
Specification
Architecture
Gateway’s protocol powers the credentials that are being issued for the Citizen, Builder and Staker modules. As Issuers of these Gateway credentials, on behalf of the DAO, PNF has full read-only API access to the state of the credentials. We will use this API access to maintain a self-hosted mirror database that maps the credentials, their state, and associated Ethereum wallets. This provides us with a complete self-sovereign map of governance power that we can use for Snapshot votes.
When a user votes, they will vote with an Ethereum (e.g. Metamask) wallet that they have previously connected to their Gateway account. The Snapshot strategy (voting algorithm) will then be able to pull the Gateway ID that is associated with the Ethereum wallet, all of the credentials that have been issued to the Gateway ID, and thus the voting power associated with the Ethereum wallet. This achieves our requirement of a user being able to cast a vote only once and register their voting weight in all houses simultaneously.
The Snapshot strategy will wait until the vote has concluded then it will calculate the voting weights and normalize them so that each of the houses has their predefined voting distribution (defined below).
Voting Journey
- Registering Voting Power: Voters will use Gateway to register all of the activities that will earn them voting power. This includes completing forms on the Gateway dashboard, connecting Ethereum wallets that they’re staking wPOKT with, and connecting POKT wallets that they’re staking nodes with. This will associate their various wallets and credentials to the same Gateway ID.
- Tracking Voting Power: PNF will maintain a database of voting power which regularly mirrors the state of the Gateway protocol, ensuring we have an up-to-date map of Gateway IDs (voter identities) and all of their associated activities (voting power).
- Locking-in Voting Power: When a proposal is created, a timestamp is locked in as a cut-off for voting power. Any credentials earned after the vote started will not contribute to voting power. This prevents gaming of votes.
- Gating Voting with Passport: In order to vote, voters will need to provide Snapshot with a valid Gitcoin Passport that has a Humanity Score > 20. The Passport itself is tied to a specific Ethereum wallet. This enables us to maintain sybil protection and protect the limits in our governance. For example, with an individual Builder voting power limit of 10, even if a voter has multiple GatewayIDs with 10, they will only be able to vote once with the Passport.
- Voting with Ethereum Wallet: As is standard with Snapshot, voters will use an Ethereum wallet (e.g. Metamask) to cast their vote. This Ethereum wallet must have a valid Gitcoin Passport attached. If they have previously connected their Ethereum wallet to their Gateway ID, all of the voting power they registered with Gateway will be readable by Snapshot. The Snapshot strategy will pull the associated Gateway ID then pull all associated credentials (voting power).
- Voting Weights Tallied at the End: Once the vote concludes, Snapshot will tally up all votes and normalize them so that each of the houses (Citizen/Builder/Staker) has their predefined voting distribution (defined below). Since weights won’t be normalized until the end, and we can’t predict voter turnout as it’s happening, it won’t be possible to maintain a running tally of voting weights, which is a good thing per the requirement above.
Snapshot Strategy
General Principles:
- No quorum. Individual voter weights in each dimension are a function of how many in the dimension voted, not how many exist.
- Inter-house limits must be used to ensure that each house has a set proportion of voting power regardless of how many users vote.
- No credential stacking. People can claim multiple instances of a credential, and this can be done to proactively prevent their voting power expiring, but they shouldn’t be able to stack them for more power. The Snapshot strategy (voting algorithm) should reflect this.
Voting Weights:
- Citizens: 10% of Total
- Builders: 45% of Total
- Stakers: 45% of Total - which breaks down, as described in the Staker spec, as follows
- Nodes: 40% of Stakers (18% of Total)
- Gateways: 30% of Stakers (13.5% of Total)
- LPs: 30% of Stakers (13.5% of Total)
Note: the final weights are subject to change in the final proposal. For example, one change being considered is to increase the Citizens house to 20% and decrease the Builders/Stakers houses to 40% each.
Other Checks:
- Citizen Credential: If a voter doesn’t possess a Citizen credential, their voting weight will be 0%.
- Gitcoin Passport: This does not need to be checked by the Snapshot strategy because we are using Passport to gate voting within the Snapshot interface.
The weights of individuals within each house are defined in the specifications for each house: Citizens, Builders, Stakers. Citizens are 1-person-1-vote, Builders can earn up to 10 votes each, and Stakers have their weight defined as the square root of their stake/burn amount (with a fixed % allocated collectively to Nodes, Gateways, and LPs). This determines how much weight they have relative to others in their house, however, for the final result the normalization to enforce the 10/45/45 split will adjust each individual’s weight in proportion to how many voted in their house; if there are more Stakers, each will individually have less voting weight than fewer Builders.
Metagovernance
The Snapshot strategy itself will be modular, with separate functionalities for calculating each house (each house strategy) and normalizing their weights (aggregation strategy). Snapshot also supports versioning for strategies so that we can easily upgrade them. Combined with our modular approach, this means the voting module will be completely upgradeable, in keeping with our modular governance strategy.
The boundaries of upgradeability for the Snapshot strategy, including the ability to adjust the weights of each of the houses, and upgrade our voting mechanisms, will be defined in the Metagovernance module which will be detailed in a later specification.
—
We are getting close to having all specifications fully defined and published! We look forward to any feedback on this Voting Specification as well as the related specifications for the Citizens, Builders, and Stakers houses. We will soon be publishing a complete proposal to the DAO that ties everything together, so any feedback at this stage will be considered for the final proposal.
Many thanks, PNF