RFP-4: Build a Discourse Tokenlog Plugin to Enable Pipeline Governance


We recently restructured Discourse with the intent of enabling our community to signal their priorities over feature/proposal requests (i.e. their needs to be met) and to signal how satisfied they are with new releases (i.e. the satisfaction of their needs).

The Discourse Topic Voting plugin lets users upvote topics within a category, up to a vote limit, meaning there is already functionality for users to signal their needs/satisfaction (with vote scarcity enforcing prioritization).

Meanwhile Tokenlog is a new project that is building Snapshot-style upvoting for backlog prioritization by communities, with an initial focus on GitHub issues.


Build a Discourse plugin that merges the functionality of the Topic Voting plugin and Tokenlog, enabling DAO voters to prioritize our ecosystem pipeline in Discourse. This could include settings for:

  • Quadratic Voting: give voters limited set of votes to apply to each topic, with reduced weight for each additional vote that they apply to the same topic
  • Conviction Voting: increase the weight of votes the longer they are applied to a topic
  • Quadratic Conviction Voting: turn both of the above on
  • Approval Thresholds: a threshold beyond which items are “approved”, with some UI indicator to highlight all topics which have been approved


Build a stronger operational foundation for scaling the DAO’s project pipeline.

Objective Key Results

DAO has ability to signal priorities over project pipeline and decide payments based on pipeline fulfilment.

How to Test Progress & Measure Results

  • Measure signaling participation on Discourse hearts vs plugin votes
  • Measure quality of signal (anyone vs voters)

Team Needed:

Leader: @JackALaing (Governance Lead)
Roles Needed: Developers
Other inputs needed: Maybe design (maybe because we should be able to just reuse our existing Discourse elements)

Additional Justifications

We could also use this tooling for whitelists and CampaignNet, using a Discourse sub-category to hold all whitelist submissions and upvotes to prioritize items in the whitelist.

It could feasibly also be used for more continuous signaling on the value of a given parameter (rather than approving discrete PUPs). For example, we could have a sub-category for the parameter, then at any time someone can submit a new topic to the sub-category, with the value that they think the parameter should be, and voters can choose which value(s) to upvote, perhaps with quadratic conviction voting to incentivize them to commit to signaling on one value. These aggregate signals could then be used to help inform the discrete PUPs that are used to actually change a parameter.