CPS-0023? | Cardano Multi Asset Treasury (CMAT)

[HinsonSIDAN]

This CPS outlines the motivation of turning Cardano treasury from lovelace only into capable of holding multi assets including various Cardano Native Tokens.

Our co-authors (me plus Felix & Nicolas) would continue seeking for perspectives and feedback to update the draft until we confirm, mostly by circulating this draft and workshops to be held during upcoming Cardano Summit.

Also tagging #1061 for cross referencing, as the progress / update on the proposed CIP-159 will affect how the community should approach this CPS.

---

Rendered document

[HinsonSIDAN]

Putting some bullets collecting from community on concern side:

• Treasury action is usually too slow (which allows front-running treasury conversion)
• No good candidate for actively managing the CMAT
• The problem statement is too narrowly-scoped

[fallen-icarus]

IMHO this is not a good counter argument. As blockchains grow in adoption, it will attract the attention of malicious entities. All it takes is one bad actor to ruin it for everyone else. Spam prevention is an absolute necessity.

The better question is: which spam prevention technique has the best trade-off profile?

[HinsonSIDAN]

My line of thinking is spaming the treasury might indeed not a vulnerability. Since it is mostly costing the spammer fee to carry such tx and eventually it might affect no one (just like current cardano address). This imo need further discussion to clarify the necessity

[fallen-icarus]

My line of thinking is spaming the treasury might indeed not a vulnerability. Since it is mostly costing the spammer fee to carry such tx and eventually it might affect no one ...

I don't think this is accurate. It is very cheap to mint CNTs and it is also very cheap to send them. I could mint 50-100 CNTs in one tx for about 0.2 ADA and then send these worthless CNTs to the treasury for another 0.2 ADA. I don't think the tx fees alone are enough to deter this at scale. You would also need a governance process for cleaning up the Treasury address. Once it hits 10,000 assets, it could be problematic to trustlessly track.

Regardless, my comment was more that I think the downsides to using another minUTxO-like deposit mechanism are not being considered enough by the community. As I explained in a thread on X, microfees/microdonations are worth supporting and the minUTxO-like mechanism prevents them. This is not to say that minUTxO needs to be decreased! Only that there are use cases where another spam prevention mechanism would be better. CIP-159 deliberately uses a whitelist to support these microfees/microdonations, and these also seem relevant to the Treasury.

[HinsonSIDAN]

Yea I get your point, I am more inclined to think as you stated as well indeed. But from network point of view, it might not as relevant since depending on the design, it might not affect the usage of CMAT even there are couples of irrelevant tokens in treasury. Indeed it is exactly Polkadot community's POV, for their way of implementation of multi-asset treasury, people can send in irrelevant tokens to it like a typical cardano address. As long as indexers find a way to ignore it efficiently, it might not cause any problem. So this discussion item is dependent on which technology path we choose to implement CMAT imo.

[fallen-icarus]

A less technical challenging solution, ...

Just because it doesn't touch the ledger code doesn't mean it is a smaller "technical challenge". Complexity exists at an ecosystem level. If making the changes at the ledger level results in less complexity at the ecosystem level, that is the preferred solution. I would argue that the (currently undefined) smart contract approach could actually result in more ecosystem complexity, not less.

[HinsonSIDAN]

Yes indeed more discussion is much needed. From this tweet, seems PI is in favour of this approach indeed.

I might also spend some time in crafting a CIP in regards to the CPS, but gotta hear more from different perspectives

[fallen-icarus]

Speaking from the perspective of CIP-159:

Treasury action is usually too slow (which allows front-running treasury conversion)

IMO this is actually a feature, not a bug. It should be hard to change what assets are supported! I was thinking it would have to go through the full voting process to get the whitelist certificates approved which should be very difficult to prevent a fickle treasury. This means whatever CNTs end up being supported need ecosystem-wide support. This rules out all but possibly some stablecoins right now.

No good candidate for actively managing the CMAT.

What do you mean "actively managing"? Why should the CMAT be actively managed more than what it already does? IMO the only thing that should be added is the ability to hold whitelisted CNTs. The funds inside the treasury should not be actively managed. They should just sit there until a treasury withdrawal is made. If the current ADA should be diversified into a supported stablecoin, this would involve an approved treasury withdrawal + conversion + treasury deposit of the new stablecoin. Then it just sits there until the community approves another diversification conversion or withdrawal. I do not think the treasury should be actively rebalanced since this opens the door to possible abuse/mismanagement - the entities doing the rebalancing could effectively pick winners and losers in DeFi which is not a good thing right now.

