PIP-37: Credentializing Reputation within the Existing DAO System [CREDS]

Thank you, @aos_bs, for jumping in. I’d like to briefly address one of your concerns. As mentioned by @Dermot, the new system is modular, which means we can swap out any of the components and third-party services at any given time. For example, if the community ever decides to move away from GitCoin Passport for identity checks, we can use any of the other available plugins provided by Snapshot or develop our own custom solution.

It is still only individuals that get a vote. Even in the staker house all voting power is tied to an individual that controls such gateway / nodes / liquidity provider stake.

It’s really appreciated. Please take my pushback as a healthy part of this open discourse.

1 Like

Thanks again @Dermot, and I also appreciate your pushback and viewpoints on this. I agree this is healthy and is an example of our existing system working :wink:

This is an example of the complexity I can’t seem to grasp. Why would someone want a vote worth less than all the other votes? Expicially someone running a gateway / nodes / liquidity pool?

The creds system gives voting power to individuals who provide impact to the POKT ecosystem. That power that can be earned as a builder or staker

Only one person can represent a gateway’s voting power, and similarly only one person can represent the voting power attributable to a staked node / LP stake or GitHub PR, or any other approved form of impact.

Can you please explain more about what you mean by having a vote less than other votes? I don’t understand the point you’re making so clearly I am missing something

1 Like


Please join us for a round table community discussion on this proposal at the ecosystem call on 4/24/24:

We’ll be facilitating a final discussion on CREDS in real time to answer any outstanding questions about the proposal.


Hey all, it’s a bit unfortunate the final vote went up when I had a pre-planned vacation. I hope you’ll forgive me for tuning back in at this late stage and sharing a few thoughts before the vote concludes.

First, apologies again that our approach to this proposal and the way it has been laid out over time has been unhelpful. In hindsight we could have had people vote on each of the specifications individually as we went along. It seems the burning countdown of a vote has inspired people to dig in to the key topics and that is good food-for-thought regardless of what happens next.

And for those that have, thank you for calling out your objections publicly here in the forum and engaging in the debate. Having fewer contentious debates than we did in the past is great, but the lack of healthy conflict has actually been a problem in the DAO imo so it’s good to see it returning. If you have voted against, or plan to, please share your reasoning here publicly so we can understand what the objections are and ultimately align on how to make necessary improvements to the current system.

That last part is important, because the challenges outlined in the forum post from last August will still be there unless people vote for this. The original governance system envisioned trophies to be verified credentials, the thing we seek to automate here. A discord selfie as proof of humanity is elegant and simple, until you realise it excludes heart and soul contributors like PoktNews who are exercising a right a privacy that I think most people here believe in (which Gitcoin Passport solves). We are removing paths that reflected a historical set of personas in POKT, and updating so everyone has the same ability to earn governance no matter what hat or persona fits them best in future. And we are keeping our core 1P1V system but starting small experiments with the use of Stake in governance. In sum I know this can feel like a big change, particularly when it’s something as critical as the rules we all play by. But my ask is for you to consider whether in isolation any one of those changes is much more than a simple evolution on what we already have today.

Sorry it’s been a less than perfect process to this point… I hope it doesn’t deter you from voting Approve and helping us take a big step forward now. But whether it’s now (please!) or later I’m sure we’ll soon have a tech enabled governance system that is as big a flex as the protocol :muscle:


A couple of people asked my opinion, and so I am just copypasting into here for posterity’s sake. As of now, I will vote yes.

  • I caution us of misattributing the existing system for lack of new voter accreditation. If this were the case, then we could drastically change the quest system. Lack of participation or new voters doesn’t have to be an indictment of the system, but just be reality. It turns out that the baseline for decentralized governance of a highly specialized and quick moving protocol may be low.
  • I agree w/ a lot of @steve 's point and this proposal does add a concerning amount of complexity. I think we should pay heed to his characterization that this system does add an non-trivial amount of arbitrary weighting and I do salute him sticking up for 1P1V.
  • I am having trouble groking why a bicameral system is a required for success; seems more like a compromise to me. I worry about how prospective members may view this architecture when trying to figure out how/when their vote counts.
  • The existing system was build for different needs. It is inevitable that we change this system and I have trusted the governance specialty of @JackALaing and @b3n even if I don’t always understand/agree with it.

