Testing evm_rpc with dfx

Developers CDK
1

I’m having some issue with evm_rpc when testing locally.

2025-10-22 16:46:52.956405 UTC: [Canister uzt4z-lp777-77774-qaabq-cai] ("Cycles to Add", 1_780_784_000)
2025-10-22 16:46:52.956405 UTC: [Canister uzt4z-lp777-77774-qaabq-cai] Calling RPC {block = null; transaction = {accessList = null; blobVersionedHashes = null; blobs = null; chainId = ?31_337; from = null; gas = null; gasPrice = null; input = ?"0x95d89b41"; maxFeePerBlobGas = null; maxFeePerGas = null; maxPriorityFeePerGas = null; nonce = null; to = ?"0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512"; type_ = ?"0x0"; value = ?0}}
2025-10-22 16:46:52.956405 UTC: [Canister 7hfb6-caaaa-aaaar-qadga-cai] TRACE_HTTP src/http.rs:119 JSON-RPC request with id `7` to localhost: JsonRpcRequest { jsonrpc: V2, method: "eth_call", id: Number(7), params: Some(EthCallParams { transaction: TransactionRequest { tx_type: Some(JsonByte(Byte([0]))), nonce: None, to: Some(0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512), from: None, gas: None, value: Some(0), input: Some(Data([149, 216, 155, 65])), gas_price: None, max_priority_fee_per_gas: None, max_fee_per_gas: None, max_fee_per_blob_gas: None, access_list: None, blob_versioned_hashes: None, blobs: None, chain_id: Some(31_337) }, block: Tag(Latest) }) }
2025-10-22 16:46:54.295174 UTC: [Canister 7hfb6-caaaa-aaaar-qadga-cai] TRACE_HTTP src/http.rs:151 IC Error for request with id `7` with code `CANISTER_REJECT` and message `http_request request sent with 1_145_760_000 cycles, but 1_262_760_000 cycles are required.`
2025-10-22 16:46:54.996018 UTC: [Canister uzt4z-lp777-77774-qaabq-cai] RPC Error #HttpOutcallError(#IcError({code = #CanisterReject; message = "http_request request sent with 1_145_760_000 cycles, but 1_262_760_000 cycles are required."}))

I’m adding 1.7B Cycles to the call to the RPC canister(7hfb6). This is a simple eth_call where I call to get the symbol for an token.

The rpc is returning an error “http_request request sent with 1_145_760_000 cycles, but 1_262_760_000 cycles are required.” So 1. it isn’t forwarding along all the cycles I sent, and 2. it isn’t sending enough cycles.

When I call the get_nodes_in_subnet call I get 31. I’m assuming that the evm_rpc may be hard coded for the fiduciary subnet and that may have 28? Or maybe since dfx does 31 by default but the http outcalls canister thinks it has 34?

I’m not sure where the issue might be and I’m not sure if I even have control over it from a dfx standpoint.

dfx 0.29.2

Here is my pulled.json, so I think I’m using the latest versions of the rpc?

"canisters": {
    "um5iw-rqaaa-aaaaq-qaaba-cai": {
      "name": "cycles-ledger",
      "wasm_hash": "ed99402535bb4f58e4ab469acc40c903f2fdeea409be16623d5c6a9131cbf120",
      "wasm_hash_download": "ed99402535bb4f58e4ab469acc40c903f2fdeea409be16623d5c6a9131cbf120",
      "init_guide": "Set max_blocks_per_request in Init record",
      "init_arg": "(variant{Init=record{max_blocks_per_request=1000}})",
      "candid_args": "(LedgerArgs)",
      "gzip": true
    },
    "7hfb6-caaaa-aaaar-qadga-cai": {
      "name": "evm_rpc",
      "wasm_hash": "0d99ec53d3efed4bb8171294c0d184033d7a008afc76b63e49f693d86a84add3",
      "wasm_hash_download": "0d99ec53d3efed4bb8171294c0d184033d7a008afc76b63e49f693d86a84add3",
      "init_guide": "https://internetcomputer.org/docs/current/developer-docs/multi-chain/ethereum/evm-rpc/evm-rpc-canister",
      "init_arg": null,
      "candid_args": "(InstallArgs)",
      "gzip": true
    },
    "tghme-zyaaa-aaaar-qarca-cai": {
      "name": "sol_rpc",
      "wasm_hash": "cbdebc79037029cdc2fcb11eb67ffc25791dcfc226923fba06557b171b406e6c",
      "wasm_hash_download": "cbdebc79037029cdc2fcb11eb67ffc25791dcfc226923fba06557b171b406e6c",
      "init_guide": "https://internetcomputer.org/docs/current/developer-docs/multi-chain/solana/sol-rpc/sol-rpc-canister",
      "init_arg": null,
      "candid_args": "(InstallArgs)",
      "gzip": true
    }
  }
}
2

@skilesare A few points from my side.

It is actually expected that the EVM RPC canister does not forward all of the cycles to attach to make the HTTP outcall(s), this is because it also charges some cycles to offset the cost of the API keys it has for the various RPC providers. This fee is actually based on the number of nodes in the subnet.

Could you please share how you deployed the EVM RPC canister locally? The number of nodes in the subnet is configured in the canister init_arg (with a default value of 34, the number of nodes in the fiduciary subnet). The fact that getNodesInSubnet returns 31 for you suggests that you might have some non-default settings.

Lastly, could you share how you are making the calls with dfx? It is possible that if you are making a request to multiple RPC providers (hint: this is the case if you don’t specify your own providers)? In this case it is possible that you are running out of cycles after already making an HTTP outcall to some providers.

1 Like
3

The init args must be the issue as I have what is below(I don’t remember how this got there). If I change the string will dfx deps deploy recalculate the arg_raw? And how can one force a reinstall for dfx deps deploy(or do an upgrade if that will re init the args)?

"7hfb6-caaaa-aaaar-qadga-cai": {
      "arg_str": "(record { nodesInSubnet = 31 })",
      "arg_raw": "4449444c016c01f3db8bed067901001f000000"
    },
4

The above arg_str should actually be invalid since nodesInSubnet is optional. The correct form would be '(record { nodesInSubnet = opt 34 })'. (I would expect the string value is discarded in favor of arg_raw.)

As for arg_raw, I believe you can compute it yourself with didc (see here):

$ ./dicd encode '(record { nodesInSubnet = opt 34 })'
4449444c026c01f3db8bed06016e7c0100011f

Since the EVM RPC canister also accepts upgrade args, it should be enough to simply redeploy the canister with the right arguments. Otherwise dfx deploy -–mode reinstall should do the trick. I’m not certain how that would work with dfx deps however. My best guess would be to run dfx deps init with the new args followed by dfx deps deploy.