ckETH’s New Exchange Rail Turns Ethereum Deposits Into an ICP Workflow

The Internet Computer’s latest Chain Fusion upgrade targets a familiar failure point: centralized exchanges can send tokens to an address, but they generally cannot call the smart-contract helper that previously connected an Ethereum deposit to an ICP principal.

NNS proposal 143820, recorded as executed, upgrades the ckETH minter canister sv3dd-oaaaa-aaaar-qacoa-cai with Wasm hash da607e433d408192428aaa14373efbd8dcb083a0e7184099b909b7a758971b07. The proposal identifies commit faa1a8a77f71e183b37bb9f25907e90cab7516bc and introduces the deposit-from-exchange flow described in the DFINITY design document.

The key change is an address-based attribution model. A user calls deposit_erc20 on the minter, which derives a dedicated Ethereum address for the user’s ICP principal and subaccount. The user can then withdraw a supported ERC-20 token from a centralized exchange to that address. The exchange needs only a normal token transfer; it does not need to understand ICP principals, subaccounts, or the ckETH helper contract.

The minter scans registered deposit addresses. When it detects a sufficient balance, it creates an attestation binding the deposit address to the intended ICP account. On the first sweep, the deposit address also signs an EIP-7702 authorization that delegates execution to a sweeper contract. EIP-7702 is Ethereum’s standard for letting an externally owned account set a persistent delegation indicator to contract code; the official specification defines the authorization list and delegated execution model.

A separately funded sweeper address submits the transaction and pays Ethereum gas. The delegated code verifies that the attestation belongs to the deposit address, then routes the funds through the existing deposit helper. That preserves the established ReceivedEthOrErc20 event and lets the minter’s existing log-based accounting credit the corresponding ckERC20 balance.

The architecture separates three responsibilities. The main minter address holds the backing assets and serves withdrawals. Deposit addresses identify user accounts. The sweeper address has its own Ethereum nonce lane, so a stuck sweep should not block withdrawals from the main address. The design also makes sweeping permissionless: anyone may submit a valid sweep, but the attestation fixes the account that receives credit and the destination remains the minter’s main address.

Backing is treated as an accounting invariant rather than an assumption. Sweep gas is funded by burning ckETH from the minter’s fee account before ETH is spent, so the design requires cumulative ckETH burned for sweep gas to cover cumulative ETH spent. This does not make gas free; it moves the funding obligation into an explicit minter-controlled accounting path.

There are operational boundaries. The user must arm the relevant deposit address and token pair, and a transfer that arrives after the scanning window may wait until the registration is re-armed. Unsupported tokens are not automatically credited. The existing helper-contract route remains available, while the new path is designed for exchange withdrawals that cannot attach ICP-specific calldata.

The upgrade is therefore less about adding another bridge endpoint than about changing where identity enters the deposit flow: from a contract call supplied by the user to a deterministic destination address controlled by the minter. That is a meaningful Chain Fusion UX shift, but its safety still depends on correct token support, address verification, attestation handling, fee-account funding, and the audited sweeper delegate. The NNS dashboard records the upgrade as executed, while the design document describes the intended behavior; this article does not independently measure production throughput or user adoption.