CIP-0113? | Programmable tokens

[michele-nuzzi]

This CIP proposes a solution to CPS-3 (Smart Tokens) implementable already with V2 Plutus contracts.

If adopted as a standard it would allow to emulate the behavior of account-based ledgers tokens on Cardano.

---

(rendered proposal in branch)

[michele-nuzzi]

Please note that at this moment this is only a draft and may contain errors in the logic.

If you spot any or have suggestions on how to improve the logic contributions are more than welcome!

[matiwinnetou]

Question:
Would wallets have adhere to this standard, if no how would they know that they should show said ERC-20 alike asset in their wallets without it? If yes how could they do this?

[nielstron]

@matiwinnetou How it works on EVM compatible chains is that the wallet stores locally a list of common tokens / users can manually add token addresses to track. Try installing Metamask and interacting with milkomeda.muesliswap.com

[michele-nuzzi]

@matiwinnetou the solution proposed emulates the way tokens are used on EVM chains in many aspects

As @nielstron said the user of a wallet needs to manually add the contract to track

Wallets can find the user balance by the NFT associated with the payment credentials.

[matiwinnetou]

I see, thanks, this helps a lot. So I guess it would be of course also possible to have some registry for those tokens so wallets could use it.

[rphair]

thanks @michele-nuzzi - I just edited title to be specific & put the Draft status into the review stage itself; feel free to change back when you feel the drafting process is complete: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request

Also I'm adding a link to the readable proposal into the original comment & please keep updated if it changes path 🙏

[L-as]

As I've noted elsewhere, a system as described in this CIP is inherently centralised (but trustless) and thus can't support the throughput it would on account-model based ledgers.

A much simpler system which likely serves your needs is a system where the owner is noted in the token name of a token. Let's assume it's a PKH for simplicity, but in the future we want scripts + datums as owners too.
You then only own a token if you 1) actually hold it and 2) the token name includes your PKH. The token name can also contain extra information through hashing the PHK along with token-specific information. If necessary, a UTXO can be created to ensure the preimage is stored on Cardano itself. Then sending a token to someone would entail burning then minting it again. In this process, arbitrary checks can be done through the minting policy.
Implement royalties is trivial, and would be done by including the author name in the token name too.
Implementing freezing for USD stablecoins would include checking a centralised Merkle tree of frozen addresses and checking that yours is not included.

As for supporting scripts, I think just allowing a script + datum to be used as owner might be enough.

Also, unrelated to the idea itself, I would appreciate it if the CIP was better checked for grammatical/formatting errors/typos, etc.

[L-as]

@michaelpj might be interested

[michele-nuzzi]

@L-as Thank you for helping with the CIP.

I like a lot the system you propose but from a first read I believe is missing an equivalent for the approve and transferFrom methods since the spending of a token always requires the owner to include them in a transaction.

Regarding throughput, it is only limited to the phase of the creation of a new account; while I understand it is a bottleneck it is an operation performed only once and it should not cause too many problems. Once an account is created it remembers its own state and multiple accounts can be used in parallel.

I recognize my writing is not the best and I'll try to put more effort into it.

[L-as]

@michele-nuzzi That is somewhat true, however, you could implement it by freezing the old tokens (ref inputs) and minting new ones, but this might not be any better than what you describe. How common is transferFrom and approve? The issue is a token that supports freezing would have transfer transactions that are more complex than the ones in this CIP AFAICT.

There is also the issue of complexity, the scheme described in this CIP is not simple, and also requires more effort from wallet developers to show the information.
A complex scheme also has a higher chance of bugs.

I'm not sure which scheme is better when taking that into account.

[michele-nuzzi]

From what I can tell transferFrom is the preferred way for a smart contract to move those tokens.

It is true that for this first draft, it might be tricky to implement something like freezing; I was thinking to add a second field to the Account datum so that it can have additional arbitrary data:

