PIP-8: Use Coordinape for Contributor & Voter Onboarding



Currently there is only one class of stakeholder (Voter) in the DAO and it is pretty high-friction to enter. Becoming a Voter requires completing a series of quests to level up and verifying their identity on BrightID. The level of friction involved is undermining the engagement of contributors in our community. I am therefore proposing that we recognize a new class of stakeholder (Contributor), which would be easier to enter, and would be a stepping stone to becoming a Voter. This would be administered through Coordinape.


The key motivation behind this proposal is to maximize the engagement of community contributors by minimizing friction.

Specification & Rationale

New Contributor Onboarding Path

The path to becoming an official Contributor will be Coordinape’s vouching system, which will govern access to the POKT DAO gift circle.

Any existing Contributors will be able to nominate new Contributors along with a reason. Then a 14 day period will begin in which other Contributors will be able to vouch for the nominee. If the nominee gets 3 vouches, they’ll be an official Contributor.

This should be pretty low friction compared to our other onboarding paths because it allows members of the POKT DAO gift circle to use their own discretion, rather than being a set of rigid rules like the quest and BrightID verification system.

Adjusted Voter Onboarding Path

The highest source of friction in the Voter onboarding path is currently BrightID, due to it being a pretty arbitrary black box that gives no feedback on what needs to be done to achieve verification. Verification is determined by sponsorship from an app and connections with a minimum number of people depending on their score in the BrightID social graph, where the score is determined by how close they are to the center of the graph. However, BrightID is another community that we don’t have much overlap with, which makes it difficult for our community to verify each other.

The POKT DAO gift circle is also a social graph in a sense, except it is a social graph with only Pocket Network community members. In addition, vouching for a nominee can include assessing whether said nominee is a unique person. Therefore it is my belief that Coordinape could replace BrightID in the Voter onboarding path.

If someone is vouched into official Contributor status, and they get qualified by completing the quests, then they’d be eligible to claim their vote. In this way, becoming a Contributor is a more direct stepping stone to becoming a Voter.

Dissenting Opinions



Coordinape is very easy to use and works out of the box. Currently the Contributor role in Discord will have to be manually assigned after successful nominations but the Coordinape devs are receptive to the idea of updating their Discord bot to auto-assign a role when someone new enters the Coordinape Gift Circle.


If this proposal is approved:

  • I will add all existing Voters to the POKT DAO gift circle, who will then be able to nominate new Contributors.
  • The Contributor role in Discord will be manually assigned by me when new people are inducted into the POKT DAO gift circle
  • BrightID will be removed from the Voter onboarding path and replaced with the Contributor role


Copyright and related rights waived via CC0.


I love this idea but I would passionately suggest the following.

Value our Values.

Instead of attempting to build a reputation/reward system based on the estimated value of an output, we should instead think of how to align the “way we work” and value that.

Risks of output based merit.

  • flashier stuff gets valued more
  • complex contributes limits the ability for others to fairly value
  • timing matters, if the SME’s are busy or if there are parallel workstreams that need someone’s limited attention, it is not valued the way one believes it should be.

All of these things lead to an inaccurate estimation of the value of our social network and run a high risk of a political climate that is more about campaigning to the invisible power structures then it is about collaborating for the common good.

Values in an organization are already established for the purpose of aligning around “the way we work”

My fundamental assumption for putting this forward is this.

“If the values are comprehensive and widely acceptable, then valuing them at the core of a rewards system will not only create the outputs we believe will result in a better ecosystem and product(s), but also the culture that will give it sustainability.”

I believe valuing the values will do the following.

  • Allow the majority of contributors to fairly determine the merit of a given work
  • Minimize the political/output driven evaluations and there risks.
  • Create and environment where values are always at the top of the conversation which in the long run will make the culture outputs more sustainable and autonomous.
    - does there need to be more documentation/explanations?
    - do some need to be made more clear, added or removed?

It keeps the most important aspect of a community “culture” the top of mind, because people’s rewards depend on it.

What would be needed.

Exercise with the values as they exist to see what aspects need to be reworked, removed, added, or additional education (examples, documentation, etc) to see.

Dissenting Opinions

The values as the are described now won’t work

Excellent, sounds like our new growing community should do an exercise to iterate on them in a way that makes them able to be demonstrated in a merit system.

Demonstration of the values does not account for domain expertise

This may be true, but a community rewards system does not need to solve for this.

We have other mechanisms that are better suited for that anyway, the DAO proposal system and VC funding are two examples. What a community rewards system should optimize for is decentralized autonomous organization, literally. You do this by focusing on “how we work” not “what we work on and how hard we believe it is to get done.”

You can see in the language of output driven rewards system that it will inherently create separations, and classism.

I would also add the values can be described in a way that is inclusive of difficulty or expertise required. For example some the concept/elaborations around a value like “relevancy” focuses contributions and their subsequent rewards throughout time.

Interpreting the demonstration of a value is more subjective then an output.

I believe this is a risk if the language, context, education and support that exists anyway, but the sbutle beauty of using the values in this way is that it is a forcing function to make them explicit enough to be widely accepted.

I would also argue that is possible to make there demonstration more objective, using “remove dependencies for others” as an example we can refine that language and context to result in a culture where every contribution is documented, curated into single sources of truth and embedded into our commons channels such that new people do not need to start from scratch and take others time.

Using ROSE bot as an example. you could say “rose bot took X amount of time to set up and required these skills therefore it is worth Y” which is very zero-sum gamey.

