Is ckERC20 is done? Can I use it for my custom token?

Developers
1

Hello, everyone.

I checked that ckUSDC is live on the mainnet.
This means ckERC20 is done?
I am waiting for ckERC20 to be done.

Best regards

2

Yes, ckUSDC utilizes ckERC20 behind the scenes!

1 Like
3

Thank you for your response.

So this means I can use ckERC20 for my custom token?
If so, where can I find guide how to use it?
I already have ERC20 token on ethereum. I am going to make ckERC20 token on internet computer so that users can convert token between ethereum and IC.

Thanks

4

Hi @bohdan1227, here are two options.

  1. You can propose that the ckETH/ERC20 canisters that are under NNS control (so the canisters listed here) add support for a new ERC20 token. That would be a proposal similar to Proposal: 129750 - ICP Dashboard, and if the NNS DAO approves, your ERC20 token is now supported by these canisters.

  2. You can take the source code of ckETH/ERC20, and deploy your own instance under your own control, such that you don’t need the approval of the NNS.

Out of curiosity, for which ERC20 token would you like to have a ck-version?

3 Likes
5

Hi, Manu.

Thank you for your kind guide.

We have token on ethereum and we are going to make it convertable between ethereum and ICP.
We are waiting for ckERC20 to be ready and it seems it’s already finished.
And I think first option is fit for us.
If you can help with this, that would be grateful.

Best regards

6

I suggest creating your own implementation/canister for custom tokens for now. Take a look at this tutorial. It will give you an idea of how to start with HTTP outcalls, verify events generated by your ERC20 token, and then perform your tasks on the Internet Computer blockchain.

7

What are the security implications of a custom ckERC20 canister?
For example, what happens to ckAsset if the developer does not top up the cycles or deletes it at some point?

8

The security of a trusted custom ckERC20 canister shouldn’t solely rely on the developer’s hands. It’s an NNS-backed project, meaning it is controlled by the Internet Computer community.

Moreover, ckAssets are essentially ledger canisters that use the ICRC standard token, providing a standardized and secure framework for token management.

9

@Manu is there any plan about ckUSDT, anyway, the official ckUSD series promoted by dfinity will make the ecosystem more and more prosperous.

10

Hi, everyone!

I found solution to send proposal using quill.
I am going to send proposal to ckERC20 Ledger Suite Orchestrator Canister to add ckNOBL (our utility token).
but what I am concerning is that where I should put ethereum NOBL address. Is it okay to add on Summary text?

This is what I referred; How-To: Create an NNS motion proposal - Internet Computer Wiki

Best regards

11

Looks like you submitted proposal 130142, which is a Motion proposal. It will not add support for NOBL if it is executed. Motion proposals to not change any code. The payload is inaccurate.

@Manu provided a link to a previous successful proposal 129750 that upgraded the NNS canister. Notice that it is a System Canister Management topic of the NNS Canister Upgrade type, not a Governance topic of the Motion type. You would have to submit this type of proposal and it would need to have complete and accurate details in the payload in order for it to execute automatically if it is adopted by the NNS.

That said, I don’t think the intent is for the community to do this on our own yet. I have a feeling that DFINITY intends to lead a community discussion on what ERC-20 token we want to see implemented as the next ckERC20 token. I would still expect DFINITY to originate ckERC20 token proposals for now. Whenever it is open to the community, there would certainly be an expectation of plenty of discussion and community feedback prior to submitting the proposal. Generally, proposals that hit the NNS without any warning don’t get adopted. You should lead community discussion and give people time to think about and make educated decisions on how they would vote for your proposal. People need to be given time to study and discuss your proposal.

Anyway, I hope you find this to be constructive feedback. Good luck.

4 Likes
12

Why do we need gatekeeper for a simple ckERC20? Anybody should be able to launch a ERC20 token in a decentralized manner without permission.

2 Likes
13

Go for it. Submit a System Canister Management proposal for your favorite ckERC20 token. Here is a primer to get you started.

14

Are you saying that the submission is not correct?
…plenty of discussion before submitting? I am also wondering how this will hamper the onboarding of many devs - some devs like to act quickly without first having to build up a fraternity… are you saying we need to first become buddies?

15

Hi, @wpb

Thanks for your explain.

