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.
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.
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.
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.
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.
@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?
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.
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.
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.
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.
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.