Correct, and the DAO may not transfer the permissions unless it first amends this clause.
1 Like
@JackALaing, so this is more about strengthing the PNF role? Or making it more challenging to make changes. I’m back to the opinion that this has nothing to do with CREDS, so maybe this should just be removed from the edits and discussed in a future proposal.
The point wasn’t to strengthen PNF’s role but to secure the ACL permissions, which if transferred to another entity would have no protections.
In any case, I’ve edited the PR to remove this clause and update subsequent numbering because this debate is outside the scope of the CREDS upgrade. Thanks for helping tighten things up.
You can see the commit here: CREDS Upgrade Focused by jacklaing · Pull Request #10 · pokt-network/governance · GitHub
1 Like
Sorry for being late to the party. I generally support this initiative, however, I agree with some of the pushback that @steve brings to the table that the implementation could use some improvement. I’ll document my thoughts below:
The Current System
The current system is aged and no longer fit the needs of the network. I can appreciate the comments about the premature ossification arguments of the current system - they were developed years ago and haven’t matured with the project. However, I tend to believe that the Pocket ecosystem (and our governors (myself included)) struggle to rapidly iterate with new PIPs. Instead, we wait and propose major changes to systems that require much back and forth and adjustment and end up wanting to circumvent the PIP process in the name of moving quickly.
To provide a solution or a recommendation rather than just stating the obvious, we may want to move away from sweeping changes to more focused PIPs that incrementally improve our systems. This proposal feels like the former.
Checks and Balances
It appears as though the Foundation is given the right to decide who votes and how much that vote is worth. This appears to be a dangerous thing to delegate. By handing over this as a delegated responsibility (rather than a vote), creates risk of a DAO takeover if the Foundation were to be compromised. Alternatively, a simple Foundation-led change could change the entire voting system in their favor such that the DAO voter base would be unable to remove them and protect the DAO. While the DAO is trustworthy at the moment, I think it could be dangerous to assume that there would never be an attack at that level.
I’d recommend we create checks and balances for voter weighting changes or voter eligibility:
- A time delay for implementation where the DAO could overturn the change suggested by PNF with a simple majority (a veto), or
- All changes to voter weighting changes or voter eligibility are voted on and changes require a large threshold to change (67% or 75%)
For this proposal, I’d be comfortable with some sort of limited-time delegation (60 days for the foundation to make changes (with a veto right).
Time-Based Disenfranchisement
While I appreciate wanting to have an actively engaged voter base, I’m not sure that the threat of disenfranchisement is the best way to keep people engaged. With this proposal, we risk DAO voter turnover, which is antithetical to creating a broader, more diverse voter base.
It’s worth asking the question: if this system were implemented today, how many “Builders” would be eligible to vote (outside of OGs)?
This proposal might have the unintended consequence of creating bloat in the PIP system by encouraging voters at risk of losing a vote to propose popular, yet valueless PIPs to retain their vote. This bloat might have the unintended consequence of discouraging voter participation.
A further concern is a near-term concentration of power. As written today, after 1 year of this proposal, the power dynamic shifts toward the core team (who are building the protocol & running the Foundation). As an example, let’s say that all else is equal (OGs just keep voting, but don’t create any proposals), there are a few PIPs and RPFs, but nothing substantial. When OGs are removed there will be an instantaneous concentration of power back to the Foundation and Grove contributors. This concentration of power could be used to change the project or manufacture even more malicious outcomes.
That said, a nerfed version of this that I could get behind might be a system that allowed engaged voters to retain their “seat” through a voter record (e.g. the DAO voter must vote on 66% or more of all proposals put to a vote).
Elimination of Important Contributor Tracks
I agree with @Jinx, there’s very little carveout for non-technical contributions other than creating PIPs and DAO scholars, undoing a lot of the inclusivity that came from the previous tracks (as antiquated as they were). Building a protocol is more than simple coding, it’s coordination, community, and purpose and I would suggest a system that is inclusive and rewards the hard work of people like @steve and @Jinx who stay engaged and contribute in non-technical ways.
3 Likes
Agreed! This proposal feels like a more sweeping change because it lays the groundwork – in the form of a more robust modular architecture – for us to more easily make incremental improvements to the system. From here on out, we can issue new credentials to enfranchise new voters, use PUPs to adjust various parameters within the governance system, such as the credential weights, expiry periods, Gitcoin Passport MinimumHumanityScore, VoteSuccessThreshold, etc.
We removed this in the latest edit to the constitution PR but forgot to edit the proposal body to reflect this.
The only thing that has been delegated to PNF in the new constitution is the MinimumHumanityScore, which is in place as a safety mechanism.
You can see this under Parameter Delegates in the Constitution:
Issuing new credentials will now have to be approved by the DAO via PUPs.
It’s not about incentivizing engagement by threatening disenfranchisement, but ensuring that the voter base consists of those with recent context.
We talked about this in the first PGOV post:
It seems fair that those who would make decisions should have been active within the last 12 months.
If the DAO wished to introduce a mechanism like this, it would be as simple as issuing a new Builder Credential that recognizes voter participation. This could be automatically issued to voter accounts based on Snapshot data, under criteria such as voting on 66% of proposals in a 6-month period. There are other considerations – such as a perverse incentive to vote on proposals one doesn’t understand just to retain the voter record, which leads to the need for an abstention option in every vote – but this can be debated in a subsequent proposal if there is appetite for such a mechanism.
This is a good example of the kind of incremental improvement that this new modular architecture enables. We have 12 months in which to monitor credential activity and issue new credentials as needed.
They can also earn a vote through any successful proposal (not just PIPs), by opening a socket that pays them for their work, winning an RFP, or completing bounties. I posit that non-technical contributions should be equally capable of being paid for their work as technical contributions and if they’re paid then they’ll also earn their vote.
We have 12 months following this vote in which to issue more credentials and enfranchise a broader set of contributors. Examples might include:
- Win a retroPGF grant (see PEP-72), which includes non-technical contributions
- Organize/coordinate the community in some objectively measurable way (e.g. hosting a meetup with X attendees)
- Contribute valuable discourse on our forum, earning X likes over Y months
- etc.
2 Likes
Why I’m voting against PIP-37
Since PIP-37 is now up for voting, I’ll summarize why I voted against it. There are several reasons, but most fall under the headings of complexity or lack of transparency.
Complexity
The complexity this proposal adds to the voting process makes it nearly impossible to understand the implications it will have fully. To get a sense of the complexity you simply need to read one of the many posts that attempt to explain how the proposed voting will work.
I’ve spent a lot of time trying to wrap my head around all the changes - but I still don’t fully comprehend everything. I’d feel better if it was just me. However, many of our most experienced and engaged community members don’t fully understand how it will work and question the complexity also. This means that a vote for this proposal will introduce a voting system that most voters will likely never fully understand. So, this is essentially a vote for dependency on a few people who will be the “oracles” for how the voting works—assuming anyone knows.
Lack of transparency
Understanding the outcome of votes should PIP-37 pass will be a black box. We will be dependent on a third-party platform that we’ll have to trust is doing what it’s supposed to do without any way of auditing the results. So, in addition to the complexity, even if you understand how the voting system works, it’s impossible to audit a vote after the fact, and many of the voters will be anonymous, further muddying the process.
So, while I trust the current PNF team and believe the spirit of this proposal is well-intentioned, I also think that if this PIP passes, the DAO vote will be one step away from meaningless. I would be more inclined to vote to turn all decision-making over to PNF. At least that way, there would be accountability. This proposal will make it almost impossible to understand the voting system and impossible to audit the outcome of a vote. So nobody will be responsible or able to challenge anything.
Entia non sunt multiplicanda praeter necessitatem
A democratic process will never benefit from increased complexity and reduced transparency.
Hello everyone, I’m Mehrdad and I’ve predominantly managed the technical aspects of CREDS. First of all, I’d like to thank the community for advocating for this system; the discussions have helped us a lot throughout the development process. Secondly, I’d like to address the two concerns mentioned by @steve.
Complexity
You’re right. Keeping up with all the forum posts and discussions has been hard. Many posts have attempted to explain the system at different stages of its development, and each post has explained a section of the system. This fragmentation of the information has added to the complexity. However, it couldn’t have been avoided, as the development of such a governance system requires phases, and community feedback was necessary for these phases.
Digested Explanation of CREDS
Here’s my simple explanation of CREDS. The system has three pillars:
- Personhood: Governors should become citizens. To be one, they need to achieve a Gitcoin passport score of 15+ (proof of humanity) and pass three quests to gain citizenship (proof of naturalization).
- Impact House: Citizens who build will receive an impact vote. Each person has one vote, but based on the type, some votes might expire sooner than others, and their collective accounts for 80% of the total vote. To claim it, you can either migrate your old vote or get a new one as part of genesis voters.
- Stake House: Citizens who stake wPOKT in a DAO-created Uniswap LP or are running nodes get 10% of the total vote, and gateways get the remaining 10%. The former claim process is fully automated, and gateway votes are permissioned. To create a fair distribution of power, the square root of the values will be considered as that citizen’s voting power.
Furthermore, the above will be used to calculate the final voting result based on the citizens who vote.
Lack of Transparency
I can assure you that the voting system is fully transparent. To calculate the voting power through snapshot.org (our voting platform), we need to create a snapshot of the state of governance. The system automatically does this on a daily basis. A list of all the eligible wallets to vote, with their voting power and link to the PDAs they have claimed to achieve that said amount of vote, is stored on an immutable database (Arweave). At the date of creating a new proposal, the voting strategy will use the last snapshot created before the proposal to calculate the vote. Here’s an example of the generated proof.
Although we’ve been entrusted to run the system, we cannot tamper with the results as all the code for both generating the proof and calculating the final result from that is publicly available, and anyone can check the immutable proof as all the necessary information is publicly available.
Additionally, the snapshot itself will generate final tamper-proof evidence for all the votes that have been cast.
Should you need more information or have in-depth questions, I’m more than happy to jump on a call and explain the whole thing with utmost detail.
4 Likes
Thank you for jumping here @creepto.
I agree that a complex system needs to be developed in phases with community feedback. I just wish we’d broken it down into parts that could have been voted on and implemented incrementally, avoiding such a dramatic change all at once.
However, the complexity, in my opinion, is less about the system implementation and more about the voting mechanics. Questions like: What percentage of the community will likely fall into each house? How might that impact voting outcomes? How will we decide when changes are necessary? Why might changes become necessary?
How would someone verify that a wallet is eligible? Is the eligibility requirements valid, and is the wallet associated with a natural person—not an AI bot or something like that? This is the black box I’m referring to. As I understand it, we need to trust your system and its ability to determine personhood and track credentials accurately. But we have no way of auditing that. We can’t see the code you use or the checks you’ve made to decide. Is that correct?
2 Likes
Thank you for sharing your thoughts. Surely that is an ideal scenario and now that we have the foundation of the system it is much easier to do this for the coming iterations. However, if we were to cast a vote on PGOVs 1 through 7 it would have taken just 49 days of voting, not to mention the time for debates and discussions. Additionally, in some cases, we had to adjust our previous decisions due to the limitations of our current underlying technology. While your suggestion is ideal, it wasn’t feasible for this iteration.
To answer your questions, I adjusted the 3D Gov simulation model v1, which represented the old system where citizens, builders, and stakers had 10%, 45%, and 45% voting power, respectively. (that was discussed on the builders call at Feb 15th) I then created simulation model v2 using the same data. This will allow you to test different scenarios.
Additionally, I will share my personal assessment to further answer your questions.
Based on the genesis builders and the DAO voters (assuming there’s no duplication in the file and between the two), the builder house (representing 80% of the total) will have around 130 votes (1P1V) if everyone migrates to this system. This number will change as votes expire or as new builders join the community (the joining process is permissioned and manual as of now). On the other hand, the staker house is divided between gateways (10% of the total) and liquidity/node providers (10% of the total). With the introduction of new gateways, that 10% will be further distributed among them reducing the voting power of the two existing gateways. Lastly, liquidity/node providers is distributed among all of the stakers and as mentioned in the model, if the voters who hold 80% of the staked POKT collude, their cumulative power will be roughly 4% this indicates that the power has been well distributed and there isn’t a centralized power among stakers.
The above demonstrates that the model is decentralized and attempts to include everyone within the community who has had an impact.
As for why and how changes might become necessary, I believe it is important to consider that this is the first iteration of CREDS. As the system progresses, we will be able to analyze the proposals, votes, and PDAs more effectively. This will allow us to understand voter behavior better and optimize the system.
Regarding personhood, I must clarify that this is not our implementation. We are using the GitCoin Passport Plugin, which is installed directly on top of Snapshot by Snapshot and is also used by other organizations. The code is open source, and you can find more information here and here.
Moreover, to assess the eligibility of a wallet, you must check the proof that we generate daily from the PDAs in the mygateway.xyz protocol. The wallets and all of their associated PDAs that are valid are captured and stored there. Using the proof is not the only way; the proof itself can also be assessed. It is possible for you to request a wallet directly and trigger the proof generation function, which will ask the owner of the wallet to sign and reveal their PDAs to the requester.
1 Like
Again, I appreciate your weighing in here @creepto.
In our current system, one person has one vote. A proposal with more votes wins. It’s that simple. No models are necessary.
This proposal overcomplicates the voting process. It goes way beyond automating the voter credentialing process and making voting paths open to more people - which were the primary goals as I understood them.
Your above comment reinforces my opinion. We don’t understand how the proposed voting process will work or its implications, so we’ll be figuring it out as we go - and we will be dependent on a third party and/or very few people who understand it all.
2 Likes
I appreciate your feedback @steve and although I don’t share the same sentiment I respect your opinion. The current system excludes different groups in the community such as annons and stakers. Moreover if we compare the old and new system 80% of the vote is still one person, one vote and the remaining 20% relays on a simple SQRT reduction formula and POKT staked. Same as previous, more votes wins the proposal whether it is coming from impact house or stake house. Lastly, the referred analysis is to improve the system not to evaluate it as implications has been evaluated using the shared file.
2 Likes
I also appreciate your feedback, @creepto. Voting on something as impactful and complex as this PIP should include healthy debate.
For accuracy, the current system does not exclude any group. Anyone who wants a vote today can get one if they are willing to complete the required steps. If we feel the steps are inappropriate for some groups, the current system and constitution allow us to add new voting paths that would better align for more groups. This has been done in the past and does not require an overhaul of the existing system.
On anonymous voting
I genuinely appreciate your willingness to defend your viewpoint. Your transparency lets me know you’ve considered this topic deeply. It lets me and the community know that your vote should count regardless of which side of the debate you’re on. Part of my concern with this proposal is that this kind of transparency will be lost because of the introduction of anonymous voting. The impact of anonymous voting is another unknown that this proposal introduces. The decision to allow anonymous voting could have been the topic of a proposal by itself.
As I’ve mentioned in previous comments, regulating how much someone’s vote or contribution is worth is highly subjective and complex. For example, how was the decision made that staking is worth 20%? That’s a rhetorical question, so there’s no need to answer. It’s just an example to illustrate the same point I’ve been making: the complexity of this proposal makes it impossible to know or even evaluate its impact should it pass.
2 Likes
Hi @steve
Jumping in here, as I think there are a few points that need clearing up.
The current system does exclude different stakeholders. There is no point talking about theory if it is never turned into practice. The current system excludes non-represented groups such as gateways, and makes it very difficult, if not close to impossible for many other valuable contributors to have a say in POKT’s governance
As well as many more valuable contributors since that post from Jack last summer such as Raid Guild, @creepto and many more
The current system doesn’t allow an easy way to manage updates, as it’s all incredibly manual. This is demonstrated by how few changes have been made in the last couple of years, how few new voters have joined the DAO, and how much overhead it places on Jack to keep it running.
I personally don’t understand how the status quo is viewed as desirable.
Surely, it’s better to have a new scalable system built on a fully verifiable digital rails, as opposed to a manual off-chain process that cannot be verified, as per the current system? The newly proposed Creds system is, by definition and design, much more transparent than the current system, as every credential issued is verifiable.
And the best thing about the new system is that it is modular and can be easily upgraded over time, something that history has shown is not true with the current system.
1 Like
I appreciate you jumping in @Dermot.
This has been put into practice - it’s how everyone who currently has a vote got one.
I’m not advocating for keeping the status quo—I’m just advocating against an overly complex system. I agree that everyone who contributes should get a vote. If the current voter paths aren’t appropriate, new paths/quests could be created as they have been before.
This I agree with 100%. The system should be more automated and it should not all fall on @JackALaing. This can also be accomplished without such dramatic changes to the overall voting process.
When you refer to the “new system,” are you referring to the tech stack, the constitution changes, the addition of anonymous voters, and the voting weights? Again, the complexity of this proposal makes it confusing to know exactly.
So to be really clear, is your main issue with giving a portion of the overall vote to “stakers” and moving away from a purely 1p1v system?
I personally think that we should be formally representing all key stakeholders with a vote, and that 20% represents a material but safe proportion of the vote to start with, and learn from.
I mean the tech stack.
-
The constitution changes are administrative matters of formality.
-
Anon voting is how every other DAO works. But Gitcoin passport allows anon voting with proof of personhood, so we can enable 1 person 1 vote, so we get privacy while protecting against sybil attacks. The current system of posting selfies in discord isn’t desirable from a privacy or scale perspective, and is much easier to fake now with the rise of AI image generators.
-
The voting weights is something that has been discussed on multiple community calls and across the forum in multiple threads. I shared my view above, and I haven’t heard you directly opine on this either, so I wasn’t aware it was an issue but I’m happy to discuss if you would like to.
2 Likes
Yes. Moving away from 1p1v is a primary concern of mine.
What is “material but safe” is subjective. Also, this feels like a move to give entities a vote—as opposed to people. Gateways are not people, and the people running gateways shouldn’t have more than one vote.
I have not been able to make the calls. I have other responsibilities that conflict, so I’m trying to use this forum to express my viewpoints and understand others. I’m not getting paid to push any agenda here, and I’m not pushing back to create extra work for anyone—especially not myself. I’m just voicing things as I see them. Also, this is a discussion that should be with the community vs. one-on-one (although I appreciate the offer).
I suspect this PIP will likely pass because few people have the time required to invest in it. Ironically, with every post, I’m asking myself why I’m spending the time. But that question reminds me that the more complex something is, the less likely it is that people will spend the time to understand it - let alone voice and defend their opinion.
What I would vote for
I would vote to turn decision-making over to elected people in the community, provided there were term limits. Or a simple 1p1v system that is available to everyone who contributed in any way. But, that will likely result in more uninformed votes. So, if we move int that direction, the voting outcomes will always favor the people with the most time to spend doing this. Or the ones who control the narrative (docs, website, etc).
3 Likes
First of all, huge thanks to everyone that has contributed to this proposal itself and the discussion here. I think this is all good-faith conversation from all parties about coming up with sustainable systems for problems we currently have. That being said…
Why I voted against PIP-37
I agree with most of steve’s points (I feel very strongly about 1P1V), but the one that resonates most with me is the complexity and atomic-ness(?) of the changes as a whole. “Smoothing out the current manual verification process”, “Getting more voter engagement”, and specifically “getting more currently-involved voter engagement” (the irony is not lost on me) are all noble goals, but I think that this proposal is simply moving too many parts too quickly, and because it alters the governance rules themselves, should not be taken lightly.
In my opinion, this should be broken into smaller self-contained PIPs that can be discussed and voted on by their own merit, rather than as this sort of ‘all-or-nothing’ approach. I also think that there are inherent risks to coupling governance with a specific third party identity solution. Obviously the intent of the rule will need to be implemented somehow, but enshrining a product and vendor in governance without the appropriate escape hatches built-in from the start can lead to a serious crisis if there is a technical or process issue in the future.
3 Likes
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