Abstract

This document describes a protocol for auctioning block space to off-chain builders. It includes a Cosmos SDK module implementation, as well as a reference implementation of a builder.

Goals

• Competitive Builder Market — The protocol should support multiple builders, and builders should be able to register freely (subject to governance rules where appropriate).
• Builder Legibility — Transactions from builders are “legible” in that they are signed by the builder’s on-chain registered address.
• Native Payments — Payments from builders are done through a common module address, and distribution of payments is governed by the chain.
• Conditional Payments — Builders only pay if what they propose is included EXACTLY in the block as submitted on-chain.
• Bilateral Accountability — Builders and proposers can hold each other accountable for deviations from the protocol.
• MEV Stealing Detection — Proposers who commit to a builder, but then modify the builder’s segment, should be detectable by the builder, and actionable evidence of that misbehavior should be submittable on-chain.
• Low Intervention — The proposal should not require any changes to consensus-level data structures, the ABCI protocol, Tendermint itself, etc.
• Preferences — Chains and validators should be able to express preferences to builders about how blocks are constructed, e.g. OFAC compliance.
• Partial Block Auctions — The protocol outsources construction of only part of each block, to reduce the censorship risk posed by builders. This leaves out a reserved section (prefix) of the block for critical protocol transactions, and another section for gossiped mempool transactions (suffix).

Non-Goals

• Fast Block Rates — This version of the protocol doesn’t intend to support networks with fast (i.e. sub-second) block rates. A future version of the protocol will address this goal.
• Sub-segments — The protocol doesn’t support auctions for bundles more granular than a complete segment. For example, sub-segments, components, or other groupings sometimes used by searchers.
• MEV Stealing Prevention — The protocol doesn’t attempt to prevent MEV stealing, neither heuristically nor by construction. Future versions of the protocol may incorporate solutions to this issue, if and when those solutions are produced.

Overview

• Chains can enable or disable the builder module via a consensus parameter
• Validators opt-in to the builder module by registering a new on-chain “proposer” identity
• Builders also register on-chain identities, akin to validators registering via the staking module