x/builder: The first Sovereign MEV module for protocol-owned building

[hxrts]

Authors: @hxrts @barry @terpayyo @aleksbez

Introduction

In our last post we introduced the Sovereign MEV Toolkit, which extends the design philosophy of application sovereignty into blockspace markets and the MEV supply chain. Now we want to share some details about how Skip plans to deliver this new MEV paradigm to Cosmos. This post starts with a brief explainer on ABCI vs ABCI++, then introduces the new module we’re building to help chains capture and control MEV: x/builder. The first version of this protocol-owned builder (POB) will be available for any Cosmos chain to adopt within 1-2 months, giving chains a number of powerful new capabilities:

• Manipulation-resistant blockspace auctions
• On-chain orderflow auctions
• Transaction simulation markets
• Consensus-enforced fee markets

ABCI++ provides the building blocks for protocol-owned building and auction multiplicity

This is an exciting time to be a Cosmos app chain developer because ABCI++ provides many of the necessary primitives for implementing blockspace markets natively., which is extremely based.

As very basic background, the full node of a Cosmos chain consists of two components:

1. CometBFT (previously Tendermint): Provides a mempool, which gathers unconfirmed transactions, and the consensus algorithm, which collects transactions into blocks, shares blocks with other nodes, verifies them, and adds them to the chain. Today chain developers mostly treat this as a black box providing application input. CometBFT acts as the client.
2. Cosmos SDK application: Provides a key-value store representing the state of the chain and transaction handlers representing state transition functions, which take transactions as input. This is primarily where Cosmos devs do their magic, defining the unique functionality of their chain. The Cosmos SDK application acts as the server.

These communicate with each other over the ABCI (Application BlockChain Interface).

ABCI applications today:

With the legacy ABCI, the application is an oblivious consumer of CometBFT blocks. For each block CometBFT will pack transactions into a block proposal, and the network comes to consensus on the proposal with effectively no help from the application, apart from some minimal sanity checks. The transactions are then delivered to the application one at a time, where they update state according to the application’s transaction handler rules.

This means the application has virtually no part in block building; it simply takes blocks as a given. Devs who want more control over application ordering and inclusion have their hands tied.

ABCI applications in the Future:

ABCI++, an evolution of ABCI, opens an exciting new design space for application developers: programmable consensus. Rather than CometBFT unilaterally producing blocks and the application blindly consuming them, the application can become very opinionated about the content of blocks. Here are a few examples:

1. In “PrepareProposal” a CometBFT proposer asks the application what transactions it should include in the block proposal and in what order, satisfying arbitrary rules over transaction ordering or state.
2. When receiving the proposer’s block proposal in “ProcessProposal,” CometBFT asks the application how it should vote on the block, ensuring the specified validity rules are satisfied.
3. During block voting, specifically the pre-commit phase, CometBFT uses “ExtendVote” to ask the application for additional transactions or other data to attach to the pre-commit vote. This gives the non-proposing validators an opportunity to contribute transactions and other information to the block.

With consensus-level control, developers are empowered to recapture and redirect the MEV created by their application by programming MEV-awareness into block production and consensus. Skip is creating an advanced set of tools for exactly this purpose.

x/builder: The first generalized protocol-owned builder as an ABCI++ module

The x/builder module leverages ABCI++ to deliver an on-chain builder that any Cosmos SDK application can adopt to establish a sovereign MEV supply chain. The module provides new application mempool and consensus primitives for chains and validators, allowing application developers to enforce more expressive preferences about their blockspace and redistribute MEV revenue to chain stakeholders. The best part, it does all this without requiring any input from Skip’s Sentinel or any other centralized off-chain builders. The goal of x/builder is to give developers powerful, customizable building-blocks that allow them to fine tune how their application handles MEV. Here are some of the primitives that will soon be available for chains to experiment with using x/builder:

