Introducing the FastLane MEV Protocol: The World’s First Fully Decentralized MEV Auction for Monad Validators

In collaboration with Category Labs, Fastlane is proud to introduce the Fastlane MEV Protocol. The protocol consists of the Fastlane Sidecar: a minimal external client that optimally orders top-of-block and backrun bundles, and the Fastlane Auction Handler: a smart contract that searchers must plug into in order to participate in the auction process.

The Sidecar and the Auction Handler require zero new trust assumptions or centralized third parties, such as blockbuilders, private relays, or private RPCs. Instead, we leverage the existing validator set and Monad transaction pool via RaptorCast.  

Throughout its development, we collaborated closely with Category Labs, Monad’s core protocol engineering team, to ensure the protocol design aligns with Monad’s execution model and preserves decentralization and validator autonomy. The protocol is designed with several clear objectives:

• MEV is captured directly by validators, increasing validator yield.
• Searchers compete on realized value instead of a quasi-priority gas auction dynamics.
• shMON holders capture a portion of MEV, improving shMON yield.
• The system remains fully decentralized and does not introduce any new trusted parties.

Early State of MEV on Monad

Monad’s asynchronous environment naturally incentivizes spam-style MEV strategies. Searchers receive state that reflect conditions three blocks in the past. By the time you identify an opportunity, two more blocks will be executed before your transaction lands. The transactions in those two blocks can significantly change the pool state you are targeting.

This creates an incentive problem: searchers want their transactions included in the next two blocks before they actually know whether an opportunity will exist at execution time. The only way to compete is to guess.

As a result, spam bots running blind backrunning strategies send many transactions — often “fat” transactions that attempt complex onchain pathing — in the hope of blindly finding an opportunity. Because of Monad’s large blocks and low fees, this behavior is more effective than on other chains. The fact that a searcher pays their full gas limit regardless of execution gas used further encourages heavy onchain search logic inside the transaction itself.

At the moment, these strategies drive almost all MEV value to searchers and very little to validators or users. This initial release of the Fastlane MEV Protocol gives validators a direct way to participate in MEV across the network and reduces the incentive for unbounded spam.

How Other Chains’ Auctions Lead to Centralization

MEV auctions in other ecosystems — Flashbots MEV-Boost, Jito, Arbitrum’s Timeboost, Unichain, and others — are each successful on their respective blockchains.  But, they require some form of centralized coordination: private mempools, trusted relays, block builders, or other external infrastructure that sits between searchers and validators.

One of the main reasons we chose to build on Monad is its deep commitment to decentralization. Monad has built a high-performance L1 without giving up on progressive decentralization. FastLane is aligned with this philosophy.

The Fastlane MEV Protocol does not rely on new centralized entities, private relays, or privileged pathways. There is no private mempool, no third-party relay, no off-chain builder dependency, and no reliance on Fastlane infrastructure. The system is composed of:

1. A sidecar run by validators who opt in
2. A smart contract that enforces the rules of the auction (the MEV Auction Handler)

Everything else occurs within the normal Monad transaction flow.

MEV Auction Handler

The MEV Auction Handler is a smart contract that manages searcher bids, enforces payment, and distributes revenue to validators, shMON holders, and FastLane.

Searchers update their contracts to integrate with the Auction Handler. All searcher transactions set the to address to the Auction Handler contract and include calldata describing how the handler should call back into the searcher’s contract.

During execution, the Auction Handler:

• Verifies the bid.
• Ensures the bid is actually paid by the searcher.
• Pays the validator and shMON holders according to the revenue split.
• Reverts if payment conditions are not satisfied, allowing the next searcher transaction to proceed.

The contract supports both Top-of-Block and Backrun auctions. In practice, because Monad does not yet have a public mempool, early usage will focus almost entirely on top-of-block competition.

Fastlane Sidecar

Participating validators run a small sidecar process that assists in block construction. The sidecar inspects the incoming transaction pool and flags any transaction whose to address is the MEV Auction Handler. These are recognized as MEV auction participants.

Searchers do not need a special RPC, relay, or submission path. They use the normal transaction flow (e.g., raptor cast / eth_sendRawTransaction). The MEV Protocol does not introduce a parallel network or privileged channel. The sidecar simply observes the same pool every node sees.

A key feature is that validators do not need to simulate searcher transactions. The sidecar only reads calldata to extract the bid amount and orders transactions accordingly. Payment enforcement is handled entirely by the smart contract. If a searcher fails to pay the stated bid, the transaction reverts and the next bidder gets a chance at the opportunity. This minimizes validator overhead while ensuring deterministic, decentralized ordering.

Under current MEV guidelines from the Monad Foundation, validators running the FastLane Sidecar remain eligible for VDP participation. Validators should assess MEV tooling based on their own operational requirements.

Next Steps

• Searchers: Get started here
• Validators: Contact the Fastane team to participate at [email protected]