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

Proposals Improvements
11

Hey @b3n I’ve spent the last few days going through the expansive changes being proposed by this PIP.

I’ve shared some of my questions and concerns with you and @JackALaing. With this comment, I will start making my questions visible to the community.

Of all the things we vote on, changes to the constitution are the most important in my opinion. So, I’ll start my comments/questions there. I’ll also hold off on my other thoughts for now in hopes of keeping the discussion focused on one issue at a time.

The changes are not just updates to the constitution—they are a rewrite. Further, some changes violate the original (read: existing) constitution.

8.1. This Constitution may be amended according to Majority Approval in the PIP > process, unless otherwise specified in ‘Immutability’ and ‘Undo’ below.

Immutability

8.2. No Constitution amended to modify clauses or definitions marked with a ‡ will be accepted under any circumstance except per 8.6.

8.3. Constitutions amended to introduce a ‡ will be accepted if they have first received Supermajority Approval in the PIP process.

8.4. No Constitution amended to modify clauses or definitions marked with a †, or to introduce a †, will be accepted unless the proposed amendment has first received Supermajority Approval in the PIP process.

For starters, the Immutability section has been - well, muted. This is the only violation necessary to invalidate the changes per the existing constitution. But there are multiple others. To keep focused, I won’t detail the others now because the main point is that we don’t need a constitution if we can rewrite it at any time.

4.10. The Foundation shall serve as a custodial entity for Pocket Network, deferring decision-making to the Council in all cases except Material Adverse Exception Events (MAEEs), i.e. crises resulting from incomplete contracts and unforeseen events.

My second point is that the current constitution does not appear to be linked to in the Pocket documents or on the website anymore. It used to be linked in the documents, but it seems all those links have been removed. Perhaps this was an oversight and maybe it feels like a minor point, but it kind of seems like the updates are being assumed before a vote has happened. This is arguably another violation of the current constitution.

This is also true for information about the current voter paths. They are no longer in the documentation. So, anything that links to details about our current process is now a dead link. If someone wants to compare the existing process to get a vote to the proposed method, all they will find is the newly proposed process. For example, if you visit this post on the messari site, which discusses our current system, you’ll notice all the links are dead. Again, this feels like a decision has been made without a vote.

6.2. PIPs will not be permissible if they contain multiple new specifications that could feasibly be divided into separate proposals without losing their meaning. This is in place to prevent omnibus proposals, whereby unpopular proposals are pushed through by bundling them with popular proposals.

So, I’m not just pointing out issues without suggesting a resolution; here is my suggestion.

  • Make changes to the constitution with amendments - like the current constitution suggests
  • Keep the changes focused on credentialing and reputation

There are too many significant changes conflated into this one proposal. I’ve spent over 12 hours reviewing the changes and considering their implications, and I still don’t feel like I fully understand them.

At this point, I would vote against this proposal for that reason alone—it conflates too many things, and I suspect most voters won’t have the time to consider them properly.

3 Likes
12

Thanks @steve for the feedback and for taking the time to review the proposal.

On constitutional amendments

we don’t need a constitution if we can rewrite it at any time.

Constitutions include processes to amend them (metagovernance). Our amendment process is the PIP, as defined in 8.1, which we are following. Therefore these changes would be in accordance with 8.1 if the proposal passes.

We are also retaining the current amendment process in the new constitution via 7.1:

7.1 Amending the Constitution: An amendment to this Constitution, including the introduction of new Parameters, shall be considered ratified and adopted upon securing an affirmative Vote that meets or exceeds the ConstitutionAmendmentThreshold.

We included the removal of the immutability clauses in our proposed amendments because they have not been used to date (no clauses have the markings referenced), and we feel it is still premature to ossify clauses within our constitution, so all possible changes are essentially subject to 8.1 (majority approval). If at a later date we felt the need to ossify, there is nothing stopping us from reintroducing clauses like this through another PIP.

On documentation

The docs are a little messy right now because they’re going through a refactor but the docs for the existing system can be found here, under Governance – Earn Your Vote | POKT DOCs.

It looks like the Node Runners sub-page was accidentally dropped during a larger refactor edit by one of our contributors, so I’ve restored that page, but every other voter path was in there.