This discourse is filled with good material and I am glad there have been several addendums to the original proposal. That being said, I see value in moving forward and I find the proposal compelling enough to vote yes.


I forgot to follow up on this. Thanks for the clarification @JackALaing, that was my largest objection to the proposal. I still have a few concerns that make me a “no” until they are addressed:

  1. Lack of tracks for non-technical builders - while I understand that there are ways to earn your vote as a non-technical person, the plans to include those personas aren’t included in this sweeping proposal.
  2. Time-based enfranchisement - I don’t believe current or future voters should lose their vote once they receive one or the timelines between involvement should have to be so long that those individuals couldn’t possibly be relevant anymore. I don’t see a reasonable argument that someone like @steve couldn’t contribute as a valuable governor despite not seeking to create PIPs and other proposals. I view governors as a persona in their own right and those people should be empowered to weigh in on key issues without needing to push forward new legislation for the sake of new legislation.

I would have preferred a modular approach to the governance update, but we’re here now and I don’t want to get in the way of the governance overhaul. I could swing to a “yes” if these issues are addressed.


Hey @adam - to address the lack of non-technical builders, i think you’ll find that quick grants and bounties are a great opportunity for non-technical contributors to be involved. If you check the Quick Grants section of the forum you can see the currently open ones, which range from dev-rel like activites (which I agree are technical) to copy editing, analytics, local community hubs and POKT docs (which are not). There are lots of opportunities to contribute, and we’re scoping out a POKT builder ideas page - similar to Optimism, surfacing more opportunities to work on POKT for both technical and non-technical contributors.

A Carve Out for Governors
I agree. These are great ways to be involved and be compensated for work and earn a vote. I’m not sure it would apply to people like me who want to be engaged but don’t necessarily want to go through the process of monetizing work on Pocket (although maybe it makes sense to do so). Given the broad scope of the proposal which lacks this important track, and the fact that we’re going to have some fatigue on the governance topic itself, I’m not comfortable kicking the can on such an important issue.

On a similar note, I think the lack of tracks for us non-technical folks is going to lead to proposal or authorship bloat where voters will create proposals just to get them passed or simply just co-author their voting block with proposals to keep their vote active. The latter will lead to debates about who truly wrote this proposal which is a waste of time.

Quick Grants / Voter Segmentation
Regarding the Quick grants: how much knowledge does a socket/quick grant winner have about the protocol? My gut says it very much depends on the grant itself. If I’m the person doing the website maintenance, I might not know about the economics of the protocol or the technical aspects.

To this point: I haven’t thought through the idea entirely (and it’s probably going to be controversial), but I’d like to see a future where there are voting tracks where eligible voters can delegate votes to individuals who are experts in those tracks (possibly up to some sort of limited threshold of voting power to avoid over-concentration of power). At present, your only option is to abstain from a vote if you don’t know the topic or just follow whoever is arguing the way that makes sense to you on the forum.


Thanks for jumping in here @RichCL.

Pushing back on this proposal has been challenging for me because of precisely what you said above. I also trust and respect the experience that @JackALaing, @b3n, @doctorrobinson, @Dermot, and the rest of the PNF team bring. But what if they were to move on? Would you still vote for this proposal? That’s the question I’ve been asking myself.

Here is an example of the complexity this system adds and why I’m sure your statement above will be true if this proposal passes.

Let’s say we have 100 voters. 51 voted in favor of a proposal, and 49 voted against it. Does the proposal pass?

Under our current system. The simple answer - yes.

Under the new proposed system - who knows? I can’t answer this simple question.

Perhaps someone who is voting for this proposal can answer that question for any undecided voters.


They designed a system that will last after they are gone. If voters want to change the system or amend the constitution at a later date, that won’t be on the architects.

I agree that we are dulling Occam’s Razor w/ this design. However, once we concede to a bicameral system, then I am fine relaxing our assumptions on needing 1P1V.

Furthermore, this seems to reflect the reality that not everyone’s voice should count the same. This is not crazy given the fact that Pocket’s ecosystem represents a technical protocol where different skills sets deliver varying levels of impact. While debatable, I personally find it to be an inconvenient truth.

1 Like

I voted no - for now.

Not because I’m happy with the status quo. On the contrary. Like most everyone else, I support improvements like making the voter base more inclusive & our voting system scalable.

