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.

[rphair]

@michele-nuzzi do I understand correctly that you and @colll78 have merged this with the candidate CIP-0143? If so I should say that is a brilliant step forward for Cardano and a rarely seen but vital part of any standards effort. 🎉

• @colll78 please, if so, confirm it's OK that we close CIP-0143? | Interoperable Programmable Tokens #944 as Deprecated (with note pointing here).
• Again, if I've understood correctly, that PR discussion should also be added to the Discussions: in this CIP (noted below).

Upon confirmation of the merge, I'll also remove candidate CIP-0143 from CPS-0003 just merged yesterday: https://github.com/cardano-foundation/CIPs/blob/master/CPS-0003/README.md

In any case this needs re-review and please I hope both of you can make it to our next CIP meeting where I've put it on the agenda: https://hackmd.io/@cip-editors/106

[michele-nuzzi]

@rphair I should be able to join the meeting the 18th

[michele-nuzzi]

Some updates in view of the next CIP meetings

we have an implementation compliant with the current standard proposed at HarmonicLabs/programmable-tokens

we have also tested the implementation in preprod

the tx d60e1814bb3c54dac253eedd36bf7236988d986587716b0102718534a7651e44 deploys a transfer manager policy

the transactions 18d840b71f1280949e0dcc9b6033e341cf68817c217849ce56da3bca5e1d1230 and bef4b363806244577d9b14c3a10b0205268c4a1d99ed2946ade8f2570875caaa showcase a programmable transfer using that transfer policy.

One transfer takes 38831 memory unit for the utxo spending validation (fixed), and in this case, for the transfer policy 707007 memory units are spent (this is implementation specific)

with a max tx memory unit parameter of 12_500_000, this sums up to around 5.97% of the max memory.

For the CPU instead, the spending (fixed) is of about 14034494 CPU units, and the transfer policy (implementation-specific) takes (in this case) 220104372 CPU units.

with a max tx CPU unit parameter of 10_000_000_000, this sums up to around 2.34% of the max CPU in a tx.

[rphair]

thanks @michele-nuzzi - could you reference the relevant details from #444 (comment) by:

• adding these benchmarks into either the CIP or the repository for your reference implementation?
• updating the link for showcase transactions? (currently it just points to that repository)

[fallen-icarus]

@michele-nuzzi Can you give more context to the above benchmarks? What was the transfer policy checking? I'd assume more complicated transfer policies will require more memory. Also, a quick look at those transactions only shows 1 asset being transferred. How do the benchmarks scale with more programmable assets (each governed by different transfer policies)?

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