The constitution is also linked on this page DAO (OS) | POKT DOCs and can be found in the official governance repo GitHub - pokt-network/governance

On significant rewrites / bundling amendments

We included the amendments we did because they are, in our opinion, long overdue updates that ultimately improve the constitution.

However, I appreciate that there isn’t much context on why each of these changes are being proposed. We had hoped that the diff in GitHub would provide transparency into changes but I can see that 1) the restructure makes it harder to follow, 2) the diff doesn’t include justifications. I am going to correct this by following up here with a document that outlines all of the proposed changes with justifications.

If there is pushback on the bundling of constitutional amendments that do not directly relate to the functional upgrade that is CREDS, we are happy to open a new PR for this proposal with a narrower set of amendments, then defer the other amendments to a longer participatory process.

In any case, whatever the preferred path forward on timing/sequencing, we do feel strongly that a constitutional refactor is necessary, including all of the changes that are included in the current PR.

2 Likes
13

Thanks for the follow up on this @JackALaing

I think this is a step in the right direction.

This is a better approach in my opinion.

New question

Can you explain how new voter paths are created going forward? For example, if in the future some new group feels disenfranchised, do we have to go through this process again?

1 Like
14

A key part of this proposal is the modular architecture which defines a new set of governance parameters that can be delegated to PNF in the same way that the RelaysToTokensMultiplier, ServicerStakeWeightMultiplier, and MaxApplications are on-chain protocol parameters that were delegated to PNF.

The table of BuilderCredentials is itself a parameter that is proposed to be delegated to PNF. Each BuilderCredential represents one “path” to obtain a full vote in the DAO (where everyone in the Builder House is limited to 1-person-1-vote). So merging a PR to GitHub, winning an RFP, submitting a successful proposal, etc, these are each paths to a vote.

Delegating this parameter to PNF means that PNF is granted the authority by the DAO to modify credentials and to issue new credentials. In consultation with stakeholders over time, or through recommendations from the community/DAO, PNF would have the ability to issue new BuilderCredentials without having to go through a lengthy proposal process.

In other words, we are establishing a more dynamic system that makes it easier for us to mint new voter paths as needed. Examples might include:

  • Win a retroactive public good funding grant
  • Organize a community call / local meetup
  • Stake X nodes / serve X relays
2 Likes
15

Thanks, @JackALaing. This is what I thought and also a concern of mine.

This change to the constitution gives PNF 100% authority over who gets to vote going forward. As a result of this PIP, the DAO/community will no longer truly have a say over what it takes to get a vote, and this could also mean no say in what proposals get passed.

To illustrate my point, PNF could create a new path that gave everyone who attended a community call a vote. Then, PNF could create content on the website and in the docs to promote any new agenda and put it to vote. I’m not saying that would happen, but PNF would have the authority and power to do that.

That control, along with control over all the information on the website and documentation, gives PNF everything needed to ensure the outcome of any vote.

I trust you, @Dermot, @b3n, and the rest of the PNF team. But this isn’t the way if we’re trying to create a governance model that works regardless of our levels of trust in one another.

3 Likes
16

hey Steve, it’s a really good point to align on. Like you, my bias is to have a more trustless model as much as possible… provided that isn’t at the expense of the systems legitimate need to adapt in service of its goals. This was the issue with the old system… it ossified around paths and personas that don’t represent the evolving spectrum of POKT stakeholders.

Any powers PNF is delegated is for the DAO to decide and should be enshrined in a way that makes you and other members of our community comfortable that the right checks and balances are in place. And to be clear, delegating to PNF was for us a shorter term solution to enable further infrastructure and expertise around the system to be built in the DAO, which these powers could be delegated back to.

Perhaps changing the delegation so that PNF proposes new credentials direct to the DAO for a vote is preferred? Or perhaps the community implements their own public mechanism for making recommendations on new credentials to be created with a timelock that PNF has some control over before enabling. We just want clarity how it is operated so that we can balance capture resistance and any adversarial factors against the legitimate need for a reputational system that is dynamic and responsive and can grow with POKT for the next 3-5 years and beyond.

