CIP-0143? | Interoperable Programmable Tokens

[colll78]

Abstract

This CIP proposes a robust framework for the issuance of interoperable programmable tokens on Cardano. Unlike all its predecessors, this framework allows these tokens to be used in existing dApps, and does not require dApps to be developed specifically for these tokens.

---

(latest version rendered from branch)

[Riley-Kilgore]

Love to see this, and think it's rather clean.

That said, personally I am sort of partial toward the idea that the user credential, instead of being applied to the script, should be present as the stake credential for the address.

Then the only logic that would change for the Programmable Logic Base Script is to require approval from the stake credential of the address from which smart tokens are being spent, as opposed to any parameter being provided.

This means that a single reference UTxO could be used for all users of the system.

[colll78]

That said, personally I am sort of partial toward the idea that the user credential, instead of being applied to the script, should be present as the stake credential for the address.

The issue with that is that it changes the semantics of DeFi (ie. it would be inoperable with protocols like Optim / Fluid where you can lend your stake) and breaks the ability to have franken-addresses / script staking credentials. Also it makes it impossible (or very difficult) to do things like stake the Ada in a liquidity pool because then the staking credential would need to be both the pool script and also contain actual logic for staking (and thus you could not use withdraw zero you would need to withdraw the current balance). However, it does simplify the transfer logic so I am open to the suggestion if people thing the tradeoffs above are acceptable.

This means that a single reference UTxO could be used for all users of the system.

I am confused. We don't really have any reference UTxOs.

[Riley-Kilgore]

I think the Stake based DeFi argument is valid, although I am not sure it is necessary for any activity to occur through this system that is not specific to the programmable tokens. It seems that the only activity that really ought to occur through this system is activity related to programmable tokens (although the ability to access non-programmable tokens is awesome for DeFi).

I am confused. We don't really have any reference UTxOs.

Generally it reduces the transaction size and fee to leverage reference UTxOs / reference scripts, I haven't looked too deeply into some of the recent changes to the cost model, but it remains relevant. We do not currently have the ability to store an unapplied script inside of a UTxO and apply it on-chain with the ability to only include its parameters in the witness set as we do with redeemers. Maybe this could be another CIP, I have been thinking about writing one.

Therefore, if a user is regularly using the proposed system, they will want to have a UTxO which contains the script which they are using. The solution I suggested means that only one UTxO would be required to contain that script, whereas otherwise it requires one 'reference script' as a UTxO on-chain per user.

[rphair]

@colll78 I'm tagging this Triage to introduce it at the next CIP meeting (https://hackmd.io/@cip-editors/102) where I believe people will be happy to see this: please attend if you can since I think they would also appreciate you being there to talk about your method a bit.

Please, as soon as you can, remove all the CIP template comments from the source. Generally also it helps to have a link to these proposals and/or some explanatory content in the first comment: I'll copy in your Abstract but please also add any other details that might help reviewers landing directly on this page.

I've also set the CIP title from the document title, which I think works well to distinguish your method from the others in the Rationale.

An essential topic for the meeting & assigning a CIP number will be to confirm this is really a Plutus category proposal as you've originally written, or if it would be more useful & meaningful to categorise it Tokens like those others. I'll leave the Category: tag off until we can confirm it here or at the meeting.

[rphair]

Suggested change

	<!-- Existing categories:
	- Meta | For meta-CIPs which typically serves another category or group of categories.
	- Wallets | For standardisation across wallets (hardware, full-node or light).
	- Tokens | About tokens (fungible or non-fungible) and minting policies in general.
	- Metadata | For proposals around metadata (on-chain or off-chain).
	- Tools | A broad category for ecosystem tools not falling into any other category.
	- Plutus | Changes or additions to Plutus
	- Ledger | For proposals regarding the Cardano ledger (including Reward Sharing Schemes)
	- Catalyst | For proposals affecting Project Catalyst / the Jörmungandr project
	-->

et cetera, please, all down through the document 🙏

[rphair]

Suggested change

	# Smart Token Directory & Minting policy
	### Smart Token Directory & Minting policy

These are all part of the specification, so need to be subheadings of it; etc. for following sections...

[rphair]

Suggested change

	# Transfer Logic Scripts
	### Transfer Logic Scripts

[rphair]

Suggested change

	# Programmable Logic Base Script
	### Programmable Logic Base Script

[colll78]

Therefore, if a user is regularly using the proposed system, they will want to have a UTxO which contains the script which they are using. The solution I suggested means that only one UTxO would be required to contain that script, whereas otherwise it requires one 'reference script' as a UTxO on-chain per user.

I understand your point now. I edited the CIP to include a linked list implementation for the directory, in this case the linked list node could store the transfer logic ref script.

[rphair]

This continues #944 (review) (2 comments got dropped from GitHub UI not working over my Internet connection yesterday).

I'm also highlighting the Category: question so we can settle it no later than Tuesday's CIP meeting, if not confirmed or changed here in the meantime.

[fallen-icarus]

What happens if the TransferLogicScript isn't available or returns False? If a UTxO has a bunch of assets where one of them is a programmable token that needs this transfer script, this script can cause the entire UTxO to be stuck. A malicious person could possibly use this to attack Cardano where they deliberately trap a large number of UTxOs and all of their assets.