• Top-of-block auctions: A new transaction type that is executed at the top of the block, or not executed at all. The top of block transaction is selected via a single pay, in-mempool auction that does not affect the gas price or inclusion rates of ordinary transactions. Top of block auctions will come with a host of useful, tunable parameters for chains of all types.
• Bundler transactions: Meta-transactions that allow users to specify other transactions they want to backrun, or otherwise bundle with, as well as a fee they’re willing to pay to do so (for permissionless backrunning auctions on-chain or in-mempool).
• Bundled transactions: Proto-transactions that can only be executed as part of a bundler transaction and optionally allow users to specify bundler addresses whose transactions may bundle them (for off-chain orderflow auctions).
• Consensus-enforced fee markets: Batteries-included, controller-based fee markets (e.g. EIP-1559) with consensus-enforced ordering.
• Application-aware fee markets: Fee markets that dynamically adjust transaction pricing by measure of importance to the application (e.g. improving user experience by reducing fee ClaimRewards transactions during periods of low congestion).
• Multiplicity for bundle + bid availability: Vote extensions that include auction-winning bundles and transactions for bundle and top-of-block auctions, preventing censorship and manipulation by the proposing validator.
• Top-of-contract auctions: Extending top-of-block auctions to specific wasm/evm contracts, enabling each contract to auction off the right to be the first transaction that interacts with the contract.
• Encryption: Enabling optional encryption of bids, bundles, transactions, or the entire mempool (e.g. using Ferveo or Fairblocks).

We’d like to get these tools into developers hands as soon as possible, so we plan to release x/builder in four stages:

For devs who want to get into the weeds, here’s an RFC that describes top-of-block auctions in the planned implementation of V0. We will release further RFCs for additional features in the coming weeks.

V0 will be available in late April for any chain with PrepareProposal and ProcessProposal support (Cosmos SDK v0.47 and up). Osmosis has committed to adopting the new module as soon as possible, and we’re working closely with Duality on our decentralized auction design but we’d love to see more Cosmos chains adopt x/builder to extend their sovereignty and take control of their own MEV. Please reach out or comment if you’re interested!

We’re also beginning to spec out additional features with early partners who have requested to further enrich their blockspace capabilities. Some of these include:

• Transactions that can only be executed and put on chain if certain predicates are satisfied (e.g. price of OSMO > JUNO) (i.e. “preferences”) and transaction types that claim to satisfy preferences (i.e. “solvers”)
• Reserving blockspace for other chains / protocols (i.e. liquid staking providers)
• Enabling proposers to simulate transactions, ensuring non-reversion (e.g. for a fee or for network delegates who delegate above a certain threshold
• Extending auction functionality to optionally run over multiple blocks
• Adding new types of auctions (e.g. sealed bid, gradual dutch auctions)

Defining a new path for Cosmos MEV

We’re excited to be working with an early group of chains to integrate our protocol-owned builder, including Sei, Evmos, Stride, Berachain, Juno—and we’re continuing our close research collaboration with Osmosis and Duality. We feel like we’re barely scratching the surface of what ABCI++ can offer and where we can take x/builder, so please reach out or comment if you have any additional ideas. Skip started down this path because we saw that the solutions developed for Ethereum weren’t going to work for sovereign app-chains, but in order to create better solutions we need to work closely with chains to understand their unique needs.

We are excited to build x/builder and more POB primitives in the open and collaborate on a new path towards on-chain, accountable blockspace markets. We invite any interested Cosmos chains to get in touch and join us in exploring the frontier of Sovereign MEV!

[Ketchup_Q]

This is pretty cool.

Some questions:

• Arbitrary validity conditions can make the search for a valid block very expensive. How have you been thinking about dealing with the computational overhead of such a problem?
• With ABCI++, is the idea that a chain can have a new application deploy and specify additional validity conditions? If so, what are the limitations of these conditions? Would changing the validity conditions require an update to client software?

[hxrts]

• The arbitrary rules are programmed into the node, so this really up to the application developer how exhaustively they want to search.
• It’s certainly possible to expose an interface for block validity to a VM, so conditions could be programmed via smart contracts. However, the chain would likely want to restrict who can modify these conditions, either specific parties or chain governance for instance.

[sergio]

Small comment on the ABCI++ figure. The “BeginBlock, [Delivertx, …], EndBlock” is replaced by the one-shot FinalizeBlock. It’s just a detail, and doesn’t change the semantics of the API in any significant way

[hxrts]

Thanks for that clarification Sergio! It’s actually helpful to surface this because it’s an important change that devs should be aware of. Even though it doesn’t change the API, they’ll be using FinalizeBlock where they once used these other functions.

[hxrts]

note the x/builder module has been renamed to x/auction, which is now included in Skip’s Block SDK as the “MEV lane” described here: 1️⃣ MEV Lane | Skip Protocol Docs