Do you have a preferred solution in mind for how this should be operated or expressed in governance? I don’t know the depth of feeling around this but it would be great to hear more perspectives from you and other voters.

1 Like
17

Thanks for your response, @b3n, and for the many DMs from me that you and @JackALaing have responded to regarding this PIP.

As I’ve said, I respect and trust the current PNF team. However, we are all aligned in wanting a system that can be trusted regardless of who is leading PNF in the future. So, from my perspective, this is not about getting comfortable now. It’s more about keeping us comfortable over the next “3-5 years and beyond”.

Why is a complete overhaul of the constitution necessary if the main goal is “to enfranchise more of our community as DAO Voters”?

I will personally help ensure that anyone who wants a vote gets one

The current system for getting a vote does not disenfranchise anyone. To get a vote under the current system, you simply need to commit some time. There are no other barriers. If you can read and respond to this comment, you have the skills to get a vote.

So, I would be willing to create a course and hold a monthly meeting to guide anyone interested through the process of getting a vote. No experience or technical skills are required; just a time commitment. In addition to my willingness to do this, I know other OG voters who would be willing to help to ensure it’s sustainable. So, if anyone wants a vote and is willing to invest a little time, we can ensure they get one.

Getting a vote is too hard, and I don’t want to be doxed

If you disagree with my assertion that anyone can get a vote today, I’d like to understand why. If you answer that the time commitment is too much or that you don’t want to be doxed, those are different than claiming that people are being disenfranchised.

If the actual viewpoints are that the process should be easier and that anonymous voting should be allowed, I get it. Getting my vote took months, and I almost didn’t do it because of the time commitment. I also wasn’t sure I wanted everyone to know my viewpoint because I have strong opinions - as I suspect you now know by now. But again, those reasons are not the same as being disenfranchised. When people are disenfranchised - they don’t have the right to vote. In this case, everyone has the right even if they are not willing or able to invest the time. Or are not willing to be doxed.

Is it about who has the voting power?

So, assuming reason prevails here, you see my logic as to why nobody is actually being disenfranchised. And why I’m questioning the reasoning behind a push to overhaul the Constitution and voting process so radically.

Of course, a more automated process that scales would be necessary if the objectives are less about enfranchising people and more about the opinions that more voters are needed, or that we need voting terms, or credentialing should be revised. If that’s the root reasoning behind this proposal, let’s discuss it without the propaganda.

Your question: Do I have a preferred solution in mind? The short answer is no. But that’s because I’m still trying to determine this proposal’s primary objective and the reasoning and motives behind it.

The “disenfranchised” narrative doesn’t hold up to fundamental reasoning. Plus, using that word in this context minimizes its true meaning, which makes me a bit agitated. We don’t need more content on the web that future LLMs will use to minimize the contextual meaning of something like what it means to be genuinely disenfranchised. But that’s my emotions - back to reasoning.

As I’ve expressed, this proposal is too complex and conflates too many things. So, perhaps you could state the primary objective, and I can try to respond to your question about how I think it could be operated or expressed in governance.

So, what is the primary objective of this proposal?

If you can answer the question above objectively in a sentence, I’ll gladly share my suggestions. Perhaps the main objective is one of the following:

  • Make it easier for people to get a vote
  • Limit the control of the small group of existing voters
  • Remove current voters who are no longer active
  • Empower PNF with more control over the voting process
  • Automate the voting process

Whatever it is, let’s make it clear so everyone can weigh in. I know nobody wants people to be “disenfranchised” from understanding what this proposal is really about. :wink:

2 Likes
18

Hi Steve, Thanks for asking these questions and highlighting the need for a more effective way of making sure key information hasn’t been missed.

Hopefully this answers your main question:

The objectives are described here in our first post from August 2023: PGOV1 - Evolving Pocket’s Governance: Introducing 3D Governance

As you can see it specifically calls out the objectives, challenges and proposed solutions, starting with:

While community feedback over the last 6 months have evolved the specifics, the objectives and reasoning remain unchanged. Although we linked this in the proposal above, we didn’t explicitly call it out as containing our detailed reasoning which was a mistake. I will add it to the proposal.

