PIP-1: Upgrade Governance to Improve Voter UX

Attributes

Summary

Upgrading our governance tooling and processes to fully adopt POKT Arcade, a series of gamified community onboarding quests, and Snapshot, an off-chain voting tool, will drastically improve the UX of becoming a voter and voting on proposals.

Abstract

The current UX of vote acquisition and voting on proposals is far too frictioned: you need to deposit POKT to the DAO treasury using the CLI, use a tx memo to link your Aragon and Discord accounts to your Pocket account, this deposit then needs to be verified manually by moderators (the plan was to eventually peer-review using Aragon Agreements), and proposing/voting itself is then at the mercy of gas costs.

We have designed an improved process that fully embraces POKT Arcade, for more scalable distribution of votes and more efficient (off-chain) voting.

Motivation

  • Minimize Friction of Voting: the only determinant of voter engagement should be voters’ interest in issues
  • Simplify Vote Acquisition: to maximize stakeholder representation, acquiring a vote should be costless for those who have proven their stakeholder status (by completing POKT Arcade quests)

Specification

New DAO Onboarding Flow

  1. When you join the Discord server, you’ll choose some topics that are of interest to you
  2. If you choose Node Running, App Infra, Community, or DAO/Governance, you will automatically enter the Arcade, revealing channels with your first set of quests
  3. Each time you complete a quest, you will report the evidence in #achievement-unlocked and earn a new role

    CleanShot 2020-11-23 at 22.19.05@2x
  4. Once you’ve achieved enough of the quest role set, you can level up by writing !become-{newrole} in #achievement-unlocked
  5. Once you reach the 3rd level on any of the 4 paths, you will qualify for a vote in the DAO; you can claim the Qualified role by writing !qualify in #claim-vote
  6. You will also need to link your BrightID to Discord, to prove you are a unique human being and prevent Sybil attacks on our governance
  7. Once you have proven your community participation, by earning the Qualified role, and your unique humanity, by earning the Verified role, you can claim a vote by writing !claim-vote in the #claim-vote channel
  8. You are now officially a Voter! All that’s left is to use the Collab.Land bot to claim an airdrop of your voting token, which you can use to submit gasless votes in Snapshot!
    CleanShot 2020-11-23 at 22.24.21@2x
  9. Proposals will be submitted to Discourse and all new posts/replies will be automatically cross-posted to Discord to ensure maximal engagement in debates
  10. When proposals are submitted to Snapshot for voting, notifications will be automatically posted to the #proposals channel, ensuring you never miss a vote

Gasless voting is a massive improvement to our governance UX; nowhere in the above flow do you need to own any cryptocurrency, other than the POKT you may need in the course of completing quests

Constitutional Amendments

Rationale

Simplify Vote Acquisition

  • Arcade minimizes cost of vote acquisition: Unlike the Governance Stake system, playing POKT Arcade and receiving a voting token airdrop costs nothing to community members, other than the time spent reporting on the Arcade quests and POKT they may need to use the network. As a bonus, it all takes place in our Discord metaverse, making it immediately accessible to all newcomers.
  • Arcade is the best filter for engaged and knowledgeable voters: Making POKT Arcade the only way to get a vote ensures that our first voters are our most engaged and knowledgeable stakeholders. It will also serve as an additional incentive to play POKT Arcade, which has been designed to onboard community members.
  • Governance Stake is now redundant: The Governance Stake was adopted to ensure Voters have skin in the game. However, by legitimately participating in the network, and proving this through completion of POKT Arcade quests, Voters would have enough skin in the game. The Governance Stake is arguably therefore redundant in this sense.
  • Portable Voting Rights are more aligned with our Lean Governance strategy: By using generic non-transferable tokens to represent voting rights, rather than specific smart contracts, our governance stack has more optionality. Using alternative governance tools simply requires connecting the same wallets to those tools. The voting signal is also decoupled from on-chain execution, meaning we can apply on-chain execution in any system independent of the chain (xDAI) used for the voting tokens, giving the DAO more agency to enact its will on any system.

Minimize Friction of Voting

