preferred on
Points of Focus
- External builders assemble most Ethereum blocks before validators propose them.
- Programmable blocks can add intra-block credit, state-aware computation, and deterministic placement.
- Programmable blocks can give protocols and searchers deterministic transaction placement without requiring an Ethereum hard fork.
What happens before a block is proposed?
Most Ethereum blocks are built by someone other than the validator who proposes them. A builder assembles the transactions, sets their order, allocates block space, and submits the result.
For most of Ethereum’s history, that role was mechanical: collect transactions from the mempool, order them to maximize fee revenue, submit.
An out-of-protocol form of proposer-builder separation became widely used around the Merge in September 2022 through MEV-Boost rather than being implemented directly by the Ethereum protocol. It gave builders a distinct role; what it didn’t do was make that role programmable. The block was a container; the builder’s job was to fill it efficiently.
Programmable blocks change what can happen during the construction phase itself. Capital can be made available within the block through credit that borrows and settles in the same block, without external collateral, or pre-funded positions. Computation can run at build time using the block’s exact current state, before the block is proposed, rather than at execution time when that state is already shifting.
We can guarantee a protocol or searcher exactly where their transaction lands before the block is submitted. Today they face two bad options: overpay for position or bid less and hope. Guaranteed ordering removes the choice.
Each of these is a capability that doesn’t exist at the execution layer. They require the builder to function as an active participant in block construction rather than a passive assembler of transactions that have already been submitted.
The state of the current market
A handful of builders produced the substantial majority of Ethereum blocks, competing almost entirely on the same two variables: order flow access and latency. The fastest builder with the most direct connections to high-volume traders had a structural advantage that was difficult to close on those terms.
Block builders have the potential to evolve into a new execution layer for Ethereum, similar to how smart contracts expanded the network’s capabilities.
That framing is deliberate. Smart contracts didn’t replace the base layer; they added a new surface where logic could live. Programmable blocks do the same thing one phase earlier in the pipeline.
Why this doesn’t require a fork
The distinction that matters most is that this expansion arrives through builders operating within the existing PBS architecture. No Ethereum Improvement Proposal (EIP) is required, no hard fork, no validator coordination, no waiting for a governance process to conclude.
Ethereum’s protocol upgrade process is deliberately conservative, for good reasons. Changes at the consensus layer carry systemic risk, and the governance process reflects that.
The smart contracts analogy is instructive: The application layer moved faster than the protocol layer precisely because it could iterate independently. Builders can run features that change what Ethereum can do for market participants without touching what Ethereum does at the consensus layer. The development cycles are shorter, the risk profile is different, and iteration speed is closer to software than to protocol governance.
The honest limits
Programmable block features create new surface area alongside new capabilities. Intra-block credit introduces a new category of risk. If the borrowing logic fails to repay inside the block, the builder excludes the bundle entirely.
The failure mode is handled by the builder, not enforced at the protocol layer. That’s a different trust model from a smart contract guarantee, and it requires the builder to enforce repayment correctly every time.
State-aware computation at build time requires that the builder’s view of chain state is accurate and current; a corrupted state view fed to a builder can manipulate the output of that computation. These risks are real engineering problems, not theoretical ones, and they require the same rigor as any other category of financial infrastructure.
The broader claim should be held more loosely. Smart contracts expanding Ethereum’s capabilities is a historical fact. Whether programmable blocks represent a shift of the same order or a useful but more incremental development will be answered by what gets built on top of them.
The analogy is a design ambition, not a completed argument, to be clear.
What builds from here
The applications that benefit most from programmable blocks are the ones that currently can’t be built reliably on Ethereum because their requirements exceed what the execution layer guarantees: complex multi-step strategies that need capital across an entire block’s execution, protocols that depend on deterministic placement to function safely, market makers who need to know where their transactions will land before they commit to a quoted price.
These are not edge cases. They represent a significant share of what serious decentralized finance participants do, through workarounds that add cost and complexity because the base layer cannot give them the guarantee natively. Make the block programmable, and most of those workarounds stop being necessary.
Ethereum shipped with a layer where new logic could live, and the industry spent a decade finding the edges of it. The construction phase is the next such layer. It is already open, and it needs no permission to use.
The block was a container — it does not have to stay one.
Share
Most read articles
