I think this should be quite manageable, because I believe most of these L2s (including Optimism / Base) use the Ethereum JSON RPC interface. So I would hope that most of the ckERC20 work would directly carry over to ck-ERC20-on-base tokens, you would just make the HTTP outcalls to the ETH RPC interface use a different chain id. But none of this is tested, and I’m sure there will be some surprises. So I think dfinity will first focus on getting ckETH fully done, then ckERC20 for Eth mainnet, and then we (dfinity or other ICP community members, it’s all open source) can see how much effort it would take to take the code of ckETH / ckERC20 and make it work with L2s.
You can now play around with ckETH yourself! We have a testing version of ckETH installed on ICP mainnet that we call ckSepoliaETH, as it works with Sepolia testnet Ether.
You can obtain Sepolia ETH (from some faucet, like this or this or this), convert it to ckSepoliaETH, send ckSepoliaETH around between wallets, and convert back to SepoliaETH. You can find the instructions here.
The canister IDs of ckSepoliaETH can be found here, and the ckSepoliaETH minter also exposes a dashboard showing conversions and the corresponding ethereum transactions.
Note that there is no nice front-end yet, so you’ll have to be comfortable with some dfx calls especially for the last step. If you’re a developer and aim to support converting between ETH and ckETH in your dapp, then you can also start experimenting with ckSepoliaETH.
Please keep the following in mind
This is still under development, so things may break, and the state of the canister will be reset upon upgrades.
It is expected that there are still bugs. Please help us make ckETH rock solid by reporting those here.
In case the instructions don’t work for you, please report back, and we’ll be happy to help and improve the instructions.
Hi Manu, can we have a working group so that the community can provide valuable feedback on the design of the bridging? This will be a major feature and I know that we’d like to provide some commentary on the design to make it as interoperable with our products as solutions as possible.
hey everybody, the ckSepoliaETH minter is minting again!
What went wrong? The minter periodically looks up the current Ethereum block height, and then looks for Ethereum deposit events in block interval [last_scraped_height; current_height], and then updates last_scraped_height to current_height, indicating that we observed those events. The problem is that there is an off-by-one error here. As an example, we may at one point scrape the events for blocks [500, 600], and then [600, 700], but since these intervals are inclusive, the events in block 600 are now observed twice. If there happens to be a deposit event in block 600, it would now be processed twice. By a funny coincidence, this actually happened at block 4458589: it happened to be at the boundary of the scraping interval, and happend to contain a deposit transaction.
What went well? We had asserts in place that would disallow ever minting ckETH twice for the same deposit event. So when we got to block 4458589, the minter ran into an assert that prevents it from minting again, causing the log-scraping routine to get stuck, as it panics due to this assert every time it tries to make progress. But getting stuck is much better than incorrectly minting ckETH!
We fixed the off-by-one error, and now you see that the minter is making progress again, and everybody that deposited SepoliaETH should see their ckSepoliaETH now.
Thanks to everybody that already tried to convert SepoliaETH into ckSepoliaETH, you all helped uncover this bug!
First off, a big thank you to the team working on ckETH. Your hard work is really making a difference and it’s awesome to see.
As an experienced Ethereum developer, I was excited to test ckETH while working on a payment system. I found it super easy and efficient to accept both ETH and ckETH directly with just a click of a button. This is a huge step forward, not just for the Internet Computer, but also for Ethereum, as it cuts out the need to create a new contract or deal with multiple JSON RPC calls for verification.
I have created a payment system that accepts ETH directly into the canister, although the minting process takes a bit of time. However, this wasn’t a big issue as we can verify the transaction event directly from the canister using outcalls.
I’m also working on a tutorial video to share how I built the payment system using ckETH. I’ll drop the video here soon!
Thanks again for your hard work on ckETH. I’m looking forward to discussing more about it and seeing the progress in this forum.
Max this is a good initiative. Having open working groups promote transparency, which ICP lacks at the moment. Waiting for official response from DFINITY. @Manu
We are also archiving the discussions in this topic, including the time stamps and flags.
Is DFINITY planning KYC for this feature like they did with last minute KYC announcement for ckBTC?
As Jan mentions a “decnetralized solution” but having only one party, i.e. toniq labs providing API, which was decided by DFINITY does not seem decentralized.
Yes, Max and I actually met to discuss in a bit more detail, and we are hoping that some parts of ckETH can be reused by bitfinity. Wrt transparency: note that this forum thread is exactly created for that purpose: we outlined our planned design, keep everybody up to date on progress, develop completely in the open with open source code, and actively ask for feedback. In your view, does this forum not achieve to give transparency? How could we do better?
We do have technical working groups, but overall they are not very well attended, so I think a forum discussion is a better approach.
Just to be precise: there is no KYC in ckBTC, but there is chainalysis KYT. So this is not about knowing identities of users, but rather about avoiding money laundering.
We do not plan to do something similar in ckETH. The canister does contain a list blocking addresses that are sanctioned by OFAC, see the source code. Curious to hear your thoughts on this.
The wiki page explains that the KYT canister can actually work with multiple parties providing chainalysis API keys. So if anybody would like to help, please get a chainalysis KYT subscription and propose to add your principal as an additional API key provider.
Yeah we do know that. This design iteration came after the community outrage. Doesn’t change the flawed approach DFINITY initially took while designing the feature.
As for ETH
I did not expect it to be uncensored either. What would DFINITY do if something like Spinner.cash gets hit with OFAC sanctions?
Its not about preventing money laundering or illicit activities. DFINITY has made it clear that it will do everything in its control to avoid legal liabilities, even if it means enforcing censorship and ignoring Neutrality.
No it does not. For a “non profit” swiss corporation building decentralized cloud, DFINITY sure collects a lot of data in this governance forums and enforces censorship.
My Question to you is why did DFINITY not get chainalysis subscription for KYT?
It only makes sense for DFINITY to Fund and Create a decentralized KYT canister controlled and funded by DFINITY, since they are the only devs who built this feature.
Why do we have to rely and depend upon third party such as Toniq which along with DFINITY was Front running this feature for their Ordinals “Marketplace”
WHY CANNOT DFINITY PROVIDE API?
if you feel the questions above are off topic, I could ask them same in KYT topic, would you (or DFINITY) answer there?
Thanks to the updates on ckETH by Manu and the development team, the IC community can now experiment with a test version of #ckETH!
ckSepoliaETH (ckETH test token) is now available on ICPSwap. We have minted some ckSepoliaETH and added liquidity for the purpose of testing its stability, conducting research, and preparing for the eventual launch of ckETH.
Here are some mint guidelines we have put together to help interested users easily participate in the testing of minting. Please take a look:
1/ Use your wallet and connect to ICPSwap: ICPSwap
Click on “Add Token” and select ckSepoliaETH to add it.
2/ Visit: ckETH Minter Dashboard
Under “Principal → Bytes32 conversion,” input your wallet’s Principal ID from the first step to obtain a 0x address.
3/ Visit Sepolia Testnet scan: CkEthDeposit | Address 0xb44b5e756a894775fc32eddf3314bb1b1944dc34 | Etherscan
Click “Connect to Web3” and use MetaMask or another wallet to connect.
In the “deposit” field, enter the amount you want to mint. In the “_principal (bytes32)” field, input the 0x address obtained in the second step.
Click “Write.”
4/ Visit the dashboard for ckSepoliaETH: ckETH Minter Dashboard
Monitor the progress. After approximately ten minutes, once the ICP network and Sepolia Testnet data synchronization is complete, you can return to your ICPSwap wallet to check the balance of ckSepoliaETH.
Thanks! Worked fine for me, just had to get some SepoliaETH to the MetaMask first - the faucet.sepolia.dev didn’t load (MetaMask linked there) but sepoliafaucet.com worked fine - now I see the faucet mentioned in this topic already, but still it can be convenient to have this also under the post with your instruction.
We explored the issue of KYT for ckETH and our conclusion was to not delay deployment by introducing a full blown KYT. It may be interesting to know that one of the factors that played a role in this decision was that exchanging ETH without KYT is the rule rather than the exception in the wider blockchain space.
Nonetheless, the first version of the ckETH canister
Implements the OFAC blacklisting
Provides full traceability and transparency of transactions within ckETH
so it provides some basic protection for legitimate ckETH holders.
We plan to hand over control of ckETH to the NNS. That means that if the voters believe that KYT should be added to ckETH, this is possible in a future upgrade.
Threshold ECDSA is at a different level of abstraction (further down the stack) and the decision to do KYT for one application that uses (ckBTC) is not immediately linked to the decision to do KYT for another application (ckETH).
For ckETH it was a trade-off where we had to decide if the risks of not doing KYT via chainalysis (or some other providers) is big enough to implement it in the first version of the canister, or go with a simpler implementation and refine this later (if deemed necessary via NNS). We picked one side of the trade-off and I outlined the reasons.
hope this helps clarify how the decision was made.
