Out of date, please see the latest version here: https://talismanwallet.notion.site/Incentive-Pools-Public-Repository-c892ee8da6ae46e49e6871e092fa217b?pvs=4


Introduction

Talisman Wallet (aka the Paraverse Foundation) is on a mission to build a profitable software product company that can systematically grow and monetise its user-base. This goal is strongly aligned with the Polkadot network as success inevitably means the growth of the Polkadot economy and addressable market for Parachains. As a software company our largest expense is the salaries of the software engineers we employ so naturally when choosing how to leverage their time we strive to be thoughtful and precise by testing and validating new ideas before implementing them. It’s essential that bad ideas fail fast and are scrapped so that only good ideas make it into our roadmap because every feature we build is a bet that costs finite time and resources to execute. Additionally, each feature we build also increases ongoing costs to maintain and support our code and divides our attention, so if the bets we make do not take us closer to sustainability and eventually profitability we will likely fail and disappear.

Under the current treasury status quo there is no established process in which Talisman can solicit funding from the treasury without also compromising on the priorities and operating model outlined above. There are two reasons for this:

1. Cost plus pricing

The outputs of your typical treasury proposal are valued based on the input costs. For example: software is based on the hourly rate of software engineers, and events on the cost of catering, location hire, etc. This a reasonable starting point for pricing services the treasury wants to acquire but it needs to be adapted for a trust free environment where there are no explicit budgets or hierarchal leadership. This creates an incentive for treasury service providers to maximise billable hours rather than systematically figuring out how to create positive outcomes for the network, as the latter often involves experimentation, iteration, and changing course when new information emerges.

2. Output-based success criteria

Success criteria for proposals is typically based on whether the works outlined in the proposal are completed or not, rather than whether they create a desired impact or tangible value. This is fine for once-off projects but implementing success criteria based on impact and results will ultimately be necessary for proven teams like Talisman to be properly incentivised to discriminate over what is true and effective and scale up the ideas that work, as opposed to scaling the work which is maximally billable and popular in the treasury.


Background of the Proposal

On August 2nd I published a post called: Incentive Pools - A novel model for results-based treasury funding to unlock growth for the Polkadot network to Polkassembly in an attempt to start a conversation with the community and treasury governors about these issues which I labeled: “Addressable incentives problems”. It’s my hope that as a community we can agree on a more pragmatic method of treasury funding in which proven teams like Talisman are better incentivised to create value for the network and token holders. I was cautiously optimistic when I published the post but received overwhelmingly positive feedback which has spurned me to develop the idea further into a legit proposal and SEND IT. The original post was reasonably short in comparison to other proposals of similar value but definitely not twitter length. It can be summarised as 3 parts:

  1. An argument why the Treasury to must results-based funding and how the current approach incentivises teams to expand their billable hours and spend unnecessary time on politics.
  2. An idea called Incentive Pools that offers treasury funded teams similar compensation to a commission-based salary package typically used for sales people. Incentive Pools provide basic funding to cover costs with a large upside for accomplishing tangible results.
  3. A technical spec for a prototype implementation of an Incentive Pool that leveraged a multisig, a staking proxy, and a preselected group of curators.

The ideas behind Incentive Pools and my grasp on the issues at hand have improved substantially since my original post thanks to community feedback. In this proposal I will attempt to establish clear framing and build the previous post by covering the following:

  1. A very brief reintroduction to the idea of incentive pools