Update voting details

  • Improves voting UX: Using Snapshot for proposals/voting costs nothing.
  • Flexible mechanism design is more aligned with our Lean Governance strategy: Snapshot-style architectures have less overhead/complexity, making them much easier to experiment with. For Snapshot, updating our voting policies is as simple as writing a new “strategy”, no complex smart contract upgrades required.
  • Moving with industry standards means we’ll have access to cutting-edge governance technologies: Aragon v2 represents a full commitment to this new design standard, which means the best future innovations are likely to require adoption of the new standard. For example, since pivoting to this new strategy a few weeks ago, a similar off-chain voting tool has already emerged at ETHonline (Tokenlog), which would enable us to use our existing voting tokens to prioritize feature/bug backlogs. We are already exploring how we might integrate this as a Discourse plugin.
  • Signaling vs Executive Vote distinction now redundant: Since we’re using Snapshot + Aragon Agreements, we can remove the distinction of signaling vs executive votes. All votes are now signaling votes until the result of the vote (Governance Transaction) is staked on to be submitted on-chain.
  • Remove aspirational designs: For now we should remove reference to anything that is not currently available or designed for the current tooling. Snapshot’s flexibility means we should take the time to reevaluate the optimal voting mechanisms for different proposal categories, since implementing these mechanisms will involve less overhead.

Update action submission requirements

  • The constitution no longer needs to be signed using the new version of Aragon Agreements.
  • With the full adoption of off-chain signalling, submission of proposals is decoupled from submission of on-chain actions. All votes are now signaling votes until the result of the vote (Governance Transaction) is staked on to be submitted on-chain.

Update Arbitration to account for off-chain votes

  • No actions can be submitted on-chain (yet)

Sunset Champion System

  • Champion system is now redundant (and undermines the neutrality of POKT Arcade): POKT Arcade is designed to be fair to all stakeholders who engage with Pocket Network, whereas the champion system was a stopgap to allow for trusted community members to be onboarded. Now that POKT Arcade will qualify stakeholders, we don’t need the Champion system anymore, and it is in fact detrimental to the neutrality we are trying to establish.

Remove Bootstrap Measures

  • With the PIP-1 changes, none of the bootstrap measures are relevant anymore.

Dissenting Opinions

Reliance on Aragon Agreements for On-Chain Enforcement

Since publishing this proposal, the likelihood of Aragon Agreements and the associated Snapshot plugin being finished has become less certain due to the resignation of the team (Aragon One) who were building it (though I am told in the Aragon Discord that these products will be finished by the Vocdoni team). This means there is a less certain path to disintermediating the Foundation from the executive function (submitting the results of votes on-chain). However, all of the off-chain signaling tooling is still available, our governance as it stands will be no different from existing multi-sig systems used in most Ethereum projects, and I’m confident we can find a substitute to Aragon Agreements (e.g. Kleros) if necessary. I don’t believe this should stop us from proceeding with using Snapshot and CollabLand.

POKT Arcade in Adversarial Environments

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.

RFP-1 aims to research and build custom Snapshot strategies that would help address this potential weakness as we scale. I don’t see this being a problem at this stage in our project’s life.

Implementation

Once all of the current voters have weighed in on this proposal, we’ll airdrop voting tokens to them and vote on this proposal using the new method described above. This will give them direct experience of using the new flow, ensuring their decision is informed by experience.

If the voters approve these amendments, we’ll merge the above commits with the master branch of the constitution and add a new version count per “Tracking Constitutional Amendments”. We’ll then proceed with fully implementing POKT Arcade and Snapshot.

We are also currently working on a number of refinements that will enhance the constitution’s clarity and robustness as a legal agreement. These amendments are independent of the changes outlined in this proposal, so there is no reason for them to hold up the implementation of this governance upgrade.

Potential for Future Developments

Copyright

Copyright and related rights waived via CC0.

4 Likes

The level of thought that went into this proposal and its inherent reflection of the principles underpinned in Pocket’s constitution, in particular sustainable decentralisation and user-centricity, gives me a lot of hope and excitement for Pocket’s future. Moving even further away from coin voting is to be welcomed. Consequently, I believe that this governance proposal is a very smart and welcome one.

Looking at the POKT arcade app and node paths, any serious node or app should be able to claim their vote relatively easily. There is a higher hurdle for community members, but still, nothing that is too insurmountable. If you care enough, you can get a vote, and that is one of the most important parts of this proposal IMO. It will be interesting to see the types of POKT Arcade paths expand as the platform grows in importance and its stakeholder base becomes more diverse as a result.

The one part of the proposal that I’m not so clear on is the proposed removal of the DAO’s ability to remove voters. Can you please unpack the following sentence some more?

The collateral required to initiate Governance Transactions (using Aragon Agreements) should be sufficient incentive to prevent attempts to knowingly subvert the Constitution

1 Like

I’ve just realized that the higher levels won’t be visible to people who haven’t leveled up yet, so in the interest of fully understanding what will be required to become a voter in the different paths, here are the quests that community members will need to complete to become Qualified.

