EVM RPC canister overview
EVM RPC is an ICP canister smart contract for communicating with Ethereum and other EVM blockchains using an onchain API. Communication with EVM-compatible chains includes obtaining and sending information such as:
The logs of a specific block or transaction.
Information about a block.
Details about a transaction.
Historical data regarding the network's gas fee.
Transactions for a specific address.
Submitting a signed transaction.
Querying the state of a smart contract.
To use the EVM RPC canister, you can send requests to the instance deployed on the mainnet, or you can fork the source code and deploy your own instance of the canister.
The source code for this project is available on GitHub (internet-computer-protocol/evm-rpc-canister ⭐️) under the Apache 2.0 license.
Goal
The goal of the EVM RPC canister is to act as a gateway between canisters on ICP and EVM-compatible networks through RPC services such as Alchemy, Ankr, or Cloudflare. The EVM RPC canister provides the necessary methods for other ICP canisters to send requests to the Ethereum JSON-RPC API and receive responses.
Terminology
Below is a list of terms used to describe different aspects of using the EVM RPC canister:
RPC service: An IPv6 service such as Alchemy, Gateway.fm, or CloudFlare that offers access to the Ethereum JSON-RPC API over HTTPS. Note that other EVM blockchains are often covered by such a JSON-RPC API as well.
network: An EVM blockchain such as the Ethereum mainnet, Sepolia testnet, or layer-2 chain.
chain id: A well-known unique numeric identifier for an EVM network.
provider: A specific JSON-RPC service registered in the EVM RPC canister. Every chain id for a particular service requires a different provider and typically also requires a different API key. Multiple providers can be registered for a service / chain id combination.
Supported JSON-RPC providers
| Ethereum Mainnet | Arbitrum One | Base Mainnet | Optimism Mainnet | |
|---|---|---|---|---|
| Alchemy | ✅ | ✅ | ✅ | ✅ |
| Ankr | ✅ | ✅ | ✅ | ✅ |
| BlockPi | ✅ | ✅ | ✅ | ✅ |
| Cloudflare | ✅ | |||
| LlamaNodes | ✅ | ✅ | ✅ | ✅ |
| PublicNode | ✅ | ✅ | ✅ | ✅ |
Management of API keys
RPC providers often require API keys be used to authenticate RPC requests. Authenticated requests help mitigate potential DoS attacks that exhaust the request rate limits set by RPC providers. Using an API key can come with challenges for developers, such as:
API keys for RPC providers often require a paid subscription and/or compute credits beyond a certain number of requests per month.
For developers who want to build a quick prototype, it may not be worth procuring multiple API keys until later in development.
When a dapp developer controls an API key, the dapp is considered less decentralized.
Storing API keys securely is not supported at the platform level and requires developers to use their own strategies for protecting their keys, creating an additional complexity for developers who want to use reproducible builds. Personal keys are also visible to all nodes on the ICP subnet. Learn more about authentication.
To provide a solution for developers, the production EVM RPC canister is configured with the required API keys. If a developer wants to use their own providers with their own API keys, however, they can pass their own keys to the EVM RPC canister. Test variations of the EVM RPC canister do not use API keys.
Costs
Calls made to the EVM RPC canister cost cycles. The cost per request is generally similar to making the equivalent HTTPS outcalls in your own canister.
Learn more about the costs of EVM RPC requests.
Deployed canister
The EVM RPC canister runs on the 34-node fiduciary subnet with the following principal: 7hfb6-caaaa-aaaar-qadga-cai.
Refer to the GitHub repository for information on how to verify the hash of the deployed WebAssembly module.