I want to build a little something for the Hackathon with my team. I’m trying to get an overview of the fungible token “standards” / token standard proposals that are available right now. Our main requirement is that it is implemented in Rust because we will need to implement additional functions and we want to stick with Rust throughout all of our canisters.
Based on this requirement, the most promising options regarding their activity, maturity and documentation seem to be:
I have read through the existing token threads in this forum and the documentation of the listed standards. However, I have a hard time on really figuring out pros and cons between the different options.
I would welcome all input that helps us to choose a token to work with. No matter if that is an objective argument or a subjective impression from your development experience with it. All help is super welcome! Thanks!
Based on the fact that the SNS will use the ICP Ledger functionality and because the structure has been proven to work over the course of a year with billions of dollars in it, I’d recommend the ICP Ledger standard for the hackathon. Origyn has used it to launch our OGY token with minor updates. We have also added some functionality to implement standard gateways so that you can give a pass-through canister rights to operate on the ledger. Our latest code base is located at ic/rs/rosetta-api/ledger_canister at master · ORIGYN-SA/ic · GitHub. You could fork that code or the base ledger from dfinity at ic/rs/rosetta-api/ledger_canister at master · dfinity/ic · GitHub and change a couple of variables(symbol, name, etc) and deploy a proven ledger very quickly.
I’ll try to get our dip20 passthrough canister open-sourced in the next couple of days, but it allows for adding transferFrom functionality to a standard ledger(a bit slow for consensus, but it gets the job done).
Nice to meet you. Quick disclaimer: I’m leading the team that develops the ICP Ledger Canister so I’m obviously biased .
Anyway, you should consider the ICP Ledger Canister as a starting point because:
it’s simple and easy to extend
it’s well tested and used by the NNS. In future it will also be used for SNS and ckBTC
we can support you if needed.
it’s supported by tools such as dfx and it exposes the Rosetta API via the Rosetta node
Hi Mario,
thanks for the answer and the disclaimer . What you and @skilesare say makes a lot of sense and looks pretty obvious.
I might be wrong here, but all decentralized exchanges that are being built right now seem to use fungible tokens based on IS20 or DIP20. Do you have an idea why they are not using a token based on the Ledger Canister?
Honestly I can give you only my limited point of view. IS20 and DIP20 guys may tell you more. There are several reasons I can think about.
First of all, the Dfinity Foundation has done a poor job discussing, explaining and promoting the ICP Ledger Standard until recently. The ICP Ledger was always going to be a standard but the Foundation had to focus on core features of the IC in order to provide the great platform we have today. The ICP Ledger Standard suffered as a result of this.
This has changed now and we are investing time and effort in making the ICP Ledger Standard available to everybody. The Dfinity Foundation is also discussing with the community about a common Token Standard and we are in contact with most teams developing a standard.
A second reason is that the ICP Ledger Standard doesn’t work at Principal level but at Account level where an account is a hash of Principal and Subaccount. Most teams behind other standards disagree with this. There is an explanation of why at Dfinity we think using Principals is a bad idea but, again, we did not discuss about this with the community enough.
A third reason is that the ICP Ledger Standard API is very simple and may lack some of the functionalities that DEX would like to use. For instance, the ICP Ledger Standard lacks the ERC-20/DIP-20 approve/transferFrom and it lacks notify from IS20. There are good reasons for this, e.g. we think that a smaller API is better for tokens, but again this wasn’t discussed with the community. There are reasons why DEX want those methods and we should have tried to find a common ground before.
There would be a lot more to talk about but I think in the end the root cause for having multiple standards is that we didn’t have a conversation about a common Token Standard before writing down each standard.
The good news is that there is still time as the IC is new and DEXs are even newer. My hope is that we can sit down together now and find a common solution.
It would make working with tokens on the IC much simpler and everybody would benefit from that.
I will say that is20 will not be a bad choice - supported by our wallet. Safety against cycle drain attack, and we intend to have the same api as the ledger for payments when it is updated, the ledger is good but is20 will have full cross-chain and dex support and is backed by a well-funded team. In addition, we will work to support the foundation on improving and updating the ledger standard.
For defi you may at the moment find is20 has a simpler api. Please also see the comparison:
Thank you for the extensive response. A main takeaway from your post for me is that the ICP ledger standard is a very good way to start unless you want to do a lot of stuff with a DEX, right?
Yes, I think the ICP Ledger is a very good way to start. It is already supported by most exchanges off-chain and hopefully it will be supported by some DEXes.
.