If we are being precise then it’s important to state that I/we haven’t used the word disenfranchised anywhere. Saying ANY builder who attains a particular credential, and not just those named personas or paths in the existing system, reaches my threshold for saying enfranchised but I’d need more time to think on the semantics. Were Stakers, who can now use an adapted token weighting method to vote via their Stake included before?

Questioning whether Stakers or Investors or Gateways are already included highlights an important reason we think the proposed change is helpful:

I hope this gives a bit more clarity. Let us know!

1 Like
19

Thanks again @b3n for your response.

The reasoning for my posts is that the objectives are not clear, in my opinion. That’s why I’m trying to restate what I think I understand. I might be the only one in the community who isn’t exactly clear, but I’m guessing that’s not the case. So, all I’m asking for is a bit of clarity.

So, asked another way, am I correct in saying that the reasoning for the change is the following:

  • Make it easier for people to get a vote
  • Limit the control of the small group of existing voters
  • Remove current voters who are no longer active
  • Empower PNF with more control over the voting process
  • Automate the voting process

Again, I’m just trying to understand and, hopefully, help others understand the purpose of this PIP.

Again, I’m just trying to clarify the objectives in simpler terms.

To continue being precise, the word enfranchise—used in the context this PIP is using it—means to give someone the right to vote. Everyone has the right to vote now—some just choose not to go through the current process. But you imply that some don’t have the right, which is misleading, in my opinion.

Back to the point

Am I misleading anyone by saying this PIP aims to do the following?

  • Make it easier for people to get a vote
  • Limit the control of the small group of existing voters
  • Remove current voters who are no longer active
  • Empower PNF with more control over the voting process
  • Automate the voting process
20

Ok great, will address your list directly:

This is not an objective but in some cases is an ancillary benefit. The current system is unequal when it comes to effort requirements across the different personas. It is about making the requirements more even, not easier. For people who are knowledgeable, engaged and contributing, in some cases it will be easier to get a vote. For others, who now might have to make direct contributions like having a PR accepted to a Shannon or Morse repo, it is arguably harder.

This is not an objective at all. What we do want is to reverse the inertia in voters and to have a more scalable definition (builders and stakers) that can grow with the DAO

This is an objective. The current system aims to have the “most knowledgeable and engaged” people as voters in the DAO, but does not meet its own standard when voting power is for life. It is not possible to be engaged if (over some time horizon) you are no longer active.

This is not an objective and it would not be a benefit. If it was not explained clearly enough here then I can say now that we will change the delegation of this parameter to being DAO controlled. This will mean the addition of any new credentials can only happen via a DAO vote unless an alternative operating mechanism is proposed by someone.

This is a primary objective. The current system is a bunch of discord tags administered by one centralised actor. Verified credentials are a way of automating the existing trophies and provide further programatic benefits for efficiency and innovation.

If it has not come through already then the other key objective is to unbundle reputation from “personas”. If we do not do this, we will always be chasing our tail to define new personas and plug gaps as the ecosystem evolves. The current system rewards an action (with a trophy) for one persona, but a different persona completing this same action would get no such reward. This creates a path dependence that to me is at odds with the idea of reputation itself. We are all “builders” of POKT and forcing ourselves to splinter into different personas or tribes does not serve a clear purpose.

Below I try to highlight the changes between the current and future state. I hope it can help communicate the nature of the upgrades we are pursuing and how much of this is an evolution (with some tweaks!) on what we already have.

image
image1634×1002 103 KB

3 Likes
21

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.

2 Likes
22

Kyle here from the Gitcoin Passport team :wave:

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.

4 Likes
23

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?

Thanks again!

3 Likes
24

My take is that we are not here yet.

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.

3 Likes
25

Thanks again for weighing in here @kbw .

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.

1 Like
26

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

I recommend looking at the rich diff for easiest readability. CREDS Upgrade Focused by jacklaing · Pull Request #10 · pokt-network/governance · GitHub

Guide to the diff:

  • Red line beside clause: deleted
  • Green line beside clause: added
  • 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.

5 Likes
27

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.

1 Like
28

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.

2 Likes
29

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?

1 Like
30

Correct, and the DAO may not transfer the permissions unless it first amends this clause.

1 Like