Ethereum Integration
Canisters on ICP can interact with Ethereum and any EVM-compatible chain (Polygon, Avalanche, Arbitrum, Base, Optimism, and others) without bridges or trusted intermediaries. The integration combines two ICP capabilities: HTTPS outcalls to read chain state and chain-key ECDSA signatures to authorize transactions.
How it works
Section titled “How it works”Reading Ethereum state. Canisters query Ethereum via JSON-RPC, the same API used by standard Ethereum clients. Because HTTPS outcalls involve all subnet replicas independently fetching the URL and reaching consensus on the response, the result has strong integrity guarantees. Rather than making raw HTTPS outcalls directly, most canisters use the EVM RPC canister, which provides a typed Candid interface and handles multi-provider redundancy automatically.
Signing Ethereum transactions. Each canister can derive an Ethereum address from its chain-key ECDSA public key. To authorize a transaction, the canister calls sign_with_ecdsa on the management canister, receives a threshold signature produced by the subnet nodes collectively, and includes the signature in the serialized transaction before submitting it.
Submitting Ethereum transactions. The signed transaction is submitted via the EVM RPC canister’s eth_sendRawTransaction endpoint, which relays it to multiple JSON-RPC providers for broadcast.
This flow (query, sign, submit) lets canisters call any Ethereum smart contract, hold ETH or ERC-20 assets, and participate in DeFi protocols entirely from onchain ICP code.
EVM RPC canister
Section titled “EVM RPC canister”The EVM RPC canister (7hfb6-caaaa-aaaar-qadga-cai) is a system-level canister that acts as a gateway between ICP canisters and Ethereum JSON-RPC APIs. It is controlled by the NNS, so its behavior cannot be changed by any single party. For supported chains, built-in providers, and cycle costs, see EVM RPC canister.
Multi-provider architecture
Section titled “Multi-provider architecture”For each Candid-RPC method (such as eth_getTransactionReceipt or eth_getBlockByNumber), the EVM RPC canister sends the request to at least three independent JSON-RPC providers by default and compares the results. Supported providers include CloudFlare, Alchemy, Ankr, and BlockPI.
Results are returned in one of two forms:
- Consistent: all queried providers returned the same result. This is the expected case for finalized data.
- Inconsistent: providers returned different results. The caller receives the full set of results and can decide how to handle the discrepancy (for example, by waiting for more confirmations or querying additional providers).
Callers can override the defaults: specifying a different number of providers, listing concrete providers to use, or setting a minimum agreement threshold.
Available methods
Section titled “Available methods”The EVM RPC canister supports the standard JSON-RPC Ethereum API, including:
eth_getBlockByNumber,eth_getBlockByHash: block dataeth_getTransactionCount,eth_getTransactionByHash,eth_getTransactionReceipt: transaction dataeth_getLogs: event logs (used to detect deposits for chain-key tokens)eth_feeHistory,eth_gasPrice: fee estimationeth_sendRawTransaction: broadcast a signed transactioneth_call: call a smart contract read function
Beyond Ethereum mainnet, the canister also has partial support for Polygon, Avalanche, and other popular EVM networks.
Chain-key Ether and ERC-20 tokens
Section titled “Chain-key Ether and ERC-20 tokens”ckETH and ckERC20 tokens (such as ckUSDC and ckUSDT) are chain-key tokens backed 1:1 by assets on Ethereum. They follow the same architecture as ckBTC (a minter canister plus an ICRC-1/ICRC-2 ledger canister) but use a different deposit mechanism.
Deposits. Because ICP cannot observe Ethereum state directly (unlike Bitcoin, which uses a native adapter), ckETH uses a helper smart contract deployed on Ethereum. Users send ETH or ERC-20 assets to this helper contract, which emits an event. The ckETH minter periodically queries the event log via the EVM RPC canister to discover deposits and mints the corresponding chain-key tokens.
For full minting, redemption, and security model details, see Chain-key tokens.
Next steps
Section titled “Next steps”- Ethereum guide: code examples for reading state and sending transactions
- Chain Fusion overview: integration patterns and supported chains
- HTTPS outcalls: how canisters reach external HTTP endpoints
- Chain-key cryptography: threshold ECDSA signing
- Chain-key tokens: ckETH and ckERC20 architecture
- Chain-Key Token Canister IDs: ckETH minter, ledger, and index IDs