Intermediate

 

How to create Treasury Proposal

The Treasury in Polkadot is a pool of funds generated from various sources such as block production rewards, transaction fees, slashing, staking inefficiencies, etc. The Council governs the use of these funds and decides on the allocation of these funds through a spending proposal process. A stakeholder can propose a spend by reserving a deposit, which will be slashed if the proposal is rejected or returned if it is approved.

The spend period, which is the waiting period before distribution, is subject to governance and is currently set at 24 days. If the Treasury runs out of funds, approved proposals are kept in the queue and will be funded in the next spend period. If the Treasury has unused funds at the end of a spend period, it experiences a 1% burn to encourage spending.

The funds in the Treasury can be used for various purposes, including infrastructure deployment, network security operations, ecosystem provisions, marketing activities, community events, and software development. The Council has the final decision on how the funds are used and their spending is subject to a burn if not spent.

Funding the Treasury​

The Treasury is funded from different sources:

Slashing: When a validator is slashed for any reason, the slashed amount is sent to the Treasury with a reward going to the entity that reported the validator (another validator). The reward is taken from the slash amount and varies per offence and number of reporters.

Transaction fees: A portion of each block’s transaction fees goes to the Treasury, with the remainder going to the block author.

Staking inefficiency: Inflation is designed to be 10% in the first year, and the ideal staking ratio is set at 50%, meaning half of all tokens should be locked in staking. Any deviation from this ratio will cause a proportional amount of the inflation to go to the Treasury. In other words, if 50% of all tokens are staked, then 100% of the inflation goes to the validators as reward. If the staking rate is greater than or less than 50%, then the validators will receive less, with the remainder going to the Treasury.

Parathreads: Parathreads participate in a per-block auction for block inclusion. Part of this bid goes to the validator that accepts the block and the remainder goes to the Treasury.

Creating a Treasury Proposal​

The proposer has to deposit a minimum of 100 DOT or 5% of the requested amount with a maximum cap of 500 DOT as an anti-spam measure. This amount is burned if the proposal is rejected, or refunded otherwise. These values are subject to governance so they may change in the future.

Please note that there is no way for a user to revoke a treasury proposal after it has been submitted. The Council will either accept or reject the proposal, and if the proposal is rejected, the bonded funds are burned.

Announcing the Proposal​

To minimize storage on chain, proposals don’t contain contextual information. When a user submits a proposal, they will probably need to find an off-chain way to explain the proposal. Most discussion takes place on the following platforms:

• Many community members participate in discussion in the Kusama Element (previously Riot) chat or Polkadot Element.

• The Polkassembly discussion platform that allows users to log in with their Web3 address and automatically reads proposals from the chain, turning them into discussion threads. It also offers a sentiment gauge poll to get a feel for a proposal before committing to a vote.

Spreading the word about the proposal’s explanation is ultimately up to the proposer – the recommended way is using official Element channels like the Polkadot Watercooler and Polkadot Direction room.

Creating the Proposal​

One way to create the proposal is to use the Polkadot-JS Apps website. From the website, use either the extrinsics tab and select the Treasury pallet, then proposeSpend and enter the desired amount and recipient, or use the Treasury tab and its dedicated Submit Proposal button:

The system will automatically take the required deposit, picking the higher of the two values mentioned above.

Once created, your proposal will become visible in the Treasury screen and the Council can start voting on it.

Remember that the proposal has no metadata, so it’s up to the proposer to create a description and purpose that the Council could study and base their votes on.

At this point, a Council member can create a motion to accept or to reject the treasury proposal. It is possible that one motion to accept and another motion to reject are both created. The proportions to accept and reject Council proposals vary between accept or reject, and possibly depend on which network the Treasury is implemented.

The threshold for accepting a treasury proposal is at least three-fifths of the Council. On the other hand, the threshold for rejecting a proposal is at least one-half of the Council.

You will notice the “spend period” at the top of the Treasury UI.

Tipping​

Next to the proposals process, a separate system for making tips exists for the Treasury. Tips can be suggested by anyone and are supported by members of the Council. Tips do not have any definite value, and the final value of the tip is decided based on the median of all tips issued by the tippers.

