Base Flashblocks Across RPC Providers: Pending vs Confirmed

You submit a swap on Base, poll eth_getTransactionReceipt, and wait. Two seconds later the sealed block arrives. The sequencer already ordered that transaction about 200ms after you sent it. If your RPC still answers pending from a mempool, or ignores pending entirely, you just paid for a 2-second UX on a 200ms pipeline.

Flashblocks are Base's sub-block preconfirmations. A ~2-second sealed block is streamed as roughly ten deltas. On a Flashblocks-aware node, the JSON-RPC "pending" tag is that in-progress sequencer state, not Geth's txpool. This directory lists ten paid providers for Base in data/providers.json. Only some of them document that difference. The rest still appear on the Base hub. Know which is which before you wire blockTag: "pending" into a trading UI.

What pending means on Base

On Ethereum L1, "pending" usually means "include the node's transaction pool." Geth will even reject eth_getLogs when fromBlock/toBlock is pending. Indexers that copied that mental model onto Base will misread Flashblocks.

On Flashblocks-aware Base RPC, "pending" means "the current preconfirmed block in progress," refreshed about every 200ms. "latest" is the last sealed block (~2s). "safe" and "finalized" are still the tags you persist for a cursor.

The same method, three different worlds:

eth_getBlockByNumber("latest", true): sealed block. Hash is stable. Fine for accounting.

eth_getBlockByNumber("pending", true) on Flashblocks: in-progress block. The transaction list and blockHash change as later Flashblocks land. Do not persist that hash as canonical.

eth_getBlockByNumber("pending", true) on a node that never enabled Flashblocks: mempool view, empty, or an error. Measure it.

Base's public HTTP endpoints (mainnet.base.org, sepolia.base.org) are Flashblocks-enabled for "pending". They do not serve WebSocket RPC. eth_subscribe is a paid-provider problem. Do not point an app at wss://mainnet.flashblocks.base.org/ws. That is the operator infrastructure stream, not an application API.

A 10,000-block eth_getLogs backfill is a different question. See the public vs paid guide for when a public URL stops being enough. Flashblocks is about the head of the chain, not history.

HTTP methods that actually change

Flashblocks does not invent a parallel JSON-RPC. It rebinds "pending" and adds a few Base-specific calls. Confirmed reads ("latest", "safe", a hex block number) keep their old meaning.

eth_blockNumber still returns the sealed height. Do not use it as a Flashblocks cursor. Poll "pending" or subscribe.

eth_sendRawTransactionSync is EIP-7966. It is not in this repo's cuPerRequest tables. Treat it as a write plus a wait, and confirm the provider documents it before you block a request thread on it. base_transactionStatus is Base-specific. Same rule: if the provider page does not mention it, probe it, do not assume.

Preconfirmed receipts can still disappear if the sequencer reorders before seal. For a UI checkmark, Flashblocks is the right signal. For a database write you will not unwind, wait for "latest" or "safe".

WebSocket subscriptions

On a Flashblocks WSS endpoint, eth_subscribe with newHeads fires about every 200ms instead of every 2 seconds. Three extra subscription types exist only on Flashblocks-aware sockets:

Public Base HTTP does not do this. The Base hub public URL is for the pending-vs-latest probe below. For a socket, pick a paid provider that documents the three Flashblocks subscriptions, then compare credits on that hub's calculator.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_subscribe",
  "params": ["pendingLogs", {
    "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
  }]
}

That filter is USDC Transfer on Base. On a Flashblocks socket it emits as preconfirmed transfers land, not at seal. Unsubscribe with eth_unsubscribe and the subscription id. Leaving it open is how people discover their WebSocket connection limit.

Providers this directory lists for Base

data/providers.json is the source of truth for who this site will put on the Base hub. Infura's supported_chains array in that file does not include base. It is omitted here on purpose.

Flashblocks support is not a column in that file. The method weights below are the ordinary eth_* costs from the same JSON. Flashblocks reads are billed as those methods. The "Flashblocks docs" column is whether the provider currently publishes a Base Flashblocks page. Docs are not a live probe. Re-check before you hard-code a subscription name.

"Not found" means this guide could not cite a provider Flashblocks page. It does not mean the node is incapable. Public Base HTTP is Flashblocks-aware, so a provider that proxies that stack may already rebind "pending". Until they document newFlashblocks, do not build a product on the subscription name.

