CPS-0003? | Smart tokens

[szist]

The CPS standard is coming from this proposal: https://github.com/cardano-foundation/CIPs/tree/master/CIP-9999

The topic of smart tokens at this stage is not ready for a CIP, so I deemed a CPS to be a better fit for discussions. Since the CPS standard is not set yet and also this topic would require proper discussions potentially elsewhere, I also made this as a DRAFT.

The need to extend the functionality around tokens and their utility was raised in the Interoperability working group - input-output-hk/Interoperability-working-group#16

Disclaimer:
I don't think I'm a good fit to define the full requirements for what smart-tokens should fulfill, neither have I the overview of the development direction of Cardano. I also don't have the connections to push this forward. I think experts in regulations, compliance definitely should have a strong say, with dapps and wallets defining how they would work from the UX perspective. My aim here is simply to raise the topic.

---

(rendered proposal in branch)

[rphair]

thanks @szist - I believe this is a valid subject for a CPS: between the high profile use cases and the reasons we might not want to do this (centralisation, complexity, breaking changes from existing methods). There is enough of an inventory of risks & benefits for the community itself to start processing this, after some ledger / core experts & NFT veterans can help refine it (cc @JaredCorduan @alessandrokonrad)

A similar discussion began immediately after this CIP was submitted (#378), addressing your NFT use case. You might incorporate some of this discussion in your CPS and/or contribute to that discussion.

I'm also going to follow what I believe is your intention and convert this officially to a GitHub draft; more information here: GitHub Docs > Converting a pull request to a draft

[michaelpj]

You might be interested in #336

[L-as]

I am very sure you don't want this. This entire issue stems from a conflation with what tokens are considered to be in Ethereum and Cardano. You don't want to use tokens for these use cases.

You can effectively implement ERC-20 on top of Cardano, in several ways:

• Single UTXO with Merkle Tree of (owner, amount) pairs.
• One UTXO per "coin" with helper token to authenticate coin. Datum would include amount, owner, etc.

"Smart tokens"/spending policies don't offer any benefit over the above in terms of fees, efficiency, simplicity, or similar.

[matiwinnetou]

I am very sure you don't want this. This entire issue stems from a conflation with what tokens are considered to be in Ethereum and Cardano. You don't want to use tokens for these use cases.

You can effectively implement ERC-20 on top of Cardano, in several ways:

• Single UTXO with Merkle Tree of (owner, amount) pairs.
• One UTXO per "coin" with helper token to authenticate coin. Datum would include amount, owner, etc.

"Smart tokens"/spending policies don't offer any benefit over the above in terms of fees, efficiency, simplicity, or similar.

It would be nice to have PoC for this / some examples we could play with.

[szist]

I am very sure you don't want this. This entire issue stems from a conflation with what tokens are considered to be in Ethereum and Cardano. You don't want to use tokens for these use cases.

You can effectively implement ERC-20 on top of Cardano, in several ways:

• Single UTXO with Merkle Tree of (owner, amount) pairs.
• One UTXO per "coin" with helper token to authenticate coin. Datum would include amount, owner, etc.

"Smart tokens"/spending policies don't offer any benefit over the above in terms of fees, efficiency, simplicity, or similar.

could you elaborate please? Depending on how exactly you want to implement this I see issues in every direction. If you have a single utxo, you run into spend/interaction conflicts and tx chaining won't solve it for you. If you try to start emulating a "blockchain with tokens" with coins on utxos, to me it seems you are just moving security risks to the authentication token. In either case you would need direct full smart contract support from wallets anyhow. So I don't see how this is more efficient or simpler.

[L-as]

Supporting this in wallets is neuded anyway; wallets need to in general be able to show user funds locked by protocols.

Wrt. the single UTXO solution, transaction chaining can still solve this, wrt. the multi UTXO solution, I'm not sure what you mean about moving risks. It's waaaay simpler than any proposed solution I've seen for spending policies.

[szist]

Supporting this in wallets is neuded anyway; wallets need to in general be able to show user funds locked by protocols.

Wrt. the single UTXO solution, transaction chaining can still solve this, wrt. the multi UTXO solution, I'm not sure what you mean about moving risks. It's waaaay simpler than any proposed solution I've seen for spending policies.

Could you please actually elaborate :) rather than just refuting contradicting my points. If you have a single utxo and you want to do chaining with 100x people + smart contracts trying to interact with the same token at the same time from all over the world, how are you doing transaction chaining?

As for the auth coin. If the auth coin ever gets leaked, the token practically becomes worthless, as you could create a utxo with an auth token with arbitrary amount. This way you increase the surface of potential vulnerabilities from the validator script that would track the coins and datums, to also the minting policy that handles minting/burning the auth coins.