Currently, the tippers are the same as the members of the Council. However, being a tipper is not the direct responsibility of the Council, and at some point the Council and the tippers may be different groups of accounts.

A tip will enter a closing phase when more than a half plus one of the tipping group have endorsed a tip. During that time frame, the other members of the tipping group can still issue their tips, but do not have to. Once the window closes, anyone can call the close_tip extrinsic, and the tip will be paid out.

There are two types of tips:

• public: A small bond is required to place them. This bond depends on the tip message length, and a fixed bond constant defined on chain, currently 1 DOT. Public tips carry a finder’s fee of 20%, which is paid out from the total amount.

• tipper-initiated: Tips that a Council member published, do not have a finder’s fee or a bond.

INFO

For information about how to submit a tip from the Treasury you can read this support article.

To better understand the process a tip goes through until it is paid out, let’s consider the example below.

Example​

Bob has done something great for Polkadot. Alice has noticed this and decides to report Bob as deserving a tip from the Treasury. The Council is composed of three members Charlie, Dave, and Eve.

Alice begins the process by issuing the report_awesome extrinsic. This extrinsic requires two arguments, a reason and the beneficiary. Alice submits Bob’s address with the reason being a UTF-8 encoded URL to a post on Polkassembly that explains her reasoning for why Bob deserves the tip.

As mentioned above, Alice must also lock up a deposit for making this report. The deposit is the base deposit as set in the chain’s parameter list, plus the additional deposit per byte contained in the reason. This is why Alice submitted a URL as the reason instead of the explanation directly: it was cheaper for her to do so. For her trouble, Alice is able to claim the eventual finder’s fee if the tip is approved by the tippers.

Since the tipper group is the same as the Council, the Council must now collectively (but also independently) decide on the value of the tip that Bob deserves. Charlie, Dave, and Eve all review the report and make tips according to their personal valuation of the benefit Bob has provided to Polkadot. Charlie tips 10 DOT, Dave tips 30 DOT, and Eve tips 100 DOT.

The tip could have been closed out with only two of the three tippers. Once more than half of the tippers group have issued tip valuations, the countdown to close the tip will begin. In this case, the third tipper issued their tip before the end of the closing period, so all three were able to make their tip valuations known.

The actual tip that will be paid out to Bob is the median of these tips, so Bob will be paid out 30 DOT from the Treasury. In order for Bob to be paid his tip, some account must call the close_tip extrinsic at the end of the closing period for the tip. This extrinsic may be called by anyone.

Bounties Spending​

There are practical limits to Council Members curation capabilities when it comes to treasury proposals: Council members likely do not have the expertise to make a proper assessment of the activities described in all proposals. Even if individual Councillors have that expertise, it is highly unlikely that a majority of members are capable in such diverse topics.

Bounties Spending proposals aim to delegate the curation activity of spending proposals to experts called Curators: They can be defined as addresses with agency over a portion of the Treasury with the goal of fixing a bug or vulnerability, developing a strategy, or monitoring a set of tasks related to a specific topic: all for the benefit of the Polkadot ecosystem.

A proposer can submit a bounty proposal for the Council to pass, with a curator to be defined later, whose background and expertise is such that they are capable of determining when the task is complete. Curators are selected by the Council after the bounty proposal passes, and need to add an upfront payment to take the position. This deposit can be used to punish them if they act maliciously. However, if they are successful in their task of getting someone to complete the bounty work, they will receive their deposit back and part of the bounty reward.

When submitting the value of the bounty, the proposer includes a reward for curators willing to invest their time and expertise in the task: this amount is included in the total value of the bounty. In this sense, the curator’s fee can be defined as the result of subtracting the value paid to the bounty rewardee from the total value of the bounty.

In general terms, curators are expected to have a well-balanced track record related to the issues the bounty tries to resolve: they should be at least knowledgeable on the topics the bounty touches, and show project management skills or experience. These recommendations ensure an effective use of the mechanism. A Bounty Spending is a reward for a specified body of work – or specified set of objectives – that needs to be executed for a predefined treasury amount to be paid out. The responsibility of assigning a payout address once the specified set of objectives is completed is delegated to the curator.