We were very careful to calibrate the requirements so that serious nodes or developers will naturally qualify for a vote within the course of using the network, but still encouraging community participation:

  • Nodes who perform well will achieve 2/5 of the required quests in Level 2 of the node path (below) and will need to make up the rest by contributing to tooling/documentation, helping other nodes, and/or helping with beta testing new protocol versions.
  • Developers who submit a lot of relays, but who are not directly integrated with the network (e.g. using Pocket Gateway), will need to make at least one community contribution before qualifying.

Node Path

3/3 of the following quests

Then 5/7 of the following quests

Developer Path

1/3 of the following quests

Then 5/10 of the following quests

Community Path

6/8 of the following quests

Then 4/6 of the following quests

A Note on Future Iterations of POKT Arcade

If this proposal is approved and POKT Arcade becomes the onboarding/filtering mechanism for DAO voters, it will naturally then fall within the purview of the DAO. If concerns arise about the efficacy of specific quests (e.g. too easy, too hard, biased), the DAO will be able to make these changes by approving PIPs.

There are more details here about how Aragon Agreements will work with Snapshot.

Essentially, any voting that takes place in Snapshot is not guaranteed to execute, it is simply a signal. The process for actually executing a decision depends on whether the decision involves an Ethereum transaction, a Pocket Network transaction, or neither:

  • Ethereum transaction: to execute the transaction, someone will need to press the “Submit on-chain” button and stake collateral on the legitimacy of the decision. There will then be a delay during which anyone else can stake against the transaction; if this happens, Aragon Court will rule on the dispute with reference to the Pocket DAO Constitution. This means, even if there are a malicious subset of voters, they shouldn’t be able to execute decisions without risking losing their collateral (hence “sufficient incentive”).
  • No transaction: The Pocket Network Foundation will be responsible for executing off-chain decisions and will therefore rule on any disputes that community members raise in the forums or Discord server. I’m working on another PIP that will bring more clarity to this process.
  • Pocket Network transaction: Until we have a direct cross-chain integration, this process will be the same as the case in which there is no transaction. We’ll work towards a direct cross-chain integration that will eventually enable us to remove the Foundation from the equation and use the same process as for Ethereum transactions.

Thank you Jack for the great thoughts that have gone into this proposal. It is crucial to make sure that voters are not mere token holders but individuals/entities who understand Pocket and are committed to its growth. The proposal achieves this to some extend. Nevertheless, I believe there is still some room for improvement. I am noting down some of the questions I have below:

  1. What are the implications for the existing governance members? What happens to the stake of existing voters?
    1a. Is the stake returned?
    1b. Do they have to go through Arcade game to keep their vote?
    1c. What is the skin in the game for current voters when the stake is returned?

  2. Regrading node running using third-party services: Some governance members have already made a significant contribution to the Pocket network and plan to do so. But they are not too technically able to follow the node, developer, or community path and might need to revert to third-party node services to participate in DAO. How are such parties integrated into the new set up? Overall, the assumption is that contribution to Pocket Network is only possible on a technical level through the required activities laid out for node, developer, and community paths. Is this the right assumption? How is bringing more widely used protocols, applications, and other technical partners and coordinating a partnership with Pocket Network less important than contributing at the technical & community level? (This is a point relevant for new members also who are capable to contribute at non-technical & community levels)

  3. In the current setup, there is no mechanism to punish the malicious actors. With a one time contribution, I am becoming a voter for perpetuity. How will this ensure skin in the game? One time contribution of something, in this case, my time, do not create a skin in the game unless I can also lose what I have gained by spending my time. In the case of token stakes, there is always a chance that I might get my stakes burned, and I have an incentive not to support malicious activity. But if I get a vote for perpetuity with no mechanism to lose that right, I can basically do whatever I want in the network.

  4. If your argument against the above statement is Aragon agreements, how can you make sure the malicious voter is not challenging legitimate proposals and slowing down the development? How can you make sure that malicious cartels are not continuously trying to subvert the network and the network merely being saved due to the diligence of an honest voter who challenges this (this also leads to time waste and could happen over & over again)?

  5. Lastly what mechanism is in place to make sure only voters can signal on the proposals in Discord? How can one differentiate between the signals made by a Discord member and a voter?

Existing voters are grandfathered in. These community members were chosen as the seed because they have already made significant commitments to Pocket, so they already have skin in the game in that sense. Voters who submitted a POKT governance stake to the DAO treasury will have it returned.

1 Like

The community path is not very technical at all. The most technical quests in that path are swapping the endpoints on your wallet and creating educational content.

