PGOV1 - Evolving Pocket’s Governance: Introducing 3D Governance

Pocket has a category-leading governance model that combines 1-person-1-vote and reputation in a system called “Proof of Participation” that has a perfect gini coefficient of zero. However, the system is not without some legacy challenges in our representation - namely gaps, inertia, and imbalances in representation. The question PNF has been considering is:

How can Pocket iterate on these strong foundations to improve the representation of our governance by solving these three flaws?

Our answer is 3D Governance.

3D governance seeks to evolve Pocket’s governance system by facing challenges in our existing system head-on and turning them into strengths:

  • Noticing gaps in our representation, and evolving the system to be the most representative
  • Seeing the inertia in our voting group, and creating a governance system that is more dynamic and automated
  • Seeing the imbalance in representation across stakeholders, and designing systematic balances in representation

We expand on the challenges and our proposed solutions for each below:

Challenge 1: Gaps in Representation

Pocket’s trophies are good at enfranchising certain stakeholder categories. However, the system forces people into one particular “path” towards earning a vote which is quite prescriptive. It works well for node operators who simply:

  • Stay unjailed for 1 month
  • Process 50k relays
  • Help a fellow node operator
  • Submit an improvement to node docs
  • Upgrade your node to a new protocol version before the upgrade height

However, other stakeholder categories are not recognized well by the trophies:

  • Contributors: There is no path for current contributors to earn a vote, so they are limited to going through the Node or the Community Shepherd paths
  • Community Shepherds: If you don’t have Twitter or have few followers, you are dependent on being able to find errors in official content (which gets harder over time). Worse, these are such a narrow slice of what it means to be a community member as to be almost pointless

In practice this means that certain contributors in our ecosystem have been underrepresented in the DAO. There is something wrong when the following active contributors do not have a vote:

  • PoktNews
  • Liquify (v0 snapshots)
  • Nodefleet (v0 testnet)
  • Ritesh (design)
  • BigBoss (community protocol contributor)
  • Tokikuch (community protocol contributor)
  • AmishBatman (Node Pilot)
  • ethen (SendWallet)
  • msa (Economics)
  • All Community Hub organizers
  • 4 of 6 full-time core protocol developers
  • 33 of 37 current PNI employees

POKT stakeholders who contributed capital to the ecosystem are also not enfranchised because they’re not personally operating nodes. The following funds do not have any votes: Placeholder, 1kx, Arrington Capital, Zee Prime, Coinshares, Mechanism Capital, Tribe Capital, Kucoin Ventures, Maven11, TRGC, EdenBlock, DACM, Decentral Park Capital, Dominance, Rockaway. While we are not advocating for Pocket to pivot to token voting, our ecosystem is diminished by not having these voices and perspectives represented in our DAO.

Solution 1: Realign around 3 Dimensions of Contribution

Rather than endlessly attempting to multiply the number of paths to cover all our stakeholder categories, we think it is better to simply abstract towards three distinct dimensions of contribution in Pocket. In doing so, we would directly enfranchise two stakeholder categories that have been so far underrepresented (Builders and Stakers) and make it easier for new contributions to be recognised in these categories:

Dimension Contribution Understands & Defends
Citizen Actively participate in the community and work to understand and exemplify Pocket’s DNA The vision, values, and culture of Pocket
Builder Actively create value and drive impact for the project The systems of Pocket and how to create value (e.g. technical feasibility, operational excellence, sell/market Pocket)
Staker Actively deploy the POKT token to support the security, performance and/or utility of the network The pragmatic, economic imperatives of the project (e.g. financial sustainability, token economics)

To tie it back to the current system, we would expand the scope of contributions within the system and evolving the current paths into these new dimensions:

  • Community Shepherd → Citizen: less arbitrary community activities (e.g. tweets, memes, and copy editing), more “citizenship tests” that you understand Pocket and actively participate in our community
  • Governor/Contributor → Builder: less governance activities, more recognition of different categories of builder and the things that drive impact
  • App & Node → Staker: broaden the scope to include anyone who stakes POKT on either side of the market and roughly weight votes by stake magnitude

Challenge 2: Inertia in Representation

Our trophy system is also inert – earning a vote takes a long time for stakeholders, as many can attest, and once the vote is earned it is locked in regardless of whether they continue to be stakeholders.

This means the DAO is slow to onboard new voters…

…and over time the DAO is diluted by inactive voters.

This lack of dynamism inhibits the effectiveness of our representation over time.

Solution 2: Enable Dynamism by Automating Representation

We suggest upgrading the technology powering our governance, introducing an automated and responsive Verified Credentials system to enable more dynamism in representation.

