diff --git a/docs/base-chain/flashblocks/apps.mdx b/docs/base-chain/flashblocks/apps.mdx
index 5ae0d4a80..49f3a4321 100644
--- a/docs/base-chain/flashblocks/apps.mdx
+++ b/docs/base-chain/flashblocks/apps.mdx
@@ -1,29 +1,79 @@
---
-title: Flashblocks
+title: Flashblocks Integration
sidebarTitle: Apps
-description: Experience lightning-fast transaction confirmations of Base by using Flashblocks. Preconfirmations happen in just 200 milliseconds—designed for real-time apps, games, and seamless UX.
+description: Integrate Flashblocks into your app for 200ms transaction confirmations using RPC APIs and popular libraries like Ethers, Wagmi and Viem.
---
-## Overview
+Get **200ms transaction confirmations** on Base—10x faster than the standard 2-second block time.
-Flashblocks enable up to 200 millisecond transaction confirmations on Base by leveraging preconfirmations, ultra-fast signals that arrive before the next block is sealed. Built for developers who demand instant UX, it's ideal for high-frequency apps, games, and real-time interactions where waiting even a few seconds is too long. By integrating directly within Base's infrastructure, Flashblocks enables, seamless, ultrafast and snappy user experiences without compromising security.
+## Endpoints
-## Integrating Flashblocks
+| Network | RPC URL | Status |
+|---------|---------|--------|
+| **Mainnet** | `https://mainnet-preconf.base.org` | ✅ Live |
+| **Sepolia** | `https://sepolia-preconf.base.org` | ✅ Live |
-Flashblocks is enabled for developers on Base. There are two ways you can integrate with Flashblocks data. You can either use the WebSocket API to stream real-time block updates, or use the RPC API to query the Flashblocks-aware RPC endpoint.
+
+**Already using a node provider?** Alchemy, Infura, QuickNode, and dRPC all support Flashblocks—just use the `pending` tag with your existing endpoint.
+
-### RPC API
+
+Public endpoints are rate-limited. For production, use a [node provider with Flashblocks support](/base-chain/tools/node-providers) or [run your own node](/base-chain/node-operators/run-a-base-node#enable-flashblocks).
+
-Base offers the following public Flashblocks aware RPC endpoints. These are rate limited and may not be suitable for production use - we recommend using a node provider that runs Flashblocks integrated nodes.
-Major node providers such as Alchemy, Infura, QuickNode and dRPC have Flashblocks-aware RPCs that can be leveraged
+---
+
+## Quick Start
+
+Use the `pending` tag with any supported RPC method:
+
+```bash
+curl https://mainnet-preconf.base.org -X POST \
+ -H "Content-Type: application/json" \
+ -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["pending",false],"id":1}'
+```
- | Network | URL |
- | :----------------- | :------------------------------- |
- | Mainnet | https://mainnet-preconf.base.org |
- | Sepolia | https://sepolia-preconf.base.org |
+That's it—your app now receives 200ms preconfirmations instead of waiting 2 seconds.
+---
+
+## Use Cases
+
+Flashblocks is ideal for:
-The following RPC methods can return Flashblocks specific data. All standard Ethereum JSON-RPC methods are still supported as usual.
+- **Decentralized exchanges** — Near-instant trade confirmations
+- **Onchain games** — Real-time state updates for responsive gameplay
+- **Trading bots** — Faster feedback loops for automated strategies
+- **Live dashboards** — Real-time balance and transaction monitoring
+- **Any app requiring instant feedback** — Improved UX across the board
+
+---
+
+## Supported RPC Methods
+
+| Method | Description |
+|--------|-------------|
+| `eth_getBlockByNumber` | With `pending`, returns the most recent Flashblock |
+| `eth_getBalance` | With `pending`, reflects balances from the latest Flashblock |
+| `eth_getTransactionReceipt` | Returns receipts for preconfirmed transactions |
+| `eth_getTransactionByHash` | Returns preconfirmed transaction details |
+| `eth_getTransactionCount` | With `pending`, returns the updated nonce from Flashblocks |
+| `eth_call` | With `pending`, executes against the latest Flashblock state |
+| `eth_estimateGas` | With `pending`, estimates gas against the latest Flashblock |
+| `eth_getLogs` | With `pending`, returns logs from the latest Flashblock |
+| `eth_simulateV1` | Simulates transactions against the latest Flashblock state |
+| `eth_subscribe` | Stream Flashblock data in real-time (Beta) |
+| `base_transactionStatus` | Check if a transaction is in the mempool (Beta) |
+
+
+**WebSocket Note:** Do not connect directly to `wss://mainnet.flashblocks.base.org/ws`. This endpoint is reserved for infrastructure-to-node data syncing. For real-time streaming, use `eth_subscribe` via your RPC node or node provider's WebSocket.
+
+
+---
+
+## RPC API Reference
+
+Detailed documentation for each Flashblocks-enabled RPC method.
#### eth_getBlockByNumber
@@ -214,9 +264,13 @@ Each subscription returns **one item per WebSocket message** and emits events ev
| Subscription | Description | Response |
|--------------|-------------|----------|
-| `newFlashblockTransactions` | Stream transactions as they're included | One transaction per message |
-| `pendingLogs` | Stream logs matching a filter | One log per message |
-| `newFlashblocks` | Stream block state updates | Block state per Flashblock |
+| `newFlashblockTransactions` | Stream [transactions](/base-chain/flashblocks/websocket-reference#diff-object) as they're included | One transaction per message |
+| `pendingLogs` | Stream [logs](/base-chain/flashblocks/websocket-reference#log-object) matching a filter | One log per message |
+| `newFlashblocks` | Stream [Flashblock](/base-chain/flashblocks/websocket-reference#flashblock-object) state updates | Full Flashblock per message |
+
+
+For detailed response schema documentation (Flashblock, Diff, Metadata, Receipt, Log objects), see the [WebSocket Reference](/base-chain/flashblocks/websocket-reference#schema).
+
---
diff --git a/docs/base-chain/flashblocks/architecture.mdx b/docs/base-chain/flashblocks/architecture.mdx
new file mode 100644
index 000000000..da113d605
--- /dev/null
+++ b/docs/base-chain/flashblocks/architecture.mdx
@@ -0,0 +1,39 @@
+---
+title: Flashblocks Architecture
+sidebarTitle: Architecture
+description: Understand the sequencer architecture and infrastructure components that power Flashblocks on Base.
+---
+
+## Before Flashblocks
+
+Base operates a high-availability sequencer system with five sequencer instances:
+
+| Component | Role |
+|-----------|------|
+| **op-node** | Standard OP Stack consensus layer (CL) |
+| **op-geth** | Standard OP Stack execution layer (EL) |
+| **op-conductor** | High availability controller with Raft consensus for leader election |
+
+One sequencer instance acts as the **leader**, responsible for building blocks and propagating them via P2P. The remaining four act as **followers** that sync the chain. Leadership transfers if the current leader stops producing blocks.
+
+## With Flashblocks
+
+Flashblocks introduce several new infrastructure components:
+
+| Component | Purpose | What It Unlocks |
+|-----------|---------|-----------------|
+| **rollup-boost** | CL↔EL Engine API proxy | Enables sharing Flashblocks with the EL without modifying the CL. Provides a stable seam for future block-building evolutions (multi-builder, etc.) |
+| **op-rbuilder** | Out-of-protocol builder at 200ms cadence | Produces the sub-second Flashblocks, decoupled from the EL. Enables pluggable builder mechanisms |
+| **websocket-proxy** | Flashblocks stream fan-out | Broadcast layer so many consumers can read the stream without overwhelming the builder |
+| **[base](https://github.com/base/base)** | RPC surface exposing preconfirmations | Converts streamed Flashblocks into familiar RPCs so apps and wallets can consume preconfirmation state |
+
+Both [rollup-boost](https://github.com/flashbots/rollup-boost) and [op-rbuilder](https://github.com/flashbots/op-rbuilder) are built and maintained by Flashbots, while Base maintains the websocket-proxy and [base](https://github.com/base/base) components.
+
+---
+
+## Further Reading
+
+- [Flashblocks Overview](/base-chain/flashblocks/overview) — Key concepts and transaction lifecycle
+- [Enable Flashblocks](/base-chain/node-operators/run-a-base-node#enable-flashblocks) — Run your own Flashblocks-aware RPC node
+- [WebSocket Reference](/base-chain/flashblocks/websocket-reference) — Technical reference for infrastructure-to-node data syncing
+- [Flashblocks Deep Dive](https://blog.base.dev/flashblocks-deep-dive) — Engineering blog post with implementation details
diff --git a/docs/base-chain/flashblocks/docs.mdx b/docs/base-chain/flashblocks/docs.mdx
deleted file mode 100644
index 6aed7392b..000000000
--- a/docs/base-chain/flashblocks/docs.mdx
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: "Flashblocks FAQ"
----
-
-## Flashblocks Block Building
-
-### Are flashblocks optional?
-
-All Base blocks are built by the Flashblocks builder, meaning Flashblocks are always live. However, apps may choose not to rely on preconfirmations and are welcome to continue to have an integration that does not rely on Flashblocks.
-
-### Is there any difference in tx inclusion for flashblocks vs. 2s block?
-
-No particular differences except more frequent timing, both still pick txs based on tx fees ordering. You can read more about it here (https://docs.base.org/base-chain/network-information/block-building#flashblocks).
-
-### Is it possible for the sequencer to stop publishing flashblocks, if so what happens?
-
-The sequencer will not stop publishing flashblocks, unless an extreme circumstance arises, that causes running flashblocks to be unsafe. If this happens, the preconfirmation is disabled across the network and confirmation falls back to 2s blocks.
-
-### Why is my tx having trouble getting included now?
-
-It's possible that larger txs (> 15m gas limit) will have a harder time to land. This is due to how the builder allocates gas, it incrementally adds 1/10th of the total block gas limit to each flashblock. You can read more about it here (https://docs.base.org/base-chain/network-information/block-building#flashblocks).
-
-### How do I ensure my TX is in the first flashblock?
-
-Unfortunately there's no way to guarantee which flashblock a transaction lands in, similar to how it cannot be guaranteed that a transaction lands in a specific block. To ensure quick inclusion, you may set a higher priority fee on your transaction.
-
-### How frequently do flashblocks reorg happen?
-
-Flashblocks reorgs on Base Mainnet is currently effectively zero, with only rare exceptions. We are committed to maintaining a reorg rate below 0.01% going forward. You can check the latest metrics in the Flashblocks section at https://base.org/stats
-
-### What does it mean when a flashblock is reorged?
-
-It means when a flashblock was streamed out as preconfirmation but it didn't end up getting included in that particular block. Currently applications building with flashblocks should have this expectation in mind but we are actively working on reducing reorgs to 0.
-
-## Flashblocks Websockets
-
-### Why are there 11 flashblocks?
-
-Index 0 only contains the system txs but doesn't use any gas limit, thus index 1-10 are the actual flashblocks that take pending txs from the txpool to build blocks.
-
-### Why sometimes there are less than 10 flashblocks?
-
-This is expected for now, it happens when the previous block takes too long to build the system then compensates by having less time to build the next block, resulting in less flashblocks.
-
-### What encoding format is the data in transactions?
-
-Those data are RLP encoded.
-
-### Why am I getting rate limited?
-
-We currently set the maximum number of connections to our public websocket. We are aiming to have websocket supported on the RPC nodes soon, thus will soon encourage everyone to connect to the RPC for websocket stream rather than connecting to the websocket proxy directly.
-
-## RPC
-
-### Why am I getting rate limited using mainnet-preconf.base.org?
-
-We set explicit rate limiting on the public endpoint. In order to not get rate limited, we strongly encourage utilizing third party node providers, most of which already support flashblocks aware RPCs on Base today.
-
-### What RPC methods do you currently support that have flashblocks enabled?
-
-Currently the ones that have flashblocks enabled are:
-- eth_getBlockByNumber (with pending tag)
-- eth_getBalance (with pending tag)
-- eth_getTransactionReceipt
-- eth_getTransactionByHash (with pending tag)
-- eth_getTransactionCount (with pending tag)
-- eth_call (with pending tag)
-- eth_simulateV1 (with pending tag)
-- eth_estimateGas (with pending tag)
-- eth_getLogs (with pending tag)
-
-## Node
-
-### How can I set up a RPC node that's flashblocks-aware?
-
-In order to set up a node that's flashblocks-aware you must use the reth binary that we provide under https://github.com/base/node/tree/main/reth.
\ No newline at end of file
diff --git a/docs/base-chain/flashblocks/faq.mdx b/docs/base-chain/flashblocks/faq.mdx
new file mode 100644
index 000000000..5fdcf49c5
--- /dev/null
+++ b/docs/base-chain/flashblocks/faq.mdx
@@ -0,0 +1,143 @@
+---
+title: Flashblocks FAQ
+sidebarTitle: FAQ
+description: Frequently asked questions about Flashblocks, including block building, WebSocket data, RPC usage, and node setup.
+---
+
+
+For a comprehensive introduction to how Flashblocks work, see the [Flashblocks Overview](/base-chain/flashblocks/overview).
+
+
+## Block Building
+
+
+
+ All Base blocks are built by the Flashblocks builder, meaning **Flashblocks are always live**. However, apps may choose not to rely on preconfirmations and can continue using standard RPCs without any Flashblocks integration.
+
+
+
+ No significant differences—both order transactions by fee. The main difference is timing: Flashblocks occur every 200ms instead of every 2 seconds.
+
+ See [Block Building](/base-chain/network-information/block-building#flashblocks) for details.
+
+
+
+ The sequencer will not stop publishing Flashblocks unless an extreme circumstance makes running them unsafe. If this happens, preconfirmations are disabled network-wide and confirmations fall back to standard 2-second blocks. The sequencer continues operating normally.
+
+
+
+ Transactions with large gas limits (> ~18.75M gas, which is 1/10 of the ~187.5M block limit) may have longer inclusion times. This is because the builder allocates gas cumulatively—each Flashblock `j` can use up to `j/10` of the total block gas limit. Large transactions can be included once enough cumulative capacity exists.
+
+ See [Gas Allocation](/base-chain/flashblocks/overview#gas-allocation) for the full breakdown.
+
+
+
+ There's no way to guarantee which Flashblock a transaction lands in, similar to how you can't guarantee a specific block. To improve chances of quick inclusion:
+
+ - Set a higher priority fee
+ - Keep gas limits below ~18.75M (1/10 of block limit) to be eligible for Flashblock 1
+
+
+
+ The Flashblock builder uses a **dynamic mempool** that continuously accepts new transactions while building. This design prioritizes **low inclusion latency** over strict fee ordering.
+
+ **What this means:**
+ - Transactions are ordered by fee *at the time they're selected* for inclusion
+ - If a high-fee transaction arrives after a lower-fee transaction has already been committed to the current Flashblock, the high-fee transaction will appear after it (or in the next Flashblock)
+ - This is expected behavior, not a bug—the builder doesn't "reorder" already-committed transactions
+
+ **Why this tradeoff?**
+
+ A "snapshot" mempool (freezing the transaction pool at the start of each block) would guarantee strict fee ordering but increase inclusion latency. The dynamic approach gets transactions included faster at the cost of occasionally "breaking" the expected priority gas auction (PGA) order.
+
+ **For traders and bots:** If strict fee-based ordering is critical for your use case, be aware that arrival timing matters as much as fee amount within a 200ms Flashblock window.
+
+
+
+ Base targets a Flashblock reorg rate of < 0.1%. While reorgs are rare, applications should implement fallback logic for critical operations.
+
+ Check current metrics at [base.org/stats](https://base.org/stats).
+
+
+
+ A reorg means a Flashblock was streamed as a preconfirmation but wasn't included in the final block. This is rare due to architectural improvements in rollup-boost that prevent tail Flashblock reorgs. Apps should handle this possibility gracefully, but occurrences are minimal.
+
+
+
+---
+
+## WebSocket
+
+
+
+ **No.** The raw Flashblocks WebSocket (`wss://mainnet.flashblocks.base.org/ws`) is reserved for infrastructure-to-node data syncing. Applications should not connect to it directly.
+
+ Instead, query your RPC node or node provider (e.g., QuickNode, Alchemy, Infura, dRPC) for Flashblocks data via:
+ - **RPC API**: Standard JSON-RPC methods with the `pending` tag
+ - **WebSocket subscriptions**: Use `eth_subscribe` via your node provider's WebSocket endpoint
+
+ See [App Integration](/base-chain/flashblocks/apps) for implementation details.
+
+
+
+ Index 0 contains only system transactions and doesn't use any gas limit. Indexes 1-10 are the actual Flashblocks that pull pending transactions from the txpool.
+
+
+
+ This is expected. When the previous block takes longer to build, the system compensates by allocating less time to the next block, resulting in fewer Flashblocks.
+
+
+
+ Transaction data in the [`diff.transactions`](/base-chain/flashblocks/websocket-reference#diff-object) array is Recursive Length Prefix (RLP) encoded.
+
+
+
+ The public WebSocket has a maximum connection limit. For production use, we recommend:
+
+ 1. Running your own [Flashblocks-aware RPC node](/base-chain/node-operators/run-a-base-node#enable-flashblocks)
+ 2. Using a third-party node provider with Flashblocks support
+
+
+
+---
+
+## RPC
+
+
+
+ The public endpoint has explicit rate limiting. For production use:
+
+ - Use a third-party node provider with Flashblocks support (Alchemy, Infura, QuickNode, dRPC)
+ - Run your own [Flashblocks-aware RPC node](/base-chain/node-operators/run-a-base-node#enable-flashblocks)
+
+
+
+ The following methods are Flashblocks-enabled:
+
+ | Method | Usage |
+ |--------|-------|
+ | `eth_getBlockByNumber` | Use `pending` tag |
+ | `eth_getBalance` | Use `pending` tag |
+ | `eth_getTransactionReceipt` | Returns preconfirmed receipts |
+ | `eth_getTransactionByHash` | Use `pending` tag |
+ | `eth_getTransactionCount` | Use `pending` tag |
+ | `eth_call` | Use `pending` tag |
+ | `eth_simulateV1` | Use `pending` tag |
+ | `eth_estimateGas` | Use `pending` tag |
+ | `eth_getLogs` | Use `pending` for `toBlock` |
+ | `eth_subscribe` | Stream Flashblock data in real-time (Beta) |
+ | `base_transactionStatus` | Check if transaction is in mempool (Beta) |
+
+ See [App Integration](/base-chain/flashblocks/apps#rpc-api-reference) for full examples.
+
+
+
+---
+
+## Node Setup
+
+
+
+ Use the Reth binary from the [Base node repository](https://github.com/base/node/tree/main/reth). See the [Enable Flashblocks guide](/base-chain/node-operators/run-a-base-node#enable-flashblocks) for complete setup instructions.
+
+
\ No newline at end of file
diff --git a/docs/base-chain/flashblocks/node-providers.mdx b/docs/base-chain/flashblocks/node-providers.mdx
deleted file mode 100644
index 0e297752f..000000000
--- a/docs/base-chain/flashblocks/node-providers.mdx
+++ /dev/null
@@ -1,145 +0,0 @@
----
-title: How to host Flashblocks-aware RPC nodes
-sidebarTitle: Node Providers
----
-
-## Quick Start
-
-1. **Prerequisites**:
- - Docker and Docker Compose
- - Minimum hardware requirements (see [node README](https://github.com/base/node?tab=readme-ov-file#hardware-requirements))
- - Access to a Flashblocks websocket endpoint, we provide public endpoints in the env files in the repo
-
-2. **Set Up Environment**:
-
- ```sh
- # Clone the repository
- git clone https://github.com/base/node.git
- cd node
- ```
-
-3. **Start the Node with Flashblocks Support**:
-
- ```sh
- NODE_TYPE=base CLIENT=reth RETH_FB_WEBSOCKET_URL="wss://mainnet.flashblocks.base.org/ws" docker-compose up
- ```
-
-## Configuration Options
-
-- Node Type: Use `NODE_TYPE=base` to enable base reth node with Flashblocks functionality
-- Network: Use `NETWORK_ENV=.env.mainnet` for mainnet or `NETWORK_ENV=.env.sepolia` for testnet
-
-Ensure the RETH_FB_WEBSOCKET_URL is set. Base offers the following public rate limited RPC's:
-- For Mainnet: `RETH_FB_WEBSOCKET_URL=wss://mainnet.flashblocks.base.org/ws`
-- For Sepolia: `RETH_FB_WEBSOCKET_URL=wss://sepolia.flashblocks.base.org/ws`
-
-## Verifying Flashblocks Functionality
-
-Test that your node is properly supporting Flashblocks by querying a pending block:
-
-```sh
-curl -X POST \
- --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["pending", false],"id":1}' \
- http://localhost:8545
-```
-
-## Available RPC Methods
-
-Flashblocks-aware nodes provide all standard Ethereum JSON-RPC methods plus specialized Flashblocks endpoints. For more details, see the [Flashblocks RPC API documentation](/base-chain/flashblocks/apps#rpc-api).
-
-
-## WebSocket API
-
-The websocket API is intended to stream Flashblock data to nodes, so they can expose it via their RPC APIs. The endpoints are available at:
-
- | Network | URL |
- | :----------------- | :------------------------------------ |
- | Mainnet | wss://mainnet.flashblocks.base.org/ws |
- | Sepolia | wss://sepolia.flashblocks.base.org/ws |
-
-
-#### Interpreting the data
-
-To minimize the amount of data sent to nodes, each Flashblock only includes the diff data from the previous block. The initial Flashblock (when index is zero) includes the block properties (e.g. number, gas limit) and the subsequent Flashblocks only include the diff data (e.g. transactions that are present in that Flashblock).
-
-**Example Initial Response**
-```
-{
- "payload_id": "0x03997352d799c31a",
- "index": 0,
- "base": {
- "parent_hash": "0x9edc29b8b0a1e31d28616e40c16132ad0d58faa8bb952595b557526bdb9a960a",
- "fee_recipient": "0x4200000000000000000000000000000000000011",
- "block_number": "0x158a0e9",
- "gas_limit": "0x3938700",
- "timestamp": "0x67bf8332",
- "base_fee_per_gas": "0xfa"
- // ... other base fields ...
- },
- "diff": {
- "state_root": "0x208fd63edc0681161105f27d03daf9f8c726d8c94e584a3c0696c98291c24333",
- "block_hash": "0x5c330e55a190f82ea486b61e5b12e27dfb4fb3cecfc5746886ef38ca1281bce8",
- "gas_used": "0xab3f",
- "transactions": [
- "0x7ef8f8a0b4afc0b7ce10e150801bbaf08ac33fecb0f38311793abccb022120d321c6d276..."
- ],
- "withdrawals": []
- // ... other diff fields ...
- },
- "metadata": {
- "block_number": 22585577,
- "new_account_balances": {
- "0x000f3df6d732807ef1319fb7b8bb8522d0beac02": "0x0",
- // ... other balances ...
- },
- "receipts": {
- "0x07d7f06b06fea714c1d1d446efa2790c6970aa74ee006186a32b5b7dd8ca2d82": {
- "Deposit": {
- "status": "0x1",
- "depositNonce": "0x158a0ea"
- // ... other receipt fields ...
- }
- }
- }
- }
-}
-```
-
-**Example Diff Response**
-```
-{
- "payload_id": "0x03e303378749418d",
- "index": 4,
- "diff": {
- "state_root": "0x7a8f45038665072f382730e689f4a1561835c9987fca8942fa95872fb9367eaa",
- "block_hash": "0x9b32f7a14cbd1efc8c2c5cad5eb718ec9e0c5da92c3ba7080f8d4c49d660c332",
- "gas_used": "0x1234f",
- "transactions": [
- "0x7ef8f8a0b4afc0b7ce10e150801bbaf08ac33fecb0f38311793abccb022120d321c6d276..."
- ],
- "withdrawals": []
- // ... other diff fields ...
- },
- "metadata": {
- "block_number": 22585577,
- "new_account_balances": {
- "0x000f3df6d732807ef1319fb7b8bb8522d0beac02": "0x0",
- "0x4200000000000000000000000000000000000015": "0x1234"
- // ... other balances ...
- },
- "receipts": {
- "0x07d7f06b06fea714c1d1d446efa2790c6970aa74ee006186a32b5b7dd8ca2d82": {
- "status": "0x1",
- "gasUsed": "0x1234f",
- "logs": []
- // ... other receipt fields ...
- }
- }
- }
-}
-```
-
-## Further Resources
-
-For detailed information about node setup, including hardware requirements and additional configuration options, refer to the [Reth node README](https://github.com/base/node/tree/main/reth#readme).
-
diff --git a/docs/base-chain/flashblocks/overview.mdx b/docs/base-chain/flashblocks/overview.mdx
new file mode 100644
index 000000000..a3bd1d21f
--- /dev/null
+++ b/docs/base-chain/flashblocks/overview.mdx
@@ -0,0 +1,163 @@
+---
+title: Flashblocks Overview
+sidebarTitle: Overview
+description: Understand the sequencer architecture, block building algorithm, and integration options for Flashblocks on Base.
+---
+
+## What are Flashblocks?
+
+Flashblocks introduce **200ms** incremental state updates to Base, significantly reducing perceived latency for users.
+
+Built in collaboration with [Flashbots](https://www.flashbots.net/), this mechanism streams sub-blocks within the standard 2-second block interval, providing near-instant sequencer preconfirmations, allowing applications to reflect state changes long before the full block is gossiped to the rest of the network.
+
+
+Flashblocks are always live on Base. All blocks are built by the Flashblocks builder. Apps can choose whether to consume preconfirmations or wait for standard 2-second block finality.
+
+
+### Key Concepts
+
+| Term | Definition |
+|------|------------|
+| **Flashblock** | A 200ms sub-block containing a portion of the full block's transactions |
+| **Preconfirmation** | An ultra-fast signal that a transaction will be included, before the full block is sealed |
+| **Full Block** | A series of 10 Flashblocks combined to form the complete 2-second block |
+
+Each block contains **10 Flashblocks** (indexes 1-10), each arriving every 200ms. Index 0 exists but only contains system transactions. See [Gas Allocation](#gas-allocation) for how gas budgets work.
+
+
+## Architecture
+
+For details on the sequencer system and Flashblocks infrastructure components (rollup-boost, op-rbuilder, websocket-proxy, and base), see the [Architecture](/base-chain/flashblocks/architecture) page.
+
+## Transaction Lifecycle
+
+When you send a transaction to Base, here's what happens:
+
+### 1. Submission
+```
+User → DNS (mainnet.base.org) → Load Balancer → Proxyd → Mempool
+```
+
+The transaction reaches the private mempool and is inserted into the txpool as pending.
+
+### 2. Distribution
+The mempool maintains P2P connections with execution layers (op-reth, op-rbuilder), ensuring all pending transactions are synced for block building.
+
+### 3. Block Building
+During each 200ms block building loop, op-rbuilder selects transactions based on:
+
+1. **Transaction fee** — transactions are ordered by fee (highest first)
+2. **Gas limit and remaining capacity** — each Flashblock `j` can use up to `j/10` of the total block gas limit
+
+
+**Dynamic Mempool:** The builder uses a dynamic mempool that continuously accepts new transactions while building. This minimizes inclusion latency but means a late-arriving high-fee transaction may appear after an already-committed lower-fee transaction within the same Flashblock. This is expected behavior, not a violation of fee priority—transactions are ordered by fee *at the time they're selected*.
+
+
+### 4. Block Building Algorithm
+
+The builder follows this process for each 2-second block:
+
+```
+FOR each flashblock j FROM 0 TO 10:
+ 1. Wait until next 200ms window
+ 2. Calculate available gas: (j / 10) × total_block_gas_limit
+ 3. Sort pending transactions by fee (descending)
+ 4. Select top transactions that fit within available gas
+ 5. Execute transactions and update state
+ 6. Stream flashblock to websocket-proxy
+```
+
+
+**Index 0** contains only system transactions and doesn't use any gas limit. **Indexes 1-10** are the actual Flashblocks that pull pending transactions from the txpool.
+
+
+### 5. Preconfirmation Delivery
+Once a transaction is included in a Flashblock, it's streamed to the websocket-proxy, which RPC nodes listen to. When you call a Flashblocks-aware RPC method (like `eth_getTransactionReceipt`), the node retrieves the preconfirmed data from its cache.
+
+
+For the complete WebSocket message schema, see the [WebSocket Reference](/base-chain/flashblocks/websocket-reference#schema): [Flashblock](/base-chain/flashblocks/websocket-reference#flashblock-object), [Diff](/base-chain/flashblocks/websocket-reference#diff-object), [Metadata](/base-chain/flashblocks/websocket-reference#metadata-object), [Receipt](/base-chain/flashblocks/websocket-reference#receipt-object).
+
+
+---
+
+## Gas Allocation
+
+The gas budget is **cumulative**, not per-Flashblock. Each Flashblock unlocks an additional 1/10 of the total block gas:
+
+| Flashblock | Cumulative Gas Available |
+|------------|--------------------------|
+| 1 | 1/10 of block limit (~18.75M gas) |
+| 2 | 2/10 of block limit (~37.5M gas) |
+| 3 | 3/10 of block limit (~56.25M gas) |
+| ... | ... |
+| 10 | Full block limit (~187.5M gas) |
+
+
+**Unused gas carries forward.** If Flashblock 1 only uses 0.3/10 of gas, Flashblock 2 can use up to 1.7/10 (the cumulative 2/10 limit minus what's already been used).
+
+
+**Implications for large transactions:**
+- Transactions exceeding 1/10 of block gas (~18.75M) can be included once enough cumulative capacity exists. For example, a 20M gas transaction can be included in the 2nd Flashblock if the 1st Flashblock leaves at least 1.25M gas unused (since 2/10 = 37.5M cumulative, minus 20M needed = 17.5M already consumed is acceptable).
+- There is a separate **max gas limit per transaction** on Base, which is distinct from Flashblock capacity.
+- Large transactions may experience slightly longer inclusion times while waiting for sufficient cumulative capacity.
+
+---
+
+## Reliability
+
+### Reorg Rate
+
+Base targets a < 0.1% Flashblock reorg rate. A reorg means a Flashblock was streamed as a preconfirmation but wasn't included in the final block.
+
+A reorg means a Flashblock was streamed as a preconfirmation but wasn't included in the final block. This is rare due to architectural improvements where rollup-boost stores Flashblocks in a `best_payload` variable and only returns the final payload on `get_payload`, preventing tail Flashblock reorgs.
+
+
+**Implement fallback logic.** While reorg rates are low, applications should handle the possibility of preconfirmation reorgs by falling back to full block data for critical operations. Check current metrics at [base.org/stats](https://base.org/stats).
+
+
+### Builder Failover
+
+The op-conductor verifies builder health by checking if the builder remains synced with the tip of the chain. If a builder falls behind, leadership transfers automatically. This ensures high availability—Flashblocks won't experience extended outages due to unhealthy builders.
+
+### Fallback Behavior
+
+If an extreme circumstance makes running Flashblocks unsafe, preconfirmations are disabled network-wide and confirmation falls back to standard 2-second blocks. The sequencer continues operating normally.
+
+---
+
+## Performance Characteristics
+
+| Metric | Value |
+|--------|-------|
+| Flashblock build time (P50) | ~10ms |
+| Preconfirmation latency | ~200ms |
+| Full block time | 2 seconds |
+| Flashblocks per block | 10 |
+| Reorg rate | < 0.1% |
+
+---
+
+## Integration Paths
+
+Choose the integration method that fits your use case:
+
+| Use Case | Recommended Approach | Documentation |
+|----------|---------------------|---------------|
+| **Apps needing instant UX** | Flashblocks-aware RPC with `pending` tag | [App Integration](/base-chain/flashblocks/apps) |
+| **Infrastructure providers** | Host Flashblocks-aware RPC nodes | [Enable Flashblocks](/base-chain/node-operators/run-a-base-node#enable-flashblocks) |
+| **Standard apps** | Continue using regular RPCs | No changes needed |
+
+
+Applications should avoid hard dependencies on the WebSocket stream. RPCs provide stable behavior and automatic failover to regular blocks if Flashblocks go down.
+
+
+---
+
+## Further Reading
+
+- [App Integration Guide](/base-chain/flashblocks/apps) — RPC methods, code examples, and library integrations
+- [Enable Flashblocks](/base-chain/node-operators/run-a-base-node#enable-flashblocks) — Run your own Flashblocks-aware RPC node
+- [WebSocket Reference](/base-chain/flashblocks/websocket-reference) — Technical reference for infrastructure-to-node data syncing
+- [FAQ](/base-chain/flashblocks/faq) — Common questions about Flashblocks
+- [Block Building](/base-chain/network-information/block-building) — Detailed block ordering configuration
+- [Flashblocks Deep Dive](https://blog.base.dev/flashblocks-deep-dive) — Engineering blog post with implementation details
diff --git a/docs/base-chain/flashblocks/websocket-reference.mdx b/docs/base-chain/flashblocks/websocket-reference.mdx
new file mode 100644
index 000000000..9711e53a6
--- /dev/null
+++ b/docs/base-chain/flashblocks/websocket-reference.mdx
@@ -0,0 +1,434 @@
+---
+title: Flashblocks WebSocket Reference
+sidebarTitle: WebSocket Reference
+description: Technical reference for the Flashblocks WebSocket API, data formats, and response schemas used for infrastructure-to-node data syncing.
+---
+
+This page documents the Flashblocks WebSocket API used for **infrastructure-to-node data syncing**.
+
+
+**Applications should not connect directly to `wss://mainnet.flashblocks.base.org/ws`**. This endpoint is reserved for node infrastructure. Apps should query their RPC node or node provider (e.g., QuickNode, Alchemy) for Flashblocks data instead. See the [App Integration guide](/base-chain/flashblocks/apps) for implementation details.
+
+
+
+For background on how Flashblocks work and the [base](https://github.com/base/base) component, see the [Flashblocks Architecture](/base-chain/flashblocks/architecture).
+
+
+---
+
+## WebSocket Endpoints
+
+| Network | URL |
+|---------|-----|
+| Mainnet | `wss://mainnet.flashblocks.base.org/ws` |
+| Sepolia | `wss://sepolia.flashblocks.base.org/ws` |
+
+
+These endpoints are rate-limited (max 10 connections per IP).
+
+
+
+Applications should avoid hard dependencies on the WebSocket stream. RPCs provide stable behavior and automatic failover to regular blocks if Flashblocks are unavailable.
+
+
+
+---
+
+## Message Format
+
+Messages are delivered as **Brotli-compressed binary** data. Decompress before parsing as JSON.
+
+To minimize bandwidth, each Flashblock only includes **diff data** from the previous Flashblock:
+
+- **[Index 0](#flashblock-object)** (initial): Contains the [`base`](#base-object) object with full block properties, plus the first [`diff`](#diff-object)
+- **[Index 1-10](#flashblock-object)** (subsequent): Contains only [`diff`](#diff-object) data (new transactions, updated state root, gas used)
+
+---
+
+## Schema
+
+### Flashblock Object
+
+The root structure of each WebSocket message.
+
+
+
+Unique identifier for the block being built. Remains consistent across all 10 Flashblocks within a single full block.
+
+
+
+Flashblock index within the current block (0-10). Index 0 contains system transactions only; indexes 1-10 contain user transactions.
+
+
+
+Block header properties. **Only present when `index` is 0.** See [Base Object](#base-object).
+
+
+
+Block differences/updates for this Flashblock. See [Diff Object](#diff-object).
+
+
+
+Additional data including balance updates and transaction receipts. See [Metadata Object](#metadata-object).
+
+
+
+Example:
+```json flashblock.json
+{
+ "payload_id": "0x03997352d799c31a",
+ "index": 0,
+ "base": { ... },
+ "diff": { ... },
+ "metadata": { ... }
+}
+```
+
+---
+
+### Base Object
+
+Contains full block header properties. **Only present in Index 0** (the first Flashblock of each full block).
+
+
+
+Hash of the parent block.
+
+
+
+Address receiving transaction fees (coinbase).
+
+
+
+Block number in hex format.
+
+
+
+Maximum gas allowed in this block (hex).
+
+
+
+Unix timestamp of block creation (hex).
+
+
+
+Base fee per gas unit (hex, EIP-1559).
+
+
+
+Previous RANDAO value for randomness.
+
+
+
+Arbitrary data included by the block builder.
+
+
+
+Example:
+```json base.json
+{
+ "parent_hash": "0x9edc29b8b0a1e31d28616e40c16132ad0d58faa8bb952595b557526bdb9a960a",
+ "fee_recipient": "0x4200000000000000000000000000000000000011",
+ "block_number": "0x158a0e9",
+ "gas_limit": "0x3938700",
+ "timestamp": "0x67bf8332",
+ "base_fee_per_gas": "0xfa",
+ "prev_randao": "0x0000000000000000000000000000000000000000000000000000000000000000",
+ "extra_data": "0x"
+}
+```
+
+---
+
+### Diff Object
+
+Contains the block state changes for this specific Flashblock. Present in every message.
+
+
+
+Merkle root of the state trie after applying this Flashblock's transactions.
+
+
+
+Hash of the block at this Flashblock index. Changes with each Flashblock as more transactions are added.
+
+
+
+Cumulative gas used up to and including this Flashblock (hex).
+
+
+
+Cumulative blob gas used (hex, EIP-4844).
+
+
+
+Array of RLP-encoded transaction data included in this Flashblock.
+
+
+
+Validator withdrawals included in this Flashblock (typically empty on L2).
+
+
+
+Merkle root of transaction receipts.
+
+
+
+Bloom filter for quick log searching.
+
+
+
+Merkle root of withdrawals.
+
+
+
+Example:
+```json diff.json
+{
+ "state_root": "0x208fd63edc0681161105f27d03daf9f8c726d8c94e584a3c0696c98291c24333",
+ "block_hash": "0x5c330e55a190f82ea486b61e5b12e27dfb4fb3cecfc5746886ef38ca1281bce8",
+ "gas_used": "0xab3f",
+ "blob_gas_used": "0x0",
+ "transactions": [
+ "0x02f90133..."
+ ],
+ "withdrawals": [],
+ "receipts_root": "0xa83fdcff1e433d49",
+ "logs_bloom": "0x00000000...",
+ "withdrawals_root": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421"
+}
+```
+
+---
+
+### Metadata Object
+
+Contains additional block metadata, including balance updates and transaction receipts. This is where the most useful data for trading applications lives.
+
+
+
+Block number as a decimal integer.
+
+
+
+Map of addresses to their updated ETH balances (hex). Only includes accounts whose balances changed in this Flashblock.
+
+
+
+Map of transaction hashes to their [Receipt](#receipt-object) objects. Contains execution results for transactions in this Flashblock.
+
+
+
+Example:
+```json metadata.json
+{
+ "block_number": 22585577,
+ "new_account_balances": {
+ "0x000f3df6d732807ef1319fb7b8bb8522d0beac02": "0x0",
+ "0x4200000000000000000000000000000000000015": "0x1234"
+ },
+ "receipts": {
+ "0x07d7f06b06fea714c1d1d446efa2790c6970aa74ee006186a32b5b7dd8ca2d82": { ... }
+ }
+}
+```
+
+---
+
+### Receipt Object
+
+Transaction execution result. Receipts come in two formats: **EIP-1559** (modern) or **Legacy**. Check which field is present to determine the type.
+
+
+
+Receipt data for EIP-1559 transactions. See [ReceiptData](#receiptdata-object).
+
+
+
+Receipt data for legacy transactions. See [ReceiptData](#receiptdata-object).
+
+
+
+Receipt data for L1→L2 deposit transactions. See [ReceiptData](#receiptdata-object).
+
+
+
+Example:
+```json receipt.json
+{
+ "Eip1559": {
+ "status": "0x1",
+ "cumulativeGasUsed": "0x1234f",
+ "logs": []
+ }
+}
+```
+
+---
+
+### ReceiptData Object
+
+The actual receipt information, regardless of transaction type.
+
+
+
+Transaction status: `0x1` for success, `0x0` for failure.
+
+
+
+Total gas used in the block up to and including this transaction (hex).
+
+
+
+Array of event logs emitted by the transaction. See [Log Object](#log-object).
+
+
+
+Nonce for deposit transactions (L1→L2 only).
+
+
+
+Example:
+```json receiptdata.json
+{
+ "status": "0x1",
+ "cumulativeGasUsed": "0x1234f",
+ "logs": [
+ {
+ "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
+ "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"],
+ "data": "0x0000000000000000000000000000000000000000000000000000000000001234"
+ }
+ ]
+}
+```
+
+---
+
+### Log Object
+
+Event log emitted by a smart contract. Crucial for detecting swaps, transfers, and other contract events.
+
+
+
+Contract address that emitted the event.
+
+
+
+Array of indexed event parameters. The first topic is typically the event signature hash (e.g., `Transfer(address,address,uint256)`).
+
+
+
+ABI-encoded non-indexed event parameters.
+
+
+
+Example:
+```json log.json
+{
+ "address": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
+ "topics": [
+ "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
+ "0x000000000000000000000000abc123...",
+ "0x000000000000000000000000def456..."
+ ],
+ "data": "0x0000000000000000000000000000000000000000000000000000000000001234"
+}
+```
+
+---
+
+## Complete Example
+
+### Index 0 Response (Initial)
+
+The first Flashblock of each full block includes the `base` object:
+
+Example:
+```json
+{
+ "payload_id": "0x03997352d799c31a",
+ "index": 0,
+ "base": {
+ "parent_hash": "0x9edc29b8b0a1e31d28616e40c16132ad0d58faa8bb952595b557526bdb9a960a",
+ "fee_recipient": "0x4200000000000000000000000000000000000011",
+ "block_number": "0x158a0e9",
+ "gas_limit": "0x3938700",
+ "timestamp": "0x67bf8332",
+ "base_fee_per_gas": "0xfa"
+ },
+ "diff": {
+ "state_root": "0x208fd63edc0681161105f27d03daf9f8c726d8c94e584a3c0696c98291c24333",
+ "block_hash": "0x5c330e55a190f82ea486b61e5b12e27dfb4fb3cecfc5746886ef38ca1281bce8",
+ "gas_used": "0xab3f",
+ "transactions": [
+ "0x7ef8f8a0b4afc0b7ce10e150801bbaf08ac33fecb0f38311793abccb022120d321c6d276..."
+ ],
+ "withdrawals": []
+ },
+ "metadata": {
+ "block_number": 22585577,
+ "new_account_balances": {
+ "0x000f3df6d732807ef1319fb7b8bb8522d0beac02": "0x0"
+ },
+ "receipts": {
+ "0x07d7f06b06fea714c1d1d446efa2790c6970aa74ee006186a32b5b7dd8ca2d82": {
+ "Deposit": {
+ "status": "0x1",
+ "cumulativeGasUsed": "0xab3f",
+ "logs": [],
+ "depositNonce": "0x158a0ea"
+ }
+ }
+ }
+ }
+}
+```
+
+### Index 1-10 Response (Diff Only)
+
+Subsequent Flashblocks only include the `diff` (no `base` object):
+
+Example:
+```json
+{
+ "payload_id": "0x03997352d799c31a",
+ "index": 4,
+ "diff": {
+ "state_root": "0x7a8f45038665072f382730e689f4a1561835c9987fca8942fa95872fb9367eaa",
+ "block_hash": "0x9b32f7a14cbd1efc8c2c5cad5eb718ec9e0c5da92c3ba7080f8d4c49d660c332",
+ "gas_used": "0x1234f",
+ "transactions": [
+ "0x02f90133...",
+ "0x02f90196..."
+ ],
+ "withdrawals": []
+ },
+ "metadata": {
+ "block_number": 22585577,
+ "new_account_balances": {
+ "0x000f3df6d732807ef1319fb7b8bb8522d0beac02": "0x0",
+ "0x4200000000000000000000000000000000000015": "0x1234"
+ },
+ "receipts": {
+ "0x7c69632dc315f13a...": {
+ "Eip1559": {
+ "status": "0x1",
+ "cumulativeGasUsed": "0x1234f",
+ "logs": []
+ }
+ }
+ }
+ }
+}
+```
+
+---
+
+## Further Resources
+
+- [How To Build a Base Flashblocks Listener](https://docs.getblock.io/guides/how-to-build-a-base-flashblocks-listener) — Step-by-step Go tutorial
+- [Flashblocks Overview](/base-chain/flashblocks/overview) — Key concepts and transaction lifecycle
+- [App Integration](/base-chain/flashblocks/apps) — RPC examples and library integrations
+- [Reth node README](https://github.com/base/node/tree/main/reth#readme) — Hardware requirements and configuration
+- [Flashblocks Deep Dive](https://blog.base.dev/flashblocks-deep-dive) — Engineering blog with implementation details
diff --git a/docs/base-chain/network-information/block-building.mdx b/docs/base-chain/network-information/block-building.mdx
index 99ec7866b..12eb9d12f 100644
--- a/docs/base-chain/network-information/block-building.mdx
+++ b/docs/base-chain/network-information/block-building.mdx
@@ -21,24 +21,36 @@ See the [Configuration Changelog](/base-chain/network-information/configuration-
## Configurations
### Flashblocks
-Currently, blocks are built using [op-rbuilder](https://github.com/flashbots/op-rbuilder) and priority fee auctions occur
-every 200ms. There are two changes from the vanilla ordering to be aware of:
-#### Timing
+Blocks are built using [op-rbuilder](https://github.com/flashbots/op-rbuilder) with priority fee auctions occurring every **200ms**. This reduces effective block times from 2 seconds to 200 milliseconds through preconfirmations.
-Flashblocks are built every 200ms, each ordering a portion of the block. Unlike the current system where later-arriving transactions with higher priority fees can be placed at the top of the block, Flashblocks creates a time-based constraint. Once a Flashblock is built and broadcast, its transaction ordering is locked even if a transaction with a higher priority fee arrives later, it cannot be included in earlier, already built Flashblocks.
+
+For a comprehensive technical deep dive into Flashblocks architecture, see the [Flashblocks Overview](/base-chain/flashblocks/overview).
+
-#### High Gas Limits
+*There are three key differences from vanilla ordering:*
-If your app creates transactions with large gas limits, we recommend monitoring to detect any changes in inclusion latency. Transactions with gas limits over 1/10 of the current block gas limit (currently 14 million gas), face additional constraints:
+1. **Timing** — Flashblocks are built every 200ms, each ordering a portion of the block. Once built and broadcast, transaction ordering is locked. Later-arriving transactions with higher priority fees cannot be included in earlier Flashblocks.
-* Each Flashblock can only use a portion of the block's total gas limit
-* Flashblock 1: up to 1/10 of the total gas
-* Flashblock 2: up to 2/10 of the total gas
+2. **Gas Allocation** — Each Flashblock has an incrementally increasing gas budget. Flashblock 1 can use 1/10 of the block gas limit, Flashblock 2 can use 2/10, and so on until Flashblock 10 has access to the full limit.
-And so on for subsequent Flashblocks
+ | Flashblock | Available Gas |
+ |------------|---------------|
+ | 1 | ~14M gas (1/10) |
+ | 2 | ~28M gas (2/10) |
+ | 3 | ~42M gas (3/10) |
+ | ... | ... |
+ | 10 | ~140M gas (full) |
-Consequently, transactions with large gas requirements must wait for later Flashblocks with sufficient gas capacity. For example, a transaction exceeding 1/10 of the block's gas limit cannot be included in Flashblock 1 and must wait for Flashblock 2 or later.
+
+ Transactions exceeding 14M gas cannot fit in Flashblock 1 and must wait for later Flashblocks. Monitor inclusion latency if your app creates large transactions.
+
+
+3. **Dynamic Mempool** — The builder continuously accepts new transactions while building each Flashblock. This minimizes inclusion latency but means transactions are ordered by fee *at the time of selection*, not globally across all transactions that arrive during the 200ms window. A late-arriving high-fee transaction may appear after an already-committed lower-fee transaction.
+
+
+ This is a deliberate tradeoff: faster inclusion at the cost of occasionally "breaking" expected priority gas auction (PGA) ordering within a Flashblock. See the [Flashblocks FAQ](/base-chain/flashblocks/faq) for more details.
+
### Per-Transaction Gas Maximum
diff --git a/docs/base-chain/node-operators/run-a-base-node.mdx b/docs/base-chain/node-operators/run-a-base-node.mdx
index 8cb92e696..4d26727dd 100644
--- a/docs/base-chain/node-operators/run-a-base-node.mdx
+++ b/docs/base-chain/node-operators/run-a-base-node.mdx
@@ -1,5 +1,5 @@
---
-title: 'Getting Started'
+title: Run a Node
description: A tutorial that teaches how to set up and run a Base Node.
---
@@ -10,6 +10,7 @@ This tutorial will walk you through setting up your own [Base Node](https://gith
By the end of this tutorial you should be able to:
- Deploy and sync a Base node
+- Enable Flashblocks for 200ms preconfirmations
## Prerequisites
@@ -100,3 +101,70 @@ echo Latest synced block behind by: $((($(date +%s)-$( \
```
You'll also know that the sync hasn't completed if you get `Error: nonce has already been used` if you try to deploy using your node.
+
+---
+
+## Enable Flashblocks
+
+Once your node is synced, you can enable Flashblocks to serve 200ms preconfirmations to your applications.
+
+### Configuration
+
+To enable Flashblocks, start your node with the following environment variables:
+
+```sh
+NODE_TYPE=base CLIENT=reth RETH_FB_WEBSOCKET_URL="wss://mainnet.flashblocks.base.org/ws" docker-compose up
+```
+
+| Variable | Description | Values |
+|----------|-------------|--------|
+| `NODE_TYPE` | Enables base reth node with Flashblocks | `base` |
+| `CLIENT` | Execution client | `reth` |
+| `RETH_FB_WEBSOCKET_URL` | Flashblocks WebSocket endpoint | See below |
+
+### WebSocket Endpoints
+
+| Network | URL |
+|---------|-----|
+| Mainnet | `wss://mainnet.flashblocks.base.org/ws` |
+| Sepolia | `wss://sepolia.flashblocks.base.org/ws` |
+
+
+**These WebSocket endpoints are for node infrastructure only.** Applications should not connect directly to `wss://mainnet.flashblocks.base.org/ws`. Instead, apps should query your RPC node for Flashblocks data. See the [App Integration guide](/base-chain/flashblocks/apps) for details.
+
+
+
+The [base](https://github.com/base/base) binary listens to the Flashblocks WebSocket stream and caches preconfirmation data. When Flashblocks-aware RPC methods are called, it returns data from this cache.
+
+
+### Verify Flashblocks Functionality
+
+Test that your node is properly serving Flashblocks by querying a pending block:
+
+```sh
+curl -X POST \
+ --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["pending", false],"id":1}' \
+ http://localhost:8545
+```
+
+A successful response will include block data from the latest Flashblock. If Flashblocks are temporarily unavailable, the node falls back to returning the latest finalized block.
+
+### Available RPC Methods
+
+Your Flashblocks-aware node supports all standard Ethereum JSON-RPC methods, plus these Flashblocks-enabled endpoints:
+
+| Method | Flashblocks Usage |
+|--------|------------------|
+| [`eth_getBlockByNumber`](/base-chain/flashblocks/apps#eth_getblockbynumber) | Use `pending` tag |
+| [`eth_getBalance`](/base-chain/flashblocks/apps#eth_getbalance) | Use `pending` tag |
+| [`eth_getTransactionReceipt`](/base-chain/flashblocks/apps#eth_gettransactionreceipt) | Returns preconfirmed receipts |
+| [`eth_getTransactionByHash`](/base-chain/flashblocks/apps#eth_gettransactionbyhash) | Use `pending` tag |
+| [`eth_getTransactionCount`](/base-chain/flashblocks/apps#eth_gettransactioncount) | Use `pending` tag |
+| [`eth_call`](/base-chain/flashblocks/apps#eth_call) | Use `pending` tag |
+| [`eth_simulateV1`](/base-chain/flashblocks/apps#eth_simulatev1) | Use `pending` tag |
+| [`eth_estimateGas`](/base-chain/flashblocks/apps#eth_estimategas) | Use `pending` tag |
+| [`eth_getLogs`](/base-chain/flashblocks/apps#eth_getlogs) | Use `pending` for `toBlock` |
+| [`eth_subscribe`](/base-chain/flashblocks/apps#eth_subscribe-beta) | Stream Flashblock data in real-time (Beta) |
+| [`base_transactionStatus`](/base-chain/flashblocks/apps#base_transactionstatus-beta) | Check if transaction is in mempool (Beta) |
+
+For code examples, see the [App Integration guide](/base-chain/flashblocks/apps#rpc-api).
diff --git a/docs/docs.json b/docs/docs.json
index 8f8998bd9..65cc21400 100644
--- a/docs/docs.json
+++ b/docs/docs.json
@@ -105,8 +105,10 @@
"group": "Flashblocks",
"pages": [
"base-chain/flashblocks/apps",
- "base-chain/flashblocks/node-providers",
- "base-chain/flashblocks/docs"
+ "base-chain/flashblocks/overview",
+ "base-chain/flashblocks/faq",
+ "base-chain/flashblocks/architecture",
+ "base-chain/flashblocks/websocket-reference"
]
},
{
@@ -1014,7 +1016,8 @@
"cookbook/defi-your-app",
"cookbook/go-gasless",
"cookbook/base-app-coins",
- "cookbook/testing-onchain-apps"
+ "cookbook/testing-onchain-apps",
+ "cookbook/deploy-openclaw-on-aws"
]
},
{