# We’re making Base 10x faster with Flashblocks

> Bringing near-instant responsiveness to apps on Base Mainnet.

**Published by:** [Base Engineering Blog](https://blog.base.dev/)
**Published on:** 2025-05-15
**URL:** https://blog.base.dev/accelerating-base-with-flashblocks

## Content

People expect lightning-fast responses when interacting with apps, and a snappy user experience is key to enabling the global onchain economy. With Flashblocks, a technology built by Flashbots, Base chain will have 200-millisecond “preconfirmation blocks” making transactions feel instant. This will make Base 10x faster than it is today, slated to go live this Summer. If you're a builder, node operator, or wallet interested in integrating Flashblocks on Base, you can integrate them on Base Sepolia today in preparation for the full rollout on Base Mainnet. We recommend reading ahead to understand what is required to integrate Flashblocks and give your app’s users a 10x faster experience. Bringing Flashblocks to Base MainnetCurrently, Base creates a new block every 2 seconds. Flashblocks are sub-blocks issued by the block builder and streamed to nodes every 200ms, allowing for early confirmation times.Each Flashblock contains ~10% of the transactions (by gas) of a regular block, and a series of Flashblocks can be combined to recreate a full block. They are an optional addition for nodes and applications that want to have a faster UX. Without making any changes, nodes and applications will continue to function the same way they do today. Since enabling Flashblocks on Base Sepolia, we’ve seen up to 10x reduction in transaction inclusion times (see appendix below) from users around the world. To experience the speed firsthand, see Flashblocks live on testnet in our demo and try some of the apps that other builders have built. Comparison of tx inclusion times with and without FlashblocksHow apps, wallets, and indexers can integrate FlashblocksIntegrating FlashblocksAt a high level, there are two ways you can integrate Flashblocks:Recommended: Use an RPC provider that supports Flashblocks.Subscribe to Flashblocks from the websocket.We strongly recommend that you use an RPC provider instead of subscribing to the websocket as it’ll support the libraries you're familiar with today and supports graceful fallback in the event of a Flashblock outage. You can find detailed information on how to integrate Flashblocks into your application, RPC endpoint support and which libraries support Flashblocks in our docs. Transaction OrderingFlashblocks will change transaction ordering within blocks in two key ways: Timing 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. High Gas Limits 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:Each Flashblock can only use a portion of the block's total gas limitFlashblock 1: up to 1/10 of the total gasFlashblock 2: up to 2/10 of the total gasAnd so on for subsequent FlashblocksConsequently, 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. Understanding reverts, reorgs and reliabilityReorgs When the Flashblocks stream differs from the final block, there has been a reorg. This will result in some RPC responses returning data that could be different from the final block. In our initial release, this may happen. Although we expect it to be very infrequent, your application needs to be able to handle them. We plan to reduce how often these reorgs occur in future updates. Revert Protection In our initial release, revert protection will not be enabled. Transactions will continue to revert on Base as they do today. We plan to investigate enabling revert protection in future updates as part of our ongoing development roadmap. Reliability If there is a Flashblocks outage the chain will continue to progress, but fallback to the standard two second block times. During an outage:RPC calls and sending transactions will continue to work, with slower transaction inclusionThe websocket endpoint will not return any data Outages are expected to be infrequent - our SLA for Flashblocks uptime is 99.9%.Node Operator IntegrationsFlashblocks are an optional feature for your nodes. When not activated, your nodes will function exactly as they do today. Activating Flashblocks makes two changes to the execution client:They connect to the Flashblocks data streamFlashblock information will be used to modify the responses of some ETH RPC endpointsEnabling FlashblocksYou'll need to run our Base Reth binary with integrated Flashblocks support. If you're interested in seeing Flashblocks compatibility with other execution clients, please submit an issue on the base/node repository, and we'll explore expanding support. For full configuration instructions and setup guidance, refer to our documentation.Receiving FlashblocksAs Flashblocks are built, they’re broadcast immediately by the sequencer over a websocket. Our websocket endpoints are publicly available but rate limited. If you operate a large number of nodes please reach out and we can provide you with an authenticated endpoint which will have minimal rate limiting.RPC ModificationsReceiving a Flashblock, causes the nodes to update their internal in-memory state of the pending block, which is used to modify the responses to some ETH RPC’s. If you have a caching or routing layer in front of your nodes, you may need to modify the behaviour for certain RPC endpoints. A full list of endpoints can be found here.ReliabilityIf there’s an outage of any part of the Flashblocks infrastructure nodes will continue to work as they do today with two second block times and blocks being distributed over the P2P network. Our SLA for Flashblocks uptime is 99.9%. We’ve designed our infrastructure and node integration to gracefully handle Flashblock outages and fallback to the current situation of two second blocktimes.Staying in the LoopWe’re really excited to see what you build with Flashblocks. We recommend following @base and subscribing to this blog to receive the latest updates on Flashblocks. For questions or support, please reach out to us on Discord or @BuildOnBase.AppendixWe’re measuring transaction inclusion time as, the total time it takes to:Send a transaction to BaseInclude the transaction in a block Share the block to other nodes on the networkUser fetch a receipt of inclusionYou can reproduce our results using the transaction latency tester. By making a handful of internal infrastructure improvements, we believe we can further reduce the transaction inclusion latency by another 80-120ms.

## Publication Information

- [Base Engineering Blog](https://blog.base.dev/): Publication homepage
- [All Posts](https://blog.base.dev/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@base-engineering-blog): Subscribe to updates
- [Twitter](https://twitter.com/base): Follow on Twitter

## Optional

- [Collect as NFT](https://blog.base.dev/accelerating-base-with-flashblocks): Support the author by collecting this post
- [View Collectors](https://blog.base.dev/accelerating-base-with-flashblocks/collectors): See who has collected this post