An Introduction to the Top-of-Block Auction Mechanism

The upcoming governance proposal about the v25 upgrade will propose the introduction of a new feature called the top-of-block auction mechanism, which taps into the potential of Skip’s Block SDK to refine how transactions are processed and to add new bidding functionalities.

Block SDK Overview

The Block SDK design segments blocks into “lanes”. Each lane handles different kinds of transactions, operating under its own set of rules for block construction. This approach should help make transaction processing more efficient and customizable.

Here’s what you need to know:

  • Lane-Specific Transactions: Different types of transactions are processed in their own lanes, each with a cap on block space.
  • Iterative Processing: Lanes fill up the block one at a time in a specific order, both during the block proposal and verification stages.

Top-of-Block Auction Overview

The top-of-block auction lives in it’s own lane and is all about optimizing how transactions get ordered within a block. Here’s a quick rundown:

  • Auction Participation: Users can now submit transaction bundles through a new type, AuctionTx. Just remember, AuctionTx should only contain the MsgAuctionBid message.
  • Bidding Mechanics: You can place your bids either via a dedicated AuctionHouse smart contract (TBD) or directly through the Msg type.
  • Auction Parameters:
    • MaxBundleSize: Capped at 5 transactions per bundle.
    • ReserveFee: A minimum of $1 (USDC) required to bid.
    • MinBidIncrement: Bids need to be at least $1 (USDC) higher than the previous highest bid.
    • FrontRunningProtection: Initially set to true to help keep things fair.

What This Means for Osmosis

Better Pricing Through Faster Arbitrage: The top-of-block mechanism significantly speeds up the resolution of arbitrage opportunities, particularly interchain, which directly leads to more efficient pricing within the ecosystem.

New Revenue Streams Explained:

  • 95% of the Auction Proceeds: This portion goes into an escrow account, with the usage determined by community governance, potentially funding new projects or burning mechanisms.
  • 5% to Validators: The validators producing the block receive this portion, incentivizing timely and efficient block production.

Advanced Transaction Filtering Capabilities:

  • Validators can now more precisely manage which transactions are prioritized, enhancing the network’s integrity and efficiency. This detailed filtering is seen as a proactive measure rather than tampering, aiming to optimize network throughput.

Future Potential with Zero-Fee Transactions:

  • We are exploring avenues like zero-fee lanes for specific transactions such as claiming staking rewards and governance voting, aiming to remove barriers to participation and foster greater community engagement.

Keep the conversation going—share your thoughts, feedback, and questions below!

6 Likes

Interesting new feature!

Are there already other chains which have this principle implemented and where we can check how this is running? What does it bring for the project / stakers? How often is it used? That kind of things.

Does this mean that essentially this can compete with ProtoRev in general? Since that is what this seems to imply. ProtoRev has arbitrage, but if you are able to frontrun ProtoRev via these lanes and the Top-of-Block Auction Mechanism then we are only shifting how things are handled on chain.

The Community Pool is also already meant to fund projects and we have Reverie as well. Do we really need another route to build a pot of gold to fund projects? Or should we rather convert it into real yield for the protocol and decrease OSMO-inflation? That might be more beneficial in the long run imo.

Furthermore; how is the 5% for validators meant? Meant as additional staking rewards (such that of that 5% the first 90-95% is given to stakers and the remaining 5-10% is validator commission)? Or will it be sent to the associated validator addresses?

Does this mean that validators will have the option to include a list of prioritized transaction types or something? Or how is this intended to work?

1 Like

Are there already other chains which have this principle implemented and where we can check how this is running? What does it bring for the project / stakers? How often is it used? That kind of things.

Neutron and also Juno have this running in Production.

=> neutron/app/lane.go at main · neutron-org/neutron · GitHub
=> juno/app/keepers/keepers.go at main · CosmosContracts/juno · GitHub

Skip have a breakdown of Juno MEV here that’s a good read => Skip’s State of MEV: JUNO. This article covers the State of MEV on… | by Skip Protocol | Medium

We should hope that this gets used heavily when there is momentum in the market.

Does this mean that essentially this can compete with ProtoRev in general?

Protorev captures cyclical arb opportunities, the top-of-block auction will capture more CEX <=> DEX arb opportunities. Both the top-of-block auction and protorev are built by Skip!

how is the 5% for validators meant?

