NexFlow › Library › Blast RPC endpoint guide

Blast RPC endpoint: what a yield-bearing L2 does to your reads

Blast is an optimistic Ethereum L2 whose headline feature — balances that grow on their own — is also its biggest trap for anyone reading it over RPC. A balance can change with no transaction and no event. This guide gives you a working endpoint, the responses we got, and the Blast-specific rules for indexing and finality.

7 min read · updated 2026-09-27 · infra guide, not financial advice

Use https://nexflowscan.com/api/rpc/blast. It accepts Ethereum JSON-RPC over HTTPS POST, needs no key for baseline reads, and fans each request out over a small pool of keyless upstreams, including the rpc.blast.io endpoint that Blast's Network Information page lists as the official mainnet RPC. That same page gives the other constants you need for a wallet: chain ID 81457, currency symbol ETH, block explorer blastscan.io.

Most of what you know about Ethereum RPC carries over directly. eth_call, logs, receipts and gas estimation work the way your tooling expects. The two places Blast departs from the script are how account balances behave and how the four stages of transaction status map onto block tags.

A first request, and what came back

Start every integration by asking the endpoint who it is and where the chain tip sits. Those two answers catch wrong-network mistakes and dead nodes before either can corrupt your data.

curl -s -X POST https://nexflowscan.com/api/rpc/blast \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
# {"jsonrpc":"2.0","result":"0x13e31","id":1}

curl -s -X POST https://nexflowscan.com/api/rpc/blast \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
# {"jsonrpc":"2.0","result":"0x26f8b87","id":1}

0x13e31 is 81457, matching Blast's documentation. 0x26f8b87 is block 40,864,647. Over both the last 1,000 and the last 10,000 blocks our reads found timestamps exactly two seconds apart, so on Blast a block count converts cleanly to time: 30 blocks is a minute, 1,800 is an hour.

Rebasing balances: the indexing problem

The About Blast page explains the model. ETH held by externally owned accounts on Blast rebases automatically, with yield sourced from ETH staking; smart contracts can opt in. USDB, Blast's native stablecoin, rebases too, and for USDB contracts are included by default and can opt out. The yield is passed to holders without anyone sending a transaction.

For RPC consumers the consequence is precise and easy to miss. The Indexing Account Balances guide describes each account as holding a number of shares, multiplied by a global share price to give its ETH balance; when new yield is reported, the share price rises and every rebasing balance moves. The guide notes that no Transfer event is emitted when yield is claimed, and that share-price updates generally happen daily at midnight UTC, though that schedule is not guaranteed in code. Its recommendation is to store each account's shares along with the global share price, or to index the NewPrice(uint256 price) event on the contract that publishes it.

Put simply, if you reconstruct balances by summing transfers from logs, your numbers will drift away from what eth_getBalance returns — slowly, and in the account holder's favor. Three practical fixes, in order of effort:

Read balances directly. For a wallet or a portfolio view, call eth_getBalance or the token's balanceOf at the block you care about and do not try to derive it. This is the simplest correct approach.

Snapshot at known blocks. For accounting exports, record balances at fixed block heights — daily, or around each share-price update — rather than rolling them forward from events.

Index shares and price. For a full indexer, follow the Blast guide: track shares per account and the global share price, and compute balances from both. The documentation also describes three yield modes, so an account's mode determines whether it rebases at all.

Four stages of Blast finality, mapped to block tags

Blast's Transaction Finality page defines four statuses and how to query each. Pending is instant after the transaction reaches the sequencer, visible through eth_getBlockByNumber with the pending tag. Sequencer confirmed, also called unsafe, typically arrives within 2–4 seconds, once the sequencer includes it in a block. Safe means the block has been published to Ethereum, typically within 5–10 minutes but up to 24 hours. Finalized means the Ethereum block carrying that data is itself final, typically within 15–20 minutes but also up to 24 hours.

We read all three non-pending tags in one pass on 2026-09-27:

The safe gap sat inside the documented range; the finalized gap was longer than the typical 15–20 minutes but well within the documented upper bound. That is the reason to design around the bound, not the typical case. An exchange crediting Blast deposits, or a bridge relayer, should wait for finalized and handle the occasional long wait gracefully rather than treating it as an outage.

Fees: L2 execution plus L1 data

As an optimistic rollup, Blast charges for execution on the L2 and for the data it posts to Ethereum. The L2 side is plain EIP-1559: the latest block's base fee in our session was 299 wei, and eth_maxPriorityFeePerGas suggested 1,000,000 wei. The L1 side is where most of the cost usually sits, and it is readable through RPC.

Blast exposes the OP Stack gas price oracle predeploy at 0x420000000000000000000000000000000000000F. Through our relay, eth_call to its version() returned "1.2.0", l1BaseFee() returned 981,677,247 wei, and blobBaseFee() returned 50,002,228 wei. A wallet that shows only the L2 gas figure will understate what the user pays; read the oracle, or rely on a library that does.

One quirk from testing: the standard eth_blobBaseFee method is on our allowlist, but the upstream that picked it up answered with its own "not available on free plan" message, which the relay passed through. The oracle call above is the dependable way to get the same number on Blast.

What the relay forwards and what it refuses

Forwarded: the Ethereum read namespace — balances, eth_call, eth_getLogs, blocks by number and hash including the safe and finalized tags, receipts, eth_estimateGas, eth_feeHistory, filters, and identity calls. Refused: signing and node-internals. eth_sign and txpool_content returned -32601, "Method not allowed on this relay", and the Blast lane page states that sends and signs are refused on the public lane. Claiming yield or gas refunds on Blast means sending transactions from the account that owns them; do that from your own wallet or backend, through a provider you control.

Which lane to use on Blast

Our relay, as of 2026-09-27, offers three lanes for Blast. The method list and upstream pool are identical; throughput and payment differ.

A Blast balance indexer that snapshots thousands of accounts after each share-price update is a burst workload, and batching is the efficient way to do it — but every item in a batch counts against the per-minute budget. A keyed lane handles that comfortably; see the integration page for checkout and headers. An agent that checks a handful of Blast balances on demand can use the x402 lane and pay per call. When the free lane is exhausted, the relay replies HTTP 402 so your client knows to switch.

Frequently asked