Skip to content

RPC overview

Base exposes one EVM-compatible JSON-RPC API across two performance tiers. Switch a single endpoint URL and the pending block tag to move from 2-second sealed blocks to 200ms pre-confirmations — every other method behaves the same.

NetworkChain IDTypeArchive
Mainnet8453ProductionYes
Sepolia84532TestnetYes
TierHTTPWSS
Standardhttps://mainnet.base.orgwss://mainnet.base.org
Flashblockshttps://mainnet-preconf.base.orgwss://mainnet-preconf.base.org

Flashblocks endpoints are fully EVM-equivalent — every standard eth_ method works identically. The difference is what the pending block tag returns.

  • On Standard endpoints, pending reflects the transaction pool (unmined state).
  • On Flashblocks endpoints, pending reflects the pre-confirmed block currently being built, refreshed every ~200ms with new batches of sequencer-ordered transactions.

Methods such as eth_getBalance, eth_getStorageAt, and eth_call execute against real sequencer state up to 1.8 seconds before a block seals, with sub-second latency.

Base nodes implement the standard Ethereum namespaces plus a small set of Base-specific methods.

  • eth — core Ethereum protocol methods for accounts, blocks, transactions, gas, and logs. Available on both Standard and Flashblocks endpoints.
  • net — network identification (net_version).
  • web3 — client identification (web3_clientVersion).
  • debug — replay and tracing utilities for deep transaction inspection. Computationally expensive; availability depends on the node provider.
  • txpool — inspection of the local mempool.
  • base — Base-specific helpers, including pre-confirmation status checks (base_transactionStatus).
  • Flashblocks — pre-confirmation methods (eth_simulateV1) and WebSocket streams (newFlashblockTransactions, pendingLogs, newFlashblocks) available only on Flashblocks endpoints.

Methods marked with a check mark support the "pending" block tag on Flashblocks endpoints.

MethodDescriptionFlashblocks pending
eth_blockNumberCurrent block number
eth_getBalanceAccount ETH balanceyes
eth_getTransactionCountAccount nonce / tx countyes
eth_getCodeDeployed contract bytecodeyes
eth_getStorageAtContract storage slot valueyes
eth_callExecute read-only callyes
eth_getBlockByNumberBlock data by numberyes
eth_getBlockByHashBlock data by hash
eth_getBlockReceiptsAll receipts for a blockyes
eth_getBlockTransactionCountByNumberTx count by block numberyes
eth_getBlockTransactionCountByHashTx count by block hash
eth_getTransactionByHashTransaction data by hash
eth_getTransactionByBlockHashAndIndexTx by block hash and index
eth_getTransactionByBlockNumberAndIndexTx by block number and index
eth_getTransactionReceiptReceipt for a mined tx
eth_sendRawTransactionSubmit signed transaction
eth_gasPriceCurrent gas price
eth_maxPriorityFeePerGasMax priority fee estimate
eth_feeHistoryHistorical base fee and rewards
eth_estimateGasEstimate gas for a txyes
eth_getLogsQuery event logs by filteryes
eth_chainIdNetwork chain ID
eth_syncingNode sync status
net_versionNetwork version ID
web3_clientVersionClient version string
eth_subscribeSubscribe to events (WSS)yes
eth_unsubscribeCancel a subscription (WSS)

Pre-confirmation methods that deliver sub-second transaction signals on Base. These are only available on Flashblocks endpoints and let you read state, simulate bundles, and stream events up to ~1.8 seconds ahead of block sealing.

MethodDescription
eth_simulateV1Simulate transaction bundles against pre-confirmed state
base_transactionStatusCheck whether a transaction has been received by the mempool
newFlashblockTransactionsSubscribe to individual pre-confirmed transactions
pendingLogsSubscribe to filtered logs from pre-confirmed transactions
newFlashblocksSubscribe to the full Flashblock payload stream

Development and debugging utilities for transaction replay and block inspection. Debug methods replay execution and are computationally expensive — availability and rate limits vary by node provider.

MethodDescription
debug_traceTransactionFull EVM execution trace for a transaction
debug_traceBlockByHashEVM traces for every transaction in a block by hash
debug_traceBlockByNumberEVM traces for every transaction in a block by number

All requests are HTTP POST with Content-Type: application/json.

FieldTypeDescription
jsonrpcstringAlways "2.0"
methodstringThe RPC method name
paramsarrayMethod parameters in order
idnumber | stringIdentifier echoed back in the response

Request:

{
"jsonrpc": "2.0",
"method": "eth_getBalance",
"params": ["0x742d35Cc6634C0532925a3b8D4C9dD0b4f3BaEa", "pending"],
"id": 1
}

Success response:

{
"jsonrpc": "2.0",
"id": 1,
"result": "0x1a055690d9db80000"
}

Error response:

{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32602,
"message": "Invalid params"
}
}
CodeNameDescription
-32700Parse errorInvalid JSON
-32600Invalid requestNot a valid JSON-RPC 2.0 object
-32601Method not foundMethod does not exist or is unavailable
-32602Invalid paramsInvalid method parameters
-32603Internal errorInternal JSON-RPC error
-32000Server errorNode-specific error (see message)
ValueStandardFlashblocks
"latest"Most recently sealed blockMost recently sealed block
"pending"Unmined transaction pool stateCurrent Flashblock in progress (~200ms resolution)
"safe"Latest safe blockLatest safe block
"finalized"Latest finalized blockLatest finalized block
"earliest"Genesis blockGenesis block
"0x<n>"Specific block by numberSpecific block by number