Dwellir is the only provider in that file with pricing_model.type: "flat" and Base in supported_chains. Every listed method is 1 credit, including a preconfirmed receipt. That is a cost-model fact from the repo, not a ranking.

What polling costs vs a subscription

A sealed Base block is ~2 seconds. A Flashblock is ~200ms. If you poll eth_getTransactionReceipt at Flashblock cadence while you wait for a seal, that is up to 10 calls per transaction.

Those per-call numbers are eth_getTransactionReceipt from data/providers.json. Ankr's 200-credit weight is the outlier in this set. A DEX that polls 100 in-flight swaps at 200ms will burn Ankr credits 40 times faster than Alchemy CU for the same receipt method, and 200 times faster than Dwellir credits.

The subscription is the cheaper shape. One pendingLogs or newFlashblockTransactions socket delivers the same 200ms signal without 5 Hz HTTP. This repo does not list a CU weight for eth_subscribe. Ask the provider how WS messages bill, or assume Dwellir's 1 credit per response if you are on flat-rate.

eth_call against "pending" is heavier than a receipt on compute-unit plans (Alchemy 26 CU, Infura is irrelevant here because Infura is not a Base row). Dwellir still bills 1. If your UI does a pending balanceOf plus a pending receipt plus a pending nonce per user action, multiply the table. Flat-rate stops that from becoming a spreadsheet.

Smoke test on the Base hub

Do this against a URL you actually intend to ship, not against folklore.

Open Base mainnet. Copy a public HTTP URL. Send eth_getBlockByNumber twice, "latest" and "pending", true for full txs.

Compare number, hash, and transactions.length. On Flashblocks, pending is the same height or the in-progress height, with more txs and a hash that changes if you repeat the call within 2 seconds. If pending equals latest every time, you are not on a Flashblocks view.

Send a tiny eth_getBalance with "pending" and with "latest" for an address that just moved. If they match for minutes after a known tx, "pending" is not preconf.

Try eth_subscribe / newFlashblocks on that public URL. Expect failure. Public Base HTTP has no WSS. That is why the hub also lists paid providers.

Repeat steps 1-3 on a key from a provider whose docs say Flashblocks (Dwellir, Alchemy, QuickNode, Chainstack, GetBlock). Repeat on one whose docs do not (Ankr, DRPC, Tatum, BlockPI, NodeReal). Record the difference. Do not skip the probe because the marketing site says "Base RPC."

Open the hub calculator. Indexer and DeFi profiles are still eth_getLogs-heavy. For a Flashblocks UI, the mix is receipts, eth_call, and eth_getTransactionCount. Plug those weights. Dwellir's 1-credit row is the floor in this file. Ankr's 200 is the ceiling for the same receipt.

curl -s https://mainnet.base.org -H 'content-type: application/json' -d '{
  "jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["pending", false]
}'

If you need a receipt without polling, Dwellir and Chainstack document eth_sendRawTransactionSync. Alchemy and QuickNode's Flashblocks pages do not. That is a method gap, not a latency benchmark.

How to choose without a listicle

Pick the method first.

HTTP "pending" reads only: any Flashblocks-aware endpoint, including public Base for a 1-call probe. Then look at RPS and the receipt weight in the table above.

Streaming at 200ms: you need WSS and a documented newFlashblocks / pendingLogs implementation. Public URLs on this hub do not qualify.

Synchronous send: you need eth_sendRawTransactionSync in the provider's Base docs. Today that is Dwellir and Chainstack in the set above.

Mempool "did the sequencer see my tx?": base_transactionStatus, documented by Dwellir and GetBlock. Everyone else is a probe.

Then look at providers and the Base hub calculator. Flashblocks does not get its own SKU in data/providers.json. You are buying ordinary eth_* calls that happen to return preconfirmed state, plus a socket. Dwellir's flat 1-credit model is the simple option when that mix is receipt-heavy. Alchemy and QuickNode are the ones with the longest public Flashblocks method lists if you already live in those dashboards. Ankr, DRPC, Tatum, BlockPI, and NodeReal remain valid Base endpoints in this directory. They are not, as of 26 Aug 2026, citable Flashblocks documentation.

Confirmed state is still "latest" / "safe". Use Flashblocks for the wait. Use sealed blocks for the write.