MEV - FastLane Update

Hi Everyone,

It’s been roughly a year since PFL (“FastLane on Polygon”) received its first bundle on Polygon PoS, and so I wanted to take some time and update you all on our progress.

The FastLane team originally set out to build a non-predatory and decentralized MEV layer for Polygon PoS. You can view a description of our goals in this thread:

TLDR: spam posed an existential threat to the health of the Polygon PoS blockchain. An MEV layer that removes bots’ incentive for spam is critical for the long term health of any low cost chain seeking to scale user volume.

PFL is now the dominant MEV protocol on Polygon PoS. Although we’re at roughly 40% of the network, we still have a long ways to go; the majority of validators are still not connected to any MEV system, which means that transaction spam is still incentivized during their blocks.

User Protection:

PFL strongly disincentivizes sandwich attacks. After consulting with validators, we’re confident that the vast majority are aligned with users and are against enabling value extraction via sandwich attacks. Our goal was to incentivize the usage of decentralized p2p transaction propagation (the “mempool”) relative to private relays by to protecting all users, by default.

To date, we have not observed a single sandwich attack occuring through the FastLane relay. We’re actually surprised that it hasn’t happened yet, since technically they’re still possible. The result is quite amazing; Polygon PoS has the best execution quality for user transactions of any high volume PoS blockchain (we are excluding L2s like Arbitrum and Optimism).

Ethereum Sandwich Frequency ← | → Polygon PoS Sandwich Frequency

(Note that the majority of the tiny sliver of red you see at the end of the Polygon chart is actually fake sandwich volume that’s attempting to bait other bots into swapping an exploitable “salmonella” token.)

You can see a video of me presenting how the sandwich defense mechanism works here:

The deck for the mechanism is here:

Alternative MEV systems like Proposer-Builder Separation and MEV-Geth incentivize user predation (I.E. sandwich attacks). If value can be extracted, it will be extracted. The justification for these systems on Ethereum Mainnet is that validators who do extract value from users will have a higher APY than those who don’t, and will therefore grow stake faster, leading to validator centralization.

While this is a logical prediction, the opposite effect has been observed occuring in reality. The validators with large (and growing) stake amounts tend to be those with the highest fees and therefore the lowest yields. This indicates that stake acquisition is correlated more with a validator’s reputation, security, and “BD” than with yield, and that yield is dependent on stake weight (via fee %) rather than the other way around. The chain of causation here may also be dependent on the time scale - stake is inelastic.

It is likely that yield will play a greater role in stake concentration over a longer time period. We may see this play out as the technical sophistication and reputation of the non-dominant validators grows to match the dominant players.

Regardless of its validity, this centralization vector is currently a non-issue on Polygon PoS due to the permissioned nature of the validator set. It is an open question whether or not this will change for Polygon 2.0.

Censorship Resistance:

FastLane is an American-based company, and as a result we are OFAC compliant. Our objective for censorship resistance isn’t to be non-compliant or skirt regulations, but rather to avoid putting ourselves in a position that has the power to censor transactions.

The current PFL design blocks OFAC-sanctioned transactions from appearing in MEV bundles, but due to PFL’s architecture we are incapable of blocking OFAC transactions from reaching validators. We couldn’t censor them even if we wanted to.

You can read more about the PFL architecture in our white paper:


PFL is currently the only MEV protocol on an EVM chain that could turn its centralized relay off and still function, albeit more slowly. This is due to the fact that searchers / bots can submit bundles via the mempool.

We’re also the MEV protocol with the shortest path towards total decentralization. If we open sourced the PFL codebase and each validator ran their own PFL node as a sentry then we would be fully decentralized. While this is our eventual goal, there are a few problems that are worth discussing:

  1. The PFL node codebase is updated very frequently, meaning that validators would need to pay much closer attention to FastLane repos than they do now. This strongly conflicts with what many validators say is their favorite aspect of PFL: no additional dev ops dependencies.
  2. PFL nodes require higher specced infra than regular Polygon nodes, meaning that the dev ops costs would be slightly higher.
  3. We do not want searchers / bots to see how we defend against various potential attacks (DDoS or otherwise). We don’t think there is any risk here… but history has shown that pride comes before the fall, particularly in the MEV world.
  4. Furthermore, if we are attacked, it’s easier to defend as a single team (FastLane) than as 100 separate teams (each validator, independently). Notably, PFL was designed so that if we get DDoS’d, the validators won’t even notice… and I think many validators may prefer to keep it that way.
  5. To be blunt, full decentralization means that the FastLane team would become redundant… which we don’t like haha.

