PGOV5 - Builder Specification

Pocket exists to bring unstoppable, open data to the world. That’s the impact we want to have. The word impact captures the essence of what we are all trying to bring to Pocket and gets us to a simple truth: effort is nice but only sustained impact can see us achieve our grandest ambitions. Do or do not, there is no try.

Anyone creating impact is a Builder and our new governance system uses the term Builder in this way. Builders of the protocol. Builders innovating or experimenting us forward with Sockets. Builders passing proposals that direct funds or change parameters. Each of these builders relies on the other, and like all great open source projects, each builder benefits from the builders before them. We stand on the shoulders of giants.

Proof of Participation has always aspired to recognise the most knowledgeable and impactful members of our community in our governance system. Here, we plan to enshrine the importance of impact and Builders explicitly within the new system.

Technical requirements:

We propose that different types of impact are recognised within a set of Builder credentials. For this first iteration we propose eight (8) credentials of different values to build a reputational impact score which translates to governance power in the DAO.

The 8 credentials we propose are:

  • Protocol Builder - A builder creating impact by having PR’s merged to the Github repos of Morse and Shannon
  • Priority Builder - A builder submitting to or delivering on our open priorities (POPs, RFPs)
  • Socket Builder - A builder experimenting or pushing forward innovations through the Socket mechanism
  • Proposal Builder - A builder who has had a proposal passed or implemented
  • Bounty Hunter - A builder completing bounties for Pocket (which will be reinvigorated via Dework)
  • Thought Leader - A builder who has attained a Gold or Silver Badge in Discourse through their contributions to our governance discussions
  • DAO Scholar - A builder who has completed a Scholarship as set out in PEP31

And lastly the:

  • OG Governor - A DAO Voter migrated from the previous system, with the maximum impact score possible in the previous system (10 points = 1 whole vote)

Each credential will have a certain number of points (expressed in the technical specification below) and a Builder can accumulate points across the different Builder credentials up to a maximum of 10 points.

In this way, 10 points becomes 1 vote, creating a proportional representation system within the Builders house.

The total voting power of all Builders can never be more, or less, than 45% of the total voting power of the DAO.

Technical Specification

Below are the Credentials we want created for our MVP:

  • Protocol Builder - 5 Points (5 Points for Merged PR to Morse or Shannon Repos)
  • Priority Builder - 5 points (1 Point Approved Submission, 2 Points Awarded to Winner, 5 Points rewarded on Completion)
  • Socket Builder - 2 Points (1 Point Open, 2 Points after 2 Self Reports)
  • Proposal Builder - 5 Points (2 Points Passed/Approved, 5 Points Implementation)
  • Bounty Hunter - 1 point (Upon completion of bounty payment)
  • Thought Leader - 2 points (Discourse Gold/Silver Badge )
  • DAO Scholar - 2 Points (Upon completion of Scholarship payments)
  • OG Governor - 10 Points (Migrated Voter from previous system)

A Voter can earn as many credentials as their reputation allows for. However, governance power is only awarded up to 10 Points (the equivalent of 1 full vote) and only one credential in each of the 8 categories above can contribute to voting power (that is, you cannot earn 10 points just from bounties (1x2) or Proposals (5x2) or Sockets (2x5) for example).

This logic is for the MVP only and may change in future via the approved metagovernance process to be defined in a future specifications.

The Credentials and how they are recognised:

Credential: Priority Builder

Evidence: Submitted a response to a POP in the forum
Data Source: POP Discourse Forum Thread
Automated: No. This will be permissioned by PNF

  • 1 Point approved Submission to POP/RFP
  • 2 Points Winner of POP/RFP
  • 5 Points Winner successfully completes POP/RFP (based on final payment release)

Credential: Socket Builder

Evidence: Open (and maintain) a Socket in the forum
Data Source: Socket Discourse Forum Thread
Automated: No. This will be permissioned by PNF.

  • 1 point at Opening of Socket
  • 2 points after 2 self reports

Credential: Proposal Builder

Evidence: Funded (Approved) proposal from Snapshot
Data Source: Discourse Forum & Snapshot
Automated: No. This will be requested by the Person and approved by PNF.

  • 2 points on Proposal Passing
  • 5 Points at Proposal Implementation/Completion (based on parameter change or final payment)

Credential: Protocol Builder

Evidence: Merged PR in whitelisted Github repos for Morse and Shannon (exact repos, how often)
Data Source: Github Repos
Automated: No. (But likely to be automated in future)

  • 5 Points (upon successful merge of the PR to the Morse or Shannon Repos)

Credential: Bounty Hunter

Evidence: Completed Bounty recorded in Dework
Data Source: Dework tickets
Automated: No (Permissioned by PNF for now)

  • 1 point (based on completed payment via Dework)

Credential: Thought Leader

Evidence: Silver or Gold badge in Discourse
Data Source: Discourse Badges
Automated: No (Possible Discourse integration in future)

  • 2 points (based on evidence of badge issuance in Discourse)

Credential: DAO Scholar