Verified Credentials, powered by, would replace the Discord trophies in our current system. This platform enables us to introduce more automation into both onboarding and offboarding of voters:

  • Automated Onboarding: Credentials can be automatically assigned to stakeholders who complete the activities to earn them, integrated directly where these activities are performed - e.g. GitHub, Snapshot, and the Pocket Network blockchain itself
  • Automated Offboarding: We can define and automate triggers that automatically revoke credentials when they are no longer current or active (e.g. unstaked, jailed, etc)

In combination with this, we can evolve voting power from a binary 1-person-1-vote threshold, to a system in which each credential grants fractional voting power until the stakeholder earns a full vote. This means onboarding and offboarding can both be more responsive:

  • Responsive Onboarding: Instead of waiting until a threshold is met to earn a vote, voting power can be gradually earned over time with each credential. This is like having some voting power when one trophy is attained, rather than waiting until all trophies are attained.
  • Responsive Offboarding: Instead of voting power being locked in, we can gradually decay the voting power of inactive stakeholders as they lose their credentials.

Challenge 3: Imbalances in Representation

Treating stakeholders as a monolith, particularly in a 1-person-1-vote distribution as in Pocket’s current system, leads to difficulties calibrating the balance of power between different personas. For example, if it is easier to prove participation as a node operator, or there are simply more node operators, there will be a natural bias within the governance system.

Below is an approximate distribution of current voter representation. Note that these are rough categories with some overlap (e.g. builders who are also node operators). Funds have been highlighted to illustrate our earlier point about the lack of involvement of funds.

Solution 3: Systematise the balance of power

The final piece of this governance upgrade is to balance the power between the 3 new dimensions so that we enfranchise more stakeholders without compromising the safety of the DAO. This balance will further codify our ethos of “assigning governance powers to the most engaged, knowledgeable and experienced members of our Pocket Network community” and avoid us evolving towards plutocracy.

Not only does this make our governance capture-resistant, but we think it better reflects and balances the unique perspectives (see the Understands & Defends column) that each representative group brings. See the last two columns (If Entrenched, If Unrepresented) to understand the risks of not getting the balance right:

Dimension Understands & Defends If Entrenched If Unrepresented
Citizen The Pocket vision, values, and culture Clique, cult Misaligned incentives, Soulless
Builder The Pocket systems that create value (e.g. technical feasibility, operational excellence, Pocket brand & awareness). Technocracy, Never-ending R&D Low-impact or non-viable initiatives, Theoretical circlejerk
Staker The pragmatic, economic imperatives of Pocket (e.g. financial sustainability, token economics) Plutocracy, cash grab Inefficient or expensive initiatives, Waste and Bloat

How we propose to balance these dimensions:

Citizen Builder Staker Total
10% Voting Power 45% Voting Power 45% Voting Power 100% Voting Power
Democratic 1-person-1-vote (binary) Qualified 1-builder-1-vote (gradually earned) Stake-weighted (sqrt) Sum of combined vote
All Citizens get 1 vote each. Builders earn voting power up to a limit, where they each have equal power. Tokens staked for >2 months grant voting power, which is the square root of their stake.

Note that each of the above dimensions will weight their “internal votes” differently, as described in each column, but the 10/45/45 voting power splits will be enforced at the aggregate level. That is, more voters in any one dimension will not increase that dimension’s voting power relative to the other dimensions, but simply dilute the existing members of the dimension.

Justifications used to calibrate the above split:

Dimension Justifications for Higher % Justifications for Lower %
Citizens Since it’s a strict 1p1v, using a voting power >= 10% acts as a margin of error that prevents either Builders/Stakers getting a unilateral 50% majority, which mitigates the risk of miscalibrating the Builder/Staker weightings. Citizens will be our broadest stakeholder class, since it encompasses the Builder & Staker classes, and it will be easier to earn the credentials proving citizenship. Since it will be easier, there is a risk of making it too easy, and this coupled with 1p1v risks the DAO being raided if the % voting power is too high.
Builders This class is most closely aligned to the original vision of “proof of participation” and reinforces our desire to be a builder-led community. As we bootstrap the DAO, this stakeholder class will be relatively small compared to the others, which means granting too much voting power to the class risks giving majority power to a small set of stakeholders.
Stakers This is the main category where network actors, such as node and gateway operators, will be enfranchised. This category also has the potential to be the most secure, since it contains a large number of stakeholders and it will be expensive to acquire significant stake-weighting and wait 2 months. We plan to square-root the stake size to determine voting power, which will give smaller stakers a more equal vote compared to whales, but nevertheless granting too much power to this category risks straying too far from the original governance vision and towards a plutocracy.

