META: Moving the Treasury Off the Relay Chain

[joepetrowski]

Note: This would affect Substrate, Polkadot, and Cumulus repos. Logging the issue here as it practically has the biggest impact to Polkadot, but expect most associated issues/PRs to be in other repos.

As part of the Common Good parachains roadmap, we'd like to move functionality from the Relay Chain into parachains. In the case of the Treasury, this move would have the dual benefit of taking some load off the Relay Chain and expanding the functionality that the Treasury can offer.

There are arguments for a few parachains to which to move the Treasury, like a governance parachain or Statemint. For the purposes of this issue, I'm going to assume Statemint, but if there are convincing arguments to put it elsewhere then let's change that.

Here are some changes, new features, and challenges that I foresee in making this happen:

Getting DOT/KSM Into the Treasury

The Treasury primarily accumulates its holdings via inflation on era change (once per era), transaction fees (every transaction), and slashes (occasionally). Since eras and slashes are still handled on the Relay Chain and people still transact on it, it still makes sense for the Treasury to maintain an account there.

It would be overkill to send messages for every transaction into the parachain. One suggested solution: add to the on_initialize of the Staking pallet to teleport all DOT/KSM to the Treasury on Statemint. This would be a daily (or 4x daily) transfer of the native asset of the Relay Chain.

Getting DOT/KSM Out of the Treasury

Several mechanisms exist to get DOT/KSM out of the Treasury, primarily:

• Treasury proposals
• Tips
• Bounties (+child)
• Regular burns

These pallets will need some tweaks. They are designed to accept proposals/tips in the native asset of the chain. One of the advantages of a Treasury on Statemint is that it could hold other assets. Users should be able to make requests for other assets, and governance should have the ability to manage asset holdings of the Treasury and acquire other assets.

Burning should be relatively unchanged, it will just need to check in with the Relay Chain to update TotalIssuance.

Multi-Asset Holdings

Holdings

The Treasury should be able to hold:

• Its Relay Chain's native asset
• Fungible assets registered on Statemint
• Non-fungible assets registered on Statemint
• Native assets of other chains under the same consensus system (member parachains)
• Native assets of bridged chains (e.g. DOT in Kusama Treasury)

Of course, governance should have the say in which assets the Treasury can hold. And of course the list can go on with e.g. NFTs registered natively on other parachains, this list is just a starting point.

Multi-Asset Spending and Acquisition

Of course, the Treasury shouldn't be limited to holding other assets, it should be able to spend them, and will need the means to acquire them.

There are a few issues to sort out:

• Governance origin to decide on when to acquire another asset (assuming super-majority Council in Governance v1 and some medium/high privilege origin in v2)
• Means of acquisition. Open to ideas here, but what I have in mind is that the Treasury states its intent to acquire an asset by some block number, and other accounts/parachains can send offers.
• Should proposals only be accepted in assets that the Treasury holds? Or should they be accepted on the assumption that the Treasury will acquire the proposal's asset after approval (and it would be on the approving stakeholders to judge whether acquisition is possible/reasonable)?

[burdges]

At some point sure but.. Is there much traffic on the treasury? Assuming no we might focus first upon heavier stuff like elections, although maybe that's harder.

We do not have a good system for selecting collators for essential parachains yet. We could discuss doing so of course, but not sure they'll all work out the same honestly.

[joepetrowski]

There's not a lot of traffic, but it still makes sense to isolate. This also moves logic into an existing parachain and can mostly be done in FRAME, while elections is a whole new parachain. Won't get into a priority argument, but I don't see how working toward this prevents working on an elections parachain as well.

[burdges]

We're maybe not too worried about liveness for statemint, but what about capture? How does one become a collator?

[joepetrowski]

By reserving DOT and declaring intent to collate, on a FCFS basis. It's a system we've wanted to update and perfectly fair to open an issue to discuss that, but how does it relate to this issue?

[burdges]

Ain't so easy to use DOT staking on a parachain because if adversaries could choose between being a validator or a collator then adversaries could monopolize being collators so they could capture the parachain.

