Background

Today, Skip operates a centralized builder and MEV relayer on several Cosmos chains, in which validators connect to the Skip “Sentinel” which aggregates bundles of transactions and associated bids to construct optimal blocks.

Upon construction, transactions are gossiped to the next block proposer, if that proposer is set up to receive MEV transactions by running a special version of Tendermint, mev-tendermint.

This design, although centralized, has solved many problems for validators, including respecting their building preferences, distribution, outsourced computation, and added little complexity to their validator operations.

However, it is still a trustful system. Our goal is to design and progress towards an in-protocol trustless and thus decentralized alternative, whereby making it one of the first decentralized MEV auction systems. This results in not having to rely on an outside builder, at the cost of some added complexity to the validation and block construction process.

Proposal

We propose to utilize Tendermint’s ABCI++ methods in layered stages. Initially, we propose a v0 system where an application will utilize the PrepareProposal and ProcessProposal methods of ABCI++.

x/auction

We will introduce a new Cosmos SDK module, x/auction, that defines a message type, MsgAuctionBid. The MsgAuctionBid message will contain an auction bid and an embedded series of signed and encoded transactions, for which to back-run. The MsgAuctionBid's bid along with the series of one or more transaction compose a bundle.

We embed or “pack” the transactions directly into the MsgAuctionBid message itself for a few reasons. Most importantly, we want to guarantee that the bidder has sufficient funds to cover the bid and associated auction fees. This isn’t possible to guarantee if the MsgAuctionBid is executed after the bundle, at least not without simulations. If the MsgAuctionBid is executed first, it needs to reference the bundled transactions somehow, yet this is challenging due to how the mempool needs select transactions that respect sender nonce values.

message MsgAuctionBid {
  option (cosmos.msg.v1.signer) = "bidder";
  option (amino.name)           = "cosmos-sdk/MsgAuctionBid";

  option (gogoproto.equal)           = false;
  option (gogoproto.goproto_getters) = false;

  string   bidder = 1;
  repeated Coin bid = 2;
  repeated bytes transactions = 3;
}

Note, the x/auction module can define via governance the total amount of bundled transactions allowed, i.e. the bundle size, along with other parameters such as supported bundle signing strategies.

In addition, we will support the ability for applications to set a reserve fee, which specifies a fee that bidder must pay to enter an auction, and a minimum buy-in fee which acts as a bid floor for the auction. Finally, there is a minimum bid increment which defines the epsilon that an incoming bid must be higher by than the local maximum bid. Applications can set these zero if they wish.

message Params {
  option (amino.name) = "cosmos-sdk/x/bank/Params";

  int32    max_bundle_size = 1;
  string   escrow_account  = 2;
  repeated Coin reserve_fee = 3;
  repeated Coin min_buy_in_fee = 4;
	repeated Coin min_bid_increment = 5;

  // TODO: Decide how to define which strategies are enabled.
}

The handler of the MsgAuctionBid will solely be responsible for sending the bid to a designated account, e.g. a multi-sig, which is determined by governance as well.