const AccountManagerDatum = pstruct({
    Account: {
        amount: int,
        state: data
    },
    /* ... */
});

and then make sure that the state field is unchanged for all the standard redeemers (easily done with equalsData)

the account manager can have other redeemers after the standard one so that maybe a Freeze redeemer can be added and this will be able to freeze a given account by modifying the state field.

Regarding wallet implementation, it shouldn't be any harder than the current resolution of ADAHandles.

[MicroProofs]

@L-as Thank you for helping with the CIP.

I like a lot the system you propose but from a first read I believe is missing an equivalent for the approve and transferFrom methods since the spending of a token always requires the owner to include them in a transaction.

Regarding throughput, it is only limited to the phase of the creation of a new account; while I understand it is a bottleneck it is an operation performed only once and it should not cause too many problems. Once an account is created it remembers its own state and multiple accounts can be used in parallel.

I recognize my writing is not the best and I'll try to put more effort into it.

I would say to avoid the ERC-20 approve function at all costs. It has plagued the Ethereum eco-system and even they are standardizing a new key signature method called permit to try to correct this terrible mistake. I'd recommend instead signatories be checked for transferFrom methods instead of the far outdated approve. I have not had the time to fully go through this. But I just want to warn against the mistake of implementing approve.

[michele-nuzzi]

@MicroProofs If that's the case then there is no difference from the Transfer redeemer. Should we just drop Approve and TransferFrom and contracts will instead look only for Transfer redeemers to be used?

[MicroProofs]

@michele-nuzzi
Yes since the whole idea of approve is you had no idea who is signing the transaction for a contract calling to an ERC-20 token contract. In Cardano we have easy access to that information. We should simplify it to just transfer. And I’ll review your draft tonight to give more feedback.

[L-as]

With those two removed is there any reason not to go for the token approach?

[michele-nuzzi]

@L-as There would still be the problem of additional (trusted) data for script execution.

Implementing freezing for USD stablecoins would include checking a centralised Merkle tree of frozen addresses and checking that yours is not included

As you said implementing logic like freezing requires some external contract; this external contract would not be a standard, so someone else that wants to move around ERC20-like tokens would (and should) not know of this additional requirement

[L-as]

@michele-nuzzi It would always be the case that transferring tokens can fail. It should not be part of the interface in the first place. For wallets to support it seemlessly, you could have a helper untrusted script associated with the MP that tells you what you need to add to fix it. That would have to be the case even with your system to support arbitrary behaviour and keep the interface simple.

[michaelpj]

I don't particularly have an opinion here and I'm not currently planning to review this. If this is a thing that people want then they can create it. I think it may not perform well (as @L-as says), and it sacrifices essentially all of the benefits of native tokens on Cardano.

A few thoughts:

