Background
Our current voting design is well optimized for the governance experience of our community members, validating the knowledge of our voters, and enabling democratic 1p1v, however it is not necessarily perfectly robust in adversarial environments.
While BrightID will provide us with sybil resistance, it doesn’t defend against malicious attacks from unique persons. Neither necessarily does POKT Arcade; earning a vote will require engaging genuinely with Pocket, which should take a few months for most people, by which time we may even have assimilated would-be attackers, but it remains the case that the aggregate incentive-alignment in this system (post-vote-acquisition) is potentially weaker than in token-weighted (excluding vote rent attacks) or reputation-weighted systems.
However, UX was not the only reason we converged on using Snapshot for our governance. It also provides us with more flexibility than any other solution to design and refine our governance mechanisms. In Snapshot, the results of proposals are determined by strategies, which are Javascript functions that return a score for each voting address. Multiple strategies can be used in parallel and strategies can include calls to nodes or subgraphs.
Existing strategies include:
- ERC20-balance (what we’ll be using with our 1p1v POKTDAO tokens)
- Using any contract call
- ERC20-balance multiplied by a coefficient, with quadratic voting and/or with delegation
- Tokens staked in a Balancer/Uniswap pool
- The quadratic weighting of Synthetix voters, based on their debt percentage in the previous fee period
- Weighted by the number of ENS sub-domains they own
- And more listed here
We already have a robust system of checks and balances on executive power (how decisions are ultimately executed in the Pocket blockchain), which prevents any protocol-level damage by corruption of the legislative branch (the Council). However, this doesn’t change the fact that any corruption would be a governance crisis. It might therefore be worth exploring checks and balances we can introduce within the Council itself, so that it can keep itself in check without having to involve the other branches.
In other words, we currently have one scoring system (Snapshot strategy) for determining the results of a vote, which simply counts the number of voting tokens a person has (1 each, enforced by the PIP-1 process); it might be worth exploring other scoring systems that we can check this with.
Summary
To reinforce our governance security, by introducing checks and balances within the Council, we should research and build custom Snapshot strategies that we can combine with our default 1p1v Snapshot strategy.
Objective(s)
Build a stronger foundation for scaling the DAO.
Objective Key Results
The Council is more robust to potential attackers.
Definition of the Project
Specification Examples
Part of this proposal is to research the best strategies, but here are some initial ideas…
We might want to add a staking requirement:
- if a voting address’ linked POKT (and wPOKT) accounts are unstaked, they lose the additional weight,
- if ALL accounts are unstaked, they are blacklisted for as long as they remain unstaked
We are likely to still want our default ERC20-balance strategy to be the democratic baseline, but we may also want to combine it with other strategy “modules” and then take the majority of those modules’ results…
- Stakeholder voting: ERC20-balance of POKTDAO
- Shareholder voting: Balance of POKT staked (and wPOKT staked), measured by linking POKT (and wPOKT) addresses to POKTDAO addresses in POKT Arcade verification process
- Contributor voting: Balance of Cred, measured by linking SourceCred addresses to POKTDAO addresses
…with a 2/3 majority required from the modules.
Since strategies can work in parallel, one voter’s weight would be simultaneously determined by their ownership of a POKTDAO token, the balance of POKT they have staked, and how much they have contributed to the community. This has two benefits: 1) combining/layering strategies should have no impact on the end user experience (the user only has to cast their vote once), 2) the meta-strategy would simultaneously prevent tyranny of the majority, the plutocracy, and the meritocracy (or any other governance weaknesses we might want to prevent):
- a stakeholder majority (of POKTDAO holders) would only be able to pass a vote if they are EITHER a shareholder majority OR a contributor majority,
- a stakeholder minority (of POKTDAO holders) would only be able to pass a vote if they are also the majority of both shareholders AND contributors, meaning they represent the most incentive-aligned stakeholders.
As part of this research, we might want to explore how the checks and balances of other legislative branches are composed (e.g. the checks and balances of the US House vs Senate). We should think about what outcomes we’d hope to achieve and which interests we’d be looking to balance. Using these examples and goals, we can then work on designing the most appropriate strategies.
Other mechanisms worth exploring include:
- Weighting towards experience: reputation, account/stake age
- Weighting towards strength of preference: quadratic voting, conviction voting, time-lock voting
- Minimizing voter friction: delegation (liquid democracy), adaptive voting period lengths, adaptive quorum biasing
- Optimizing voter representation with low participation: delegation (liquid democracy), sortition (random-sample voting), holographic consensus
- Optimizing minority protection: secret voting, quiet beginning/ending periods, rage quits
- Combinations: quadratic conviction voting, conviction-weighted delegation, reputation-weighted delegation, etc.
Milestones & Timeline
-
Research – Q1 '21:
- Scope the prescriptive goals of introducing other strategies
- Research and design the best voting systems to achieve these goals
- Begin experimenting with how these voting systems can be achieved using Typescripts, integrations with the database of POKT Arcade signatures, and calls to the POKT blockchain
-
Implementation – Q2 '21:
- Build v1 Typescripts based on the results of Q1
- If finished and adequately tested, implement
The above timeline is based on a standard research and development process, but may need to be accelerated if POKT Arcade begins to be overrun with suspected malicious actors.
How to Test Progress & Measure Results
- Sentiment analysis – voters are generally more confident in the security of the Council
- If we have succeeded, there’ll be no attacks, but we’ll equally have no counterfactuals to prove that there would have been attacks if we hadn’t done anything
Documentation Needed
- How votes are counted, once the new strategies are implemented
Team Needed
- Leader: @JackALaing (Governance Lead)
- Roles Needed: Typescript developers
Related Projects
- RFP-2: Build a Custom Discord Bot to Automate POKT Arcade Quest Verifications: will provide us with a scalable way to link POKT addresses to POKTDAO addresses, for use with a Snapshot strategy that measures POKT addresses