Seem like ckETH mint is experiecing serious delay (more than 24 hours by comparing ETH and ckETH mint trasactions timestamp), is there something wrong?
Looking at the logs it seems that one of the 3 JSON-RPC providers used (eth.llamarpc.com) is experiencing some problems since 2024.05.09. Locally this can be reproduced by making some concurrent requests, some of them being responded by an expected 502, which could be the reason behind the many errors of the type Canister http responses were different across replicas, and no consensus was reached that the minter receives.
Hi everybody! Good news, ckUSDC is now live on mainnet! With the acceptance of proposal 129750, the ckERC20 “ledeger suite orchestrator” canister (vxkom-oyaaa-aaaar-qafda-cai) created a ledger & index canister for ckUSDC, and the ckETH minter canister is now also responsible for converting between native USDC and ckUSDC. The ckETH minter dashboard now also shows its progress on converting between USDC and ckUSDC.
The canister ids for all ckERC20 tokens can always be obtained from the ledger suite orchestrator canister’s get_orchestrator_info method, which currently returns
managed_canisters = vec {
record {
erc20_contract = record { chain_id = 1 : nat; address = "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" };
ledger = opt variant {
Installed = record {
canister_id = principal "xevnm-gaaaa-aaaar-qafnq-cai";
installed_wasm_hash = "4ca82938d223c77909dcf594a49ea72c07fd513726cfa7a367dd0be0d6abc679";
}
};
index = opt variant {
Installed = record {
canister_id = principal "xrs4b-hiaaa-aaaar-qafoa-cai";
installed_wasm_hash = "55dd5ea22b65adf877cea893765561ae290b52e7fdfdc043b5c18ffbaaa78f33";
}
};
archives = vec {};
ckerc20_token_symbol = "ckUSDC";
};
Instructions on how to use the backend canisters can be found here, and I expect that many dapps will have nice front-end support for ckUSDC soon. The dashboard already has support showing all ckUSDC transactions. Please share any feedback / issues / questions in this forum thread!
Congratulations to you all. You all are stars.
Many thanks to Manu and the DFINITY team for hard work! Congratulations on the launch of ckUSDC!
DFINITY (ICP) Happy 3rd Anniversary! 
The minting and dissolving functions for $ckUSDC are live on ICPSwap: ICPSwap
ShibaInu looks like the next largest ERC20 token by MC and has over 1 Million holders. Shiba coming next week?
Amazing achievement! Congrats. You have unlocked 18 items on my todo list. This is rocket fuel.
Congratulations! Job well done!
Now how hard would it be to support other USDC from other EVMs like Avalanche and L2s?
Amazing! Great work, folks! Perfect present for the third anniversary.
@gregory-demay, you are a superhuman.
Thanks a lot @roman-kashitsyn for the kind words!
That’s useless, why would you want usdcs from a lot of different blockchains, sounds like losing valuable time
Please is there a guide on how I can get some USDC on the Sepolia testnet, I tried using the Circles faucet and after pasting my Metamask address I don’t recieve any Sepolia USDC
I think the circle faucet is the only way unfortunately. You can also DM me your address and i’ll send you some testnet USDC.
Hey everyone,
Hope you’re having a great time, i just went trough the ckETH smart contract code, and i found the event only accepts the principal id, so if i understood it right, there is no way to specify in which subbaccount of that principal id we can mint the ckETH to. If that’s the case, considering that the updating process for ETH smart contracts are not so easy, will it be possible in the future to add this functionality to specify the subAcoount?
In the future, we could add a new smart contract and make the minter parse minting events from both of them, yes.
Could you explain please the use case for subaccounts you have in mind?
Thank you so much for the reply,
If that second smart contract could be added, would be amazing.
I’m working on a cross-chain swap POC, that allows all the users to swap a token from blockchain A to blockchain B. The core of the swapping mechanism is a canister on icp which manages the whole process. Since I want to make this crosschain swap in a way that user does not need to connect or provide an ICP wallet, the tokens need to be deposited in a specific subaccount for each user in that canister.
That is one the models i though about and i found the best.
Do you have any suggestions related to it?
Is my understanding correct, that you want to “bridge” the tokens from external blockchains to ICP, then swap to another ck-* token and then bridge back to the destination blockchain on every such swap? If yes, that might be more slow and expensive than needed. Instead of maintaining IC liquidity pools, you could consider maintaining the liquidity in the native pools of corresponding blockchains and then use the EVM RPC canister (I assume we’re talking about EVM blockchains) to orchestrate them?
The reason i am considering this way despite being slow, is cheap fees. once the token is minted in icp the fees are relatively cheaper and due to reverse gas model all the hassle related to the gas fees on EVM chains will be removed. but your point is also valid. we still have to decide on that.
This question might sound dumb, but can you explain would it be possible to use Helios instead of relying on RPC providers for minter canister?
You would still need to call an RPC provider, but you could get responses that include merkle proofs (for certain requests). This means you wouldn’t need to call multiple RPC providers to increase security. However, depending on the call you need to make, you might need a lot more calls, and AFAIK you can’t get proofs for log inclusion yet (ckETH currently relies on listening for event logs), but there is ongoing work in the Ethereum community for better Light Client support.