Evidence: Completed a Scholarship in the DAO (reference PEP#)
Data Source: Discourse Forum
Automated: No (Manual whitelisting)
Weighting: 1 point

Impact rules

Builder credentials will be issued to a Gateway ID wherever the evidence criteria are met. However, governance power can not be laddered through repeating impact activities in a single area, the simplest example of which is to say you cannot get the maximum 10 points by completing 10 Bounties (1 point each). This requires further iteration and will be defined further within the metagovernance process in a subsequent specification

Decay/Expiry specification

Builder credentials will be set with an expiration date of 6 months from their issuance. Their power will be set to zero after the expiration date, meaning that credentails only provide governance power for 6 months. In this way we create a dynamic representation system that rewards current and continuing contributions to the network. Further details will be provided in the metagovernance specification.

Issuance & Permissioning

PNF will build a set of procedures for issuance of the included Builder credentials. They will issue the credentials to the relevant ID or wallet, depending on the type of credential. For example, the Socket Builder credential will be issued to the same wallet included in the Socket Request topic when opening a Socket. We will provide further details before launch to ensure builders know how and when their credentials will be issued


I assume the Decay/Expiry rule won’t affect the OG Governor role. Isn’t it?

1 Like

This seems a little fast given the sources of points, most of them will take months to be earned (PRs, Sockets, proposals approvals)


Thanks for the feedback. The parameter settings are open questions so:

I don’t disagree. We want to have a dynamic system without making it too complicated. If 12months felt more appropriate we would be open to that

The OG Governor role should also be dynamic and participating regularly should be part of keeing the OG Governor role. So Decay/Expiry will affect this credential but we can also set an agreed parameter to account for any variance from other credentials if the community and existing DAO voters feel it is necessary.


That literally makes sense and would be an excellent improvement!

1 Like

I would like to see decay/expiry to embody actual decay more. The model right now heavily focuses on quantitative contributions but doesn’t have a creative way to factor in impact and effort over time. How about some common builder dilemmas such as burnout and short hiatuses?

I lean towards once the reputation has been proven, it should remain or “decay” reasonably, which reflects the term credentials a lot better IMO. I would advocate for a slow decay - not a full-on expiration. Otherwise, you can go from having a voice in governance by doing a kickass job at contributing to Shanon to then not having a governance voice after 6 months to a year - if you’re burned out. This could also have unintended side effects where contributors feel like they have to “farm points”/ press out low-quality contributions, content, or PRs just to maintain the status quo.

Another concern with the full-on expiration is that we may see major blackouts depending seasonal periods, depending on when they gained their points (i.e December holidays where contributions are likely to be low). It would suck to lose all my points in December and not have enough time to regain them all in time for an anticipated snapshot vote.

Maybe… some others…
every X months to maintain existing credentials you…:

  • earn at least one point
  • some manual check-in process to self attest / other existing builders attesting to credentials
  • excess points you can gain to factor in decay

Of course, this comes with some cons as a lot of these credentials are verified via a human component so definitely open to other ideas too if anyone has any! I don’t have a solution for this, just wanted to write down my thoughts as a builder, but don’t think these types of scenarios are exclusive to builders.

(sorry for terrible formatting - am on mobile)


Thanks for the depth of this reply. It definitely gives us helpful detail as we think about how to create the right representation of impact across both history and current context. Creating a decay functionality is a technically challenging part of the implementation, but this is a helpful reminder for us find the right balance between what is desirable an what is feasible.


Thoughts on Decay:

  1. I agree with a @poktblade that too steep a cut in people’s voting power is going to bring volatility. The extreme being when many OG voters with10 points all lose their OG status at the same time. Some will have done other things to keep some points, but it would be a major drop.

  2. As @RawthiL says- given it may take several months to gain voting points, losing them 6 months later seems overly harsh.

a) points are held for 12 months before decay starts.
b) decay is linear and gradual: after 12 months, each task’s accrued points start to decay at the rate of 1 point per month.

Bringing in stepped decay allows for Citizens to ‘top up’ their voting power without a swift loss of voting which may deter people from consistently engaging.


I think this is reasonable. We will present some updated thoughts on parameters next week but currently everything is set to 12 months before expiry.


I agree with @poktblade here. In addition, can’t a contribution become more valuable over time without continued effort? For example, will the contributions by the builders working on Shannon no longer be valued after 6-months unless they continue adding something?

Hey @b3n, have there been updates that address the above comments from @poktblade and @Cryptocorn? This discussion crosses a number of posts - so I might have missed it.

1 Like

Hi @steve the expiry periods were extended in the final proposal, with all contributions apart from a bounty (3 months) or two months of contributing to a socket (6 months) having a 12 month expiry now.

This is much more lenient than beforehand, and the expectation is that PNF will work with the community to onboard more credentials over the 12 months post-launch so that anyone who is 1) capable of delivering impact to the ecosystem and 2) has the interest to do so, should be able to extend their governance power relatively easily within the 12 months after Creds is launched.