ckETH: a canister-issued Ether twin token on the IC

The issue was treated as an urgent incident and resolved with proposal 134344. I tested a conversion in OISY, and it worked out. Shoutout to @gregory-demay and team for fixing this on a Saturday.

6 Likes

Yes!!! Shoutout to @gregory-demay and team for fixing this on a Saturday. Thanks so much! Let us test it out.

Updated: Tested it, and it’s working fine! Thanks so much to you all!

6 Likes

@gregory-demay Hello, how to decode the principal and the subaccount in js, and what should i post if subaccount is empty?

Hello @honopu

how to decode the principal and the subaccount in js

I’m not really a javascript expert but I guess you can get inspiration from the encoding of an IC principal on the minter dashboard.

what should i post if subaccount is empty

The default subaccount corresponds to a 32-byte array full of zeroes ([0;32]) which can be represented by 0x (see the docs).

What is a list of all tools and wallets that are currently available for the ETH → ckETH conversion? I know Oisy and dfx. Any other ones?

Regarding Oisy, I see that I can convert ETH to ckETH and the destination that gets credited with the ckETH is always the principal that I am logged in with in Oisy. Wouldn’t it be possible to extend Oisy that it accepts a “destination” for the minted ckETH which could be any ICRC-1 account (principal + subaccount)?

I am trying to streamline ETH deposits into DeFi canisters, hence the question.

On github I see in EthDepositHelper.sol and ERC20DepositHelper
that the deposit functions do not have a subaccount argument:

function deposit(bytes32 _principal) public payable 

However, there is another helper contract DepositHelperWithSubaccount.sol in which the deposit function does have a subaccount argument:

 function depositEth(bytes32 principal, bytes32 subaccount)

Which helper contracts are deployed? Are they all available?

2 Likes

Some others that come to mind are ICPSwap, ICLightHouse, and plug wallet (where you click the “mint” button).

Yes they’re all available, but we recommend using the one that supports subaccounts, so 0x18901044688D3756C35Ed2b36D93e6a5B8e00E68. You can obtain that address from the ckETH minter by calling get_minter_info.

4 Likes

We are right now working on improving the conversion flow to include a “send”, i.e. to allow a destination address. But currently only in the conversion back into the native token. The way I understood it so far, this was done this way because the minters did not allow also specify an additional principal as recipient.

But we can look into it to see if this can further be improved.

2 Likes

Dear Grégory @gregory-demay and the team,

We’ve received feedback from several users who attempted to mint ckERC20 tokens but haven’t received them yet.

After checking the dashboard:

We noticed that two of the Helper Smart Contracts are marked as “deprecated,” and the one in “active” status appears to have stopped syncing blocks. The block height has remained at 22,502,174 for about 23 hours.


We also tested minting ourselves, and it has been nearly two hours without success.
Could you kindly help check if there might be a syncing issue with the block height update?

Thank you!

2 Likes

Hi @ICPSwap!

Thanks for reaching out!

We noticed that two of the Helper Smart Contracts are marked as “deprecated,”

That’s correct and was announced in this post, in addition to the proposal 134264. Dapps should migrate to using the new helper smart contract.

The block height has remained at 22,502,174 for about 23 hours.

Unfortunately it seems Ethereum JSON-RPC providers are once again unreliable since a few hours, which started around 2025-05-18 08:00 UTC.

Upon closer inspection of the minter’s logs, it seems that 2 providers are unavailable or returning incorrect data (Cloudflare and Llama), which explains the log scraping being currently stuck (agreement between 3-out-of-4 providers is required).

We will keep digging and make a proposal (e.g. to change queried providers) if needed.

3 Likes

Dear Grégory @gregory-demay, Thank you so much for the detailed explanation.

Let me share the latest update from the users’ side: the active Helper Smart Contract (0x18901044688D3756C35Ed2b36D93e6a5B8e00E68) has reached block height 22,508,174, and several users have started receiving their minted tokens.

However, the “active” block height shown on the dashboard still appears to have last synced 24 hours ago.

Does this mean that if a user mints again now, the tokens may be delayed by up to 24 hours—until a proposal is made to change the queried providers?

Thanks again for your support!

The minter is scraping the logs of 3 different smart contracts. So whether the corresponding amount of ck tokens was mint for a user depends on which helper smart contract was used for the deposit. The “Last synced block number” indicates that the minter scraped all logs for that helper smart contract until and inclusive that block number (that means for example that deposits using the deprecated ETH helper smart contract do not seem affected, while deposits using the other 2 smart contracts are affected)

3 Likes

Hi @ICPSwap!

Good news, proposal 136701 was adopted quickly to resolve the issue and the minter is no longer stuck :crossed_fingers:. All deposits should now have gone through.

5 Likes

Great news! Really appreciate how quickly you guys acted—everything looks great now!

3 Likes