I would like to start a forum thread on ckETH, where we can discuss the design and post updates wrt progress.
- Chain-key Ether, or ckETH, is an IC-native token that represents Ether (ETH), the native token of Ethereum. Anybody that has $ETH can use a canister smart contract on the IC to convert that into ckETH. Vice-versa, any holder of ckETH can choose to receive the underlying ETH instead. All ETH backing ckETH is held by a canister smart contract using the threshold ECDSA functionality.
- Since ckETH is an IC-native token, it can be transacted very fast and with low fees, and is easy to use from other IC dapps. ckETH would follow the ICRC1 and ICRC2 standards.
- If you’re familiar with ckBTC, then you can understand ckETH as the equivalent of ckBTC but for Ether instead of Bitcoin.
DFINITY is working on an implementation for ckETH, with the following components.
- A ledger canister, an archive canister, and an index canister. These three canisters are used for many ledgers on the IC, including all SNS tokens. One change here is that they need to support 256 bit amounts.
- an Ethereum smart contract to help make converting ETH into ckETH easy.
- a “ckETH minter” canister. This canister is responsible for converting between ETH and ckETH. It has minting capabilities on the ckETH ledger, and holds all the ETH using tECDSA.
How would converting ETH into ckETH work?
We plan a smart contract that exposes a function “deposit”, which takes as argument a byte string. To convert x ETH into ckETH, a user would call this deposit function and encode its IC principal as bytes in the argument. It attaches x ETH to the call. This smart contract emits an event for every deposit call.
The ckETH minter canister, using the Ethereum integration, periodically looks up the finalized height of the Ethereum blockchain, and looks if there are new deposit events registered. If so, then for each deposit event, it mints the corresponding amount of ckETH to the principal that was encoded in the deposit call.
How would converting ckETH into ETH work?
A user holding ckETH that wants to convert x ckETH into native ETH would first have to approve the ckETH minter canister to take at least x of its ckETH, by doing an ICRC2 approve. The user then calls the ckETH minter canister, saying it wants to convert x ckETH into ETH, and specifies an Ethereum address where it wants to receive the ETH. The ckETH minter canister then tries to burn x ckETH from the user (using an
icrc2_transfer_from which uses the previous approval from the user), and then construct a native Ethereum transaction sending the user ETH. We are planning that the user is responsible for the gas fees on Ethereum, so in this example, the user would receive x minus gas fees ETH.
How does the ckETH minter communicate with Ethereum?
In the long run, the plan is to use the native Ethereum integration, where IC replicas run Ethereum nodes. While we are in “phase 1” of Ethereum Integration, the ckETH minter will communicate with Ethereum by contacting providers that support the Ethereum JSON-RPC API using HTTPS outcalls. To ensure no single point of failure, the minter will contact multiple providers for any security relevant state-changing operation (e.g., minting or withdrawal) and only proceed if all received responses are consistent. How many and which providers will be contacted is still to be defined.
We hope this forum topic can serve as a good place to discuss all things around ckETH, and keep everybody up to date on our progress. From DFINITY’s side, we have @0rions, @gregory-demay, @roman-kashitsyn, @dieter.sommer, @bogwar, @benji, and myself (@manu) involved.
So please feel free to ask questions here, challenge the design / propose alternatives, we look forward to discussing ckETH!