5% goes to the validator operator address => block-sdk/x/auction/rewards/proposer_provider.go at main · skip-mev/block-sdk · GitHub

but this is configurable, so we can change this address with an upgrade and percent at any stage through governance.

Does this mean that validators will have the option to include a list of prioritized transaction types or something? Or how is this intended to work?

The block sdk opens up new ways to think about transaction processing, the top-of-block auction is one of these transaction processing “lanes” with prioritised transactions. Another example could be a free lane for claiming staking rewards.

Do we really need another route to build a pot of gold to fund projects? Or should we rather convert it into real yield for the protocol and decrease OSMO-inflation?

These are really interesting questions to discuss, I like the idea of reducing inflation as much as possible.

3 Likes

@paddy_mc thanks for the response!

But in theory the top-in-the-block could be used for cyclical arb opportunities, right? Or is that blocked in general?
Because if I understand correctly the top-of-block is handled before ProtoRev is kicking in.

Do I read this correctly that it goes to the blockproposer? So that means that the validator who mints the block gets the 5%?

That would be kinda counterintuitive compared to the fact that we removed the proposer bonus from minting a block in general.

The feature is quite interesting and could lead to a variety of impactful applications. In line with preserving the integrity of the value generated, I would not recommend redirecting the revenue to fund other projects, as fundamentally, the value is extracted from the liquidity providers (LPs). One improvement I propose is to redistribute the highest bid from the top-of-block auctions back to the pools or protocols it interacts with. For instance, if a top-of-block transaction interacts with Osmo/ETH and places a bid of 100 USDT, those funds could be distributed pro-rata to the LPs. This approach could help mitigate the LVR losses for liquidity providers, providing them with stronger incentives to engage with the protocol. However, we must be selective about which pools are granted this privilege to avoid potential strategic behavior. I would personally start with specific pools. Additionally, an interesting application to consider is defining ‘intent settlement’ as another lane where the transactions submitted are solvers’ solutions for specific intents, and the solutions per intent are ranked based on which one provides a more efficient solution.

1 Like

But in theory the top-in-the-block could be used for cyclical arb opportunities, right? Or is that blocked in general?
Because if I understand correctly the top-of-block is handled before ProtoRev is kicking in.

Protorev happens right after every transaction => osmosis/app/posthandler.go at main · osmosis-labs/osmosis · GitHub

So only if protorev misses an arb opportunity it’d be captured by searchers, that could use the block-sdk. Where as top-of-block transactions always occur in the next block. And protorev will run after these transactions as well.

e.g blockN(MEV, Default[auction(txA, txB)]), blockN+1(MEV[txA, txB], Default)

It’s my understand that there may be some overlap, but they’re mostly complementary features.

Do I read this correctly that it goes to the blockproposer? So that means that the validator who mints the block gets the 5%?

Yeah that’s correct, we may need to revisit this is a subsequent release. I think for v1 it’s best to have the validators understand where and why this revenue is happening, it’s much easier to get buy in if there is a monetary reward, I think the 5% is good for starting this initial conversation with validators. Saying that I agree it’s counter intuitive.

1 Like

Osmo/ETH and places a bid of 100 USDT, those funds could be distributed pro-rata to the LPs.

I like this idea, I think we as a community need to decide what the best course of action is with regards distributing the profits from top-of-block auction, IMO we should firstly understand if this is a significant revenue stream, then improve the protocol to work more for us.

interesting application to consider is defining ‘intent settlement’

Intent based systems are something I’m super excited about, I think that the block-sdk && the upcoming smart accounts work will enable some intent based architecture for Osmosis :osmosislogo:

1 Like

I would prefer going live with a 0% proposer fee. I don’t think validators will vote against this proposal if it was not in the design. But it will become a lot harder taking it away.
In the end it is always harder taking value away from someone, than not giving it in the first place.

Remember that high ranked validators mint more blocks and will thus receive the top-of-block reward more often. So going with a non-zero percentage will result in a difference in relative income between a high ranked and low ranked validator. And I think we can be proud that at this stage that is nearly non-existing (besides the fact of centralization of VP ofcourse, but every OSMO delegated is roughly worth the same validator income).

Good point, unfortunately the migration has already been written, it’s locked in for v25. It’s easy to change to 0 with a gov prop, let’s continue this conversation tho and see if anyone else in the community has input, specifically validators.

Sadly I am one of the very very few validators who is working on prepping governance…

1 Like