Builders as Citizens β€” Standardizing MEV Auctions in Cosmos

Hello Cosmos community!

Today, we propose a new standard interface between Cosmos-based chains and builders with the builder module. With our belief that chains are sovereign and should have full control over the shape of blocks and its revenue distribution, MEV has to become an important part of the discussion on the security and sustainability of the Cosmos ecosystem. Multiple solutions have emerged to optimize blocks using off-chain auctions. However, these solutions come with problems that we are addressing with the builder module - read the draft specification.

Problems the builder module is going to fix:

  • Operational risk and complexity for validators because of custom patches to CometBFT(f.k.a. Tendermint) - currently Skip and Mekatek, but potentially others
  • Preferences aren’t enforced - good or bad MEV - by the state machine
  • Opaque payments without clear process for determining who should pay what
  • Inefficient markets created by mutually exclusive implementations

Implemented as a Cosmos SDK module it presents a fundamentally different, more decentralized and more effective approach to MEV capture. Enabling chains to express preferences, which are modeled as functions to enforce the shape of the block and hand out tools for governance to decide how proceeds should be distributed. As well as holding builders accountable on-chain for the transactions they include in blocks.

To recap the benefits of the builder module:

  • Standard Cosmos SDK module - no custom patches required
  • Chain governance controls payment distribution
  • Chains enforce shape of blocks through preferences
  • Builders accountable on-chain

Builder module and POB

How does this relate to the Protocol Owned Builder (POB) concept from Osmosis and Skip? POB presents an interesting approach to building blocks on-chain. At the core the idea of POB is that chains should have full control over the shape of blocks and that revenue should be fairly distributed. As outlined above, we fully agree with this principle.

However, on-chain building does face some challenges. One challenge is information constraints. On-chain building is limited to the amount of information available on-chain that can be incorporated into block construction. Another challenge are computational constraints. The computational requirements of building blocks on-chain may be too high for some validators to handle. Additionally, on-chain computation is wasteful, as it needs to be replicated.

The builder module addresses these challenges, while giving chains sovereignty over their block building functions and the distribution of proceeds.

State machine validated block shapes help overcome information constraints. With this approach the state machine validates the block shape, ensuring that it meets certain criteria. This allows for a higher degree of flexibility in block construction while still maintaining security.

Transparent payment facilities ensure that revenue is fairly distributed. This approach allows for payments to be made to public goods, benefiting the community as a whole.

Next steps

The draft of the specification goes into a lot more detail. We’ve been iterating on the design with the Comos SDK team and other important stakeholders over the last weeks. We are now looking for feedback from the community and invite you to leave to participate in a lively discussion directly in this thread :).

We believe that this proposal is an important step towards a more secure and sustainable Cosmos ecosystem, and we look forward to your thoughts and suggestions!




Can you elaborate a bit on how you see this with respect to the direct competition to Skip protocol which is already active on a couple of chains and got funded to develop for this chains?

The builder module is an initiative to bring an open interface to any Cosmos chain for validators to connect to as many builders as they prefer without having to pick a single one. This allows for open competition between builders, resulting in more upside for chians and stakers. With that in mind it’s important to highlight that this is not an exclusive solution, but will benefit cases where teams like Skip run builders.

For cases like ProtoRev/POB like on Osmosis, there is a whole section in the original post up top going into more detail.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.