Achieve instant rollup communication without compromising security. XGA v4 introduces parallel block auctions for zero-latency cross-chain transactions.
The first in a three-part series detailing eXtensible Gas Auctions (XGA) v4
Block builders (nee builders) have primarily acted as basic transaction processors, selecting the highest-paying transactions from a public pool (the mempool) to construct blocks. Their value proposition was straightforward: access to limited blockspace, often leading to a dynamic where builders could extract value simply by controlling this access by winning the MEV Priority Auction (‘Flashbots Auction’).
Post-merge Ethereum implemented Proposer-Builder Separation (PBS), separating the roles of block construction and block validation. This separation led to the development of complex MEV supply chains involving searchers, builders, and relays. In this model, searchers identify profitable transaction bundles and send them to builders, who aggregate bundles and public mempool transactions into full blocks. These builders then submit their blocks to MEV relays, which act as intermediaries, forwarding the highest-value block to the proposing validator for inclusion. Validators are incentivized to connect to relays and propose blocks via MEV-Boost because these blocks typically offer higher value, capturing a significant portion of the MEV and priority fees.
The Current Block Building Abstraction
MEV relays, conducts "full-block auctions". In this model, builders bid for the validator's entire block space, and there is a one-to-one mapping between a builder and the block they submit.
This current regime relies on builders capable of extracting high-value "top-of-block" (ToB) MEV opportunities, such as CEX-DEX arbitrages, possess a significant advantage. Integrated searcher-builders—firms that combine searching and building capabilities—are particularly adept at capturing these lucrative ToB opportunities through methods like maintaining private order flows and accessing specialized exchange feeds. This allows them to construct blocks with higher potential value, enabling them to consistently outbid other builders in full-block auctions. This information asymmetry is what leads to market concentration in the building space. Additionally, it leads to reduced Validator profits, which ultiatemly reduce the security budget of th entire network. The dominance of these integrated entities has been a major factor contributing to centralization and reduced competitiveness within the builder market. The top 2 builders account for nearly 85% of market share.
XGA is an out-of-protocol relay design that directly addresses the centralization issue by splitting the block auction. Instead of auctioning the entire block as a single unit, we propose to separate auctions for the Top-of-Block (ToB) and the Rest-of-Block (RoB). This "parallel block auction" approach enables bypassing the centralized builder to access blockspace. The auction construction uses a special variant of a Second Price Auction in the style of a Forward Contract Call Market.
The Parallel Auction is an auction for ‘Future’ blockspace: it does not run concurrent with the existing Flashbots auction, rather the auction settlement occurs with the Flashbots Auction.
2 of just 8 more proposed auction designs Link
Why should I care about these Block Auction proposals?
Ethereum’s Auction market is largely invisible to the casual observer, yet this will ultimately prove more consequential than any market fluctuation or regulatory crackdown. Since Ethereum's implementation of Proposer-Builder Separation, an oligopoly has emerged. Integrated firms that both search for profitable transaction opportunities and construct blocks now dominate the auction process through privileged access to exchange data and private transaction flows.
Any ‘On Chain’ Solution such as PEPC or ePBS are bypassable: by trusting that the relay enforces proposer commitments communicated by the proposer to the relay off-chain. Any real solution must have some off chain component.
Whats better than 1 Auction?
XGA introduces several innovative auction approaches:
Elastic Supply Scheduling : Instead of a fixed supply, the amount of available blockspace varies with price. When prices are low, less blockspace is offered, creating a concave supply curve to prevent severe underpricing.1
Forward Contract Market : Enables purchase of future blockspace (2 epochs ahead), creating a forward contract market for blockspace.
Modified Uniform Price Auction : Addresses "winner's curse" issues in traditional uniform price auctions through alternative tie-breaking rules that exert more pressure at the margin.
Bidding Fee charged only at execution : Participation and Bidding Mechanics
Market participants only pay for their bid if they execute their contract, off chain, replicating the existing Flashbots Auction structure.
The XGA auction addresses “contention”. State contention occurs when multiple participants try to access the state simultaneously. Ethereum cannot handle concurrent access directly, so transactions must be linearized or put in a specific order. For a contentious state, changing the order in which transactions are processed changes the outcome. This means the final state can be completely different depending on the sequence of transactions**.**
Builders Mediation: They decide the order in which state access occurs**.** Since the order determines the outcome deterministically, they effectively decide outcomes by choosing which transactions to include and in what order. This allows Builders to select outcomes from a set of possibilities.
Distinction by Transaction Type: The impact differs depending on the type of transaction, Order-Invariant Transactions (Priority Insensitive) and Contentious Transactions (Priority Sensitive).
As a result of the XGA Auction focusing on Order Invariant Transactions, it enables a distinct kind of rollup model: Gloated rollups.
Skymiles, the original shit coin
These transactions enable a specific design for a subset of collating in advanced builders, primarily manage concurrent access through linearization and strict ordering based on their ability to simulate outcomes**.... Rollup sequencers manage dependencies on the host chain state to preserve their own simulation capabilities, primarily through time lagging their references to older, stable blocks in run-ahead designs, or accepting a one-block delay in based designs, with a special case for zero-block communication when referencing predictable, order-invariant actions included atomically on the host chain.**
To avoid the unpredictable nature of the most recent Ethereum state and the risk of reorgs invalidating the rollup state, run-ahead sequencers cannot reference the current state of the Ethereum host chain. Instead, they implement a delayed reference by referencing older, well-justified Ethereum blocks that are considered stable and highly unlikely to be reordered.
Optimism waits 3 to 4 minutes before referencing an Ethereum block.
Arbitrum waits for justification, which is closer to tens of minutes.
This deliberate delay ensures that the sequencer has perfect knowledge that the state of Ethereum referenced by the rollup will not change, thereby preserving the crucial ability to simulate and provide reliable pre-confirmations**. T** heir entire fast pre-confirmation system relies on this time-lagging of host references to maintain simulation capability.
In contrast, Based Rollups can reference the current Ethereum state, but this still results in a one-block delay when referencing the full host state: since the builder doesn't know the state of Ethereum after the current block completes while its constructing the rollup block that is linked to it2.
This is benefit in the forward contract design: the transactions submitted are for inclusion in future blocks, not the current block. This enables partial state simultion. This can not be achieved under any other mechanism3.
Pre-confirmations in Rollups:
Require delayed communication to reference stable past states
Need perfect sequencer knowledge for reliable simulation
Typically delay host state references by minutes to ensure stability
Incompatibility Issue:
Reliable pre-confirmations require referencing past stable states
Same-block communication requires current state reference
Either a rollup block is simulated exactly right and accepted by Ethereum, or it isn’t—there’s no “pretty close.” Consider three concrete, independent alternatives a builder might face:
Submit a run-ahead block that references only an Ethereum header from four minutes ago (Optimism-style).
Submit a based-rollup block that reads the currentEthereum state but accepts a one-block delay before anyone can interact with it.
Submit an atomic based-rollup block that piggy-backs on a same-block, order-invariant host-chain action (e.g., an ERC-20 transfer) so there’s zero delay.
Because the outcome for each option is discrete—valid or invalid —the builder must be right almost every time for the strategy to pay off. A near miss (one mis-ordered Uniswap swap, one host-state read that changes in the next block) still bricks the entire rollup block and forfeits its MEV. In statistical terms we’re still staring at a probability distribution, but unless one path carries an overwhelming share of that probability mass, the builder will end up wrong more often than right even with a perfectly calibrated model. The fatter the tail on “block accepted,” the lower the operational risk.
Hence this is why run-ahead sequencers deliberately look only at well-justified Ethereum blocks—information so stable it’s practically a “sure thing.” The only way to minimize the percentage of incorrect decisions is to predict outcomes that have very little uncertainty associated with them.
Transactions that use a forward contract for guaranteeing settlement by virtue have little uncertainity associatd with them.4 In fact we can observe if the transaction has been broadcasted elseware to further enhance the order invariance.
📍 In our next post we introduce an algorithmic approach for the effective tracking of asynchronous computational progress across different host states by mapping records to reference frame coordinates. This is implemented in the mempool as a way of progress-detection to supervise computation across differeitanted operations.
There will be no airdrop to subscribers
Elasticity in supply creates stronger incentives for bidders to reveal their true valuations, counteracting the underbidding problem identified by Wilson
While based rollups can achieve zero-block latency by specifically referencing only order-invariant actions on the host chain (whose outcome the builder can predict even if the full state isn't known), the general practice in run-ahead designs is to introduce delay to ensure overall state predictability for simulation.
When the rollup block is submitted atomically with order-invariant actions (the resulting output of the transactions), the rollup state transition function can reference the output state of those actions and remain simulatable even though the the entire host state is unknown.
We assume a well formed, valid, and nonconcentious submitted transaction.
Nothing in this post constitutes financial advice or a solicitation to invest.