We can discuss (and probably nitpick) about the above percentages, but please note that the system can be calibrated over time through meta-governance. For example, as the Builder class scales, we may find it safer to increase the % from 40% and bring the DAO closer to a builder-led vision. Alternatively, if we find that all dimensions are accurately and safely calibrated, we may decide that it makes sense to bring them all into equal power to balance their perspectives. What we are optimizing for in the beginning is a safe and effective transition to the new system.

The system also requires some additional safety mechanisms that we would propose including:

  • Proof of Citizenship – this means a Builder or Staker can only vote if they are also a Citizen, meaning they understand our DNA and they’re active in our community (i.e. you can’t just buy your way into governance).
  • Proof of Personhood (Gitcoin Passport) – this prevents sybil attacks on our governance. All of the proposed weightings require anti-sybil protection: 1-person-1-vote for obvious reasons, 1-builder-1-vote to prevent builders creating sock puppets once they reach the cap, sqrt of stake-weight to prevent stakers bypassing the sqrt by distributing horizontally across multiple voter identities.

Entering a New Dimension

This post serves as an introduction and is therefore missing finer details which will follow in a subsequent proposal regarding specific credentials, how votes will be weighted, how this will be implemented technically and what is the meta-governance process for evolving the system.

How to Participate

At this stage, we are welcoming feedback on the above. In particular:

  • Ideas about specific activities that should be recognized in each of the 3 dimensions
  • Concerns about the safety of the envisioned power weightings
  • Questions about how the system works so we can make sure that participation and communication on this evolution is clear to new and existing members of our community
  • Ways you can or want to help

Next Steps

We have begun collaborating with implementation partners and scoping out the technical implementation details of the above system. It is important to us to keep momentum towards having the system evolve but we are conscious of wanting to make sure there is time for open discussion. So next steps we anticipate are:

  • Keeping this discussion open for up to 2 weeks to allow community discussion
  • Introduction of technical specifications for each component of the system within the next 2 weeks, supporting further discussion and calibration
  • The introduction of a proposal for voting on to evolve the system once technical specifications are provided
  • The provision of an implementation plan with timings to be provided at the same time as the proposal

It is our intention that the implementation runs side by side with the discussion and we are already working on defining an MVP of the system which would be launched within 2 weeks of a vote approving these changes.

It is truly exciting to think about evolving our system to better represent the people who drive impact in Pocket every day. We look forward to your feedback and input to help make this new system the best it can be.


This is such a huge step forward for Pocket and a giant fuckin’ leap for DAO-kind!

I am all for it and eager to see the proposal soon!


One of the main reasons I joined Pocket was because of our governance model and its resistance to capture. Unstoppable means decentralised governance and I think you’d be surprised how many of your favourite DAOs are completely captured and involved in decentralisation theatre. What Pocket has already is truly special.

I think the evolution outlined here keeps the core governance ideals of capture resistance and self governance by the most knowledgeable and engaged, but enfranchises those people who have so far been underrepresented.

It’s also right to acknowledge people who have provided input and feedback around this new architecture. Please don’t take their involvement as strict endorsement of the outline from Jack… they provided feedback on earlier designs and demonstrate the cross section of people looking at, inspired by or contributing to our governance in some way:

Phil H
Sanket and Ayyan at
Jeremy & Zak at
Fabien at


Great post @JackALaing!

I particularly liked this bit. With a dimension like “Staker” it would be easy for someone who isn’t actually active in the ecosystem to have significant voting power… but with requiring them to be a Citizen they would have also have public participation.

3 Questions:

  1. Regarding staking, does this mean providers would be able to use their customer's stake to add to their vote weight?

  2. If a user is using a provider, do they get to claim their staking vote? If so, how do you see a voter claiming their stake when it is with a provider?

  3. Will anyone be able to see the weight of someone's vote, especially if they are part of multiple dimensions?

Great direction @JackALaing :+1: I’m excited to see where this goes.


The specifications of each dimension are still being ironed out, and we’ll be looking to gather more feedback on the details when we publish them, but I can provide a general answer that should be directionally correct.

On the subject of whether operators/owners will get the voting weight associated with their stake, I believe the answer lies in non-custodial staking. If the owner of the tokens uses non-custodial staking, they’ll be able to verify on-chain that the stake belongs to them. If the owner has given up custody to an operator, the operator would be able to use the stake for votes, and the owner would have no way to prove on-chain that the stake belongs to them. I believe this is a reasonable trade-off and should diminish in relevance over time as non-custodial staking becomes the majority (which I expect to happen in the long run).

