| The WhitePaper Reading Club - DevConnect - Nov 16th 2025 | |
|---|---|
| Berachain: Pre Confirmation | Rez (Berachain), Rongxin (WPRC) |
Summary
Berachain pre-confirmations enable an order of magnitude transaction latency reduction for end users.
Why This Is Important
In traditional Web2 applications, users have normalized web pages loading in milliseconds, with hyper responsive interfaces. In Web3, users are forced to reset expectations as transaction latency is bounded by block times of 2 seconds or more. Such latency imposes limits on the class of applications that can exist on a blockchain. Existing pre-confirmation proposals have failed to realize their full potential due to a lack of vertical integration across the entirety of the core protocol, forcing subpar solutions. On Berachain, owning the full stack allows for a best in class solution, achieving latency reductions that will enable a new class of applications to bridge the gap between the innovators and the majority.
Key Innovation
Our key innovations include (i) Beacon-Kit, a custom consensus client leveraging proposer lookaheads to optimistically trigger payload building and (ii) Bera-Reth, a high performance customized execution client built on the Reth SDK. Leveraging the interactions between these components allows us to reduce the receipt latency for end users.
Overview
Berachain leverages a pipelined architecture where a designated sequencer creates and distributes partial blocks at regular intervals within the standard 2-second block window, providing transaction confirmations before full consensus finality. These partial block confirmations are propagated to nodes across the network and served through the RPC, utilizing existing APIs for wallet compatibility. When validators opt in to the preconfirmation network on Berachain, the sequencer will build blocks for their slot, which the validator can then propose for consensus. Users who would rather wait for consensus finality retain optionality to do so. The pre-confirmation system gracefully degrades to standard block production if any component fails, ensuring liveness is never compromised.
Background
Berachain operates as a Layer 1 Blockchain that combines the Ethereum Virtual Machine (EVM) with CometBFT consensus to achieve instant single-block finality. Berachain’s modular architecture leverages the Engine API standard to manage communication between the Beacon-Kit consensus client and the bera-reth/bera-geth execution clients. The network currently operates with 60+ distributed validators who can enter the network permissionlessly by staking BERA.
Team
Rez Bera (Software Engineer): Berachain / Immutable / Redbelly Network. Cal Bera (Software Engineer): Berachain / Coinbase
Components
(Key Innovations - focus on the innovations, and key parts)
| Sequencer | An extension of the RPC node running Bera-Reth. When enabled, it listens to Beacon-Kit, the consensus client, for forkchoiceUpdated events that lets the sequencer know details like the: canonical chain head and identity of the next validator. This lets the sequencer check if the next validator is part of the the pre-confirmation whitelist, and whether to start building a “pre-confirmation” block.When a whitelisted validator is detected, the sequencer immediately begins its 200 millisecond cycle of building partial blocks: the sequencer selects TXs from its local mempool, executes and orders them in-memory, then seals and signs the resulting payload. These signed partial blocks are streamed to validators. The validator then re-executes it locally to verify correctness. If valid, it responds with a signature or acknowledgement committing to include the pre-confirmed transactions in its next proposed block. The sequencer continues this 200 ms pipelined loop until the validator calls engine_getPayload, at which point the final full block is assembled for consensus. Question:(i) How many “pre-confirmed partial blocks” can a sequencer purpose? (ii) Will Sequencer also need to provide a stake in the future? What happens if they start spamming validators with invalid TXs? (iii) Is Sequencers are temporary role or are they permanent? |
|---|---|
| Validator | Validators that wish to accept pre-confirmation blocks opt in to some sort of whitelist maintained by Beacon-Kit and the sequencer. Phase 1: only select validators are added to this list. Economics: Participation offers both benefits and trade-offs. Whitelisted validators can attract more transaction flow by offering sub-second confirmations and may earn extra priority fees from apps. However, they also face higher computational overhead, as they must re-execute partial blocks from the sequencer every 200 ms. Misbehavior—such as failing to honor pre-confirmed promises—could lead to reputational damage or potential slashing mechanisms in future iterations. Questions: (i) What are the machine requirements for pre-confirmation nodes? (ii) Are there current incentives for validators to accept pre-confirmation blocks over normal blocks? |
Impact on Players Over Time
| Sequencers | Possibly create a small but distinct “sequencer operator”, typically run alongside validator or RPC infrastructure. This depends on the operational complexity (cost of running a “mini” validator) and the revenue opportunities (“tx fee split”). Note: Like Flashbots’ mev-boost, pre-conf is out-of-protocol. If successful, these systems could be formalized into the protocol layer, e,g a “fast confirmation” tiers that coexist with traditional finalization. |
|---|---|
| Validators | If pre-confirmations increase computation or bandwidth requirements, the effective hardware floor for validators could rise. This may reduce validator diversity slightly, as smaller operators struggle to maintain consistent performance within 200-millisecond execution windows. But, as participation is optional, it will not affect consensus security, any centralization effects will likely be gradual, not structural. |
| DApps | Latency-sensitive applications (trading, gaming, real-time DeFi) are likely to integrate directly with pre-confirmation-enabled RPCs or operate their own infra for better control and UX. Others—such as custodial, settlement, or compliance-focused services—may continue using finalized-state RPCs for determinism and auditability. The ecosystem will likely evolve toward a mixed model, where both pre-confirmation and finalized endpoints coexist, each optimized for different user priorities. |
| Eth Ecosystem | Berachain’s approach fits into a broader trend seen across Ethereum’s research and L2 ecosystems: creating markets for execution guarantees. Like Ethereum’s mev-commit, Execution Tickets, and based preconfirmations, these mechanisms aim to make transaction inclusion, ordering, and timing programmable. Together, they shift blockchains from passive ordering systems toward active coordination layers between users, builders, and validators. Note:Also add more complexity. Ultimately, block production may become a professional job. |