I also read ic/rs/ethereum/ledger-suite-orchestrator at master ¡ dfinity/ic ¡ GitHub .
Then, what do you suggest for new ckERC20 token support?

Or should we wait for a while that dfinity team discuss and decide about ckNOBL support?

Please let me know what should I do.

Best regards

16

Did you read @Manu’s suggestion?

You can take the source code of ckETH/ERC20, and deploy your own instance under your own control, such that you don’t need the approval of the NNS.

17

Thanks everyone for your interest in enabling additional ckERC20 tokens.

To recap;

  • The ckERC20 orchestrator has been built to enable new tokens in a scalable manner which doesn’t require coding, only canister configuration updates.
  • New ckERC20 tokens are enabled by an NNS DAO proposal. Anyone in the community with a neuron may submit proposals. DFINITY will publish a clearer help guide soon.

However as the orchestrator smart contract is newly deployed, DFINITY would suggest that the community activates new ckERC20 tokens at a reasonable pace, at least initially, to mitigate new smart contract risk. Suggestion would be around ~10 additional ckERC20 tokens beyond ckUSDC over the next 2 months.

DFINITY will both propose additional ckERC20 tokens and vote on community initiated ckERC20 proposals. The foundation’s goal is to encourage a diversity of twinned tokens, so will vote agnostically on community initiated ckERC20 proposals. Though the foundation will sanity check proposals for technical accuracy (e.g. proposal is correctly formed, payload and text is consistent, ICRC-1/2 configuration is consistent with the ERC-20 token being twinned etc).

Hope this helps & let the “chain fusion summer” begin…

13 Likes
18

Thanks for clarifying @Pete. Presumably the ‘ckERC20 Ledger Suite Orchestrator’ canister therefore shouldn’t need upgrading to a new binary (just to facilitate a function call to add the new ckERC20 token to the canister configuration and create the new ledger suit). But unless I’m mistaken it looks like the intended pathway for triggering this is a ‘System Canister Management’ (SCM) proposal, executing the NnsCanisterUpgrade function (is that correct?).

In an ideal world, wouldn’t it be worth avoiding desensitising the community to SCM proposals proposed by unrecognised neurons / non-Dfinity devs (given the potential for such proposals to modify critical system components). It feels like this sort of thing should have a dedicated proposal type with limited scope in terms of the changes it can apply.

Please let me know if I have the wrong end of stick.

1 Like
19

You’re right that ckERC20s are added using normal canister upgrade proposals. While this proposal type can do more than is needed to add an ERC20 token, the upside of using this type is that there is no need for custom logic in the NNS. You could imagine introducing some new ckETH/ckERC20 specific proposal type, but now there’s a new type of proposal that needs to be built into the NNS and that all voters need to understand.

In an ideal world, wouldn’t it be worth avoiding desensitising the community to SCM proposals proposed by unrecognised neurons / non-Dfinity devs (given the potential for such proposals to modify critical system components).

This i actually see very differently. I don’t think anybody should trust some proposal just because it happens to be submitted by dfinity. We should always verify that all proposals make sense, and otherwise reject, the submitted should be irrelevant imo.

20

Thanks @Manu.

You could imagine introducing some new ckETH/ckERC20 specific proposal type, but now there’s a new type of proposal that needs to be built into the NNS and that all voters need to understand

I was thinking that a more general purpose way of achieving this might be to introduce a ‘System Canister Payload’ proposal (or similarly named), such that it’s clear that all it does is feed the payload to an update call on the canister (and not capable of modifying the binary that the canister is running). This way there’d just be one new NNS function that is clearly self describing, and therefore more understandable for the majority of the community and easier for them to review and hold an opinion on. I think making things easier for more people to engage is an important thing to strive for, don’t you think?

I don’t think anybody should trust some proposal just because it happens to be submitted by dfinity

I agree - personally I would never manually vote on a proposal without first reviewing and doing my best to understand the changes. However I don’t think this is true for everyone. Personally, I think it would be a good thing to encourage everyone in the community to exercise extreme scepticism in the face of SCM proposals that originate from new or unrecognised neurons. But I’m not sure it’s realistic to expect everyone in the community to exercise that same level of scepticism for every single SCM proposal, particularly not if they’re normalised and typically proposed by anyone. The potential for damage from a nefarious SCM proposal seems enormous.

1 Like