November 10, 2025

From Fair Ordering to Fair Inclusion

We've reached a new frontier in scaling Ethereum. The OP Stack ecosystem now powers more than 60% of all Ethereum Layer 2 transactions, with a growing share leveraging Flashbots' Rollup-Boost stack.

Previously, every block contained a hidden struggle for order: who gets in first, who gets left out, and who captures the value in between. Flashbots addressed this with the Rollup-Boost stack, leveraging Proposer-Builder Separation (PBS) and Trusted Execution Environments (TEEs) to make the auction verifiably fair — transactions are ordered by priority fee, not sequencer discretion.

But fairness guarantee ends at the TEE's boundary. The builder decides which bids enter, and the TEE can only fairly order what it receives.

The issue isn’t a bug in the builder; it’s an architectural limitation. The builder’s mempool still lives outside the TEE, running on a trusted node that remains vulnerable to manipulation. A malicious bidder can bribe or collude with the sequencer to censor competing bids, creating an incentive for selective inclusion.

An untrusted mempool means an untrusted auction. As we outlined in "Real-Time Auctions Are Eating Up Blockchains," the ability to censor bids is equivalent to compromising the auction's integrity itself. The system must verify that it included every valid bid; otherwise, no amount of cryptographically guaranteed ordering matters.

pod is proposing an upgrade to the existing rollup-boost stack that enables verifiable inclusion.

pod's architecture makes it uniquely suited to serve as a programmable, verifiable mempool. It's built on a leaderless architecture, removing the single sequencer that represents the central point of censorship. When you send a transaction, it doesn't wait for a leader; instead, it is directly posted to validators that independently process it in parallel, achieving responsive sub-second finality (typically under 150 ms) and producing a cryptographic certificate of inclusion.

The TEE no longer listens directly to the network. Instead, it subscribes to pod for attestations on bids and the finalization of the auction. Once it verifies sufficient attestation on that closure, it knows the local set of bids is complete and can safely execute its ordering logic. That assurance comes from pod’s past-perfection certificate, a cryptographic proof that the inclusion window has closed and the bid set is complete, giving the TEE a verifiable point of finality before it builds the block.

pod guarantees censorship-resistant inclusion. The TEE guarantees verifiable ordering. Together, they complete the vision: an end-to-end, trustless priority auction.

Implementation Overview

Our v0 implementation demonstrates the architecture in action and lays the groundwork for what comes next. Instead of running the standard op-rbuilder, you run a modified version, which is configured to use pod as its mempool. That's it. Your TEE, core sorting logic, and sequencer remain unchanged.

Step 1: The auction contract.

import {requireTimeBefore, Time} from "pod-sdk/Time.sol";

contract Auction {
    using Time for Time.Timestamp;

    event BidSubmitted(
        uint256 indexed auction_id, address indexed bidder, Time.Timestamp indexed deadline, uint256 value, bytes data
    );

    /**
     * @notice deadline in microseconds
     */
    function submitBid(uint256 auction_id, Time.Timestamp deadline, uint256 value, bytes calldata data) public {
        requireTimeBefore(deadline, "Auction deadline passed");

        emit BidSubmitted(auction_id, msg.sender, deadline, value, data);
    }
}

A Solidity contract on pod acts as the auction's smart inbox. Its sole job is to accept bids via submitBid(). This smart contract creates a verifiable, programmatic entry point for bids. There’s no explicit auction initiation; anyone submitting a bid with the same auction ID and deadline automatically participates in the same auction.

Step 2: Wait for finality.

auction
    .auction
    .provider()
    .wait_for_auction_end(auction_deadline)
    .await
    .context("waiting for auction end (past perfect time)")?;

When the sequencer requests a block, the builder first calls wait_past_perfect_time(auction_deadline). This is a blocking call that only returns once the pod network has cryptographically guaranteed that no new bids can be confirmed for the given auction.

Step 3: The new mempool.

let bids = auction
	.fetch_bids_for_deadline(auction_deadline.into())
	// .fetch_bids(U256::from(auction_deadline )) // auction ID is in microseconds
	.await
	.unwrap_or_else(|err| {
	    tracing::error!(target: "payload_builder", ?err, "failed to fetch bids from pod");
	    Vec::new()
	});

As soon as finality is achieved, the builder makes a single RPC call to the auction contract to fetch the complete set of bids. In future versions, this process can become fully streaming; the builder will subscribe to the contract’s event log to receive bids as they arrive, eliminating the need for a bulk fetch at the end of the auction.

Step 4: Building the block.

The builder now has a complete, verifiable, and censorship-resistant set of bids to pass to the TEE for fair sorting and block construction.

You can run the full demo and see for yourself with just a few commands.

Clone the example from GitHub: optimism-tx-auction

Experiencing it firsthand is the best way to appreciate how seamlessly the pieces work together.

The trustless auction is here—and we’re ready to help you put it to work. Whether you’re building a new rollup, refining your builder pipeline, or pushing the limits of MEV research, we’ll help you integrate, test, and scale the next generation of trustless L2s.

‍

Aaron Bassett