We'd prevent permanent capture with erasure coded state checked points, but even temporary capture makes essential parachains tricky.

It's avoidable if parachains have minimal state aside from their blocks, like elections.

We should consider what happens to the treasury, or even say staking, if they become unavailable for an epoch or so, due to capture. If it's fine, then we could randomly churn some nodes into being collators somehow, and ensure they could join using erasure coded check points.

[joepetrowski]

Sure, those are all fair points about parachains in general, but it's really off topic for this issue. I never said that this is higher priority than anything else, like staking/governance/etc, nor that the collator selection mechanisms are perfect (they are definitely not, and actually should be revisited). I made paritytech/cumulus#1159 for further discussion on that topic.

This issue is a rather large task with open questions about Treasury design, let's keep this thread focused on that.

[olanod]

Means of acquisition. Open to ideas here, but what I have in mind is that the Treasury states its intent to acquire an asset by some block number, and other accounts/parachains can send offers.

@joepetrowski Don't fully understand this, you mean the Treasury says "we want to collect X amount of Y token" and parachains and individuals bid saying "I'll give you the Y tokens for this much KSM"?

Another idea I mention in a section of our Kreivo common good chain proposal is to supercharge the treasury and view it like a decentralized VC that decides via governance how to "diversify its portfolio", an "investments" subsystem could define a strategy on how to progressively convert the native token reserves to other assets based on the public's opinion, perhaps the new conviction voting system could work for this? based on how much conviction people put on a specific asset the treasury could trade tokens automatically. The trading part might be tricky though, It's in the scope of a parachain like Kreivo to have a x-chain DEX but not for Statemine so trading via XCM in a set of trusted DEXes could be an option but also brings more complexity.
Acquiring tokens would be only the beginning, what I find more interesting is the spending part and how to make it more convenient to support projects in the ecosystem with a system like the payments pallet. This also opens the opportunity for projects to seek funding without relying on centralized capital.

[joepetrowski]

Don't fully understand this, you mean the Treasury says "we want to collect X amount of Y token" and parachains and individuals bid saying "I'll give you the Y tokens for this much KSM"?

Indeed. More details in the Cumulus issue linked above.

[gilescope]

I’m not sure the treasury should try and be a VC. That requires picking sides / winners. In my opinion the focus for the treasury should be on neutrality where practical.

…

On Tue, 21 Jun 2022 at 12:30, joe petrowski ***@***.***> wrote: Don't fully understand this, you mean the Treasury says "we want to collect X amount of Y token" and parachains and individuals bid saying "I'll give you the Y tokens for this much KSM"? Indeed. More details in the Cumulus issue linked above. — Reply to this email directly, view it on GitHub <#98>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEJCDDYDQ26B5FTLXB7A3VQGRVVANCNFSM5S4KVIWQ> . You are receiving this because you were assigned.Message ID: ***@***.***>

[olanod]

@gilescope I would agree with you if the decision is to be taken arbitrarily and subjectively by a few designated individuals, but we wouldn't have to pick sides if a system follows deterministically the "will of the people" no? overtime it could become a more complex system that takes more factors into account like data coming from oracles, "KPIs"/goals set by the on-chain government, the will of a future AI overlord and what not. Aren't real world governments also investing strategically in different industries or spending public resources in programs that aid bootstrapping local companies? Similarly the list of eligible projects could be limited to early stage ones that haven't received previous funding, but that's just to say that there are many ways this investing mechanism could be implemented in practice.

[burdges]

I doubt VC is a useful term here. Afaik, the treasury won't be doing what VCs actually do. It's closer to government spending i guess.

I doubt the treasury could ever usefully spend money on marketing or promotion, for example.

It's likely parachain projects do ask for treasury funding for software work the project feels to be common good, but the community feels to be too project specific, and thus the community asks for tokens, but..

It might make sense doing this occasionally, but imho any project who winds up in this situation might fair better with a VC who then spends not only tokens but their own time.

