Unichain Unichain Flashblocks: read a pending block
Flashblocks stream partial block updates on Unichain, an Ethereum layer 2 network. Read them through a compatible RPC using the
pending
block tag to inspect preconfirmed transactions.
- Preconfirmation timing
- About 200 milliseconds for early transaction feedback.
- Full block interval
- 1 second on Unichain.
- Network support
- Unichain Mainnet and Unichain Sepolia; Sepolia supports contract and integration testing with test funds.
- RPC dependency
- A Flashblocks-aware endpoint. Public RPC endpoints are rate limited and unsuitable for production workloads.
What the pending view contains
For block reads,
pending
exposes the latest partial block and its preconfirmed transactions through a compatible endpoint. This view gives applications execution feedback while the full block is still taking shape.
The Flashblocks extension leaves Unichain's core consensus unchanged. Keep early preconfirmation feedback separate from full-block confirmation and Ethereum finality when presenting transaction status.
Inspect a block without sending a transaction
If an app only updates when full blocks arrive, check its RPC reads before changing transaction logic. That observation alone does not establish whether its provider lacks Flashblocks support.
This read-only inspection uses Unichain Sepolia and requires a Flashblocks-aware endpoint for that network. Reading block data needs no wallet signature or transaction funding, so the check can stop after inspection.
| Inspection stage | Expected data and limits |
|---|---|
| 1. Confirm the environment | Use an endpoint targeting Unichain Sepolia, chain ID 1301; mainnet uses chain ID 130 and carries real value. |
| 2. Check endpoint support | Confirm the provider supports Flashblocks on the selected network, since an ordinary Ethereum RPC interface alone does not establish compatibility. |
| 3. Prepare the block request |
Use
pending
as the block selector for
eth_getBlockByNumber
, with the second parameter set to
true
for full transaction objects.
|
| 4. Send the read | Submit the JSON-RPC payload to the selected endpoint; an RPC error or rate-limit response leaves the block inspection incomplete. |
| 5. Inspect the result | A successful response exposes the partial block's preconfirmed transactions, establishing a pending-block read without proving final settlement for an individual transaction. |
| 6. Stop or change the endpoint | Stop after inspecting the result without submitting a transaction. If the endpoint lacks Flashblocks support, choose a compatible provider before expecting early feedback. |
Other pending-state reads and fallback behavior
Account-balance reads with
eth_getBalance
can include preconfirmed changes, while
eth_call
evaluates contract calls against pending state. For account nonces,
eth_getTransactionCount
reads the transaction count from that state.
Each method retains its normal parameter layout;
pending
fills the applicable block parameter. Production integrations need a node provider explicitly supporting Flashblocks.
Applications can continue using ordinary full-block data without adopting Flashblocks. This provides a fallback when the chosen RPC cannot supply early preconfirmation data, with feedback tied to full blocks.
