Include blog post + modify gas limit

docs/base-chain/flashblocks/apps.mdx

@@ -8,6 +8,8 @@ description: Experience lightning-fast transaction confirmations of Base by usin
 
 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.
 
+To learn more about Flashblock block building, see the [Block Building](/base-chain/network-information/block-building) section, or read our [Flashblocks deep dive](https://blog.base.dev/flashblocks-deep-dive) blog post.
+
 ## Integrating Flashblocks
 
 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.

docs/base-chain/network-information/block-building.mdx

@@ -24,13 +24,15 @@ See the [Configuration Changelog](/base-chain/network-information/configuration-
 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
+##### **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
+![Flashblocks Timing Diagram](/images/flashblocks/flashblocks-timing-diagram.avif)
 
-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:
+##### **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 (block gas limit currently at 187.5 million as of Jan 21, 2026), face additional constraints:
 
 * Each Flashblock can only use a portion of the block's total gas limit
 * Flashblock 1: up to 1/10 of the total gas
@@ -47,9 +49,3 @@ Base enforces a per-transaction gas maximum of **25,000,000 gas**. Transactions
 Fusaka's [EIP 7825](https://eips.ethereum.org/EIPS/eip-7825) **will** change the block validity conditions and enforce a lower per-transaction gas maximum of 16,777,216 gas (2^24). We expect this protocol change to be adopted in all OP Stack chains around January 2026.
 
 Bundler operators for smart contract wallets must configure their systems to limit the bundle size to fit within this cap.
-
-### Vanilla
-
-Blocks are built every 2s by [op-geth](https://github.com/ethereum-optimism/op-geth). Transactions within those blocks are ordered by
-priority fee, see the ([code](https://github.com/ethereum-optimism/op-geth/blob/optimism/miner/worker.go#L627)).
-