Bounty Proposal: Bounty: The Genesis Incentive Pool

Proposer: [Polkadot/Kusama Address with an On-chain identity]

Date: 14.09.1993

Requested allocation: 999,999 $DOT

Proposed Curator reward: 1%

Short description:  A bounty to implement an incentive pool for Talisman Wallet


Introduction

This proposal aims to offer a credible plan in which Talisman can utilise treasury funding to generate superior outcomes than is currently feasible with status quo treasury practices by implementing a novel concept called an Incentive Pool. In addition to generating better results it can also provide a pathway to financial sustainability and independence for Talisman, as opposed to deepened dependence on the Treasury which would occur as a natural side effect of the current incentives presented under the treasury status quo.

The Problem

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 efficient by validating new ideas before spending time 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.

Despite the obvious benefit Polkadot ecosystem if Talisman is successful in it’s mission, under the current treasury status quo there is a very strong incentive to discard the operating model outlined above which emphasises the creation of a high-quality product and novel methods of influencing new users to adopt it in favour of simply maximising the size and scope of proposals which has the potential to spurn a race to the bottom for everyone. This is caused by two addressable issues:

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, hierarchal leadership, or principal in charge. In the absence of a principal agents (treasury service providers) try 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.