Happy New Year all!
Here is a tutorial on how to acquire ckETH. Please feel free to share!
6 Likes
Hi everybody!
Now that ckETH is up and running, DFINTIY is shifting focus to ckERC20.
What is ckERC20?
Ethereum has many more valuable assets than just ETH, and many of them follow the ERC-20 token standard. With ckERC20, we plan to support âtwin tokensâ on ICP for a subset of those ERC20 tokens. For example, USDC is an ERC20 token, and (after the ckERC20 project is up and running) we would have ckUSDC on ICP. Similarly to ckBTC and ckETH, the ckUSDC token would be fully backed by native USDC which is held by a canister, and anybody can convert between USDC and ckUSDC.
How do we propose to build it?
The ckETH project currently consists of a standard ledger suite (consisting of a ledger canister, an index canister, and an archive canister) and the ckETH minter, which is responsible for converting between ETH and ckETH, and holding the native ETH that backs all ckETH. We propose to extend the ckETH minter canister to also support conversions for ERC-20 tokens.
Converting a native ERC20 token into ckERC20
We propose to have an Ethereum smart contract specifically to help with ckERC20 deposits. To convert a native ERC20 token on ethereum into ckERC20, the user would
- approve the ckERC20 helper smart contract to take some of their ERC20 tokens (eg, approve that the helper contract takes 10 USDC out of my account)
- call the âdepositâ function on the helper smart contract, specifying which ERC20 token the user wants to convert and the amount, and the userâs ICP principal that would receive the corresponding ckERC20 tokens. The helper smart contract would take the specified amount of the userâs tokens (as approved in step 1), emit an event showing that a deposit happened, and forward the funds to the ckETH minter EOA address (controlled via threshold ECDSA).
This is all that the user needs to do. Behind the scenes, the ckETH minter will periodically look for such deposit events in finalized Ethereum blocks and mint the corresponding ckERC20 for the users.
Converting ckERC20 into native ERC20
If a user has ckERC20, they can request to receive the native ERC20 token back. However, this would lead to an Ethereum transaction that costs gas in ETH. Our proposal is to let the user pay that fee in ckETH. The flow could then look like:
- ICRC2 approve the ckETH minter to take some amount of ckETH
- ICRC2 approve the ckETH minter to take some amount of some ckERC20 token
- call the ckETH minter requesting to withdraw some specified amount of some ckERC20 token to a specified Ethereum address
Behind the scenes, the ckETH minter will burn the userâs ckERC20 and ckETH tokens, and submit an Ethereum transaction to send the user the native ERC20 tokens to the specified address.
How to manage all these ledger suites under NNS control?
We propose to have ckERC20 all under NNS control. However, since every supported ERC20 token leads to a separate ledger canister suite, this may lead to many canisters that have to be upgraded via NNS proposals. We propose to introduce a âledger suite orchestratorâ canister. This LSO canister would be controlled by the NNS, and all ckERC20 ledger suites would be controlled by the LSO canister. This means we could have one NNS proposal to the LSO canister saying âupgrade all ledgers to version Xâ, rather than requiring many separate proposals. The LSO would also be useful in keeping all these separate canisters topped up with cycles.
Which ERC20 tokens would be supported?
We propose to start with USDC and USDT, as this would bring trusted stablecoins to the ICP ecosystem, and stablecoins are super important for DeFi. After that, more tokens could be added via NNS proposals.
Discussion
Please let us know what you think! Suggestions, ideas, questions are all very welcome.
22 Likes
I have a concern and some questions. I am not very familiar with the design of ckETH and these tokens yet. My concern is around Circle being able to freeze USDC addresses. Iâm not arguing against their ability to do this for legal reasons, but Iâm worried that if all ckUSDC is locked in the same smart contract on Ethereum, and that is reflected in a single or small number of USDC addresses on Ethereum, then any illicit activity could prompt the need for Circle to block all of ckUSDC on Ethereum, halting the ability to withdraw from ICP back to Ethereum.
Is this how the architecture works at a high level? Is this a valid concern if so?
If this is a valid concern, could ckUSDC be architected to not flow through one address on Ethereum, thus allowing individual addresses to be accountable for their own actions and removing the centralized point of failure for the entire bridge if Circle decides they must freeze an account?
12 Likes
Thanks Jordan! The concern is valid and is applicable to any kind of smart contract using one address to store all funds. In fact, this is how Circle also blocked the Tornado Cash assets, IIRC.
In my opinion, this is not a problem of the architecture, but a consequence of the centralised nature of the asset. E.g. LUSD would not have any problems like this.
The proposed way of keeping separate deposits on separate addresses is not feasible, as ckUSDC tokens on the ICP side are fungible and the canister needs to be able to operate knowing that it has full access to all deposited ETH backing ckETH. If we would keep the deposits on individual addresses owned by this canister, then it would not be even possible to know in advance how much ETH the canister owns effectively: in contrast to the UTXO model, the ETH from every individual address would require an individual transaction with individual fees which can fluctuate arbitrary. For example, imagine that after a year the funds are scattered across millions of addresses, mostly with small balances.
7 Likes
This is very exciting news! Itâs a logical and expected development after the addition of ckETH. Iâm confident that over time, youâll be able to expand the standards to ERC-721/1155 as well.
I wanted to share my perspective as an average DeFi user in EVM networks. With the development of L2 and some EVM-compatible sidechains, conducting daily transactions with stablecoins such as USDT, USDC on the main ETH network is becoming impractical due to high fees, sometimes exceeding the transaction amount itself. Do you plan to deploy canister groups for L2 and sidechains in the future? As far as I understand, this is a feasible task considering the similar RPC node interface. I believe that the availability of L2 and sidechains from IC will unlock a significant amount of liquidity. Thanks in advance for your response!
1 Like
conducting daily transactions with stablecoins such as USDT, USDC on the main ETH network is becoming impractical due to high fees
Yes, thatâs a very good point. How much of a problem that is though depends on how people end up using ckERC20. I would imagine that for most users, converting small amounts of eg USDC into ckUSDC or vice versa does not make sense due to the fees. Instead, they would just trade ckUSDC against ckBTC, ckETH, ICP, SNS tokens etc on ICP dexes like Sonic/ICPSwap/ICDex etc, with very low fees. The fact that it is possible to convert between ckUSDC and native USDC means it will always be worth approximately as much as USDC (otherwise there is an arbitrage opportunity, and for larger value conversions the transaction fee is irrelevant), which should ensure you always get a fair price on a DEX.
If you have some small amount of ckUSDC and want to convert it to fiat, itâs likely cheaper to trade ckUSDC/ICP on a dex, and send ICP to a CEX to convert to fiat. All of the above applies equally to ckBTC and ckETH.
Do you plan to deploy canister groups for L2 and sidechains in the future?
DFINITY currently does not have concrete plans, but I do expect that in the future we would see eg ckArbitrumUSDC on ICP, perhaps DFINITY works on that at some point, or someone else in the ICP community creates it.
2 Likes
Manu can there be a way to burn ckusdc back to usdc by not having two txns involving cketh for gas fees. Itâs a bad ux. Canât you just deduct from ckusdc for gas fees?
2 Likes
@Sawyer this would require a decentralized market with excellent liquidity for converting this ckUSDC to ckETH because the minter can only pay for the transactions with ETH. Itâs not really feasible on IC right now. Moreover, the bridging is not expected to be on the agenda of an average IC user, like itâs not the case with Ethereum L2s as well.
1 Like
Has it been decided which token will pay the ckERC20 fee?
If it is in order, it will be ckETH, but I would like to be able to pay with each of my own tokens. If ICP is not required to pay for gas with native tokens, we can bring in non-crypto users who only hold ckUSDC or ckUSDT as payment.
Agreed. An integration with an L2 would be more beneficial as you can withdraw directly to a CEX address.
Good Idea. We need stable coins on IC. Only risk is what will be when eth blockchain will go down? Then this token might be worthless. Target picture would be better to have direct stablecoins minted on IC.
Team whatâs the current timeline of launching these tokens as the ICP defi ecosystem seems to be holding its breath for native stablecoins or ck stablecoins?
Our current very rough estimate is ~3 months, but of course we may run into unexpected issues that delay things.
7 Likes
Does this mean that an NNS (self custody user) will be able to swap between USDC and ckUSDC, in the same way as what is now possible for ckBTC and ckETH?
Yes exactly, the NNS FE and other front ends can support conversion between USDC and ckUSDC
Heads up: ckETH is currently processing ETH â ckETH deposits with a delay. This is due to cloudflareâs ethereum gateway is one of the gateways that are used by ckETH, and cloudflareâs gateway seems to have problems since yesterdayâs Dencun ethereum upgrade. The deposits will be processed eventually, as soon as the RPC providers used by ckETH report consistent data, which means as soon as cloudflare returns correct data.
2 Likes
But⌠I thought we didnât depend on big tech 
The Ethereum integration is still in the so called âphase 1â stage (see this post and attached links for more details). In this phase the IC minter canister fetches the Ethereum state from multiple providers (Cloudlfare, Anker, etc.) via HTTP outcalls and only if they all agree, uses this data.
3 Likes
Ah, great to hear, thanks! Iâll take a closer look at that post.
1 Like
This shows some of the phases of the project:
3 Likes