How To Build a Base Flashblocks Listener
A step-by-step guide to subscribing to Base Flashblocks and building trading applications around ultra-fast blockchain data.
Traditional blockchain confirmations are slow. On Ethereum Layer 2 networks, such as Base, blocks are produced every 2 seconds. While this is already faster than Ethereum's ~12-second blocks, it's still an eternity for time-sensitive applications like trading bots, real-time games, or DeFi protocols where milliseconds matter.
Flashblocks break the limitation of traditional blocks by creating mini-blocks every 200 milliseconds, providing users with instant transaction status while still retaining cryptographic security.
In this guide, you'll learn what base flashblocks are, their importance, data structure and step-by-step instructions on how to build a base flashblocks listener.
What Are Base Flashblocks?
Flashblocks are sub-blocks (or "mini-blocks") streamed every 200 milliseconds — that's 10x faster than Base's standard 2-second block time. Developed in collaboration with Flashbots and launched on Base Mainnet in July 2025, Flashblocks provide preconfirmations: ultra-fast signals that arrive before the next full block is sealed.
Here's how it works:
Standard Base blocks: Created every 2 seconds, containing all transactions
Flashblocks: 10 sub-blocks per full block, streamed every 200ms
Each Flashblock contains ~10% of the transactions (by gas) of a regular block
A series of Flashblocks can be combined to recreate a full block
Think of it like texting vs. email. Traditional blocks are like writing an entire email, proofreading it, and hitting send. Flashblocks are like texting — you send each line instantly and keep going.
Importance of Flashblocks for Trading
For trading applications, Flashblocks unlock several critical advantages:
Near-instant transaction feedback: Know within 200ms if your transaction was included
Front-running prevention: Once a Flashblock is built and broadcast, its transaction ordering is locked. Later-arriving transactions with higher fees can't jump ahead
Real-time state updates: See balance changes, liquidity shifts, and price movements as they happen
CEX-like experience on DEXs: Trading feels instant, not sluggish
What You're Building
In this tutorial, you'll build a Go application that:
Connects to the Base Flashblocks WebSocket stream
Handles both plain JSON and Brotli-compressed messages
Parses Flashblock data structures (transactions, receipts, balance updates)
Displays real-time blockchain activity
This forms the foundation for building trading bots, monitoring tools, or any application that needs ultra-low-latency blockchain data.
Understanding the Flashblock Data Structure
Before diving into code, let's understand what data you'll receive. Each Flashblock message contains three main components:
1. The Root Structure
The Index field tells you which of the 10 Flashblocks within a full block you're receiving (0 through 9).
2. BlockDiff — The Block Changes
Key fields for trading applications:
Transactions: Array of raw transaction data included in this FlashblockStateRoot: Cryptographic proof of the blockchain state after these transactionsGasUsed: Total gas consumed by transactions in this Flashblock
3. Metadata — Balances and Receipts
This is where the trading gold is:
BlockNumber: The full block number this Flashblock belongs toNewAccountBalances: Map of addresses to their updated ETH balancesReceipts: Transaction receipts with execution results and event logs
4. Receipts — Transaction Results
Receipts come in two flavors: EIP-1559 (modern) and Legacy. The Logs array contains event emissions — crucial for detecting swaps, transfers, and other contract events.
Prerequisites
Before we begin, make sure you have:
Go 1.21+ installed (download here)
Basic understanding of WebSockets and blockchain concepts
A terminal/command line environment
Dependencies
This application uses two external packages:
Brotli decompression (Flashblocks are compressed)
Project Setup
Create a new directory for your project and initialize the Go module:
Install the required dependencies:
Your
go.modfile should look like this:
Building the Listener
Create
main.goand start with the package and imports:
This imports standard library packages for JSON handling, logging, and signal management, plus our two external dependencies.
Define WebSocket endpoints and the data structures described earlier:
Now define all the data structures:
The GetData() and GetType() helper methods on Receipt let us work with receipts without worrying about whether they're EIP-1559 or Legacy format.
Implement the main routine: flag parsing, selecting the endpoint, connecting via WebSocket, and setting up message processing and graceful shutdown.
This covers:
Flag parsing for
-networkWebSocket connection via gorilla/websocket
Signal handling for graceful shutdown
Message loop reading text or binary (Brotli) messages
Flashblock messages are typically Brotli-compressed. Decompress them with:
Unmarshal JSON into structs and print a readable summary.
Pretty-print the flashblock:
This output shows:
Flashblock index (0-9)
Block number and hash
Gas usage and roots
Transaction list (truncated hashes)
Balance update count
Receipt summaries
Running the Listener
1. Build and Run
Expected Output
When running, you'll see Flashblocks streaming in real-time:
You'll see new Flashblocks appear approximately every 200 milliseconds.
Shutting Down
Press Ctrl+C to stop the listener. It will send a proper WebSocket close message before exiting:
Extending for Trading Applications
Now that you have the basic listener working, here are some ways to extend it for trading:
1. Filter Transactions by Address
Monitor specific addresses (your wallet, a DEX router, etc.):
2. Detect Swap Events
Watch for Uniswap V2/V3 swap events by checking the first topic (event signature):
3. Track Balance Changes
Monitor when specific addresses receive or send ETH:
Important Considerations
Preconfirmation vs. Finality
Flashblocks provide preconfirmations, not final confirmations. While extremely reliable, there's a small chance (during rare reorgs) that a Flashblock's data might differ from the final block.
For critical transactions:
Use Flashblocks for fast UI feedback
Wait for full block confirmation for settlement
Rate Limits
The public endpoints (wss://mainnet.flashblocks.base.org/ws) are rate-limited. For production applications:
Use a node provider (GetBlock) with Flashblocks support
Consider running your own Flashblocks-aware node
Handling Disconnections
In production, add reconnection logic:
Complete Code
Here's the full main.go file:
Conclusion
You've built a real-time Base Flashblocks listener in Go that:
Connects to the Flashblocks WebSocket stream
Handles Brotli-compressed messages
Parses and displays transaction data, receipts, and balance updates
Resources
Last updated
Was this helpful?