Thanks again, @b3n - this was an extremely helpful reply. So the primary objective of this PIP is to automate the voting process, with a secondary objective of removing inactive voters.
I’m glad to hear that enabling PNF to have more control over the voting process is not an objective. Eliminating any constitutional changes that are not absolutely necessary to support the primary objectives stated above will address most of my main concerns.
My only other main concern is with allowing anonymous voters. My concern here has to do with how we prevent AI agents from being used to gain votes. I have not done a deep dive into how the new system ensures “personhood,” but I do know that AI agents are almost impossible to detect from humans if all you’re looking at is an online activity like social accounts, GitHub commits, etc… This might be a question for the GitCoin team.
Really great questions on how to prevent AI agents from participating. A few thoughts and details on how Passport works:
Passport is an identification aggregator that enables humans to showcase they are unique in non-doxxing ways. Passport holders verify “stamps”, and as more stamps are verified, the higher likelihood the wallet owner is a real human (and not just a bot or scripted wallet). It is absolutely possible to build an AI agent that goes through and verifies stamps, but it would be quite costly to do this at scale because of the cost of forgery for each of the stamps. There are multiple ways to increase ones score (social/web of trust, KYC, biometrics, on-chain activity, etc). And it’s through the combination of stamp verifications that someone increases their score.
We encourage most communities to set a required passport score of 15 or 20 to help protect their community. This offers a barrier to entry, that is often easily overcome by a real human. If you want to learn more about how passport works, you can read up here: http://support.passport.xyz
We have been chatting with some POKT members a bit to help ensure the implementation is successful, and we would love to be included in this PIP.
Hey, Kyle (@kbw for visibility) - thanks for jumping in here - I appreciate it very much.
As AI agents become more capable (like Devin for example), and begin interacting more using social accounts like GitHub, LinkedIn, etc. it seems like it will be increasingly more challenging to decipher AI actors from human actors using “stamps” as I understand how they work.
I’m guessing your team has considered this, but is this a concern we should be considering as well, in your opinion?
We still see much more sophisticated attempts at gaming the system from those in economically depressed regions than we have seen with AI agents.
for example, we have witnessed (and built counter measures) for human liveness farming, and the selling/swapping of KYC credentials where its easier to find people on the street to verify these than it is to code solutions to impersonate.
AI agents like Devin are great examples of whats possible… but not whats mainstream or available to the public.
I agree we’re not there yet. What I don’t know is whether we’ll be there later this year, two years from now, or ten.
Five years ago most experts thought it would be 80-100 years before we saw the kind of AI we’re seeing today.
So, while I agree it’s not what we’re facing today - it seems like something we should consider before it’s mainstream.
It seems like the best solution is for everyone to be doxed and vouched for by other voting members, but that’s an issue for humans who want to be anonymous.
I’ve created a new PR with a simpler set of constitutional edits that focuses only on essential CREDS changes. My general philosophy when approaching this edit was:
only remove/reword clauses if they directly contradict new clauses, no matter what other issues they may have (e.g. referencing obsolete tech)
when introducing new clauses, insert them as close as possible to the clauses they replace or relate to, to make for an easier comparison in the diff view
make no unnecessary changes to structure, so that the diff view shows only additions/subtractions, not areas that have simply been relocated
Brown line: modified. Note: most of these are just incrementing the number. The only exceptions are 4.18, the sub-header before 4.21, “6. Proposals & Voting”, and the Definitions list.
As a testament to this being a simpler set of edits, I believe a separate document explaining the edits would be overkill (and risks being lost for future reference). Instead, I’ve outlined the edits below in three groups:
1) Creds upgrade functionality
Replace 4.1-4.3 with the new voting power mechanisms
Introduce a new set of governance parameters, which will help the DAO calibrate the voting power mechanisms moving forward – HouseWeights (4.1.2), MinimumHumanityScore (4.2.1), CitizenCredentials (4.3.1), BuilderCredentials (4.1.4), BuilderPowerCap (4.4.1), StakerCredentials (4.1.4), StakerWeights (4.5.1)
2) Modular governance architecture
Reinforce the above governance parmaeters by creating a more robust modular architecture
A Parameters section is added near the end (8.15-8.32), introducing the concept of a Parameter Delegate. Note: PNF is already effectively a Parameter Delegate for the following parameters: MaxApplications, RelaysToTokensMultiplier, ServicerStakeWeightMultiplier, SupportedBlockchains. As well as granting us more flexibility for how we calibrate this new governance system, this also provides clarity to an existing practice that has emerged organically in our DAO.
Old references to delegated parameters (6.5-6.7) have been removed in favor of the new Parameter Delegates section. Note that 6.5 has not been replaced in the Parameter Delegates section because this was supplanted by the GatewayFeePerRelay parameter that was introduced by the DAO last year.
More governance parameters are introduced relating to the proposal/voting process – VoteQuorum, VoteStartDelay, VoteSuccessThreshold, ConstitutionAmendmentThreshold – further empowering the DAO to calibrate this new governance system moving forward
The Governance Transaction clauses under “Access Control List (ACL)” are updated to reference the constraints on PNF as a Parameter Delegate.
3) Misc definitions/wording
New Definitions have been added where they are introduced by new clauses
Vote/Voting definitions have been replaced, corresponding with replacement of 4.1-4.3 referenced above
Citizens section (4.27) has been renamed to Validators, to avoid confusion with the new Citizens concept this upgrade introduces
One stray instance of “Voting Tokens” (which references the old system) in 4.18 was reworded to “Voting Power” to retain the meaning but maintain consistency with the new system.
Note: there is one pending change that I will need to add to the PR when there is consensus on the final set of changes to be made. 8.8 specifies a versioning system that determines the version number of each constitutional upgrade, which is a function of how many minor/major changes there are in the constitution. Before putting this proposal up for a vote, I will amend the PR to add a version number for this upgrade as well as any previous upgrades for which this versioning method was missed.
Thanks for minimizing the constitutional edits, @JackALaing - this is much better, in my opinion. I still have reservations personally due to the overall complexity of the new voting system and what will become a dependency on GitCoin should this proposal pass. That said, I do agree we need a more robust solution and any change is going to involve risks.
The only change/addition I saw in the constitution that I had questions about was the following one.
4.22. Governance Transaction Permissions: PNF alone holds the ACL permission to submit Governance Transactions by virtue of its accountability to the POKT DAO under the PNF Articles. This exclusive permission is non-transferable.
Can you expand on how adding the above relates to the voting changes - especially the addition of This exclusive permission is non-transferable.?
Thanks again, for making this a lot easier to follow.
It is part of the existing clause 4.20 being expanded into 4.21-4.23, as part of the modular governance architecture changes I outlined above.
For reference, the original clause 4.20 is:
4.20. The Foundation multi-sig will hold all ACL permissions at launch, but the Council may work to automate (and thus disintermediate) the Executive function by building a cross-chain integration between Pocket Network and the Council’s Aragon Agent (or a similar smart contract representative). The period before automatic cross-chain execution is achieved will be referred to as the Signaling Era.
This is expanded into
4.21. Enforcing Resolutions: Pending the automatic enforceability of these Powers, PNF shall ensure the enforcement of approved proposals, execution of Governance Transactions, and amendments to this Constitution reflecting approved changes. The period before automatic cross-chain execution is achieved will be referred to as the Signaling Era.
4.22. Governance Transaction Permissions: PNF alone holds the ACL permission to submit Governance Transactions by virtue of its accountability to the POKT DAO under the PNF Articles. This exclusive permission is non-transferable.
4.23. Limits to Governance Transaction Authority: PNF may execute a Governance Transaction on the POKT DAO’s behalf only when: (i) authorized by the Powers; (ii) designated as a Parameter Delegate; (iii) executing another Parameter Delegate’s directives; or (iv) executing a DAO-approved action.
4.23 expands on the limits to PNF’s authority as the holder of ACL permissions on the DAO’s behalf (note: ACL permissions are the authority to submit on-chain transactions like gov transfer, gov change_param, gov upgrade, gov burn), making it clear that even if the DAO delegates a parameter to PNF for updates outside of the PUP process, the boundaries of this authority depend on the limits set out when the parameter was delegated.
4.22 restates “The Foundation multi-sig will hold all ACL permissions at launch” from the original clause, to make it clear that PNF holds ACL permissions precisely because it is the only entity that is held accountable to the DAO by the checks and balances outlined in this constitution and the PNF Articles. Adding the non-transferability part at the end is a safety mechanism to ensure that these sensitive permissions remain bound by the checks and balances we have established, i.e. are not transferred to an entity that is not subject to the checks and balances.
If this is a sticking point, it can be removed from this edit and deferred to the later round of edits. Note that this part could also be removed in a later set of edits if circumstances changed and the DAO wished to grant ACL permissions to other entities. It would require a constitutional amendment to unlock that capability, which would be subject to the ConstitutionalAmendmentThreshold parameter.
Thanks again, @JackALaing, for the clarification. If I understand your explanation correctly, it’s not a sticking point for me. But to confirm my understanding now, the spirit of the new language in 4.22 is that PNF may not transfer the ACL permissions to any other party. Is that correct?
@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.
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.
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
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.
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?
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.
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.
