The Sovereign MEV Toolkit

[barry]

Authors: @barry, @PossibilityResult, @hxrts

Many thanks to @JonCharbonneau for his edits and comments

This post represents joint research between Skip and Duality

Introduction

Sovereignty is fundamental to the Cosmos design philosophy and a cornerstone of any successful app chain or rollup ecosystem. In practice, this means that communities and developers control the rules that define their application. Sovereignty ensures communities can exercise meaningful choice, create opinionated new experiences, and treat users as first-class citizens.

Unchecked MEV is a threat to this sovereignty: Proposers’ and off-chain builders’ ability to unilaterally manipulate the ordering and inclusion of transactions can subvert the intended behavior of app chains and undermine their sovereignty.

Our claim is pretty simple:

1. What happens outside the bounds of consensus cannot be reliably governed on-chain.
2. Block building under PBS (proposer-builder separation) is off-chain, unaccountable, and outside of consensus. We see this in Ethereum and Skip’s current mev-tendermint solution.
3. These are not sovereign blockspace markets because the protocol has no authority over the MEV supply chain or the ability to express preferences over block construction.

Without sovereign blockspace markets, we can’t have sovereign chains.

We want to create sovereign MEV supply chains. This requires enabling protocols to express and enforce a wider range of preferences over the construction of their blocks.

This post aims to define the notion of a sovereign MEV supply chain and the properties it should satisfy. We argue PBS does not satisfy these properties and present an alternative set of mechanisms that do – what we call the Sovereign MEV Toolkit.

Duality and Skip are working together to implement two critical components of the sovereign MEV toolkit and make them available to Cosmos chains in a new module:

• Protocol-owned-building (POB): In-protocol rules for transaction ordering, transaction inclusion, block state transitions (e.g. blocks must capture all arbitrage) and validator node tooling (e.g. tx simulation markets) that allow validators + the protocol to express preferences over block construction

• Multiplicity: A proof-of-stake add-on that requires blocks to be constructed from the input of multiple proposers, increasing censorship resistance and enabling credible POB preference expression

Sovereign MEV empowers chains and roll-apps to incentivize stakeholders, monetize, and achieve more sustainable tokenomics. We firmly believe that the ability to build blocks in-protocol will incentivize the best developers to build sovereign chains and rollups.

We’re excited to share some of the architectural details of what we’re building and how we’ll leverage new features in ABCI++ in a subsequent post, but for now we’ll elaborate on why this is a crucial problem to tackle.

The Sovereign MEV supply chain

The classic MEV supply chain looks something like this:

(insert some orderflow marketplace solutions in the middle)

This has always struck our teams as surprising. Why does the supply chain end with the validator instead of the protocol? This construction pre-supposes that protocols themselves cannot “internalize” or “recapture” MEV. Validators are only one subset of protocol actors - they are not the protocol itself.

So the sovereign MEV supply chain looks a bit different:

This sequence captures the notion that application and consensus design affects MEV availability and distribution, as well as the shape of the rest of the supply chain. “Sovereign MEV” is our short-hand for an MEV supply chain where the protocol and its developers retain agency over these factors.

We claim a sovereign MEV supply chain has 3 properties:

1. Community determination of which stakeholders accrue MEV
Is value distributed to validators? Stakers? LPs? Transaction originators? Smart contract devs?

There are wildly divergent views about who is leaking the value from an MEV-generating transaction, so we believe sovereign communities should have the tools required to decide who recaptures the extracted value. For example, Duality sees impermanent loss or “loss-versus-rebalancing” as a type of MEV that is leaked from LPs to arbitrageurs, and is helping build the Sovereign MEV Toolkit to ensure their DEX returns as much of that value back to LPs as possible. In the long run, if LPing is more profitable, liquidity will move to Duality, which in turn will benefit the entire community.

2. Community determination of what kinds of in-protocol MEV are allowable
Does the protocol facilitate atomic frontrunning or sandwiching? Atomic JIT liquidity provisioning? Censor-based MEV?

There’s a big meme about “good” vs “bad” MEV that we’re often asked about. We don’t really like those labels, but we can say this: Some patterns of reordering and inclusion have broad support from validators and chain devs, and others do not (e.g., sandwiching and censorship). More importantly, it’s not our place to decide - it should be yours.

3. Community determination of how MEV is extracted
Are there off-chain builders, searchers, or matchmakers who construct the blocks? If not, how does the proposer/validator construct a block?