• No Rationale :(
• Is this actually a CIP? It seems like a design for something that someone could build on Cardano. I'll leave it to the Editors.
• I would strongly encourage some prototyping. Does it actually work? Is an implementation too expensive? Can you build other systems that actually interact with this?

[rphair]

@michaelpj: Is this actually a CIP? It seems like a design for something that someone could build on Cardano. I'll leave it to the Editors.

After putting it in Draft stage I've been watching the feedback expecting that it will produce a Rationale and other CIP prerequisites to be added before @michele-nuzzi brings it into the "Ready for review" stage. I'm not recommending anything specifically yet in case a broader approach suggests presentation as a CPS instead. The discussion has been productive so far even without a mature proposal yet.

[michele-nuzzi]

@michaelpj me and @L-as have had a very productive discussion

regarding performances, the only bottle neck is the Merkle tree which is there to guarantee the uniqueness of an account. This constraint is not really useful, there is no harm in having multiple accounts with the same credentials so it will be removed before the final CIP.

The implementation will only require the account manager.

[rphair]

Added Waiting for Author tag by consensus in today's CIP meeting while waiting for last feedback to be accommodated in the draft.

[Godspeed-exe]

Hey @michele-nuzzi @nielstron @matteocoppola

Do we have an update on the progress of this CIP? We're getting quite a lot of requests to use it.

[colll78]

@Godspeed-exe

There is very little remaining work, a small feature improvement, and the final code-base audit.

[Godspeed-exe]

Hello @colll78

Any update on this? Or an ETA?

Thanks!

[rphair]

@micahkendall @colll78 I would be happy to put this on the Review agenda for the next CIP meeting (https://hackmd.io/@cip-editors/116) to discuss whether would be appropriate to merge this as a tentative standard even if proofs-of-concept and initial implementations are still not production-ready.

We should discuss here and/or at that meeting to what extent the current CIP design & documentation could be used to others who want to put the proposal into practice... especially any interoperability issues between implementations. Editors aren't specifically qualified to assess this and would need your help to answer that question. If possible I would like to start preparing this for merge even if your own productions are still in progress.

[Ryun1]

This still need to be updated?

[Ryun1]

Need to be updated?

[rphair]

@michele-nuzzi @colll78 @matteocoppola we had an observer at yesterday's CIP meeting representing a team of developers who need to implement CIP-0113 in their own project but are still seeing only a potential, in-flux, not-yet standard and are therefore not sure how to proceed.

We need more visibility about what you are doing, with a full inventory of any issues that remain uncertain: not just so that editors know how to proceed (as I'd asked a couple weeks ago in #444 (comment)) but also to be fair to developers who need to move forward on implementations that could be painful to withdraw if this standard is changed afterward.

@perturbing also pointed out there are already "CIP-0113" (technically still nonexistent) implementations in the wild. To me this sounds like it could be a source of interoperability concerns that would either need to be addressed in advance or might not be addressable later.

The observer at our meeting also pointed out a security concern her team had found — which I would encourage them not to post in the open here, but might still need some means of sending the details by private message. If you could open up such a channel then we might collectively get ahead of that issue discreetly.

So please I would ask you on behalf of the greater Cardano community to update this thread, and finalise the CIP-0113 document itself, as a matter of priority. For the reasons above we appear to be losing our opportunity to create a real standard for Programmable Tokens: but I know we can achieve this with greater visibility & a final push to complete & standardise the great work you guys have done already. 🙏

[matteocoppola]

@michele-nuzzi @colll78 @matteocoppola we had an observer at yesterday's CIP meeting representing a team of developers who need to implement CIP-0113 in their own project but are still seeing only a potential, in-flux, not-yet standard and are therefore not sure how to proceed.

CIP113 by itself is basically ready. This will be a V1, while we wait for the new ledger BuiltinValue to allow multi-utxo seizing (V2).
V1 tokens should be easily upgradable to V2 if they keep the burning policy always allowed (so you can burn a V1 token to mint a V2).
CIP113 is a general framework and its substandards need to be defined and adopted by Cardano wallets.
I'm writing the first BaFin-compliant substandard for securities (sponsored by Finest) and I'm talking with others to see if we can have this standard that includes also other legislations (BaFin works for the EU area).

A frontend to allow easy minting of compliant CIP-113 tokens is being built, we are currently deciding the budget needed. From that frontend anyone will be able to choose the substandard, put the information needed and generate the CIP113 tokens.

A tresury withdrawal request has been formulated to cover the budget for frontend and incentivization of wallets and dApps.

@perturbing also pointed out there are already "CIP-0113" (technically still nonexistent) implementations in the wild. To me this sounds like it could be a source of interoperability concerns that would either need to be addressed in advance or might not be addressable later.

There are several, but each one has its own flaws. CIP-113 offers the most flexibility while keeping a consistent behaviour that is predictable and compatible with Native Tokens.

The observer at our meeting also pointed out a security concern her team had found — which I would encourage them not to post in the open here, but might still need some means of sending the details by private message. If you could open up such a channel then you we might collectively get ahead of that issue discreetly.

IOG currently audits CIP113 code, but something could indeed have been missed. Please send us a DM so we can check together.

[colll78]

@michele-nuzzi @colll78 @matteocoppola we had an observer at yesterday's CIP meeting representing a team of developers who need to implement CIP-0113 in their own project but are still seeing only a potential, in-flux, not-yet standard and are therefore not sure how to proceed.

We need more visibility about what you are doing, with a full inventory of any issues that remain uncertain: not just so that editors know how to proceed (as I'd asked a couple weeks ago in #444 (comment)) but also to be fair to developers who need to move forward on implementations that could be painful to withdraw if this standard is changed afterward.

@perturbing also pointed out there are already "CIP-0113" (technically still nonexistent) implementations in the wild. To me this sounds like it could be a source of interoperability concerns that would either need to be addressed in advance or might not be addressable later.

The observer at our meeting also pointed out a security concern her team had found — which I would encourage them not to post in the open here, but might still need some means of sending the details by private message. If you could open up such a channel then you we might collectively get ahead of that issue discreetly.

So please I would ask you on behalf of the greater Cardano community to update this thread, and finalise the CIP-0113 document itself, as a matter of priority. For the reasons above we appear to be losing our opportunity to create a real standard for Programmable Tokens: but I know we can achieve this with greater visibility & a final push to complete & standardise the great work you guys have done already. 🙏

Please send me a DM with the security concern.

[nemo83]

GM, happy to see things moving for this CIP. Please ensure someone from the Foundation is informed about such security concerns, we will be happy to brainstorm around them.

Have y'all a great day.

[rphair]

Thanks very much @matteocoppola for the update in #444 (comment) ... I understand then that this will be ready for a final check before merge when:

• the several TODO sections are updated or provided (especially the currently empty "Implementing" sections, since I understand from our last meeting that implementors can be worried from being left on their own in this)
• these two points from your last summary are included in the CIP in a Versioning section (mandatory for CIPs; cc @Ryun1):

• CIP113 by itself is basically ready. This will be a V1, while we wait for the new ledger BuiltinValue to allow multi-utxo seizing (V2).
• V1 tokens should be easily upgradable to V2 if they keep the burning policy always allowed (so you can burn a V1 token to mint a V2).

Warning

Since the CIP directory & Rationale already contain deprecated version numbers 0 through 2 and the current document claims a v3, please @matteocoppola ensure the version numbers quoted above are kept consistent with those in the Rationale... p.s.: or outline a very clear distinction between Specification and document versioning schemes.

Until these significant pieces can be supplied, this should remain Waiting for Author — with potential implementors advised to take #444 (comment) into account in their development plans.

Thanks also to @colll78 @nemo83 for offering to discuss any security points privately & I would invite our visitor from last Tuesday's CIP meeting to make a report to the address posted in @colll78's GitHub profile, and also to any CF contact @nemo83 might provide.

[AndrewWestberg]

Has any thought gone into upgrading existing tokens to CIP-113 without massive disruption to existing dapps? Now that the GENIUS act is the law in the USA, we need a path to moving existing non-programmable tokens over to this standard.

Instead of minting new tokens controlled by the contract, can there be a path that migrates existing tokens into the contract so they become programmable over time as they are utilized in a dapp?

[michele-nuzzi]

@AndrewWestberg would the process of locking exsisting native tokens and minting programmable in the same transaction be enough to satisfy your requirements?

@colll78 is making sure additional checks can be added on mint of programmable tokens

[AndrewWestberg]

@michele-nuzzi It's a bit more complicated than that. For example, there's ~3m USDM in the Liqwid lending pool. Of that, 1.89m is borrowed so it's not actually there in the pool. People have put up collateral tokens in order to withdraw the USDM.

If we say suddenly that there is a new programmable USDM and the old one is no longer valid, that essentially breaks the Liqwid protocol if we are no longer allowing mints of the old USDM. As people withdraw the old USDM from the protocol, the APY spikes and nobody can add old USDM to the pool to bring the APY back down because there's nowhere to get it. Those in the pool get REKT. They have a super high APY, but they can't actually withdraw because there's no new USDM coming in to capture that high APY allowing them to exit their position.

So, from my perspective, the only approach is to have a way to convert the current USDM into a programmable version without changing its minting policy id, or get Liqwid and other lending protocols to support holding a mixed bag of both old and new token and somehow resolving it over time. That, or they are able to do the conversion with some type of admin keys (icky).

[colll78]

y to convert the current USDM into a programmable version without changing its minting policy id, or get Liqwid and other lending protocols to su

The admin keys for liquid already exist as a multisig (they already use them for liqwid protocol version updates), so given that they already exist, and supporting the mixed bag as a single pool would require using them anyway (to update to a version that supports such pools with two variants of the same token), then to me in this case it just makes sense to have liqwid use them to do the conversion.

Right now, you are able to add arbitrary logic to the minting policy of programmable tokens. So you could enforce to mint X amount of programmable USDM you need to burn X amount of current USDM or send it to an always fails script.

[nemo83]

@michele-nuzzi It's a bit more complicated than that. For example, there's ~3m USDM in the Liqwid lending pool. Of that, 1.89m is borrowed so it's not actually there in the pool. People have put up collateral tokens in order to withdraw the USDM.

If we say suddenly that there is a new programmable USDM and the old one is no longer valid, that essentially breaks the Liqwid protocol if we are no longer allowing mints of the old USDM. As people withdraw the old USDM from the protocol, the APY spikes and nobody can add old USDM to the pool to bring the APY back down because there's nowhere to get it. Those in the pool get REKT. They have a super high APY, but they can't actually withdraw because there's no new USDM coming in to capture that high APY allowing them to exit their position.

So, from my perspective, the only approach is to have a way to convert the current USDM into a programmable version without changing its minting policy id, or get Liqwid and other lending protocols to support holding a mixed bag of both old and new token and somehow resolving it over time. That, or they are able to do the conversion with some type of admin keys (icky).

While I do understand that there are a number of tokens that might want to migrate to a programmable version, why would USDM want to become programmable IF the regulation does not require that? USDM unique strength is the fact that, in line with regulation, if USDM is not involved in the transfer of ownership of the native assets (as it happens for contracts on ETH where owner of the contract ie. the issuer is somewhat involved in the transfer), there is no need to be programmable.

Again I understand you come from teh angle that some time might want to migrate, but why would USDM ?

[nemo83]

I've spent some time learning about CIP-113 and what's its relation with CIP-143.

It's my understand that CIP-143 has been now superseded in favour of CIP-113 because of the more comprehensive and versatile design.

As first task I got familiar with the WST stack, deployed the frontend on https://wst.easy1staking.com/ and become familiar with what the protocol does.

As second task I've translated the plutarch code of CIP-143 https://github.com/input-output-hk/wsc-poc into Aiken with the main goals of:

1. understanding in details how the protocol works.
2. compare script costs in each language

The aiken code is available in the public fork of the WST project here: https://github.com/easy1staking-com/wsc-poc/tree/feat/implement-aiken-version-cip-143. The code is missing last updates from @colll78 that enable bulk seize, which I plan to implement in the next few days.

Along with that, on the preview testnet, I've worked on the bootstrap of the protocol, issuance of test tokens and some test transfers. It's a work in progress and I've already spotted some issues and I'm fixing them as I learn more about the two CIPs.

I've also, with the help of AI, tried to understand the features overlap between cip113 and cip143, specifically for the token registry, and the programmable logic global script. Although the overlap is extensive, there are quite a few areas where things are different or completely missing. An extensive summary of the findings is available here

I am more than happy to contribute in restoring the momentum of this endeavour, but I'd like to gauge everyone's sentiment on how to move forward.

Beside some documentation missing in this CIP (see TODO sections), there is a significant gap in the, code. How do you guys plan to move forward?

As I'm new to the process, should the conversation being held here or on a CIP meeting?

Thanks in advance.

[rphair]

I've recently heard from @colll78 that there is a critical builtin missing from Plutus that the implementation is hanging up on (negateValue or equivalent):

• CIP-0168? | More BuiltinValue Functions #1090 (comment)

This may only be incidental and not the only reason why this document or its missing pieces haven't progressed. Even the CIP editors are lacking any recent or detailed information about where this proposal is going: since we've been among the last to know about anything happening with Programmable Tokens.

@nemo83 if you or other potential implementors want to use this PR thread to challenge the authors & key developers behind this standard to provide information more regularly and more completely, you would have my own blessing. Also, unless posted otherwise, I would think that your contributions above would be welcome in the Programmable Tokens effort.

[nemo83]

I've recently heard from @colll78 that there is a critical builtin missing from Plutus that the implementation is hanging up on (negateValue or equivalent):

• CIP-0168? | More BuiltinValue Functions #1090 (comment)

This may only be incidental and not the only reason why this document or its missing pieces haven't progressed. Even the CIP editors are lacking any recent or detailed information about where this proposal is going: since we've been among the last to know about anything happening with Programmable Tokens. @nemo83 if you or other potential implementors want to challenge the authors & key developers behind this standard you would have my own blessing.

I've had a couple of chats with Phil, Matteo and Raul and it's my understanding that it's possible to achieve all we need for programmable tokens with the current smart contract capabilities and we do NOT require any HF. It is also true that a number of CIPs which will be released as part of the next HF will make the code more efficient: the result will be simpler and cheaper validators.

To quote a great point made by @colll78, the "api" of the scripts will basically remain identical, which means the discussion and implementation of this CIP can proceed regardless of whether the CIPs for the new builtins are implemented and released. Once the HF happens and the new builtins are available, the code can be quickly updated and everything will still work. Hopefully this is gonna happen before cip113 goes live so we just have one version of the scripts.

CIP-113 is designed similarly to CIP-143 and plans to reuse some code, but after studying CIP-143 code and reading through this CIP-113, I've noticed some substantial differences which make the code unusable in the current form and requires some changes.

For this reason I'd like to discuss with the other editors what's the best way to proceed.

Some options are:

• should we use cip143
• update cip143 code to be in line with cip113
• rewrite cip143 code in aiken (partially done) and update it to cater for cip113 differences

[rphair]

I posted some comments around the time of that divergence, based on some high profile announcements that were made celebrating the new CIP-0143 code base shortly after it had been officially deprecated:

• CIP-0143? | Interoperable Programmable Tokens #944 (comment)

@colll78 cleared it up shortly afterward and I'd been hoping after that point that in fact one standard would be pursued and fully documented. Today the editors are still far behind what's happening... we can only ever support qualifying something as a standard when CIP creators keep updating and advocating a document while continuing to tie it together with the development in the real world... which has not been happening with this CIP candidate nor in this PR.

If @nemo83 you think a good way forward is to reboot CIP-0143 and use it as a code base, that would be a reasonable path as far as I'm concerned. We don't have any implementation code in CIP's, so whichever one gets merged most readily will the document that best characterises the state of the art and provides the clearest explanation of how the standard is, or will be, utilised. I don't see a problem with you putting forward a redeveloped CIP-0143 as long as you & the CIP-0113 advocates keep reviewing each other's work. (cc @matteocoppola @michele-nuzzi)

If you'd like to go that route, you could submit a PR that updates the currently deprecated (Inactive status) CIP-0143 to re-differentiate it from CIP-0113 and revitalise it with examples of contemporary development. I brought up this possibility at the biweekly CIP meeting a couple of hours ago, and all editors especially me & @Crypto2099 will be on the lookout for any submission like that, to bring it quickly into the review process... as well as following & supporting the commentary here.