In what way are these proposed solutions simpler? What is the extra complexity that is added if you have a spending policy vs a smart contract tracking coins?

[rphair]

Looking to the future about how we might ensure this subject is tracked properly: since as said above this CPS shares considerations with #378... which is currently defined as a CIP but might be more useful as a CPS (#378 (comment))... could separate authors @szist and @MartinSchere post any ideas about combining these proposals into a single CPS?

[rphair]

p.s. also since mentioned in #378 (comment) this should be related to #336 (primarily in terms of reasons to not do this... or at least some reasons to be careful about considering it)

[KtorZ]

Suggested change

	CPS: ?
	CPS: 3

[szist]

I will try to incorporate the comments and considerations from the enforceable royalties into this CPS till eow. I wasn't aware of that CIP before writing this CPS. Thanks KtorZ for the updates, i'll fix the version.

[colll78]

Programmable Tokens is one of the worst components of the Ethereum ecosystem. It opens up a Pandora's box of issues that would be super hard to justify for the functionality that they offer.

approve() & transferFrom() are probably the two most desirable features introduced by Smart Tokens, but they are also immeasurably dangerous and have a hand in practically every one of the 100+ Ethereum exploits totaling to billions of dollars in damages.

Freezing tokens also comes with its own set of issues and introduces either a lot of complexity (making sure entire UTXOs are not locked just because they have 1 programmable token in them, forcing the inclusion of some type of Spending policy in every single transaction involving UTXOs that contain smart tokens even if the smart tokens are just part of the change UTXO), or a lot of spam UTXOs (ie you cannot have programmable tokens in the same UTXO as ADA / native assets). Already we have so many smart contract vulnerabilities related to unspendable UTXOs, this issue would be compounded greatly. Imagine a malicious actor lists their token on a DEX, gets paired with a ton of ADA liquidity in a pool, and freezes the asset locking everyone's funds indefinitely or someone uses it to bid on an NFT and freezes the auction indefinitely or someone just sends it to any arbitrary smart contract and freezes it thus bricking the contract indefinitely. Dust token attacks (sending out a ton of these "smart tokens" to many different addresses and then freezing spending of the token, thus effectively keeping it stuck in their wallet forever)

If this is implemented I'd suggest it be a very very small subset of vetted features of programmable tokens to avoid these issues.

"Supporting this in wallets is needed anyway; wallets need to in general be able to show user funds locked by protocols."
This should be a priority for so many reasons outside of just supporting mock ERC tokens.

"Single UTXO with Merkle Tree of (owner, amount) pairs.
One UTXO per "coin" with helper token to authenticate coin. Datum would include amount, owner, etc."

I'm not particularly fond of either of those solutions.

I propose the following solution:
Smart tokens are minted to a programmableTokenValidator that enforces that those tokens cannot be sent to anywhere outside the validator address. Each user possessing smart tokens has their own UTXOs locked at the smart contract containing their smart tokens with a datum identifying them as the owner. If Bob wants to send Alice 20 of his smartCoin, he simply spends his UTXO from the script to the script adjusting the datum accordingly.

Then any arbitrary logic can be tagged onto the validator (thus giving us programmable tokens). For instance to add the ability to freeze tokens, we just enforce that the validator checks for the inclusion of a reference Input identified by some auth token managed by the creator of the programmable token. The reference input contains a datum with the field {freeze :: Bool}, if freeze = true the validator does not allow spending of the programmable token, if freeze = false spending is allowed.

From my perspective, this seems to be the most elegant solution, and also retains all of the security guarantees provided by smart contracts being validators as opposed to actors (as in the case of ethereum).

This can be expanded to allow sending to validators that will obey the programmable token validator logic and will only send the smart tokens to other such validators (that also obey the token validator logic) or back into the token validator script, such validators can be identified by the presence of a adherenceCertificateToken locked in a UTXO at that script address.

Alternatively, use the same system, but instead of adherenceCertificateToken, just allow the value to be sent to any arbitrary script, and then deal with it the same way royalties are dealt with, namely, the honor system. All scripts would just collectively reject tokens that did not come from the programmableTokenValidator, this way the only way to get around the programmed logic would be p2p transactions or blackmarket contracts.

[michele-nuzzi]

I'm working on a CIP that proposes a solution with logarithmic complexity to add a new public key hash (account) and keeps the balance unrelated to the Merkle tree so that transactions with ERC20-like tokens can happen with constant complexity

hope to release a draft this week

[KtorZ]

Suggested change

