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.

[Ryun1]

please don't forget to update the directory name to CIP-0113 when you can

[rphair]

@michele-nuzzi thanks for your confirmation at this last hour's CIP meeting to keep refining the transaction mechanics, along with whatever changes need to be made to the "showcase" transaction(s) and accompanying benchmarks. As soon as that's posted here, we'll proceed with further GitHub review and/or put it on the next meeting agenda.

[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.