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 
. All deposits should now have gone through.
5 Likes
Great news! Really appreciate how quickly you guys actedâeverything looks great now!
3 Likes