Or you could say “Rose bot enabled community members to rapidly onboard and educate new members on the most common questions, as a result saving the core team hours a week which they can spend on providing deeper compounding value to the community”

Which is more valuable? The skills it takes to set up a bot, or the empowerment of others because of it?

In conclusion

They’re called Values for a reason, Value them.

Pocket’s values currently.


I conditionally support this proposal.

I read through the Coordinapes docs several times trying to find the answers to my question, but could not. I love the ease of use spelled out, I love the social graph aspect, and I love the vouching system, which I think can be a useful replacement for BrightID, driven by participation in our community versus participation in theirs.

Here are my questions:

  1. I don’t see any mention of the usage of the Coordinapes GIVE token, which is used for token distribution at the end of each Epoch. Does this proposal intend to be a precursor for usage of that system? If so, it raises a number of other questions regarding distribution models that may or may not be appropriate here.

  2. If the answer to item 1 is yes, can Coordinape be configured in such a way that it would distribute pokt via a network transaction versus an ETH based token via Metamask?

1 Like

There are a number of points in here that merit discussion, and you touch (in spirit) on some of the things I outlined in my comment on PEP-16. Given that the scope of this proposal seems focused on the vouching and onboarding system, whereas PEP-16 focuses on the actual Contributor model, would you be willing to move (or copy) this comment there, so we can keep the concerns regarding distribution all in one place?


I think this proposal works for where we are now and the issues we need to address with our current on-boarding.

Just like we are tweaking our DAO on-boarding now, we can grow and change as the needs arise.

Most important right now is to have a DAO that people can understand and there is a clear path. Right now we struggle in these areas. This much more approachable right now, but will no doubt require optimizing in the future.


Yes, it is assumed that this proposal is a precursor to PEP-16: Universal Contributor Income, which will use Coordinape to distribute rewards.

Yes, Coordinape is agnostic of the payment method. Here is the Coordinape allocation lifecycle as described in their docs:

  • At the start of the epoch, each member of the Circle receives a number of non-divisible GIVE tokens (Determined by the Circle Admin)
  • Members allocate their GIVE tokens to other members over the course of the epoch to reward them for the value they bring to the Circle
  • Members can adjust their allocations up until the end of the epoch
  • They can add notes to their allocations if they wish
  • At the end of the epoch, all allocated GIVE tokens become locked (now called GET tokens), and all unallocated GIVE tokens are burned
  • Budget distribution is then formulated according to the percentage of total GET tokens that each member of the circles has received

So to summarize, at the end of the epoch, we will have a % allocation for every contributor, which we can then use for payment of any token (wPOKT/POKT).

1 Like

Thanks for this thoughtful feedback, I’ll reply in the other proposal.


Yep, this is generally my perspective. Let’s keep it simple, learn from using this, then evolve.


An additional piece of context to note here is that the Pocket Network organization can have multiple gift circles in Coordinape.

CleanShot 2021-12-11 at 20.01.47@2x

I have renamed this gift circle to POKT DAO to reflect that it is the broadest circle in our ecosystem. I have also edited the proposal above to reflect that becoming an official Contributor will require being vouched into this POKT DAO gift circle, so there is no doubt whether being vouched into other Pocket Network gift circles qualifies.


It’s important to note, in case this isn’t clear, that if this proposal passes it means that only people who have been nominated/vouched into the POKT DAO gift circle in Coordinape will be eligible for a vote in the DAO.

1 Like

This proposal is now up for voting



This proposal has passed! https://cloudflare-ipfs.com/ipfs/QmQHTSZccgDHrzfWwdsYMbtTvVgJHWin22N6teAd6tg8cK

Coordinape will now be used instead of BrightID for voter onboarding.

I will be implementing these changes in the new year because I’m starting my honeymoon on Friday and I believe that launching a new process during the holidays will take the wind out of its sails.

Happy to reconsider this implementation plan if there are objections!


It’s been a long time coming but I can finally say that we have implemented this proposal (in spirit, better than the original specification).

We waited on Coordinape to add some features that are crucial for our use case (which is admittedly not Coordinape’s intended purpose) but have concluded that we just need to run with our own custom system that works the best for us.

Some things that were missing from Coordinape that made it a dealbreaker for this onboarding/verification use case:

  • A visual UI for existing circle members to see the full circle - only admins have any view of the organization, which recreates the black box we tried to get away from
  • No automatic Discord role assignment, which creates another manual bottleneck in the form of Discord admins who must assign the role when someone’s Coordinape vote has passed
  • A direct connection between the evidence being posted in Discord and the voting taking place within Coordinape - which makes it more likely that voters would verify someone who didn’t provide adequate evidence

Instead, we’ve opted for a custom Discord bot that creates simple :white_check_mark: emoji votes when community members submit the !verify command to the #verify channel, then automatically assigns the Verified role if the vote gets 33% approvals from existing voters.

This is not the Implementation that was explicitly approved in this proposal but in my view it mirrors the mechanism in a more intuitive way that will vastly improve the onboarding experience for new voters. I have not put this substitute to a vote because we have a number of important proposals waiting to go up and a number of new voters who are blocked by BrightID. If the Voters disagree with this, a proposal may be submitted to reverse this implementation and opt instead for another implementation. The current voting period (7 days) and threshold (33% of voters) will also be modifiable by PIPs.

You can find more details about the new verification mechanism here: Claim Your Vote - Pocket Network

1 Like