This is a fair point. We do have quests at the highest level of the community path which rewards community members for onboarding new nodes or applications (developers). We decided against including biz dev quests at the lower levels because we were worried about incentivizing spam against other projects; we don’t want to encourage low-value efforts to shill Pocket in other communities, because this will degrade our reputation and undermine genuine biz dev efforts.

All this said, if the quests do need recalibrating, this is all possible either now or at any time in the future as described here.

Even if we have slight disagreements on some of the quests, I would advocate for us still approving this MVP, measuring how effective it is, and then recalibrating based on that evidence.

One thing I forgot to mention is that the person who stakes on challenging a transaction can also lose their stake if the Court rules in favor of the transaction. So in addition to a disincentive to submit illegitimate transactions, there is also a disincentive to challenge legitimate transactions.

1 Like

This emphasis on skin in the game and punishing actors, in my opinion, misses the forest for the trees.

Firstly, it ignores the natural incentive alignment we have already designed at the protocol level. Pocket’s block reward is quite unique in that the revenue of nodes is directly proportional to usage of the network by customers (apps/developers). This tightly aligns the two sides of our market and means nodes are directly incentivized to always maximize the success of Pocket Network as an unstoppable infrastructure service. And even if a transaction passes the Court’s filter and is submitted to Pocket Core, the nodes serve as a last line of defense with the ability to refuse transactions, including those which would activate protocol upgrades or change parameters.

There is also the risk to consider at the other end of the spectrum, in the scenario that we do allow for burning voters. If these malicious cartels that you speak of do manage to gain a majority, what’s to stop them from burning voters who disagree with them? In this case, it’s the Aragon Court, which doesn’t care if your opinion is the majority, but whether the decision complies with the Agreement (our Constitution). If we write into the Constitution that voters can be burned in some cases, we’re making Aragon Court rulings a much more high-stakes affair; there is a non-zero risk that a malicious majority could bend the words in their favor and solidify their control. It’s also easier to define objective measures for whether a given payment, protocol upgrade, or parameter change is legitimate, than to try and define the threshold at which bad behavior should result in removal from the DAO. To summarize these points, there are two alternative scenarios I see:

  1. We allow the DAO to burn voters for bad behavior. This leaves open the risk that malicious majorities will be able to establish themselves permanently by removing opposition.
  2. We remove that power from the DAO. In the case that there’s a malicious majority, their political power carries less risk. The decisions that they might try to push through are less subjective, less permanent, and more easily challengeable by an honest minority. The minority just has to maintain this check on their power until the bad actors run out of collateral (the honest minority will never lose collateral in challenges) or enough new honest actors join the DAO to improve the voting demographic.

I’m not opposed to exploring alternative punishment mechanisms, but I think at this early stage we shouldn’t be establishing such a risky one. We do have the means to get creative with Snapshot strategies, which allows us to blacklist token addresses from voting. But when we are thinking about solutions, I would encourage us to try and learn from the governance of nation states, because the purpose of POKT Arcade is in a sense to validate the citizenship of a POKT community member. In the US, criminals lose their voting rights while incarcerated, but (in most states) have their voting rights reinstated after. It is actually unconstitutional for US citizens to be banished (analogous to burning voting tokens in our case).

No voting takes place in Discord. Community members who manage to gain all of the required roles in Discord, by completing quests, leveling up, and verifying with BrightID, will gain a Voter role which entitles them to an airdrop of a single non-transferable voting token. They will then use this voting token to signal in Snapshot votes.

Yes, looking at the community quests in detail, I am convinced they are not too technical rather it requires close engagement with the Pocket community and its activities. Nevertheless, I found some of the quests too easy (tweets & shares, emoji (wondering about the tangible value here)). But it’s a good thing that changes to quests can be made through future PIPs as more evidence of what really matters emerges.

I couldn’t find the quest related to onboarding new nodes or applications though. Which one is this? On this point, I feel there should be a way to acknowledge exceptional contributions in terms of business development. I completely agree with you that it should not be in the lower levels, and this should not be an incentive to bring scammy relationships to the network.

It’s not about whether individual quests are too easy but whether the sum of the quests required to obtain a vote are too easy. Would you say the combined 6/8 followed by 4/6 quests are too easy?

1 Like

These quests are in the higher level, beyond the threshold for qualifying for a vote.

Quests are retroactive, so if someone completes a quest before they get to that level they will still be able to claim it eventually.

However it’s true that completing these quests wouldn’t contribute to qualification for a vote.

1 Like

Thanks for putting this together @JackALaing.

POKT node runners who use a third-party hosting service like Skillz would be unable to participate in the DAO via the POKT Arcade’s node path. They would need to either host their own node or go through the community path.