Skipping ahead, although Babbage didn't add any additional functionality directly, the addition of reference inputs indirectly opened additional use-cases to the the token's lifecycle. To be specific an example: imagine an decentralized bridge with a wrapped token that gets dynamically minted or burned. As a safeguard they would introduce a global UTxO (e.g. with a datum including signature by a multisig wallet or validity token) controlled by recognized members or governance voting mechanism that includes an `enable` flag. The enable flag could be checked by the wrapped token minting policy through a reference input. When a governance vote would pass, the UTxO datum could be changed and the flag could be set to freeze the token.

Skipping ahead, although Babbage didn't add any additional functionality directly, the addition of reference inputs indirectly opened additional use-cases to the token's lifecycle. To be specific an example: imagine a decentralized bridge with a wrapped token that gets dynamically minted or burned. As a safeguard they would introduce a global UTxO (e.g. with a datum including signature by a multisig wallet or validity token) controlled by recognized members or governance voting mechanism that includes an `enable` flag. The enable flag could be checked by the wrapped token minting policy through a reference input. When a governance vote would pass, the UTxO datum could be changed and the flag could be set to freeze the token.

[CharityDA0]

Here is an example of token functionality requested for Cardano native tokens. Perhaps it can be included in the Smart Token proposal?

Title: CPS 101? - Cardano Improvement Proposal for Customizable Fees for Native Tokens

Abstract: CPS 101? proposes an innovative solution to introduce a customizable automated fee system for Cardano native tokens that can be easily executed by smart contracts on all exchanges. This proposal outlines two alternative methods for implementing the fee system - one utilizing a smart contract that controls the supply of tokens, and the other leveraging metadata of a special initial token during the mint.

Motivation: Automated fee systems have become increasingly popular in the cryptocurrency space as they incentivize token holders to hold onto their tokens and discourage frequent pump and dumps. They are also used to fund development and charitable giving. This functionality has been present on every major chain for years. However, Cardano’s current structure of native tokens makes it difficult to implement such fee systems, which rely on smart contracts to govern fees and distribution. This proposal seeks to introduce a method for implementing a similar automated fee system for Cardano native tokens, enabling greater flexibility and customization for token issuers.

Specification: Option 1 - Smart Contract-Based Fee System: To implement a smart contract-based fee system, we propose the following steps:

Create a smart contract that controls the supply of tokens and governs the behavior of the token.

Define the logic for deducting the fee from each transaction and distributing those fees to the appropriate parties within the smart contract.

Deploy the smart contract to the Cardano blockchain and associate it with the native token.

The smart contract will automatically execute and handle the fees and fee distribution whenever a transaction involving the token occurs.

Option 2 - Metadata-Based Fee System: To implement a metadata-based fee system, we propose the following steps:

Mint a special initial token that includes metadata defining the fee structure for the native token, much like the royalties done with NFTs on CIP-27.

When a user sends a transaction involving the native token, DEXs can easily implement the fee like done on NFT marketplaces.

Deduct the fee from the transaction amount, and distribute it to the appropriate parties.

Since the fee is specified in the metadata of the initial token, it does not require a smart contract to be associated with the native token.

Alternatively, the metadata could even point to a smart contract that handles the details automatically, making it more modular.

Rationale: By introducing a method for implementing a customizable automated fee system for Cardano native tokens, this proposal would enable greater flexibility and customization for token issuers. This proposal aligns with the overall goal of the Cardano ecosystem to provide a robust and flexible platform for building decentralized applications and tokens. Moreover, it will make it easier for communities to fund their projects democratically and incentivize token holders to hold onto their tokens. The proposal will make it possible for the Cardano ecosystem to attract a wide range of projects, from nation-states seeking to create their own digital currencies to charitable organizations wanting to fund their operations using the generated fees. The possibilities are endless, and the potential for innovation is vast.

[szist]

As you might've deduced by now, I'm on a hiatus since December with no end in site. Life happens. Unless there is anybody else who would want to take up this proposal, @KtorZ feel free to close this.

[rphair]

thanks for the update @szist: I've already referred a handful of people to this CPS and thread... whenever there is anyone potentially interested in carrying on the work you have done, I (we editors) will certainly refer them here. 😎

[GeorgeFlerovsky]

@colll78

Smart tokens are minted to a programmableTokenValidator that enforces that those tokens cannot be sent to anywhere outside the validator address. Each user possessing smart tokens has their own UTXOs locked at the smart contract containing their smart tokens with a datum identifying them as the owner. If Bob wants to send Alice 20 of his smartCoin, he simply spends his UTXO from the script to the script adjusting the datum accordingly.

If you squint, your proposed solution is an application of CIP-68.

Issue a user NFT to the freezing authority.

Specify the token amount and current owner in the ref NFT.

Disallow changing the amount but allow the user NFT holder to freeze.

Current owner can assign new owner.

EDIT: This is likely not the solution we would want to use, but it could be an interesting departure point for one. 😉