eth_getCode: Read the Bytecode at an Address

What eth_getCode does

What you get back is runtime bytecode: the code the EVM executes when the address is called. It is not the creation bytecode you sent in the deployment transaction, and it is certainly not Solidity source. Verified source lives with explorers, not on chain; from the node's point of view a contract is this byte string plus its storage.

The most valuable thing the method tells you is presence. Calling a function on an address with no code does not fail, it succeeds and returns nothing, so a typo in an address or a contract that was never deployed on this network presents as an empty result rather than an error. Checking eth_getCode first turns that silent failure into a clear one.

Two modern wrinkles change the reading of the result. Most production contracts are proxies, so the bytecode you see is a short delegating stub and the logic lives at an implementation address held in a storage slot. And EIP-7702, live since Pectra, lets an externally owned account point at contract code: such an account returns exactly 23 bytes, 0xef0100 followed by the 20-byte address it delegates to. Code at an address no longer implies the address is a contract.

Parameters

What it returns

A hex string holding the runtime bytecode, or 0x when the address has none. A contract's code is immutable once deployed, so for a given address and block the answer never changes; what changes across blocks is whether code is there at all.

0x covers several situations: an externally owned account, an address where nothing has been deployed yet (including a CREATE2 address computed in advance), and a contract that self-destructed back when that was possible. Since EIP-6780, selfdestruct only clears code when it runs in the same transaction that created the contract, so newer contracts effectively keep their code forever.

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x60806040526004361061006d576000357c010000...633659cfe6...5c60da1b...0029"
}

Heavily truncated: the real answer is 2,186 bytes of hex on one line. This is USDC's proxy, and the selectors in the dispatch table give it away (3659cfe6 is upgradeTo, 5c60da1b is implementation). The token's logic lives at 0x43506849D7C04F9138D1A2050bbF3A0c054402dd, which you find by reading the proxy's implementation storage slot with eth_getStorageAt.

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider("https://ethereum-rpc.publicnode.com");

async function classify(address) {
  const code = await provider.getCode(address);
  if (code === "0x") return "EOA or nothing deployed";
  // EIP-7702: 0xef0100 || 20-byte target, 23 bytes total
  if (code.startsWith("0xef0100") && code.length === 2 + 46)
    return `EOA delegated to 0x${code.slice(8)}`;
  return `contract, ${(code.length - 2) / 2} bytes`;
}

console.log(await classify("0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"));
console.log(await classify("0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045"));

Gotchas and common errors

What eth_getCode costs on BLAZED.sh

eth_getCode costs 1 credit per call on BLAZED.sh. Most results are a few kilobytes and irrelevant to billing, though the largest contracts approach the 24KB EIP-170 deployment limit and a batch of such reads still stays comfortably under the 100KB threshold where responses add 50 credits per MB. The realistic use is as a guard before other calls: one cheap read that stops you from debugging an ABI when the actual problem is an address with nothing behind it.

eth_getCode: frequently asked questions