Makes a lot of sense! Snapshot is being used across many DeFi protocols for governance and is very user-friendly. Less friction means more involvement.
All good on my front.
2 Likes
I think the differentiation has to be more than just a node runner or a third party node runner. Which path creates more decentralization & service availability for Pocket? My guess is that self node runners creates more decentralization, but what about availability - i do not know that. Or can running my nodes through a third party create same/more decentralization for the network? If it is the case, we should not be discriminating between the two. Especially, running nodes through third parties can bring more relay nodes to Pocket creating a better service. I believe the economic advantage of running nodes myself will be an incentive for me to run nodes, not to mention the veto-like power I get on governance updates. Both of this combined could be a good incentive for someone to run the nodes themselves.
1 Like
We want to incentivize more sovereign node runners because this enhances the decentralization (and thus resilience) of the network. If one hosted provider’s backend goes down, this will be less impactful on service the more independent node runners we have. Conversely, there is a good point about not letting that goal sacrifice the average quality of nodes and we’re always thinking about ways to effectively manage that balance.
However, all of this is (in my opinion) unrelated to the question of governance. We already have plenty of incentives for people to run nodes (either hosted or self-hosted) and people will self-select based on their own preferences. What we should be optimizing for in this case is the knowledge and engagement of people making the decisions. And it is an indisputable fact that self-hosted node runners are more knowledgeable and engaged when it comes to matters of running a node. You might argue that a non-self-hosted runner can still be knowledgeable/engaged in other ways, but that’s what the community path tries to capture.
2 Likes
Thank you for this very thoughtful and thorough proposal @JackALaing. In general, I support it conceptually.
I have a number of questions and suggestions related to the new process’s execution.
Here are my first two “meta”-comments.
1 - Separate Vote Acquisition from Voting
I feel this info would be easier to process if it was separated into two proposals, one for vote acquisition and one for voting. For example, acquiring votes via Arcade participation is about clear enough for me to support with a “Yes” vote.
I have a number of questions related to voting, particularly about Snapshot, Aragon Agreements, the “standard” referenced in the context of Aragon v2, as well as the voting implementation process. These questions would cause me to withhold my “yes” vote, until they are answered or this was split into two proposals.
Splitting them would also make it easier to submit more detailed feedback. Breaking this proposal into two could help move things along incrementally. In my experience, incremental progress is a powerful deadlock breaker and helps build momentum.
2 - Less is More
I’d suggest splitting the implementation details into an appendix. While I agree they are necessary, including them in the main body makes it difficult for me to follow the concepts.
Also, bi-directional linking between Discourse and Discord feels overly complex, if that’s what is being proposed. I say this speaking from experience, having seen attempts to bridge/mirror communication channels.
In my ideal world, comments and conversations, i.e. inputs, would be limited to Discourse. I’d be OK seeing these updates posted to a read-only Discord channel.
Again, thanks for the hard work here. I’m feeling excited to seeing where this leads!
1 Like
Just to be clear, are you proposing I move the Specification section to an appendix, or are there more details that you think should be moved too?
No, bi-directional links is not the intention.
New Snapshot proposals will be sent to the proposals Discord channel as notifications, using the CollabLand bot. I highlighted this point because it solves a common issue people have with other DAOs, that they’re not always sure when a vote is happening.
This will simply be a one-way notification stream to maximize engagement with proposal discussions/votes. It will work the same way that the Discourse notifications work today. To make this clearer, I have merged all proposal notification streams into a single #proposals channel and made it a read-only announcements channel. Thanks for the suggestion!
1 Like
Before I split this proposal in two, it would be helpful to understand what it is you’re unsure about.
How voting rights are defined directly influences how votes are cast. In our case, if we distribute votes as non-transferable airdropped tokens, the easiest way for us to facilitate voting is to use Snapshot. If you vote yes for the new vote acquisition process, but no for the voting process, you’ve effectively rendered the vote tokens useless. A vote against the latter might as well be a vote against the former.
Both designs (vote acquisition + voting) also stem from the same design goal: to improve the overall voter UX, hence the title of the proposal. So even if you have hesitations about some of the finer implementation details, a vote in favor of this proposal is a vote in favor of the design goals and the general direction we’d be heading in.
If there are specific implementation details you disagree with, which have alternative solutions that we could implement today, let’s discuss that.
1 Like
It turns out, while this is possible with Skillz nodes due to how they manage their infrastructure, it’s not possible with every 3rd party provider (e.g. Chainflow). That’s my bad for not realizing this sooner.
However, since you’re required to complete 5/7 of the level 2 quests to get the vote, the node path still has a filter for knowledge. Do we think this is sufficient, or do we want to explore other ways to enforce self-hosting?
I don’t think we will be able to stop a determined person who owns nodes (even though he may not personally manage them) from passing the node tests. And, the more I think about it, the more it appears both correct and desirable that he do so. As he learns what is necessary to pass the test, he will likely start to figure out that it’s not so hard after all, and he may ask himself why he is paying $100/month for each one of those nodes when he could do it for WAY less… Taa-Daa… decentralization through information.
4 Likes
Well thought out proposal @JackALaing! I think having such a Proof of Engagement process of acquiring voting power within the network will definitely be beneficial and streamlined compared to the current “closed” system. It’s also a great way of giving back to community members that help out in growing out the ecosystem and bringing in fresh ideas through a more open DAO group .
I agree that Snapshot’s UI does a good job in their governance UX and think its much better to track and vote on proposals than using Discord.
A question I have is, what is the use of Aragon Agreements vs a non transferrable ERC20 “Pokt DAO” token? The Pocket Foundation still has voting distribution powers and the power to execute the polls’ outcomes, so I think these are all signalling votes anyway. The Foundation in all cases is being trusted to execute to follow the community’s signal.
1 Like
Unless I’m misunderstanding you, this is not the case. The vote tokens are airdropped to community members automatically by the CollabLand bot once they’ve completed the POKT Arcade onboarding process.
In the early days, Aragon Agreements won’t have as much use for Pocket as it would for an Ethereum-native project. This is inevitable due to the fact that Pocket is a non-EVM, non-smart-contract blockchain, which can therefore not be integrated directly with an Aragon Agent. So, for these reasons, it is true that these are all signaling votes initially and the Foundation will be executing on the community’s signal.
However, where the Pocket DAO is interacting with Ethereum, such as in a future wPOKT system, this would provide the DAO with direct executive capabilities.
In any case, we’ve designed the Constitution and the Foundation’s Articles to keep the Foundation accountable to the community. We also have plans for how would we enable automatic cross-chain execution, thus disintermediating the Foundation, but this would be a herculean achievement and one we need to work towards as a community.
1 Like
Regarding the CollabLand, I misunderstood myself how the airdrops were done.
Thank you for the explanation regarding removing the Foundation as an intermediary for such functions. Since we’re working towards this, going with Aragon Agreements is definitely the right move for the long term.
1 Like
@chris-remus I’m wondering if these are the same concerns you alluded to when you said you had questions about the voting implementation process? If so, have I addressed them or is there anything else I can bring clarity to?
1 Like
Hey. Looked at the points made above. Granted: going through a third-party provider such as SkillZ would make it easy to pass the 3 first tasks of the Node path. Among the 5/7 tasks required to get votes through the Node, the first and second tasks would also be easily done when relying on a third party providers, however completing three additional tasks would require hands-on knowledge (or being on the verge of launching a node) with running a node and I agree with @BenVan that it could bring someone close to running a node herself if she had the will and time to do so.
The filter for knowledge is strong with the Node path indeed. The “worst” outcome I’m seeing is that someone completes the Node path and decides to keep running her node through a third-party instead of running a node independently. The community would have acquired someone who would have the technical understanding required to challenge the third-party node runner on implementation choices, which is a good way to keep third-party runners in check.
2 Likes
All very good points. I wasn’t giving enough credit to our quest design, which ensures that at least some level of personal knowledge/engagement is demonstrated. So I’m now quite happy to allow third-party node runners to complete the quests.
3 Likes
Overall, I feel comfortable to vote on the proposal as it simplifies the UI & UX, and creates a good mechanism to onboard new community members who are knowledgeable about Pocket. The only thing I would like to see is an omnichannel experience for voters from getting notified about (1) new proposals, (2) engage in discussions, (3) and ultimately to vote within the same channel. I hope this could be implemented in Snapshot. Though I am unsure whether the same level of functionalities can be delivered through Discord or the POKT forum. To conclude, I would love to do everything related to governance on a single platform without hopping through multiple platforms.
1 Like
Hey all,
Thanks for your patience. We have been waiting on some of the tooling being finalized, such as an upgrade to the Discord bot that will allow us to airdrop the voting token to the Voter Discord role (rather than using a Telegram group), which makes for a more seamless and secure experience.
I have updated the details of the proposal in light of some of the very helpful feedback you all left, making the following changes:
Removed the details about node runners who use third-parties being unable to participate. This is not enforceable anyway and there was strong consensus from you all that such node runners should be able to participate in governance.
Added a Dissenting Opinion regarding the uncertain future of Aragon Agreements, in light of the Aragon One resignations.
Added a Dissenting Opinion regarding how POKT Arcade could fare in adversarial environments, with more research in the pipeline.
Withdrew the suggestion to sunset the ability to remove voters. There was hesitation from some of you in relation to this amendment, which led to some introspection on my part, and I am now of the opinion that we should retain that option until we are 100% confident in the integrity of our DAO onboarding mechanisms and want to start ossifying them. Note that, in light of the uncertainty around the future of Aragon Court & Agreements, these clauses may need to be updated in the future, since they refer specifically to Aragon Court.
Added details about the potential for future developments we can make using this system, linking to relevant RfPs that were just published.
2 Likes
As soon as we have updated the Discord bot, I’ll reach out to each of you individually to help you claim your voting tokens. Once you all have the voting tokens, this proposal will then be submitted to Snapshot for voting. If it passes, we can continue using Snapshot for governance and the queue of other proposals such as PEP-1, PEP-2, and PEP-3 can be voted on.
1 Like
Proposal is now active for voting
This proposal passed with 5 Approvals and 0 Rejections, so I’ll now close the topic.
https://gov.pokt.network/#/pokt-network/proposal/QmRRQK6WrCoSyMjPZwQ3rHnZJJ2n2GY856WUANjskFHL4t
https://ipfs.fleek.co/ipfs/QmRRQK6WrCoSyMjPZwQ3rHnZJJ2n2GY856WUANjskFHL4t
1 Like