As for visibility of voting power, I expect this to be transparent and the only constraint will be in the tooling. Snapshot is built already to show weights per voter but if we want to be able to view a directory of voters and their weights this would have to be built.


Great proposal, as always I look forward to see the specification, specifically the stake weighting mechanism (this is a delicate thing) and citizenship claiming.
The general idea seems solid, I like the weighting based on roles and the base requirement of being a citizen (enforcing the participation requirement that makes the Pocket DAO unique).

I have some questions:

  • Have you designed a quorum system around this? Could a vote be passed by an army of citizens only? (i.e. civil attacks)
  • It seems that pool participants will not be able to prove their stake, this is OK as long as the node/app staking threshold is low enough (like today). However, if the POKT price goes up getting the required POKT to stake a full node can become prohibitive to many small participants (like in 2022). Have you any idea on how to deal with this?

Great questions as always ser.

On anti-sybil, Gitcoin passport ensures (anonymous) personhood and each voter will need to complete the core requirements of becoming a citizen by completing some quests. The barrier to becoming a citizen will be much lower than the quests in the previous system, but is still quite high for anyone trying to spoof it.

The Citizen house is true 1p1v but has only 10% of the total voting weight. More citizens means the individual weight of each citizens vote is reduced (10%/n). We don’t need a quorum for the reason you have described, but whatwe do need and are still working on are the parameters and metagovernance for weighting across all the houses (for example, if something fails in 2 houses but still has >50% of the vote is it passed?)

It’s a great question and I hope it’s ok to say we will update on this within 1 week when we return with the technical specification for Stakers.


Great proposal well thought out…

1 Like

Thank you for this initiative. Given the importance of this subject to the DAO’s future, let’s have a well-advertised community call about it . Presentation followed by a Q & A. Invite Qs in advance too.

1 Like

As Shane, Ramiro and others mention - I also like and support the idea of voters having to demonstrate a basic knowledge of Pocket and community engagement to claim voting rights in other categories.

As Ramiro notes, I do think this can have negative consequences for pools. There could be a vote to white list pools, or automatically allow any pool with ~10M+ to have an API connecting databases of user accounts to the staker system so that any user of a pool is not penalised (or the pools themselves). This could be followed by attestations of funds on a periodic basis. I see this issue is being brainstormed and welcome other approaches to fairly give pool members voting rights.

Also - is there a way to mask the staking weight? Is it an issue that this would publicly show a rough amount of POKT each staker has by the amount of POKT held for staking voting? I appreciate this is already partially viewable on chain, but anon Pocket accounts are harder to identify than those linked to citizens. Would this make a target list of whales for a malicious actor?


GRIP’s Infographic to assist in explaining 3D Governance and PNF’s vision for the future of Pocket Governance:


Added the prefix PGOV so that topics relating to the Pocket Governance upgrade can be found and followed in order


Great ideas and great presentation!

I have 2 questions.

Would one person move from a Dimension to another ? Or would it be possible to cumulate roles and associated voting power ?

Also I’d like to frame the quorum question differently: would a single Staker (or Builder) be sufficient to counterbalance a full assembly of Citizens?


Great questions, thankyou.

To vote you need to be a Citizen. Citizenship carries 10% of total voting power.
Citizen’s can also accumulate voting weight in the Builder and Staker Houses, both of which have 45% of total power (or 90% combined). The idea of 3D governance is that you accumulate voting power across the 3 dimensions, not that you “move” across dimensions :grinning:

The houses have their individual power limits which acts as the counterbalance. Whether there are 10 citizens or 100 citizens the total voting power does not go above 10%, and Staking will have 45% voting power whether it is with 10 staked POKT or 10M staked POKT


Thanks for your answers, I’m looking forward to reading the specs.
I’ve been thinking about valuable activities, but rather the fact that they couldn’t all be listed, and also that the same activity wouldn’t have the same value for Pocket over time, and that each should be accompanied by a way to measure/validate it in order to get automation…
At the end, I’ve been wondering if you would consider having a kind of lite voting process to value activities in a similar way some web3 tools allocate crownfunds to projects? (in a way that for one user, any activity could qualify to receive a certain amount of validation/endorsement for onboarding, plus in a way that empowers the community with small but useful tasks.)


We are very much aligned with this. It is our intention to do both:

  • List the set of “impact” activities that bring with them some governance powers
  • Begin a experiment around “bottom-up” contributions that allows emergent contributions that should be rewarded to be vouched in over time.

Note: the experiment listed above is planned for after the initial MVP launch of the new governance system. How it looks and evolves would sit under the “metagovernance” remit that will be outline in a spec to the DAO in a few weeks