After the Council has activated a bounty, it delegates the work that requires expertise to the curator who gets to close the active bounty. Closing the active bounty enacts a delayed payout to the payout address and a payout of the curator fee. The delay phase allows the Council to act if any issues arise.

To minimize storage on chain in the same way as any proposal, bounties don’t contain contextual information. When a user submits a bounty spending proposal, they will probably need to find an off-chain way to explain the proposal (any of the available community forums serve this purpose). This template can help as a checklist of all needed information for the Council to make an informed decision.

The bounty has a predetermined duration of 90 days with the possibility of being extended by the curator. Aiming to maintain flexibility on the tasks’ curation, the curator will be able to create sub-bounties for more granularity and allocation in the next iteration of the mechanism.

Creating a Bounty Proposal​

Anyone can create a Bounty proposal using Polkadot-JS Apps: Users are able to submit a proposal on the dedicated Bounty section under Governance. The development of a robust user interface to view and manage bounties in the Polkadot Apps is still under development and it will serve Council members, Curators and Beneficiaries of the bounties, as well as all users observing the on-chain treasury governance. For now, the help of a Councillor is needed to open a bounty proposal as a motion to be voted.

To submit a bounty, please visit Polkadot-JS Apps and click on the governance tab in the options bar on the top of the site. After, click on ‘Bounties’ and find the button ‘+ Add Bounty’ on the upper-right side of the interface. Complete the bounty title, the requested allocation (including curator’s fee) and confirm the call.

After this, a Council member will need to assist you to pass the bounty proposal for vote as a motion. You can contact the Council by joining the Polkadot Direction channel in Element or joining our Polkadot Discord server and publishing a short description of your bounty, with a link to one of the forums for contextual information.

A bounty can be cancelled by deleting the earmark for a specific treasury amount or be closed if the tasks have been completed. On the opposite side, the 90 days life of a bounty can be extended by amending the expiry block number of the bounty to stay active.

Closing a bounty​

The curator can close the bounty once they approve the completion of its tasks. The curator should make sure to set up the payout address on the active bounty beforehand. Closing the Active bounty enacts a delayed payout to the payout address and a payout of the curator fee.

A bounty can be closed by using the extrinsics tab and selecting the Treasury pallet, then Award_bounty, making sure the right bounty is to be closed and finally sign the transaction. It is important to note that those who received a reward after the bounty is completed, must claim the specific amount of the payout from the payout address, by calling Claim_bounty after the curator closed the allocation.

To understand more about Bounties and how this new mechanism works, read this Polkadot Blog post.

FAQ​

What prevents the Treasury from being captured by a majority of the Council?​

The majority of the Council can decide the outcome of a treasury spend proposal. In an adversarial mindset, we may consider the possibility that the Council may at some point go rogue and attempt to steal all of the treasury funds. It is a possibility that the treasury pot becomes so great, that a large financial incentive would present itself.

For one, the Treasury has deflationary pressure due to the burn that is suffered every spend period. The burn aims to incentivize the complete spend of all treasury funds at every burn period, so ideally the treasury pot doesn’t have time to accumulate mass amounts of wealth. However, it is the case that the burn on the Treasury could be so little that it does not matter – as is the case currently on Kusama with a 0.2% burn.

However, it is the case on Kusama that the Council is composed of mainly well-known members of the community. Remember, the Council is voted in by the token holders, so they must do some campaigning or otherwise be recognized to earn votes. In the scenario of an attack, the Council members would lose their social credibility. Furthermore, members of the Council are usually externally motivated by the proper operation of the chain. This external motivation is either because they run businesses that depend on the chain, or they have direct financial gain (through their holdings) of the token value remaining steady.

Concretely, there are a couple on-chain methods that resist this kind of attack. One, the Council majority may not be the token majority of the chain. This means that the token majority could vote to replace the Council if they attempted this attack – or even reverse the treasury spend. They would do this through a normal referendum. Two, there are time delays to treasury spends. They are only enacted every spend period. This means that there will be some time to observe this attack is taking place. The time delay then allows chain participants time to respond. The response may take the form of governance measures or – in the most extreme cases a liquidation of their holdings and a migration to a minority fork. However, the possibility of this scenario is quite low.