Standard EVM methods

For standard node RPC, Core is a pass-through: requests go to the RPC endpoint of the wallet's active network, and responses come back unchanged. If a method behaves differently than it would against a bare node, that is a bug.

Because these methods are network-reads or raw broadcasts, they need no user approval — with the exceptions noted below.

Commonly used

// Current chain, balance, and a contract read:
const chainId = await provider.request({ method: 'eth_chainId' });
const balance = await provider.request({
  method: 'eth_getBalance',
  params: [account, 'latest'],
});
const result = await provider.request({
  method: 'eth_call',
  params: [{ to: contract, data: calldata }, 'latest'],
});

Group	Methods
Chain state	eth_chainId, eth_blockNumber, eth_gasPrice, eth_feeHistory, eth_syncing
Accounts	eth_accounts, eth_getBalance, eth_getTransactionCount, eth_getCode, eth_getStorageAt, eth_getProof
Blocks	eth_getBlockByHash, eth_getBlockByNumber, plus transaction-count and uncle lookups
Transactions	eth_getTransactionByHash, eth_getTransactionReceipt, eth_estimateGas, eth_call, eth_sendRawTransaction
Logs and filters	eth_getLogs, eth_newFilter, eth_getFilterChanges, eth_getFilterLogs, eth_uninstallFilter

The full list, with parameters and live execution, is in the playground.

One entry in the playground is not part of the Ethereum specification: eth_baseFee is an Avalanche C-Chain addition. On other networks, read the base fee from a block's baseFeePerGas or from eth_feeHistory.

Methods that prompt the user

Two eth_* methods are wallet operations rather than node reads:

• eth_requestAccounts — the connection handshake; prompts the user to approve the dapp.
• eth_sendTransaction — builds, signs, and broadcasts a transaction after the user approves it on Core's transaction screen, which includes risk screening.

Specification

Parameter and return shapes follow the Ethereum JSON-RPC specification. On Avalanche, the same methods are served by the C-Chain API.