A Base Flashblock receipt can show a successful transaction before its block has sealed. Treating that receipt as final can release a withdrawal before your confirmation policy permits it. Your application needs to distinguish an early execution result from a settled transaction.
Before Denim, Flashblocks expose updates about every 200 milliseconds within Base's two-second blocks. This guide explains the pending reads, synchronous receipts, and subscriptions available through Dwellir Base RPC. It also shows where those signals belong in application confirmation logic.
Status checked September 22, 2026. Base targets October for Denim, but activation times remain undecided. Denim replaces Flashblocks, so new integrations should also follow the Base Denim migration guide.
Pending and latest answer different questions
On a Flashblocks-aware endpoint, "pending" returns the current preconfirmed state. "latest" returns the most recent sealed block. Sealing a block does not make it finalized.
| Request or signal | Before Denim | Application use |
|---|---|---|
eth_getBlockByNumber("pending", false) | Current Flashblock snapshot | Show provisional transaction inclusion |
eth_getBlockByNumber("latest", false) | Most recent sealed block | Reconcile provisional data with a completed block |
eth_call or eth_getBalance with "pending" | State including preconfirmed execution | Simulate or display provisional state |
newHeads | Sealed block updates | Follow the canonical head and handle reorgs |
"safe" and "finalized" | Stronger stages in the rollup lifecycle | Enforce the application's confirmation requirements |
Query the pending snapshot with your API key:
curl -sS -X POST "https://api-base-mainnet-archive.n.dwellir.com/$API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber","params":["pending",false]}'
Repeat the request with "latest" to compare the sealed block. The Flashblocks visualizer guide provides a working interface for that comparison.
Keep pending data separate from canonical data in caches and databases. A pending snapshot can change without its block number changing. Including the tag in a cache key avoids mixing states, but pending entries also need short expiry or explicit invalidation.
Do not use a missing or placeholder pending block hash as a durable identifier. Store transaction hashes, then reconcile block hashes and receipt status after inclusion in a sealed block. Continue handling chain reorganizations until the required confirmation stage.
A synchronous receipt still needs confirmation
eth_sendRawTransaction returns a transaction hash. On a Flashblocks-aware Base endpoint, eth_sendRawTransactionSync waits for inclusion and returns a receipt. See the method reference for the response fields.
curl -sS -X POST "https://api-base-mainnet-archive.n.dwellir.com/$API_KEY" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_sendRawTransactionSync",
"params": ["0xSIGNED_RAW_TX"]
}'
Replace 0xSIGNED_RAW_TX with a signed transaction for Base. This request broadcasts a transaction. Its receipt can contain execution status and logs before the full block seals.
The 200ms Flashblock cadence is not a response-time guarantee. Fees, inclusion conditions, and network delays affect how long a transaction takes. A timeout can also occur after broadcast, so preserve the signed bytes and transaction hash for reconciliation.
Use the sync receipt to update a provisional transaction display. Check status before reporting successful execution. Then follow canonical receipts and the required confirmation stage before making funds spendable.
Do not create another payment because the synchronous response timed out. Check the original hash and reconcile its nonce before deciding whether to rebroadcast or replace it.
Subscribe to provisional and sealed updates
Dwellir's Base documentation describes these Flashblocks subscriptions:
| Subscription | Data |
|---|---|
newFlashblocks | Pending block snapshots |
newFlashblockTransactions | Preconfirmed transactions |
pendingLogs | Logs from pending execution, with an optional filter |
For example, send this JSON-RPC message over a Base WebSocket connection:
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_subscribe",
"params": ["newFlashblocks"]
}
Keep sealed-block tracking alongside provisional events. After a disconnect, recover canonical blocks and logs over HTTP. Mark pending displays stale until the client has reconciled them.
Choose confirmation rules for each action
Use explicit transaction states such as submitted, preconfirmed, included, safe, and finalized. Execution success is a separate field. A reverted transaction can be included and later finalized.
| Action | Use a Flashblock signal? | Required follow-up |
|---|---|---|
| Show a provisional transaction result | Yes | Label it preconfirmed and handle changes |
| Refresh a pending balance | Yes | Reconcile with canonical state |
| Grant spendable credit | Only as provisional evidence | Enforce the documented confirmation policy |
| Release a withdrawal | Not as sole authorization | Enforce confirmation and bridge-specific conditions |
| Allocate the next transaction nonce | As one input | Preserve local reservations and reconcile submitted hashes |
| Create a durable accounting record | Store the observation | Resolve canonical block identity and handle reversals |
Do not use "latest" as a universal settlement threshold either. It describes the current head, which can still be unsafe. The required confirmation level depends on what the application permits after observing the transaction.
Define which records can change during a reorganization. A provisional balance can update in place. An external payout requires a confirmation policy that accounts for the cost of reversal.
For the terminology, see blockchain finality. The Ethereum safe-block guide explains L1 confirmation stages; apply Base's rollup semantics when implementing them here.
Plan the Denim replacement now
Base's migration reference replaces newFlashblocks with newHeads and pendingLogs with logs. Transaction consumers will follow canonical heads and fetch each block's transactions. Pending-state integrations also need canonical-state replacements.
Denim's planned 200ms canonical blocks retain an unsafe, safe, and finalized lifecycle. Faster block production does not remove the confirmation policy described above.
Use the Base Denim migration guide to inventory dependencies and test their replacements. For current endpoint and method details, use Base Mainnet RPC and the Base documentation. Contact Dwellir with your subscriptions and confirmation requirements when planning the rollout.