This could also be used to attack certain DApps like my lending/borrowing protocol where the UTxO with the loan's state cannot be evolved to reflect a new payment if one of the collateral tokens is a programmable token and the transfer logic script is made to return False.

[colll78]

A UTxO in a user credential cannot have more than one smart token, so for instance a programmable stablecoin that gets frozen in your programmable token wallet cannot cause other programmable tokens to be frozen. However, at programmable token addresses derived from script credentials (ie. programmable token smart contract addresses), this is an unavoidable tradeoff of ERC-20 style programmable tokens. Imagine you have a smartUSD-smartYen liquidity pool, if the smartUSD TransferLogicScript returns false (ex. due to the issuer freezing the assets in that pool) then how would the pool continue to operate? If someone exchanges their lp tokens what should they get? In practice, it is the responsibility of dApp others to limit the amount of programmable tokens in each UTxO as much as possible (ideally a single programmable token per UTxO) but in pooled protocols, and other potential use-cases there will be times where multiple such assets will have to exist in the same UTxO and when that is the case the risks are as you described.

In this model, protocols like your P2P DeFi apps have a security advantage of natively not requiring multi-asset UTxOs by default, so I think protocols like yours are well suited for this design. In cases such as your lending/borrowing protocol, that behavior is simply unavoidable with programmable tokens which allow custodial management of the tokens, and this is exactly how programmability works in Ethereum / other blockchains which support it, if Circle freezes the USDC in a Uniswap pool, the pool is bricked, and all the users are essentially rugged. As a user in such pools, you have to be aware of the risks. Ideally you should never interact with programmable tokens that you do not trust as is the case in Ethereum.

[fallen-icarus]

The minUTxOValue incentivizes combining UTxOs as much as possible. Since there could easily be 100s of programmable tokens, I think it is unreasonable to expect users to dedicate each one to their own UTxO with a deposit of ~2 ADA per UTxO. Users are incentivized to deliberately switch to script based addresses just to get around this requirement.

... you should never interact with programmable tokens that you do not trust

It isn't enough to trust them. I really want to stress that a hack of the control for a programmable token could be a systemic risk to the entire blockchain. Imagine if there was an honest stablecoin issuer that was widely trusted and adopted, and they use a multisig to program the stablecoin. Since it is widely accepted, the stablecoin is not kept in separate UTxOs and is used across DeFi. If malicious actors get control of this multisig, they could effectively freeze a huge number of UTxOs and DeFi DApps across Cardano. Block production would be fine, but a huge number of UTxOs would become unspendable. This would be catastrophic and possibly cost $billions, if not $trillions, in damages.

As it is, we are trying to move away from the Genesis Keys because they are a central point of failure. Yet, with this CIP, a widely adopted programmable token effectively introduces new "critical keys".

All of these programmable token CIPs ultimately seem like accidental complexity from not being able to properly model what we want with programmable tokens (ie, manage specific tokens but leave everything else alone). The eUTxO model isn't granular enough for this. I'd much prefer to see what L2s can do and have them absorb the risks over having L1 expose itself to the possible systemic risks. For example, there could be an L2 dedicated to royalties where the programming of the royalties for a specific NFT on L2 is controlled by an L1 token.

[colll78]

I agree. Programmable tokens inherently introduce a number of vulnerabilities (99% of exploits in Ethereum are a result of ERC-20 token programmability). Users who interact with programmable token dApps need to be informed of these risks (ie by wallet) and by default users should prefer to interact with native token smart contracts whenever possible.

The situation you are describe regarding the hack of the control for a programmable token is exactly how all the other chains work. If USDC freeze credentials are hacked on Ethereum, the vast majority of TVL would be locked forever (including mostly non-USDC assets that get bricked in DeFi protocols due to USDC being frozen).

[fallen-icarus]

I'm personally in Cardano precisely because it is not like the other blockchains. I don't think we should accept the trade-offs just because everyone else is doing it.

99% of exploits in Ethereum are a result of ERC-20 token programmability

This is all the more reason not to have something similar.

You could argue this is just a standard and people can choose whether or not to follow it, but I don't think this is accurate. People view accepted CIPs as "officially recognized proposals"; they trust that they have been properly vetted to have good trade-offs, and therefore don't look closer at it. The average person is not going to vet each and every token they interact with to see if it is native or programmable. In other words, rational ignorance is going to incentivize people to adopt this standard and interact with programmable tokens without really thinking about the downsides.

The trade-off profile of this CIP is heavily skewed to the downside - it forces everyone, not just programmable token users, to accept significantly more risk in order to accommodate a few use cases. These use cases are arguably not important enough to justify these risks. We have stablecoins and projects like newm are trying to make royalties work.

I apologize but I have to argue this CIP should not be officially accepted... There may be a way to safely do programmable tokens in the future, but I am not willing to use an arguably dangerous approach just to have the features now.

[rphair]

Thanks @colll78 for kicking this off at the meeting, and for offering to produce a separate CIP for any Plutus changes that may help with implementations of this CIP.

Please rename the directory to CIP-0143 and update the proposal link in the initial comment. 🎉

[colll78]

I updated the spec (included in the lastest rendered branch).