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!
xla
Mekatek