Our current plan is to begin offering decentralization as an option to validators in ~Q3 2024. As a team, we’d like to finish building a product to run on top of the PFL nodes before we decentralize the base MEV layer and put ourselves out of a job. (Announcement in Q2 2024, but for now think of it as a way for validators to monetize Ethereum Mainnet’s traffic by bringing it to Polygon PoS’s liquidity without the users ever leaving Ethereum) I know this may not be what everyone wants to hear, but it’s the truth :sweat_smile:.

We are open to enshrining the PFL contract… that would actually be great, and we may submit a PIP to that effect shortly.

FastLane Kairos:

Last week, we were pleased to launch PFL 1.99, which included a top of block auction mechanism that is expected to significantly boost validator MEV revenue. This increase is largely due to the value that Kairos offers to statistical arbitrage strategies (stat arb) that previously did not benefit from using the PFL system.

New smart contract address:


You can read about the details of the new top of block mechanism in this thread:

We’ve also added in support for orderflow auctions (“OFAs”). These OFAs must follow specific rules set in the PFL smart contract, and will be delayed by 1-2 blocks to prevent them from being used by potential sandwich attackers. Most importantly, validators must opt in to supporting these OFAs, and can set their own minimum revenue share that the OFA protocols must adhere to for inclusion.

While this style of OFA may seem different from other chains, we want to avoid the conflict of interest around having a single MEV company represent multiple, adversarial parties (users vs validators) in MEV auctions. To that end, FastLane’s involvement in this has simply been to create a trustless smart contract for revenue sharing negotiations between users (represented by OFA protocols) and validators.

MEV Metrics:

MEV revenue, transaction volume, and searcher participation all continue to climb. Although it is not yet pictured, we expect the Kairos update to significantly increase these metrics in the future.

(Think of each competitive opportunity transaction as replacing hundreds, perhaps thousands of spam transactions)


Future Plans:

The FastLane team currently has three projects that we’re working on:

  1. Atlas, an MEV OFA and Intent Settlement Engine that utilizes account abstraction (but not smart wallets) to fulfill intents and protect users from builders and sequencers. Atlas is dApp-aligned, not validator-aligned like PFL. As a result, we do not plan to launch Atlas as-is on Polygon PoS because it would be competing with the PFL relay to capture MEV revenue, which we perceive to be a potential conflict of interest. You can read more about Atlas at the github repo:
  2. An operations relay / auction mechanism. 4337-specced UserOperations that are getting bundled into transactions and propagated via the public mempool are being frontrun by bots, causing a loss for the originating bundler. Our intent (ha) is to remove any sort financial loss for the originating bundler that may disincentivize broadcast and hurt user experience… but we also want to be cognizant of the fact that this generalized frontrunning is profitable for validators, and we are very much validator-aligned on this issue. We’re working on a solution that will make all parties happy - more information soon.
  3. Cross Chain Execution Engine. More details will come with an announcement post Polygon 2.0… but the general idea here is to drive more Ethereum users to Polygon PoS and give them direct, atomic execution and access to dApps on Polygon without them ever having to leave Ethereum. Note that our focus is on atomic execution, which is a higher bar than atomic inclusion. This project will be the fusion of three of our prior projects: PFL, Atlas, and ClearingHouse. We may also team up with with projects like particle network or flashbots / SUAVE for this offering.

We are also working on an MEV solution for zkEVM, but do not expect it to differ significantly in spec from how PFL currently works on Polygon (to be honest, it may be a bit simpler).

Thanks for reading to the end! If you’d like to follow us for frequent updates and alerts, our socials are:

Alex Watts (AKA Thogard)
Cofounder / CEO @ FastLane Labs

1 Like