[HinsonSIDAN]

Speaking from the perspective of CIP-159:

Treasury action is usually too slow (which allows front-running treasury conversion)

IMO this is actually a feature, not a bug. It should be hard to change what assets are supported! I was thinking it would have to go through the full voting process to get the whitelist certificates approved which should be very difficult to prevent a fickle treasury. This means whatever CNTs end up being supported need ecosystem-wide support. This rules out all but possibly some stablecoins right now.

No good candidate for actively managing the CMAT.

What do you mean "actively managing"? Why should the CMAT be actively managed more than what it already does? IMO the only thing that should be added is the ability to hold whitelisted CNTs. The funds inside the treasury should not be actively managed. They should just sit there until a treasury withdrawal is made. If the current ADA should be diversified into a supported stablecoin, this would involve an approved treasury withdrawal + conversion + treasury deposit of the new stablecoin. Then it just sits there until the community approves another diversification conversion or withdrawal. I do not think the treasury should be actively rebalanced since this opens the door to possible abuse/mismanagement - the entities doing the rebalancing could effectively pick winners and losers in DeFi which is not a good thing right now.

These concerns are indeed what i summarize from @Crypto2099's perspective. Maybe I mis-translate some points, or can Adam provide some ink on this github discussion so more audience understand these concerns?

[HinsonSIDAN]

From Cardano Ambassador workshop discussion in Berlin, the below points are mentioned:

• Explore the possibility of executing spam prevention in offline manner as long as no security concerns on node by simply excluding from indexing
• Do we need new protocol parameters? Or we can simply recycling old protocol parameters (e.g. treasury withdrawal one)
• New guardrails introduced by new governance action (e.g. listing & delisting), and following new protocol parameters if any
• Technology pathway can be going step-by-step: In scenario of smart contract approach is easier but ledger change is more desired, it is possible to go version 1 as smart contract approach, then upgrade to ledger approach later
• A potential new use case: NCL denominated in CNTs other than ADA, like stablecoins
• Treasury can potentially participate Cardano DeFi / projects

[HinsonSIDAN]

Technical group at Day 0 discussion:

• Smart contract as treasury might not be easy to implement (due to execution units limits)
• CIP159 approach is preferred, but we are not turning treasury into an address. It is only for enabling users to withdraw the treasury. We implement the treasury in a simpler way of holding Value rather than Coin, with extra guardrails on whitelisting and de-whitelisting
• How does NCL works post CMAT? Do NCL only apply to ADA or to other assets as well?
• NIGHT token can be a pathway to drive value back to Cardano ecosystem
• Groundwork for putting BTC at treasury

[rphair]

