Multi Asset Treasury and Milestone-Based Spends

The new Polkadot Treasury version (v1.1) introduces a new feature that enables users to request a spend from the Treasury in any assets held on its accounts across any supported chain, not limited to DOT on the RelayChain. Initially, the Treasury only accumulates assets in DOT, so desired assets should first be acquired through a public referendum to facilitate future spends. However, this aspect is beyond the scope of this document.

With this enhancement comes the need for users to define new parameters. These parameters include specifying the asset requested from the Treasury, the chain on which the Treasury holds the asset, and the asset’s ID. The beneficiary account is specified to receive deposits on the chain where the requested assets are held by the Treasury.

The optional valid_from parameter allows users to set a block number from which the approved treasury spend can be paid into the beneficiary account. Until this block is reached, the spend cannot take effect. This feature enables users to publish a single referendum proposal with multiple treasury spends that will take effect at different times in the future. Each spend can be associated with a milestone; if a certain milestone is not reached, the community can cancel any approved spend until it is paid out. If the valid_from parameter is not set, the spend can be paid out immediately after approval.

Different referendum treasury tracks allow users to spend different amounts from the Treasury. These upper bounds for the tracks are defined in DOT. Therefore, when a spend is requested in a different asset, such as USDT, the Treasury needs to be able to compare it against the amounts in DOT. For this purpose, we utilize an asset rate pallet where the conversion rate is set to compare the requested amount against the upper limit of the chosen track. These rates can now be set with an extrinsic commanded by the Treasurer origin from a public referendum taken on the track with the same name. For milestone-based proposals where multiple spend calls are batched into one, when choosing a referendum track with the associated upper spend bound, users must consider the total amount of all spends.

Unlike old spends, there is no Spend period attached to Multi Asset Treasury spends, and Multi Asset Treasury spend approvals do not trigger automatic payouts. The payout must be manually triggered within 30 days of becoming valid. In cases where a payout fails on a destination chain, such as due to insufficient treasury account balance, the payout can be retried after updating the spend’s status with the check_status call.

The behaviour and API of the old spend call capable of spending local DOT tokens remain unchanged, and is now under the name spend_local.

To illustrate, we have created a step by step example where we submit a proposal to spend USDT tokens from the Treasury account on AssetHub. It’s important to note that while AssetHub has been tested to facilitate such spends, any other chain should be thoroughly tested before use.


  1. I would like to onboard a memecoin as an asset for the Treasury. Where do I start?

First, you will need to make sure that the asset is registered on AssetHub and is supported by existing swap protocols/dapps with sufficient liquidity. Then, you will need to submit your request to onboarding the asset into the Treasury via OpenGov referendum. For reference, here is some sample documentation used for the USDC and USDT referendum: DCA calculation (HydraDX AMM) | Preimage data (Technical info) | Treasury proposal (Referendum info). Finally, you will need to set the Asset conversion rate for your asset if it was not yet.

  1. When should the conversion rate for each acquired asset be set?

This will need to be proposed by OpenGov referendum on the Treasurer track, once the referendum that formally proposes the acquisition of the new assets by the Treasury has been approved and executed.

  1. Is it possible to receive multi asset payouts in a proxy/multisig account?

Yes, multi asset spend payouts can be sent to any account, including proxy, multisig, and sovereign accounts.

  1. What happens if a payout isn’t claimed on time?

The payout will expire and no longer be claimable. The beneficiary will need to submit a new multi asset spend proposal by OpenGov referendum to get the funding approved.

  1. What happens if there isn’t sufficient balance in the Treasury account to cover a given milestone-based payout?

The payout will fail. The beneficiary will need to check the status of the payout on-chain and re-submit a claim at a later date.

  1. When re-submitting a payout claim following a failed payment, will the request get priority access to Treasury funds on AssetHub?

There is no priority processing or queue. Payouts are executed based on the amount available in the Treasury account. It is the responsibility of beneficiaries to ensure that sufficient balances for their requested assets are available at the time they claim the payouts.

  1. On which track should a referendum cancelling a multi asset spend be submitted?

On the Root or Treasurer track, though the latter is recommended.

  1. How can beneficiaries return unused assets to the Treasury account?

Multi asset spend beneficiaries can simply transfer assets that they no longer need to the Treasury account on AssetHub.


Thank you for sharing this overview. :pray:t6:


Nice, that’s great.
We are having a similar concept in the Cardano version of OpenGov, called Project Catalyst where proposals have to provide specific milestones, each with a dedicated budget. Funds are only released after a Milestone has been successfully closed. In regard to Treasury Accountability it is definitely a win and decreases the risk of funded proposers going off once they receive full funds. Tho, on the flipside there is an increased bureaucratic process as Milestones based funding requires an additional review & approval process… Also, tight & fixed Milestones can sometimes slow proposers down and limit them on flexibility to changes.

However, impressive to see that you have built that on the technical layer already, compared to cardano, where milestone processes mostly happen off chain, it’s cool to see how you move the whole thing on chain. Chapeau :slight_smile:


Yes super cool to see an on-chain mechanism. Ditto all the infos that Felix added.

As a Milestone Reviewer in Project Catalyst, I support a bureaucratic process. I do my best to smooth the edges for projects under my purview. There is a lot of variation between Reviewers and their expectations for projects. Simply reading the guidelines and understand scope seems to be lost on some. Different Humans enforce the guidelines to different degrees, which honestly is good to see - definitely not bots :joy:. It can be tough on some projects, but not all. Most projects have chosen to factor into their budget the increased workload to establish, “negotiate”, and approve milestones.

I believe this does increase transparency per Treasury spend, but definitely at a cost. Because of this, the community must be keen on using the data collected in the process. Treasuries are intended to be spent, not hoarded.

The benefits of establishing Milestones Based Funding is an increase in the cohesion of new teams and collaborations. Public goal setting for a team is not a waste of time. An experienced team might not need this level of accountability and the work would slow these Humans down, but due to their experience… it is not hard work to articulate their planned workflow concisely. These breadcrumbs are nice and tell a story about maturity for less experienced teams & community to learn from. On the other side of the coin when accountability is needed, leverage is available and it is not simply a “handshake” grant funded deal that is centrally adjudicated.

Project Catalyst Resources:
How to submit Project milestones
Catalyst F11 Mentor (GPT)


Now we have an updated wiki page with new api Polkadot-JS Guides about the Treasury · Polkadot Wiki