I do however think the treasury should hold the tokens of some projects in which it invests, but more tokenized physical assets like land used for agrivoltaics or rewilding carbon credits. In principle, these might emit on-chain assets somehow, some of which require messy oracles, but some like agrivoltaics emit concrete euros held by a tokenized corporation, possible in Swiss law. In this, the treasury owning land & euros acts like a stabalizing influence on other token prices within the ecosystem.

[olanod]

@burdges I agree calling the treasury a VC might not be appropriate but there's still value in the idea of tokens not always flowing in one way and allow the community demand for a project's tokens in return even if the project is completely for the common good or in a gray area of being common good but seeking its own gains.
Among many options, this could allow the community to keep tabs on a project of interest(of thousands) launched under a parachain, if it goes rogue, the sentiment of KSM/DOT holders can be expressed in the project's governance without having to acquire new tokens and without using a big hammer to threaten the entire parachain for example.
It could also be a project's initiative to willingly give some control back to the big community to justify a bigger spending or out of gratitude because the treasury money allowed them to not have to go to a traditional VC to ask for resources.

It's interesting you touch some topics that are very related to what we want to do with Kreivo/Virto Network in the future, we have this concept of land tokens minted through DOT staking that enable people establish local communities that can manage funds collected and locked in said land cells via a tax system that charges special fees to payments on products/services, the spending of the taxes might be restricted to specific things like carbon credits or anything that aids in the economic development of the local community. It would be interesting to see the relay-chain community having a saying in local policies 🤔

[gilescope]

For NFTs we might be over a barrel if the treasury is trying to buy the only one. I don't think it should accept a proposal for an asset that it does not have enough of to enact the proposal.

Should a proposal's bond always be in the native token of DOT/KSM or should other assets be acceptable?

[gilescope]

It's better if the bond is in the proposal's currency (otherwise an fx rate would be needed to convert from the quantity proposed to the dot equivalent).

Should a proportion of the non-native assets be burned if they are not spent? Burning a proportion of the treasury is designed to force people into action. Treasury owned NFTs could not have a portion burned.

[burdges]

As for the original topic, we do not need SPREEs for this because we're treating this new parachain code as trusted, and the upgrades work like polkadot governance, yes?

[joepetrowski]

It's better if the bond is in the proposal's currency (otherwise an fx rate would be needed to convert from the quantity proposed to the dot equivalent).

Yeah but it's adding complication. As a step we can make it fixed or use the ratio of minimum balances.

Should a proportion of the non-native assets be burned if they are not spent? Burning a proportion of the treasury is designed to force people into action. Treasury owned NFTs could not have a portion burned.

IMO, no. The native asset is the only asset that ends up in the treasury "automatically" due to the protocol. Acquiring and holding some other asset is a deliberate use of the Treasury.

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/a-better-treasury-system/291/4

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/the-state-of-dotsama/676/8

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/statemint-update-roadmap/1200/24

[tonyalaribe]

This thread already describes clearly the vision we hope to achieve (Moving the Treasury out of the Relay Chain), but also some of the higher-level challenges which we hope to solve along the way:

• Multi-asset holdings
• Multi-asset Spending
• Multi-asset acquisition

There are already conversations happening around the topic of multi-asset acquisitions (DEX, TWAMMS, etc.). So I would avoid that here. But for Multi-asset holdings and multi-asset Spending, I can share the current plan I'm exploring.

Treasury assets on Statemint

Multi-asset holdings

As a community, we currently have Statemint as the hub for assets, which is the primary location for issuing and holding assets, with even long-term plans to hold and transact popular stable coins/tokens directly on Statemint.
To support the goals we have laid out for the treasury, the treasury needs to hold assets on Statemint, including the native token and other assets backed on Statemint, and be able to spend them.

This Treasury account on statemint would be spendable from the Spending Origin, which would equally be possible via referendum (Treasury spend proposals, etc.).

There will be a mechanism to teleport DOT from the relay chain to the treasury on statemint at configurable intervals, e.g., every 24 hours. The details of where this logic would sit still need to be clarified, and I would appreciate ideas.

Multi-asset Spending

With the treasury on statemint, there needs to be a mechanism to spend this for the benefit of the community. After some conversations and experimenting, the roadmap is the following:

