Base RPC Overview

How to choose between Standard RPC, Flashblocks RPC, and API method families on Base.

Base exposes an EVM-compatible JSON-RPC API through two RPC tiers:

• Standard RPC for normal Ethereum-compatible reads, writes, logs, and debugging against sealed blocks and standard pending state.
• Flashblocks RPC for apps that need preconfirmed state and transaction signals before the next L2 block seals.

Most apps should start with Standard RPC. Use Flashblocks RPC when faster state reads, transaction feedback, or realtime subscriptions materially improve the user experience.

Choose an RPC Tier

If your app needs to…	Use…	Notes
Read confirmed chain state	Standard RPC with "latest"	Default choice for balances, contract reads, blocks, receipts, and logs.
Submit transactions	Standard or Flashblocks RPC	eth_sendRawTransaction broadcasts the signed transaction; confirmation behavior depends on how you read it back.
Read preconfirmed state	Flashblocks RPC with "pending"	Useful for balances, storage, eth_call, gas estimation, pending logs, and block reads before the L2 block seals.
Track a transaction before it seals	Flashblocks RPC by hash, base_transactionStatus, or subscriptions	Preconfirmed transaction and receipt responses are strong signals, not finality guarantees.
Operate RPC or node infrastructure	Flashblocks RPC plus the raw Flashblocks stream when needed	The raw stream is infrastructure-oriented. Apps should usually use RPC methods and subscriptions.

For many app reads, the practical change is switching to a Flashblocks endpoint and using the "pending" block tag.

What is the Flashblocks Tier?

Flashblocks are sub-block preconfirmations produced while Base is building the next L2 block. Standard L2 blocks seal about every 2 seconds. Flashblocks expose the block-in-progress at about 200ms resolution, so apps can read sequencer-ordered state before the full L2 block is sealed.

On Standard RPC, "pending" follows normal Ethereum JSON-RPC behavior and reflects pending transaction pool state.

On Flashblocks RPC, "pending" reflects the current preconfirmed block-in-progress. Methods such as eth_getBalance, eth_getStorageAt, eth_call, and eth_estimateGas can use that preconfirmed state.

Preconfirmed responses are reorg-able until the full L2 block seals. For finality stages and the Flashblock reorg SLO, see Transaction Finality.

Common Tasks

Read state

Use eth_call, eth_getBalance, eth_getStorageAt, eth_getCode, and eth_getTransactionCount. Add "pending" on Flashblocks RPC to read preconfirmed state.

Send transactions

Broadcast signed transactions with eth_sendRawTransaction, then choose Standard or Flashblocks reads depending on the confirmation signal your app needs.

Track confirmations

Use transaction and receipt lookups for sealed data. On Flashblocks RPC, by-hash lookups can also return preconfirmed cache data before the L2 block seals.

Stream realtime data

Use WebSocket subscriptions such as eth_subscribe, newFlashblockTransactions, pendingLogs, and newFlashblocks when polling is too slow.

Simulate preconfirmed bundles

Use eth_simulateV1 to simulate bundles against preconfirmed state on Flashblocks endpoints.

Debug execution

Use debug methods for local development, transaction traces, and block replay. Availability and rate limits vary by provider.

Endpoint URLs

Most readers can use their provider’s Base endpoint directly. Expand this section when you need the public Base RPC URLs, chain IDs, explorers, or Flashblocks endpoint URLs.

View endpoint details

Network	Chain ID	Standard RPC	Standard WSS	Flashblocks RPC	Flashblocks WSS	Explorer
Base Mainnet	8453	https://mainnet.base.org	wss://mainnet.base.org	https://mainnet-preconf.base.org	wss://mainnet-preconf.base.org	BaseScan
Base Sepolia	84532	https://sepolia.base.org	wss://sepolia.base.org	https://sepolia-preconf.base.org	wss://sepolia-preconf.base.org	BaseScan Sepolia

Public RPC and Flashblocks RPC endpoints are rate-limited and are not suitable for production traffic. For production systems, use a node provider or run your own Base node. For more explorer options, see the block explorer catalog.

API Surfaces

Ethereum JSON-RPC API

Core Ethereum protocol methods for account queries, contract calls, block and transaction data, gas estimation, log filtering, transaction submission, and WebSocket subscriptions. These methods work on both Standard and Flashblocks endpoints.

State and contract reads

eth_call, eth_getBalance, eth_getStorageAt, eth_getCode, eth_getTransactionCount

Blocks and transactions

eth_getBlockByNumber, eth_getBlockByHash, transaction count methods, transaction lookups, receipts

Fees and gas

