# Multi Asset Treasury proposal ## Introduction There have been conversations and threads on the forums about what teams will like to see in the future of the Treasury and Statemint. Some of these conversations could be summarized to the following expectations from a treasury. A Treasury system should: - Accept and operate on multiple different assets and asset classes, so long as they implement certain trait bounds; - Function across multiple chains with asynchronous communication; - Provide a spend mechanism whereby users can propose spending any of the asset classes from the Treasury (https://forum.polkadot.network/t/a-better-treasury-system/291). This document is related to [META: Moving the Treasury Off the Relay Chain](https://github.com/paritytech/polkadot/issues/5293) and tries to help shape a concrete course of action. ### Treasury on Statemint The Treasury on Statemint will hold several assets: - The Relay Chain's native asset, i.e. DOT; - Any Fungible assets on Statemint, e.g. USDT; - Non-fungible assets registered on Statemint; - Native assets of other chains under the same consensus system, e.g. CFG; - Native assets of bridged chains, e.g. KSM. ## Proposed Course of Action ### Getting Assets into the Treasury on Statemint An instance of the Treasury pallet on Statemint will hold most of the Treasury spend related logic. Because the tokens in the Treasury come from transaction fees, inflation, slashes, etc, which happen in the Relay Chain, there will be need for a mechanism to move these assets from the Relay Chain into Statemint, and we propose doing this via logic that runs in `on_initialize` periodically (e.g. daily) and teleports the assets from the Relay Chain to Statemint. ### Managing Asset Allocation in the Treasury TODO, the Treasury should have means to: - Acquire assets in means beyond passive reception (e.g. to make a swap in a DEX); - Use assets in means beyond spending (e.g. provide liquidity to a pair in a DEX). ### Spending Assets in the Treasury There are currently a few ways of spending from the treasury; treasury proposals, tips, bounties, etc. But the Treasury pallet currently assumes operation on a single or specific asset class. But to get closer to the previously stated expectations of a Treasury, it must be possible to spend other asset classes which may also be controlled by the Treasury. To support spending other asset classes, a new (Mult Asset)Treasury pallet will be created around the `fungibles` traits. It will have spend method which will also accept an asset_id. THe rest of it's behaviour will be the same as the current behaviour, but will be built around the `fungibles` traits for operation on specific assets: ```rust= pub fn spend( origin: OriginFor<T>, asset_id: T::AssetId, #[pallet::compact] amount: BalanceOf<T, I>, beneficiary: AccountIdLookupOf<T>, ) -> DispatchResult { ``` #### Treasury Spend Proposals in Other Tokens (e.g. Stablecoins) This version of the Treasury pallet would support treasury proposals where the spend is defined in any supported asset. The treasury spend proposal referenda will be to send an XCM message to Statemint with the treasury spend extrinsic. This call will need an update to accept an asset identifier. #### Handling Spend Proposals with Insufficient Balance In the case that a spend proposal passes but the Treasury does not have enough of that asset, there are a few options: 1. Fail the proposal; 2. Put the proposal back into the referenda queue awaiting a decision deposit; 3. Have a fallback acquisition mechanism as part of the configuration. For example, if a USDT proposal passes, the Treasury could attempt to swap its DOT for USDT in the DEX. #### Some preliminary steps - Introduce `fungibles::InspectHold` and `fungibles::MutateHold` traits (They only exist for `fungible::*`) - Implement `fungibles::InspectHold` and `fungibles::MutateHolds` and `fungibles::Unbalanced` on the assets pallet - Introduce a `multi-asset-treasury` pallet which is built around the `fungibles` traits (The current treasury pallet will be built around `fungible` and not `fungibles`) - Initialize said pallet on statemint, configured via xcm to support both local and foreign assets on statemint - Support configuring a whitelist of of assets which can be spent via the treasury - Setup a means to teleport assets from the relay chain `treasury` to the new `treasury` pallet instance on statemint - Configure/Implement a means of exchanging assets of statemint for other assets which might be needed for treasury proposals. ## Unresolved Questions 1. Should the acquisition(exchange) of assets by the Treasury to support proposals defined in other asset classes be a synchronous or asynchronous process? 1. This document currently assumes a synchronous fallback acquisition, but some token exchange approaches(eg [TWAMMs](https://www.paradigm.xyz/2021/07/twamm), etc) are only practical asynchronously.