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.