eth_estimateGas, eth_gasPrice, eth_maxPriorityFeePerGas, eth_feeHistory

Logs and subscriptions

eth_getLogs, eth_subscribe, eth_unsubscribe

Flashblocks API

Flashblocks methods provide preconfirmation-specific capabilities on Flashblocks endpoints. Use them when your app needs sub-second transaction status, filtered pending logs, preconfirmed transaction streams, or bundle simulation.

Transaction status

Check whether a transaction has reached the mempool before it is sealed into an L2 block.

Pending logs

Subscribe to filtered logs from preconfirmed transactions.

New Flashblock transactions

Subscribe to individual preconfirmed transactions.

Flashblock stream

Subscribe to Flashblock payloads. Most apps should prefer higher-level RPC methods unless they need the raw payload shape.

Debug API

Debug methods replay transactions and blocks for development and incident analysis. They are computationally expensive, so availability and rate limits vary by node provider.

Trace a transaction

Inspect full EVM execution for a transaction.

Trace a block

Replay all transactions in a block by number or hash.

Flashblocks Behavior Matrix

The table below is the canonical behavior summary for pages that need exact Flashblocks semantics. Most app developers only need the decision table above; use this section when you are choosing method-level behavior or documenting provider expectations.

State and block reads

Use the Flashblocks endpoint with the "pending" block tag when you want preconfirmed state.

Surface	Standard RPC	Flashblocks RPC
State reads: eth_call, eth_getBalance, eth_getStorageAt, eth_getCode, eth_getTransactionCount	Ethereum JSON-RPC behavior against sealed blocks or standard pending state.	With "pending", reflects the current Flashblock state.
Block reads: eth_getBlockByNumber, eth_getBlockReceipts, block transaction counts by number	Ethereum JSON-RPC behavior against sealed blocks.	With "pending", reflects the current Flashblock state.

eth_getBlockByHash and block transaction counts by hash do not use a "pending" tag because they identify an explicit block hash.

Transaction and receipt lookups

Transaction and receipt lookups by hash do not accept a "pending" parameter. Flashblocks behavior is selected by using a Flashblocks RPC endpoint.

Method	Standard RPC	Flashblocks RPC
eth_getTransactionByHash	Returns sealed transaction data, or null if not found.	Can return preconfirmed transaction data from the Flashblocks cache before the L2 block seals.
eth_getTransactionReceipt	Returns sealed receipt data, or null if not found.	Can return preconfirmed receipt data from the Flashblocks cache before the L2 block seals.

Preconfirmed by-hash responses can be reorged before the full L2 block seals.

Subscriptions and Flashblocks-only methods

Flashblocks-only methods and subscriptions are available only on Flashblocks endpoints.

Surface	Behavior
eth_simulateV1	Simulates bundles against preconfirmed state.
base_transactionStatus	Checks whether a transaction has reached the mempool.
newFlashblockTransactions	Streams individual preconfirmed transactions.
pendingLogs	Streams filtered logs from preconfirmed transactions.
newFlashblocks	Streams Flashblock payloads over WebSocket.

Raw Flashblocks stream

The raw Flashblocks WebSocket stream is intended for infrastructure and node operators, not normal application polling. Applications should usually use RPC methods, by-hash lookups, or Flashblocks subscriptions instead.

Azul removes account balances and receipts from the raw WebSocket payload. Apps that need preconfirmed transaction or receipt data should use Flashblocks RPC behavior rather than depending on raw stream payload fields.

Request and Response Format

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

Every request includes the JSON-RPC version, method name, ordered parameters, and an ID that is echoed back in the response.

Field	Type	Description
jsonrpc	string	Always "2.0"
method	string	The RPC method name
params	array	Method parameters in order
id	number | string	Identifier echoed back in the response

Successful responses include jsonrpc, id, and result. Error responses include jsonrpc, id, and an error object with a numeric code and human-readable message.

Error Codes

Code	Name	Description
-32700	Parse error	Invalid JSON
-32600	Invalid request	Not a valid JSON-RPC 2.0 object
-32601	Method not found	Method does not exist or is unavailable
-32602	Invalid params	Invalid method parameters
-32603	Internal error	Internal JSON-RPC error
-32000	Server error	Node-specific error. See the returned message for details.

Block Parameters

Value	Standard RPC	Flashblocks RPC
"latest"	Most recently sealed block	Most recently sealed block
"pending"	Unmined transaction pool state	Current Flashblock in progress, at about 200ms resolution
"safe"	Latest safe block	Latest safe block
"finalized"	Latest finalized block	Latest finalized block
"earliest"	Genesis block	Genesis block
"0x<n>"	Specific block by number	Specific block by number