Multi-asset treasury pallet

The current treasury pallet is coupled tightly with the Currency traits. If we follow its current trajectory, it will evolve such that it is either implemented via fungibles (assets pallet) or fungible (balance pallet) traits or both at a higher complexity cost.

So instead, we will leverage the fairly new Pay trait , which is great because instead of coupling the treasury to fungibles (assets pallet?), fungible (balances pallet?) we can implement the Pay trait over fungibles or fungible or even just over XCM, making the treasury pallet much more flexible.

The treasury spend function will be adjusted to support as asset id argument. This way, the community will create treasury-spend proposals for specific asset classes. E.g., a proposal could request 100 USDT and be paid precisely that. However, if the treasury does not have enough funds in that asset class, the transaction will fail, and the treasury pallet will retry the Payment at the next SpendPeriod . During this time, the Treasurer could use any available means to acquire the assets in the given asset class.

In this case, the Treasurer would be an Origin that can perform more privileged operations on behalf of the treasury and might have its own Referendum track.

There's an ongoing PR: paritytech/substrate#13607

Exchange Oracle

The treasury pallet requires a means to track its budget and to tell if it currently has enough room to pay out for a particular proposal. To continue supporting such a budget, we have two possibilities:

• Have a Budget/Spend limit for every single supported asset pair.
• Have a rough spend limit configured in the native asset class, a means to convert the value of all proposals of other asset classes into an estimate in the native asset class, and use that for spend limit comparisons and bookkeeping purposes (burning, etc.).

The second option appears more straightforward since having a limit for each supported pair could be an accounting nightmare, especially when factoring in the current logic for burning assets when the treasury value is unspent. For this approach, we need a means of estimating the value of other asset classes compared to the native asset class.

The exchange pallet would provide the means for making these estimations. Its current design would be a simple map of asset pairs and a rate, with an extrinsic, which converts a balance in one asset class into the balance in the native asset class.

The exchange pallets would be configurable via referendum, and in the future could subscribe for updates from a dex or similar mechanism and use that for its configured rates. But an option configured by referendum could be a sufficient starting point for our immediate needs.

There's an ongoing PR:
paritytech/substrate#13608

Multi-asset treasury over XCM

The next step will be to configure the treasury on the relay chain to operate over an implementation of the Pay trait that works over XCM.

	fn pay(
		who: &Self::Beneficiary,
		asset_kind: Self::AssetKind,
		amount: Self::Balance,
	) -> Result<Self::Id, ()>;

The pay method would then initiate an XCM TransferAsset call to transfer the given assets from the treasury's statemint account to the given beneficiary.

The pay method is asynchronous, but the check_payment method will be needed to verify if a payment succeeded, and will be implemented over XCMs appendix workflow for communicating success of the XCM operations.

Most of the work here is configuring everything together and testing all the operations and the expected XCM interactions.

[muharem]

@tonyalaribe thank you for the proposal.
I have some questions/clarifications

With the treasury on statemint

• Treasury has only its sovereign account on Statemint, no pallet, right?

This Treasury account on statemint would be spendable from the Spending Origin

• If there is no special pallet on Statemint, then all transfers from Treasury account happens via balances or assets pallet, right? How would it possible to couple some custom Spending Origin with the treasury account? Something missing here

it will evolve such that it is either implemented via fungibles (assets pallet) or fungible (balance pallet) traits or both at a higher complexity cost.

• not sure I understand this part, and the section below it. My understanding is that the treasury pallet, nether spends native assets locally, and this already in place, nether it spends some assets from its account on a remote chain. To spend something on a remote chain, the xcm program needs to be send to the remote chain. Pay trait is a way to abstract that xcm program from the treasury pallet, right?

The treasury pallet requires a means to track its budget and to tell if it currently has enough room to pay out for a particular proposal.

• I think for now we only need to know if a particular Origin, SmallSpender for example, can spend 1000 of asset_id = 777. Right now the SmallSpender has only associated amount of native tokens it can spend at max, but it has no idea about asset_id = 777. Spend Origins associated with a referendum tracks, and tracks' constrains.