Wouldn’t 3rd party providers be able to provide the information needed to complete these tasks for individuals? Feels like those who are participating, but aren’t running the nodes themselves yet still understand the protocol should be considered. While this isn’t necessarily contemplated in the current quests, there’s no way of stopping it if a node provider wants to provide the information for someone paying them to run nodes. FWIW I don’t think this is an issue - a node provider adds an additional layer of verification for the individual completing the quest as well.

@Rajeevan_Blockwall to your questions, we expect this game to be calibrated over time. We want to be sure that everyone who’s capable of contributing to Pocket has a path to claiming a vote.

1 Like

Sure there is. We can ping a node’s service URL and confirm whether or not they’re actually self-hosting it. If you ping a Skillz node’s service URL, it returns a Skillz domain.

If they’re not running the node themselves but we still allow them to go through the node path, there is nothing to distinguish between hosted-node-runners who understand the protocol and those who do not. I don’t think it’s desirable at all that people who are running their own nodes would be treated the same as those who are paying someone else to run it for them (and I say this as someone who is running all of his nodes through Skillz). The purpose of the node path is after all to prove that you understand how to run a node, not that you understand Pocket more broadly.

Makes a lot of sense! Snapshot is being used across many DeFi protocols for governance and is very user-friendly. Less friction means more involvement.

All good on my front.

1 Like

I think the differentiation has to be more than just a node runner or a third party node runner. Which path creates more decentralization & service availability for Pocket? My guess is that self node runners creates more decentralization, but what about availability - i do not know that. Or can running my nodes through a third party create same/more decentralization for the network? If it is the case, we should not be discriminating between the two. Especially, running nodes through third parties can bring more relay nodes to Pocket creating a better service. I believe the economic advantage of running nodes myself will be an incentive for me to run nodes, not to mention the veto-like power I get on governance updates. Both of this combined could be a good incentive for someone to run the nodes themselves.

We want to incentivize more sovereign node runners because this enhances the decentralization (and thus resilience) of the network. If one hosted provider’s backend goes down, this will be less impactful on service the more independent node runners we have. Conversely, there is a good point about not letting that goal sacrifice the average quality of nodes and we’re always thinking about ways to effectively manage that balance.

However, all of this is (in my opinion) unrelated to the question of governance. We already have plenty of incentives for people to run nodes (either hosted or self-hosted) and people will self-select based on their own preferences. What we should be optimizing for in this case is the knowledge and engagement of people making the decisions. And it is an indisputable fact that self-hosted node runners are more knowledgeable and engaged when it comes to matters of running a node. You might argue that a non-self-hosted runner can still be knowledgeable/engaged in other ways, but that’s what the community path tries to capture.

1 Like

Thank you for this very thoughtful and thorough proposal @JackALaing. In general, I support it conceptually.

I have a number of questions and suggestions related to the new process’s execution.

Here are my first two “meta”-comments.

1 - Separate Vote Acquisition from Voting

I feel this info would be easier to process if it was separated into two proposals, one for vote acquisition and one for voting. For example, acquiring votes via Arcade participation is about clear enough for me to support with a “Yes” vote.

I have a number of questions related to voting, particularly about Snapshot, Aragon Agreements, the “standard” referenced in the context of Aragon v2, as well as the voting implementation process. These questions would cause me to withhold my “yes” vote, until they are answered or this was split into two proposals.

Splitting them would also make it easier to submit more detailed feedback. Breaking this proposal into two could help move things along incrementally. In my experience, incremental progress is a powerful deadlock breaker and helps build momentum.

2 - Less is More

I’d suggest splitting the implementation details into an appendix. While I agree they are necessary, including them in the main body makes it difficult for me to follow the concepts.

Also, bi-directional linking between Discourse and Discord feels overly complex, if that’s what is being proposed. I say this speaking from experience, having seen attempts to bridge/mirror communication channels.

In my ideal world, comments and conversations, i.e. inputs, would be limited to Discourse. I’d be OK seeing these updates posted to a read-only Discord channel.

Again, thanks for the hard work here. I’m feeling excited to seeing where this leads!

Just to be clear, are you proposing I move the Specification section to an appendix, or are there more details that you think should be moved too?

No, bi-directional links is not the intention.

New Snapshot proposals will be sent to the proposals Discord channel as notifications, using the CollabLand bot. I highlighted this point because it solves a common issue people have with other DAOs, that they’re not always sure when a vote is happening.

This will simply be a one-way notification stream to maximize engagement with proposal discussions/votes. It will work the same way that the Discourse notifications work today. To make this clearer, I have merged all proposal notification streams into a single #proposals channel and made it a read-only announcements channel. Thanks for the suggestion!