Tagging Triage for review at next CIP meeting (https://hackmd.io/@cip-editors/123).

[rphair]

Suggested change

	Discussions:
	- https://forum.cardano.org/t/cardano-multi-asset-treasury-cmat/149984
	- https://github.com/cardano-foundation/CIPs/pull/1061
	Discussions:
	- https://forum.cardano.org/t/cardano-multi-asset-treasury-cmat/149984
	- https://github.com/cardano-foundation/CIPs/pull/1061
	- https://github.com/cardano-foundation/CIPs/pull/1103

this

[rphair]

p.s. @HinsonSIDAN could you also refine the #1061 link above with a # (anchor) comment or review deep-link that provides, as you see it, the best entry point into that candidate CIP-0159 discussion: illustrating the importance of Account Address Enhancement to proposals in this field?

[rphair]

apologies @HinsonSIDAN I'd marked this thread "Resolved" even though we still have no pointer to the part of the #1061 discussion in which it was determined to be a prerequisite for CMAT.

[fallen-icarus]

I'm not quite sure what the last sentence here means:

From there, also not directly implementing CIP159 account as treasury due to first point above.

The treasury is currently a special stake address, is it not?

[HinsonSIDAN]

It is not a stake address now. Currently it is simply an integer represented by type Coin so far i know. My best understanding is that its very similar to behaviour of a stake address, but its a separate implementation - so updating stake address should not be automatically updating treasury as well

https://github.com/IntersectMBO/cardano-ledger/blob/master/libs/cardano-ledger-core/src/Cardano/Ledger/State/ChainAccount.hs#L47-L52

[Ryun1]

might be worth including this in the scope, it feels that this question is quite core to the problem statement

[rphair]

somehow didn't see this... echoed in meeting minute #1103 (review)

[HinsonSIDAN]

Sharing some of the thought process of the discussion amongst co-authors of this CPS.

whitelisted assets has been discussed. We agree to scope in:

1. Should we whitelist assets in CMAT?
2. If yes, what is the way to handle whitelisting.

However, we unanimously agreed on which specific assets to be whitelisted should be out of scope from this CPS for 2 reasons:

1. We prefer not to see any solution CIP solving CMAT specifically "pick the winner"
2. Even if whitelisting is deemed useful / required by the community, we rather see it in a separate CIP / topup CIP, but not in a CIP directly solving this problem.

[rphair]

@HinsonSIDAN - consensus from our discussion at the CIP meeting today was to confirm this & assign a number, but with these questions about scope & content to be addressed as soon as possible:

• the "whitelisted assets to be included" is currently deemed "Out of Scope" although the first open question relates to just such a determination.
• the "open questions" in general read more like a debate over administrative decisions for such a multi-asset treasury rather than considerations that would be useful to provide technical solutions.
• [perhaps the above point put differently] the Open Questions should be ones that lead to practical solutions like CIPs, and the editors don't currently see how that could develop.

In short: we'd like to see a full, practical consideration of the problem rather than a CPS placeholder for a single CIP, likely from the same author(s), which would propose to fill the requirement. For this to keep moving forward, it should be something that will accept ideas from across the Cardano community and we need to be sure the document is set up to accommodate & encourage that.

[rphair]

p.s. please update the directory name to CPS-0023 and update the "Rendered document" link accordingly 🎉

[HinsonSIDAN]

I feel so sorry that I cannot join the last editor meeting :(. Thanks for covering it in last meeting & I will try my best to join the next one to provide more context. As of the questions:

• the "whitelisted assets to be included" is currently deemed "Out of Scope" although the first open question relates to just such a determination.

• The "out of scope" doesn't mean this topic should not be addressed by the solution CIP. It only means the CIP should not choose which assets to be included directly as it introduce a partial problem of "choosing the winners" by a proposed CIP. If current wordings introduce ambiguity I might update the doc accordingly.

• the "open questions" in general read more like a debate over administrative decisions for such a multi-asset treasury rather than considerations that would be useful to provide technical solutions.

• The open questions would determine how technically a proposed CIP should be written. For example, if spam prevention is not important (aka no whitelisting), it is possible to use a typical Cardano address as treasury. If it is important, the proposed CIP might indicate use CIP159 like account, or implement a specific way to allow whitelisting.
• Similarly, allowing participate in DeFi means the proposed CIP should cover how it should be achieve. Potentially it could be CIP159 address or typical Cardano address as treasury, or specific implementation.
• So if wordings are deemed confusing, I can try to adjust and point out to very specific technical direction for either way of the "debate" goes correspondingly.
• Lmk if any sessions feel irrelevant also, I can try review & remove also.

• [perhaps the above point put differently] the Open Questions should be ones that lead to practical solutions like CIPs, and the editors don't currently see how that could develop.

• Likewise about, appreciate if I should proceed amending the wordings pointing towards more specific technical solutions for the open questions!

In short: we'd like to see a full, practical consideration of the problem rather than a CPS placeholder for a single CIP, likely from the same author(s), which would propose to fill the requirement. For this to keep moving forward, it should be something that will accept ideas from across the Cardano community and we need to be sure the document is set up to accommodate & encourage that.

• I believe the open questions above can lead to many potential solution CIPs. Of course in the course of drafting this CPS, we developed opinion also in a specific way of solving this problem. But hopefully we can still keep it in a neutral shape.

[rphair]

thanks @HinsonSIDAN - I think the editors wouldn't want to miss the opportunity to finely discuss these questions of scope with you & co-authors, so I've put this explicitly on the next meeting agenda for that purpose: https://hackmd.io/@cip-editors/124