Treasury
The Treasury is a pot of funds collected through a portion of block production rewards, transaction fees, slashing, and staking inefficiencies.Treasury funds are held in a system account that cannot be controlled by any external account; only the system internal logic can access it.
If you would like to create a treasury proposal on Polkadot OpenGov, follow the instructions outlined on this how-to guide.
Treasury Inflow and Outflow
Tokens that are deposited into the Treasury (i.e. the inflow) is determined by the following mechanisms:
- Transaction fees: 80% of the transaction fees of every submitted extrinsic is diverted to the Treasury, while 20% is given to the block producers.
- Staking inefficiencies: the network knows an exogenously determined parameter called ideal staking rate. The APY for stakers (nominators & validators) decreases whenever the actual staking rate is not equal to the ideal staking rate. To keep inflation constant at 10%, the system does not creates less tokens, rather some share of the overall reward for stakers is diverted to the Treasury (more information here).
- Slashes: whenever validators and nominators are slashed, a share of the slashed tokens are diverted to Treasury. They are typically rare and unpredictable events.
- Transfers: everyone can send funds to the Treasury directly. This is a rare event and typically due to grantees reimbursing some of the amount they got allocated for various reasons.
The outflow is determined by the following mechanisms:
- Burned tokens: at the end of each spend period % of the available funds are burned.
- Treasury proposals & Bounties: they make up the largest share of outflow tokens to the community and need to be approved by governance. Then, payouts occur at the end of a spend period.
- Tips: smaller payouts directly to grantees that can happen within a spend period.
On Polkadot-JS UI, navigate to Governance > Treasury to view the status of current spend period.
Treasury Tracks
OpenGov allows for managing funds through six tracks, each with its own origin and track parameters.
Access to Treasury funds requires successful enactment of referendum in the respective treasury track on-chain. Learn how to submit a treasury proposal for referendum here.
Bounties
Parent Bounties
Getting treasury funding through OpenGov, depending on which treasury track you submit your referendum, can be a long and uncertain process. This is not always a suitable option, for example, for event organizers who need to pay costs upfront or close to the event's date. Bounties solve this problem by procuring access to treasury funds in a single shot and using them to fund multiple events later on through child bounties. This is why bounties are also called parent bounties.
Parent bounty proposals aim to reserve a portion of treasury funds once, which will be used later. They save proponents the time needed to create and obtain approval for several OpenGov referenda. Bounties are managed by curators, where the curator is usually a multi-signature account. Bounties can access a large amount of funds, so managing those funds with a multisig is a good practice to enhance security. Essentially, curators are multisig addresses with agency over a portion of the treasury to promote events, fix a bug or vulnerability, develop a strategy, or monitor a set of tasks related to a specific topic, all for the benefit of the Kusama ecosystem.
A proposer can submit a bounty proposal to OpenGov, with a curator to be defined later, whose background and expertise is such that they can determine when the task is complete.
When submitting the value of the bounty, the proposer can specify a fee that will be paid to curators willing to invest their time and expertise in the task; this amount will be included in the total value of the bounty. In this sense, the curator's fee can be defined as the difference between the amounts paid to child bounty awardees and the total value of the bounty.
Curators are selected through OpenGov referendum after the bounty proposal passes; and they need to pay an upfront deposit to take the position. The deposit is calculated by multiplying the curator fee by %, and it can range between a minimum of and a maximum of . This deposit can be used to punish curators if they act maliciously. However, if they are successful in managing the bounty to completion, they will receive their deposit back, and part of the bounty funding as a payment for their efforts.
Curators are expected to have a decent track record in addressing the issues the bounty wants to solve. They should be very knowledgeable on the topics covered by the bounty and have proven project management skills or experience. These recommendations help ensure an effective use of the bounty mechanism. A Bounty is a reward for a specified body of work or set of objectives that needs to be executed for a predefined treasury amount designated to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator.
The bounty has a predetermined duration of days, with possible extension(s) to be requested by the curator. To maintain flexibility during the tasks’ curation, the curator will also be able to create child bounties for more granularity in the allocation of funds and as part of a nested iteration of the bounty mechanism.
Child Bounties
Child bounties are spawned from parent bounties. Child bounties are used to access funds directly from the parent bounty without going through an OpenGov referendum.
If you are an advanced user, see the Polkadot-JS guides about bounties and treasury.