However, since this vote went live on April 18 and just prior to that, Steve, Adam and aos_bs have raised great questions that in my respectful view require further debate.

Pushing this through now (just one day is left for voting), leaves insufficient time to properly consider these questions. And more importantly, it’s too late to make any changes that they may justify.

No downside to a NO vote

There is no downside to applying the brakes (a “no” vote) - only upside - as it will allow time for obviously needed further discussion and for possible amendments. A new vote can be held right after.

The additional time that a “no” vote will buy also will enable us to ensure that more voters know and understand the changes being proposed. This can be achieved, among other things, by a rewrite of this proposal that clearly sets out the issues including those identified at the eleventh hour.

As I write this, the vote is tied at 7-7. Given the importance of changes to our voting system, do we want this proposal to squeak through? With further time for review and debate that engages more voters and allows for possible amendments that allay concerns, a proposal on changes to our voting system is much more likely to find the wide support it ought to have.



I lean toward YES:

  • The proposed system is the interpretation of various community requests.
  • The system is not complex, in the sense of it being obfuscated.
  • Its complexity is the consequence of the community requirements.

What I don’t like:

  • Not all paths to a vote seem obvious (@Jinx 's case) we need o iterate here
  • The approach to this bundle PIP is messy.

And I think that this holds some truth:

But at the same time I don’t want to waste the effort done to this point and enter into an eternal debate around the system itself.
There is no optimal solution to this problem, we must settle at some point.

On the community requests

Through my time in the Pocket ecosystem I heard many times that changes in the voting system were needed. A vast number of reasons were given and many topics were debated, from them I can recall:

  • Giving token holder weight in voting. If someone has a lot of money in Pocket then s/he should have a lot of decision power (plutocracy).
  • The builders should have more voting power because they actually build the protocol, they are the only ones that should decide (technocracy).
  • The voters cannot remain for ever, there are a lot people with voting power that is not invested anymore and do not participate in the community, yet their votes are still valuable (deprecation of voting power).
  • The original members and important community members should have a greater voting power (vesting? leader culture? not sure how to call this ).
  • I should not give up my privacy to earn a vote. Many are in crypto for its privacy premise yet our voting system requires one to be doxed (more privacy).

While I can recall these topics from informal chats, I do not remember a real discussion (in the forum) of any of those (maybe plutocracy), and I’m sure that none of these features ever went to vote.

The PNF took the burden (wrongly or not) of making triage and bundle the most relevant requested changes into a single voting system. This might be wrong, because they decided unilaterally which of them to include, but reallity is that the community never formally discussed and voted over any of them. The PNF is there to do the job that nobody wants to do, they are the stewards of the Pocket Network and its not illogical to think that they would want to create a better system that responds to the community sentiment, whether or not a formal request for any change was made.
I don’t blame them for doing this proposal, on the contrary I thank them for giving this subject a real entity and propose actual actionable changes.

On complexity

I don’t feel that the new voting method is complex or obfuscated, its a rather simple solution to a subset of the community requests.

Using a house based system with per-house weights is not a bad approach. I would inverse the burden of the proof here and ask for a simpler implementation of a system that is able to handle all (implicit) community requests described in the previous point.

On 1-Person-1-Vote

In my opinion there are two aspects around this:

  1. 1-person means that a single human cannot hold more than one voting entity, which is respected (as much as possible) in the current and proposed voting models
  2. 1 vote meaning that any two humans (without any other feature but that of being humans) will have the same vote weight, which is directly incompatible with the community requests.

This problem is the consequence of lack of clear discussion, the PNF concluded that the community wanted a weighted system. This is not a bad conclusion if you have followed the numerous chat conversations, yet many members are now against it.

This is solved with proper discussion. I said it before, community chats are not official sources and any discussion there should not be a valid source for the community sentiment. If you want to be taken seriously, come to the forum, take the time to write a full post and give proper shape to your ideas. Maybe there is some degree of blame in PNF for not ignoring chats, but I chat users are very noisy…

On constitutional change

I think that the changes are not that distruptive, at least in the diff provided by @JackALaing I see that they are only things that need to change for better working of the proposed system.


Thanks for weighing in on this @RawthiL - I’ve always respected your balanced thinking and objectivity - we need that here for sure.

I agree with @zaatar’s comment that you pointed out in your response. I hope that the PNF team would prefer to see this kind of vote pass with more consensus. Given how much time has gone into this, giving it a little more time seems reasonable and rational.

I agree. I don’t want to enter into an eternal debate, either. But with so many people opposed and this being such an important issue, why not give it just a little more time? As @zaatar says, “There is no downside to a NO vote”—it gives us the time necessary to get everyone comfortable with the changes.

I asked for a timeline on when this would go to vote but never got an answer. Then, it went to vote five days ago without warning while I was on vacation. I don’t get paid to to focus on this like the PNF team does - I just wanted to understand it as a community member - I think the other community members who also aren’t able to focus as much time should at least be given the opportunity to understand what they are being asked to vote for.

What is the upside to rushing this vote?

To reverse @zaatar’s question - what is the upside to rushing this vote? We can vote NO now to buy some time and have the discussion that you’ve said was missing.


Thanks @steve for your comments on the forum and on the call

Looking forward to zoning in on what people would like to change with the current proposal and/or to discuss any areas that are unclear or need more debate

But first (!), to correct the record:

@b3n did respond to your request about when the proposal would go to a vote as per

The vote went up on Snapshot about 3 weeks (20 days) after you asked that question after a week of very little activity on the forum


My apologies to @b3n - I missed that. It would be nice to have a “going to vote date” when these proposals go up, just for time budgeting. But again, I did miss that, so it’s on me.


Thanks everyone for your patience on this. Voting NO and taking the extra time to seek alignment on the best path forward was a responsible choice and hopefully we can use that opportunity to find clearer consensus and the legitimacy that comes along with it.

In that spirit, we want to outline the next steps that we would propose to move towards the changes to governance.

Step 1: Discuss representation and our governance identity.

The discussions revealed some concerns about a move away from a strictly 1 person 1 vote system, and having different types of representation such as noderunners (& gateways and liquidity providers) being represented in a staker house, or allowing anons to become DAO voters through the use of Passport.

We think that these legitimate concerns arise from perhaps some misunderstanding about the proposed system. We have no intention to move away from the values POKT’s governance has always had, like being a democratic rather than a plutocratic system, or having direct representation and participation by voters. These values would not be lost in what we were proposing, but taking time to discuss what we want governance at POKT to be, and the values and philosophies behind it, can create a shared understanding around how any system we implement together lives up to those values.

This step would conclude with a vote around a definition of what POKT’s governance identity is so that this change, and any subsequent changes, lives up to these ideals.

Step 2: Discuss weighting and parameters

We heard some concerns around different types of weighting and parameters. This included things such as vote expiry, the weight of a staker house, and intra-house weights such as how much weight supply (nodes, liquidity) might have compared to demand (gateways).

We think that these concerns are reasonable and that the logic of any starting weights or new parameters should be stress tested with full community engagement on them before entering a new system.

This step would conclude with a vote on the inclusion, and starting weight, of any new parameters.

Step 3. Enablement

We heard (mostly) strong support for the technical solution recommended within CREDS, notwithstanding the fact that the way we approached enabling it with the necessary changes to the constitution was clumsy.

Given the support already garnered for our technical solution, and with steps 1 and 2 completed, we think this step would allow us to finalise the outline of the system, the technical details, and provide ample justification for any necessary changes to the constitution.

This step would conclude with a vote on the constitutional changes and upon passing would activate the updated governance system.

We have chosen this path, rather than a rapid implementation of a slimmed down technical solution, so that the important reasons behind the upgrade are not lost.

Given the exciting phase we are in and the opportunity for Shannon to supercharge the ecosystem’s continued growth and participation, we think it would be a misstep to kick the can down the road and, potentially, be faced with making changes when they are forced on us, rather than in preparation for what’s ahead. And ultimately, if the community continues to be unable to find alignment on any changes to governance, we always have the ability to return to a purely technical upgrade.

Our ask now is for feedback and comment on the recommended path forward. It’s really important that you directly share if you disagree with this plan or think it can be improved. Governance is ultimately a consent process and it’s incredibly hard, when our direct participation system gives voters their power to help guide the project, to take silence as anything other than consent.


Thanks for the update @b3n. I like the idea of breaking this into smaller parts with a vote for each part and I think the 3 steps you’ve outlined make sense.


Tagging a few others who have had input to see if they want to add anything!

@RawthiL @Cryptocorn @Jinx @zaatar @RichCL