Not surprisingly, communities have strong preferences about how MEV is extracted that are independent of the outcome. For example, communities may prefer one transaction supply chain because it’s more decentralized than another, or because MEV extraction is more democratic/accessible.

Ethereum-style Proposer/Builder Separation (PBS) does not enable Sovereign MEV

The basic idea of PBS goes like this:

1. Block building for a general purpose smart contract chain like Ethereum is hard. It requires deciding what transactions to include from a much larger set and figuring out how to optimally include and order them
2. So, validators outsource this complex task to off-chain builders. Proposers then just have to pick the most profitable builder block

PBS has been successful in commoditizing Ethereum validation - over 550,000 validators (not individuals) are able to run simultaneously without large stakers gaining any meaningful advantage.

But it doesn’t address the source of MEV. It’s a bandaid for some of the symptoms. PBS is only possible because block proposers have a monopoly over what transactions are included in a block and how they’re ordered, so they are able to sell those rights with the goal of maximizing their own profit.

Adding a new actor - the builder - is also far from a catch-all solution to centralization concerns. Builders make margins between what searchers and users pay them and what they have to pay the validator to win the block. Thus builders have a strong incentive to collude and hoard orderflow to increase margins and grow their businesses. A potential centralizing flywheel that might appear is: the more a builder wins, the more they can purchase exclusive orderflow, the more they continue to win…

So PBS has moved a powerful centralizing force farther away from the protocol and not addressed the source of the problem. Shouldn’t we instead be moving powerful forces into the protocol and driving them towards accountable decentralization?

So here’s the fundamental question for chains and rollups that want to retain their agency in the market: Is this blockspace mechanism sovereign?

In evaluating whether Ethereum’s PBS system satisfies the criteria for a sovereign MEV supply chain, the answer is definitively no.

PBS fails the three criteria we set for our Sovereign MEV supply chain:

1. The community cannot determine which stakeholders accrue MEV

PBS consists of a sequence of nested auctions, where in the final auction, the proposer picks the bid that pays them the most with no oversight from the other validators. This precludes directing revenue anywhere else. One might say, “We could have the proposer select based on the highest bid to some other account, like the community pool?” Except now the proposer can simply strike an off-chain agreement with whoever agrees to pay them the most, then censor other bidders (including the true highest bidder).

There are proposals to change how this aspect of PBS works by introducing auctions for the right to propose, but these proposals come with significant limitations and incentive compatibility issues without directly addressing the underlying concerns.

2. The community cannot determine what kinds of MEV are allowable

In theory, a protocol designer could “reprogram” PBS to enshrine or prevent certain types of MEV by implementing predicates that builder–or validator–supplied portions of the blocks must satisfy (PEPC is a step in this direction). Though in practice, as long as proposers have the ability to select blocks without consulting other validators, it will be possible to undermine many of these preferences (or otherwise interfere with liveness).

3. The community cannot determine how MEV is extracted

While PBS moves the centralizing aspects of MEV to the builder layer, it doesn’t actually mitigate any centralizing forces. This is mostly okay on Ethereum due to a mature MEV supply chain comprising many interested actors with differentiated information and orderflow.

For Cosmos chains, however, there are very few candidate builders. And given the current volume and MEV, building for one chain cannot cover infrastructure costs, let alone the overhead and personnel costs of running a business. Builders would need to build for basically all Cosmos chains just to break even. So PBS could immediately lead to a highly centralized blockspace market. We believe this will hold true for the vast majority of sovereign rollups over the next few years.

–

To be clear, PBS isn’t “bad.” Ethereum simply has very specific priorities and constraints. We’re not targeting general-purpose chains with technical debt requiring the support of hundreds of thousands of validators. And we’re not building for chains that upgrade and evolve at Ethereum’s pace. App chains and rollups aren’t bound by the same constraints, so we have an incredible opportunity here to take advantage of this flexibility and tailor blockspace provisioning mechanisms to our needs.

Sovereign MEV lets devs take back control

The alternative to off-chain builders and unchecked proposers is block building processes that are implemented in the chain client and verified/enforced as a part of consensus whenever possible. In other words, block construction where the protocol remains in the loop.

The sovereign MEV toolkit has two major parts:

1. Protocol-owned-building (POB): Protocol-defined rules for transaction ordering, transaction inclusion, block state transitions (e.g. blocks must capture all arbitrage) and validator node tooling (e.g. tx simulation markets) that allow validators + the protocol to express preferences over block construction

2. Multiplicity: A proof-of-stake add-on that requires blocks to be constructed from the input of multiple proposers, increasing censorship resistance and enabling credible POB preference expression

In short, POB enables protocols to express their block building preferences given the transactions, while Multiplicity ensures the right transactions make it into the block.

The goal is to give chain and smart contract developers and their users super powers, a new dimension of affordances to structure their own blockspace, direct orderflow, and build MEV-aware applications.

Building on this goal, we define a few different categories of mechanisms that fall into the Sovereign MEV Toolkit:

1. Consensus-enforced block validity rules established over transaction ordering and inclusion

This refers to rule sets that allow non-proposing validators to safely accept or reject blocks based on all transactions in the block and their relative ordering. For example, this could include requiring valid blocks to:

• Order transactions by descending gas price
• Contain at least one oracle transaction
• Contain no more than one special top-of-block transaction type

2. Consensus-enforced block validity rules established over state

This broadly refers to rule sets that allow non-proposing validators to safely accept or reject blocks based on whether the state transitions in the block satisfy particular outcomes. For example, protocols could require:

• A no arb condition on a DEX or across all DEXes at the end of each block
• At least some amount of gas has been burned
• No more than a certain capital limit has been withdrawn over bridges

3. Builder primitives built into node clients

This refers to enhancing validator node clients to do some of the specialized work that off-chain builders do in PBS, which is not typically required for consensus but can make block production more efficient. This might include:

• Simulating blocks prior to proposing them and removing failing transactions
• Maintaining reputation tracking and rate limiting systems for searchers who submit transactions or consume data from their RPCs
• A mempool that can run single pay auctions for state slots

4. Builder primitives built into the state machine

This refers to enriching the state machine with new state and state transition functions to model functionality commonly provided by off-chain builders. For example:

• A special transaction type that must pay a bid >> gas fee to be included and may only be included at the top of the block
• A meta-transaction that can bundle multiple transactions from the mempool together and pay to have them executed in a particular order (i.e. a “bundle”)
• A meta-transaction that can place requirements on the transactions that run before or after (e.g. specify that the subsequent transaction must originate from a particular address)

5. Multiplicity – Multiple validator block construction

Multiplicity is a concept recently shared by Duality which allows multiple validators to have input into a block. It was motivated by a recent paper in collaboration with the Duality research team, where the authors showed that without multiple concurrent block proposers, it is incredibly difficult to run a credible auction on-chain.This is in contrast with leader-based consensus protocols which give a single validator a monopoly over what is included in a block (and often how the txs are ordered). By removing this monopoly and democratizing block production we can do way more on-chain without needing to worry about the censorship of time-sensitive transactions. Future examples of multi-validator block construction might include:

• Multiplicity-tendermint, where the proposer must include a sufficient number of additional transaction payloads signed by other validators for the block to be valid
• Bullshark or Tusk, wherein blocks consist of transaction collections, each signed by a quorum originating from different validators, i.e. Narwhal
• Themis, in which the proposer incorporates information from other validators regarding the order of transactions received

A sovereign block construction process may implement one or more of these mechanisms, but collectively they make up a toolkit that enables blockchain developers to establish a sovereign MEV supply chain, tailored to their application and the preferences of the community.

Conclusion

So why are we shilling Sovereign MEV? We believe the application-specific blockchain thesis has been validated—whether you call it an app chain or a roll-app, blockchain architectures are moving toward greater application sophistication and differentiation—call it the Cosmos-ification of crypto.

Skip is out there every day talking to Cosmos application developers, validators, and Dapps, and we can tell you first hand that the prevailing wisdom about eth-style PBS as the terminal blockspace solution is wrong. PBS was designed for circumstances very specific to Ethereum, but it’s not what applications want. They want better UX for users, more control over valuable parts of their application, and fewer middle-men.

Duality wants Sovereign MEV to make LPing less painful and more profitable, proving that—in the long run—applications which can express preferences over blockspace will beat applications that don’t.

Together, Skip and Duality would like to invite application developers and community stakeholders to talk to us and help us explore this new and exciting design space of application-specific Sovereign MEV.

We’ll be sharing more details about the first version our new Cosmos module very shortly.