![\"\"](\"https://fastlane.ghost.io/content/images/2025/02/Top-Gun-Maverick-Mach-10-GIF--1-.gif\")
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:
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.
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:
Everything else occurs within the normal Monad transaction flow.
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:
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.
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.
FastLane is excited to introduce its mainnet points program to provide a clear, structured, and transparent framework for users to participate in the early development of Monad’s economic foundation. As shMON goes live on mainnet, the FastLane Points Program aligns staking, liquidity, lending, and ecosystem engagement into a unified model that rewards sustained contribution and long-term alignment.
This article outlines everything you need to know:
Whether you're here for yield, points multipliers, or long-term participation, this is your definitive guide to FastLane and the FastLane Points Program.
The FastLane Points Program rewards users for deploying MON or shMON across key parts of the Monad ecosystem. Points accrue continuously based on the amount deposited and where those assets are deployed.
All points earned are tied to real on-chain participation, ensuring incentives reflect meaningful contributions to the network’s early capital formation.
shMON is designed to be widely integrated across Monad’s leading dApps and money markets. As the ecosystem matures, users will see shMON available throughout lending protocols, DEXs, automated strategies, and other capital venues across the network.
At mainnet launch, FastLane will prioritize point multipliers for a selective group of partners that represent core pillars of Monad’s early liquidity and capital structure.
Additional partners will be onboarded over time, and new multiplier routes will be introduced as integrations expand.
Users are encouraged to follow FastLane’s public channels closely to stay updated on new incentive destinations and multiplier activations.
Users begin earning points immediately when depositing MON or shMON into qualified on-chain destinations.
Each destination contributes to continuous points-per-second accumulation and may offer additional multiplier opportunities depending on partner integrations and user participation history.
Stake MON to mint shMON and participate in Monad’s core staking layer.
Participants earn:
Deposit MON and redirect all staking yield to shMON holders while maximizing point earnings.
Participants receive:
Deposit MON or shMON into supported lending protocols that integrate shMON at mainnet and in subsequent phases.
Priority shMON markets at launch include:
These integrations form the backbone of Monad’s emerging money market ecosystem.
Provide liquidity to support the shMON–MON trading markets and improve ecosystem-wide execution quality.
Participants can LP in:
FastLane expects vault-based deposit routes—starting with a shMON–MON vault—to go live shortly after mainnet.
Vault deposits will earn points and may qualify for additional multiplier opportunities.
(Details will be announced once final partners are confirmed.)
Multipliers dramatically increase your points-per-second rate.
There are two main categories:
Users earn additional multipliers when depositing into:
These destinations represent key pillars of Monad’s early capital formation and liquidity infrastructure.
(Snapshot completed)
Early supporters will receive superior point accumulation for performing the same mainnet actions as new users.
Multiplier boosts apply to users who:
These users do not receive points automatically, but they will earn points at a faster rate once they deposit real MON into FastLane-supported destinations on Monad’s mainnet.
This reflects our core philosophy:
Testnet ≠ free points, but Testnet = higher multipliers.
FastLane provides two complementary deposit pathways designed to serve different user benefits and strengthen the economic foundation of Monad from day one.
This is the primary mode for users who want exposure to shMON’s multi-source yield engine, which is powered by 7+ yield components across the FastLane execution stack.
These sources include:
FastLane will publish detailed definitions and fee splits for each yield source as mainnet matures.
Best for high-engagement participants who want maximum points acceleration and want to strengthen shMON’s competitive edge.
This creates a powerful ecosystem flywheel:
Degen redirection increases shMON APY → Higher shMON APY, deepens liquidity, and strengthens demand → Stronger demand increases capital efficiency → A stronger yield engine benefits all shMON holders
FastLane’s incentive system operates under three core principles designed to reinforce sustainable participation, reward meaningful contributions, and build long-term alignment across the Monad ecosystem.
Points are earned exclusively through real mainnet deposits.
By tying rewards to actual on-chain participation, the program ensures that incentives reflect genuine engagement and clear capital commitment, forming a reliable foundation for Monad’s early economic development.
While testnet users and early contributors do not receive automatic point allocations, their early commitment is reflected through higher point-earning rates upon joining on mainnet.
This recognizes the foundational influence they had in shaping FastLane’s development and ensuring the protocol’s readiness for launch.
It is a model that remains fair to new users while giving thoughtful weight to those who helped us build from the beginning.
As Monad evolves, additional destinations, integrations, and multiplier pathways will unlock, enabling users to deepen their participation and benefit from a compounding incentive model over time.
This approach preserves fairness for newcomers while ensuring that sustained contributors continue to be rewarded as the ecosystem grows.
The FastLane Points Program will continue to evolve after Monad mainnet, introducing new ways for users to participate, earn, and engage across the ecosystem. As more partners integrate shMON and additional destinations come online, users will unlock a wider and more dynamic set of opportunities.
Upcoming enhancements include:
These upcoming features will make participation more interactive, more rewarding, and more connected to FastLane’s broader ecosystem vision. As the network matures, the Points Program will grow into a more creative, competitive, and community-aligned experience that encourages both collaboration and long-term commitment.
Users can begin earning points from the moment Monad mainnet launches.
Participation is simple and designed to be accessible for both new and experienced users.
Click Stake → Mint shMON → Start earning yield + points.
Both modes begin accruing points as soon as assets are deposited.
Amplify your point accumulation by deploying MON or shMON into supported earning venues across the ecosystem, including:
Each destination offers additional multiplier opportunities that increase your overall points-per-second rate.
The leaderboard will launch shortly after mainnet, accompanied by a unified interface that displays your accumulated points and highlights all available multiplier opportunities across the ecosystem.
FastLane Points Protocol will go live on Monday, Nov 24, 2025.
🏆 Track your growth at: shmonad.xyz/points
Stay connected with FastLane’s official channels for announcements, integrations, multiplier updates, and ecosystem-wide news.
The cryptocurrency world has evolved significantly over the past decade, with growing recognition, adoption, and utilisation by institutions, businesses, and end-users alike. As the gap between the crypto world and the real world closes, the demand for highly scalable, cost-effective, and robust blockchains has surged. Monad is set to meet this demand with a next-generation architecture, allowing them to serve the incoming masses at a global scale.
As a team with years’ worth of experience and a stellar track record in driving innovation and security in blockchain-based ecosystems, our entry into the Monad project and ecosystem has been guided by our passion for Monad’s mission and our desire to contribute by answering a key question: How can we make the Monad experience even better, faster, and more robust for users and businesses?
After years of research, engineering, and testing, we at FastLane have developed a number of solutions to further enhance the already promising experience on Monad. Quite frankly, we’ve been excited to unveil these innovations to the public for a long time.
In this article, we take the first step in revealing one of our many solutions launching exclusively on Monad: The FastLane shBundler.
Today, the greatest challenge to mass blockchain adoption is User Experience (UX). Despite numerous breakthroughs and innovations that offer low-latency and low-cost transactions, many blockchain projects still fall short due to poor high-level abstractions and UX provisions for businesses, institutions, and general consumers.
To give Monad and its users a competitive edge with top-tier UX and to sidestep this common pitfall, we turned to a solution widely recognised for enabling exceptional user experiences in other ecosystems: ERC-4337, the account abstraction standard.
ERC-4337 introduces intuitive UX features once considered impossible in blockchain systems, including feeless (gasless) transactions, SSO-based logins, and account recovery. Recognizing this potential, we built the FastLane shBundler—a highly robust, modular, and domain-specific ERC-4337-compliant bundler—as the core infrastructure supporting Monad’s account abstraction layer.
The FastLane shBundler introduces a number innovations and new functionalities, including:
Let’s briefly explore these innovations:
Most ERC-4337-compliant bundler implementations operate without the consensus validator or block-producing node being aware of the bundler’s processes, such as UserOp submissions and solving. As a result, these bundlers rely on unnecessary middleware and intermediaries to coordinate and deliver their final bundled transactions, introducing significant latency and inefficiencies that degrade execution quality for users and the broader ecosystem.
Recognizing these inefficiencies and leveraging our understanding (and assumptions) of Monad’s architecture, we arrived at what we call Validator-based Bundling—an approach to streamlining the entire account abstraction supply chain and execution process.
Validator-based bundling is a bundler scheme that eliminates inefficient steps and unnecessary intermediaries by vertically integrating the bundler infrastructure directly into the native stack of a Monad consensus validator. This design is accessible by running the FastLane node software, enabling a Monad consensus validator to function as a bundler—and even as a paymaster, if they prefer—for the account abstraction layer, unlocking new revenue opportunities for validator operators and their stake delegators.
![\"\"](\"https://fastlane.ghost.io/content/images/2025/02/shbundler-1.jpg\")
To facilitate this bundling scheme, we introduced the FastLane Relay Network—an overlay network to facilitate the reception and relaying of UserOps.
Additionally, a neat feature unlock we envision from Validator-based bundling is inclusion preconfirmations. In the ideal scenario—where a FastLane-powered consensus validator processes a UserOp—users could receive sub-second feedback responses for their transaction submissions. This significantly improves the user experience, complementing what Monad’s core design offers by default.
Essentially, validator-based bundling in account abstraction provides users with a superior user experience by maximizing the potential of Monad consensus validators running FastLane's software.
Monad’s Deferred Execution (a.k.a. Asynchronous Execution) optimizes transaction throughput and maximizes bandwidth efficiency by decoupling consensus from execution. Instead of executing transactions immediately after validation, Deferred Execution delays execution until a predefined future block—reducing overhead seen in earlier blockchain systems.
For core system performance objectives, this provides a significant advantage in achieving peak efficiency gains. However, for business and end-user applications, it introduces a new risk—particularly for paymasters: an attack vector we’ve identified and termed Delayed Solvency Attacks.
A Delayed Solvency Attack occurs when the bundler’s simulation doesn’t match the reality at the time of execution. Because of asynchronous execution, the bundler’s simulation will be at least 1 block behind the “true” current state of the network. So when the actual execution happens, the state may have changed. For example, a malicious user or paymaster may move their funds in between the simulation and execution of the transaction, causing the execution to revert and the bundler having to pay the gas costs. (Colloquially, this could be considered “rug-pulling” the paymaster.)
Imagine you’re a handyman hired to remodel a bathroom. Your client lacks cash on hand but writes you a check and even shows proof of a healthy bank balance. Reassured, you purchase materials and complete the job. But when you try to cash the check, the bank tells you the funds are gone—the client withdrew everything. You’ve now lost time, money, and effort. Similarly, paymasters in a Delayed Solvency Attack front transaction costs only to find that the expected reimbursement has vanished before it can be claimed.
![\"\"](\"https://fastlane.ghost.io/content/images/2025/02/Schrodingers-Cat-Meme.jpg\")
Delayed Solvency Attacks emerge due to Deferred Execution in Monad, where transactions are ordered in real-time but executed with a delay—specifically, two blocks after the block in which they are included. This creates a two-block execution lag, posing challenges for actors and observers, such as paymasters, as simulations cannot reliably predict the system’s final state post-execution.
While building shBundler, we realized this would pose a significant problem—not just for us, but for the entire Monad ecosystem. So, we set out to develop a solution—because when life gives you lemons, you make lemonade, and lucky for us, we’re in the lemonade-making business.
Our solution? A robust escrow system, powered by a super holistic resource mechanism natively integrated into our shBundler deployment, leveraging Monad’s core security to ensure that funds designated for reimbursing the paymaster remain securely reserved in the system until after block execution—when the paymaster can successfully claim them. All of this happens seamlessly, without degrading user experience or execution efficiency for any party involved.
Our escrow system for shBundler ensures that users, businesses, and—most importantly—key infrastructure providers for account abstraction, such as paymasters, can engage safely while benefiting from the top-notch UX that shBundler offers, just as they would on any other system before Monad.
Good builders ship good tech. Great builders ship tech that simplifies the lives of everyday users. The advancements and discoveries made during the development of shBundler have been an invaluable learning experience, deepening our understanding of key aspects of Monad. But ultimately, the thoughtful design choices behind shBundler serve a greater purpose: enabling FastLane’s global community to access and use Monad from Day 1—even without holding its native currency.
![\"\"](\"https://fastlane.ghost.io/content/images/2025/02/Mawuko.eth-Meme.jpg\")
This brings us to the cherry on top of shBundler—our very own FastLane Paymaster, designed to abstract and streamline the fee system for users while delivering the intuitive experience we believe should be the standard in the cryptocurrency space. We’re actively integrating with top DEXs, wallets, and other key apps and infrastructure providers to extend this fee-abstracted experience across the entire Monad ecosystem.
With the FastLane Paymaster, we’re working towards enabling:
For many users and businesses, the FastLane Paymaster will be a critical piece of our 4337-based account abstraction layer, delivering some of the most transformative UX improvements in any blockchain ecosystem.
With the launch of shBundler—featuring validator-based bundling, a robust escrow system, and seamless fee abstraction—FastLane is shaping and advancing the account abstraction landscape on Monad. This is just the beginning, and we’re excited to push the boundaries of what’s possible.
One more thing—as firm believers in building in public and open-source collaboration, we’re thrilled to announce that shBundler is now officially open to all. You can find our repository here: FastLane shBundler GitHub Repo. We invite developers, businesses, and community contributors to explore, integrate, and innovate with shBundler, and we can’t wait to see what you build.
","comment_id":"67a6bdb2faa37b0001cf892b","feature_image":"https://fastlane.ghost.io/content/images/2025/02/monads-ux.png","featured":false,"visibility":"public","created_at":"2025-02-07T18:13:06.000-08:00","updated_at":"2025-02-07T19:38:44.000-08:00","published_at":"2025-02-07T19:38:44.000-08:00","custom_excerpt":null,"codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":null,"tags":[{"id":"69210ae56c6be40001462281","name":"#0xmawuko","slug":"hash-0xmawuko","description":null,"feature_image":null,"visibility":"internal","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/404/"}],"primary_tag":null,"url":"https://fastlane.ghost.io/the-fastlane-shbundler/","excerpt":"Introduction\n\nThe cryptocurrency world has evolved significantly over the past decade, with growing recognition, adoption, and utilisation by institutions, businesses, and end-users alike. As the gap between the crypto world and the real world closes, the demand for highly scalable, cost-effective, and robust blockchains has surged. Monad is set to meet this demand with a next-generation architecture, allowing them to serve the incoming masses at a global scale.\n\nAs a team with years’ worth of e","reading_time":6,"access":true,"comments":false,"og_image":"https://fastlane.ghost.io/content/images/2025/02/monads-ux-1.png","og_title":"The FastLane shBundler: Supercharging Monad’s UX for Users and Businesses.","og_description":"The cryptocurrency world has evolved significantly over the past decade, with growing recognition, adoption, and utilisation by institutions, businesses, and end-users alike. ","twitter_image":"https://fastlane.ghost.io/content/images/2025/02/monads-ux-2.png","twitter_title":"The FastLane shBundler: Supercharging Monad’s UX for Users and Businesses.","twitter_description":"The cryptocurrency world has evolved significantly over the past decade, with growing recognition, adoption, and utilisation by institutions, businesses, and end-users alike. ","meta_title":"The FastLane shBundler: Supercharging Monad’s UX for Users and Businesses.","meta_description":"The cryptocurrency world has evolved significantly over the past decade, with growing recognition, adoption, and utilisation by institutions, businesses, and end-users alike.","email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null},{"id":"6795e2c8dae1750001fa035d","uuid":"beaf0fdd-b43e-40a9-a98d-2955b38cba6e","title":"On State Locks, State Deltas, and What Everyone Is Getting Wrong About Application-Specific Sequencing","slug":"state-locks-and-deltas","html":"Any state with utility / value that decreases upon each sequential access goes through the MEV (or PGA) crucible, where it's priced relative to what others are willing to pay for it.
MEV relays reduce the externalities of the competition (e.g., spam) by increasing the predictability of sequencing. This consequently reduces the expectation of profit from probabilistic approaches (e.g., spam again) to accessing state while it's still valuable.
Application-specific sequencing, however, is different. While MEV relays reduce the utility of redundant attempts to access contested state, ASS has the potential to make state non-contested. While this can be achieved with state locks (yuck), the more interesting pattern is to sequence state deltas rather than state absolutes.
Sequencing state deltas can be done without disrupting composability by inverting the typical model and applying a lock on the state delta (typically a transaction) rather than the state itself.
Envision state with a current value of 100. Imagine that this state is inside a smart contract with byte code specifying that if its value reaches 150 or higher, the next actor to interact with it will be paid $100.
By locking the state delta rather than the state itself, composability is preserved. Other entities can still access the state, potentially with their own state delta locks. In the delta model, we are effectively saying that \"it isn't the state itself that's valuable, but rather the state delta, without which the $100 withdrawal wouldn't be possible.
What's interesting is that state delta locks typically happen at an entirely different part of the \"transaction supply chain\". Unlike absolute state locks, which are hardcoded into smart contracts, state delta locks capture / internalize value by atomically bundling transactions. This usually happens at the frontend or wallet level of the stack and therefore does not require any updates to the app's or wallet's smart contract.
One challenge with state delta locks is that the actual value of the state can change, which may reduce the value of our state delta lock. For instance, if at the time our transaction lands the state's value is 100 then our +60 will put it over the 150 threshold and we'll be rewarded with $100, but if for some reason the state's value is only 80 then our +60 will put the post-tx state at 140 and the $100 withdrawal we locked with the state delta will fail.
This may seem like a tricky problem, but oftentimes it can be solved with some simple smart contract logic.
FastLane's Atlas, which sequences and bundles metatransactions from different actors into a single atomic transaction, introduces two tools to address this issue:
State delta locks unlock potential across various domains:
This approach likely doesn’t match the typical mental image that many have of an application-specific sequencer, despite being the only one in production today. Its non-conformity to the status quo is precisely what makes it so disruptive in the infrastructure-dominated MEV supply chain. State delta locks shift power from relays, block builders, and other infrastructure to frontend and wallet-level entities, aligning incentives with users where it belongs—all without disrupting composability.
Already live on Base, Arbitrum, BNB, Polygon, and Monad devnet, this mechanism supports use cases such as MEV refunds, OEV, and RFQs. As teams begin to explore this paradigm, its potential to reshape DEXs, lending markets, prover markets, token sniping bots, bridges, gaming, and more is becoming increasingly clear.
Unlike many \"hot narratives\" that fade anticlimactically, application-specific sequencing is real, available today, and surprisingly easy to integrate. We've only scratched the surface of what’s possible.
","comment_id":"6795e2c8dae1750001fa035d","feature_image":"https://fastlane.ghost.io/content/images/2025/01/alex-blog.png","featured":false,"visibility":"public","created_at":"2025-01-25T23:22:48.000-08:00","updated_at":"2025-01-30T18:01:51.000-08:00","published_at":"2025-01-30T17:45:40.000-08:00","custom_excerpt":null,"codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":null,"tags":[{"id":"67352f179e11f600014e89ad","name":"Research","slug":"research","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/research/"},{"id":"6616c1e63db05d0001fa803d","name":"Atlas","slug":"atlas","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/atlas/"}],"primary_tag":{"id":"67352f179e11f600014e89ad","name":"Research","slug":"research","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/research/"},"url":"https://fastlane.ghost.io/state-locks-and-deltas/","excerpt":"A Broad Explanation of MEV and the Value of Accessing State\n\nAny state with utility / value that decreases upon each sequential access goes through the MEV (or PGA) crucible, where it's priced relative to what others are willing to pay for it.\n\nMEV relays reduce the externalities of the competition (e.g., spam) by increasing the predictability of sequencing. This consequently reduces the expectation of profit from probabilistic approaches (e.g., spam again) to accessing state while it's still va","reading_time":5,"access":true,"comments":false,"og_image":"https://fastlane.ghost.io/content/images/2025/01/alex-blog-4.png","og_title":"On State Locks, State Deltas, and Application-Specific Sequencing","og_description":"A Broad Explanation of MEV and the Value of Accessing State\nAny state with utility / value that decreases upon each sequential access goes through the MEV (or PGA) crucible..","twitter_image":"https://fastlane.ghost.io/content/images/2025/01/alex-blog-3.png","twitter_title":"On State Locks, State Deltas, and Application-Specific Sequencing","twitter_description":"A Broad Explanation of MEV and the Value of Accessing State\nAny state with utility / value that decreases upon each sequential access goes through the MEV (or PGA) crucible..","meta_title":"On State Locks, State Deltas, and Application-Specific Sequencing","meta_description":"A Broad Explanation of MEV and the Value of Accessing State\nAny state with utility / value that decreases upon each sequential access goes through the MEV (or PGA) crucible..","email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null},{"id":"675b499d41e24f0001385bc3","uuid":"bca54c96-c282-440d-8dc2-a0fb28d035e7","title":"An Introduction to Blockchain Mechanism Math, Terminology, and Hieroglyphics for Deeply Casual People who want to Sound Smart when Discussing White Papers with their Peers","slug":"blockchain-intro","html":"By Alex Watts et al.
Abstract:\n\n
Mechanism Designers working in DeFi really like writing white papers. They like it a lot. Perhaps too much. They also like writing these papers in an ancient, hieroglyphics-based language that is difficult for a normal, socially-adjusted person to decipher. This is unfortunate because most of the math and game theory is actually quite simple once you understand their alien terminology. In this paper, I'll give you the tools you'll need to sound smart when discussing these white papers with your peers, which is a very important skill set because in all likelihood your peers are also trying really hard to sound smart.
Let's start with this section - the \"abstract.\" This section is really just a summary of the white paper. In this section, the Mechanism Designers will summarize a problem, then they'll summarize their solution, and then - if they're good - they'll also summarize the shortcomings of the paper. We may never know why the Mechanism Designers like to call this section an \"abstract\" rather than a \"summary\" - in fact, we'll probably never know why they do most of the things that they do. But by reading this paper, hopefully you'll be better able to understand what they're doing - and, if you're into this kinda thing, who they're doing it to.
Intuitively, this paper doesn't have any shortcomings. But if I had to pick only one, it'd be that a lot of the information in this paper is deliberately wrong. Very wrong. I'm way off on a lot of these explanations. But I'm not being byzantine - which means \"dishonest\" or \"adversarial\", by the way, and two thousand years ago it probably would've been flagged by HR departments as racially offensive against the citizens of the Byzantine empire. So yeah, I'm not being byzantine - I'm just oversimplifying things to make the concepts easier to understand in expectation.
A set is a group of things.
\nBy the way, if your first thought after reading that last sentence was\n\"that definition left out a lot!\" then be warned: it’s all\ndownhill from here.
Sets are represented with an uppercase letter (such as
When sets are defined, they’re often surrounded with brackets.\nFor example, a set of three numbers could be written as
Members of the set are represented with a lowercase letter (such\nas \\(x\\) or
There are a handful of funny-looking symbols that these Mechanism\nDesigners like to use in their white papers that you should probably\nlearn:
\n\\(\\in\\) means \"in\" and is used\nto show membership in a set
\nWhen you see \\(x \\in X\\), that\nmeans that \\(x\\) is a member of the set\n\\(X\\).
Example: if \\(X = \\{2,\n4, 6, 8, 10, 12, 14, 16, 18, 20 \\}\\), then
\\(\\cup\\) means \"union\" and is\nmeant to take two sets and combine all of their members together. This\ncombination process overwrites their redundancies so that in the new\nmerged set there’s only one copy of each duplicate.
\nWhen you see \\(X \\cup Y\\), that\nmeans you’re combining sets \\(X\\) and\n\\(Y\\).
Example: if \\(X = \\{1,\n2, 3, 4 \\}\\), and \\(Y = \\{3, 4, 5\n\\}\\) then \\(X \\cup Y = \\{1,2,3,4,5\n\\}\\).
\\(\\cap\\) means \"intersection\"\nand is meant to take two sets and make a new set only out of their\nredundancies so that there’s nothing in the new set that didn’t exist in\nboth of the parent sets.
\nWhen you see \\(X \\cap Y\\), that\nmeans you’re taking the intersection of sets
Example: if \\(X = \\{1,\n2, 3, 4 \\}\\), and \\(Y = \\{3, 4, 5\n\\}\\) then \\(X \\cap Y = \\{3,4\n\\}\\).
\\(\\subset\\) means \"sub set\" -\nall of the elements of the first set exist in the second set.
\\(\\supset\\) means \"super set\" -\nall of the elements of the second set exist in the first set. Note that\nif you see this then you’re dealing with a particularly troublesome\nbrand of Mechanism Designer and you should be on your guard for more\ntrickery.
\\(:\\) (the colon) typically\nmeans \"if\" and is often seen together with a funny looking upside-down\nA. Speaking of which...
\\(\\forall\\) means \"for all\" and\nis meant to iterate through a set, often times in the creation of\nanother one.
\nIf you’re a programmer, whenever you see
Often times \\(\\forall\\) and\n\\(:\\) are used to iterate through a set\nto create a new one.
Example: Consider this monstrous expression:\n\\(Y = \\{2x, \\ \\forall x\\in X : x>3\n\\}\\). The english translation is something along the lines of\n\"\\(Y\\) is a set of numbers that was\ncreated by taking each of the \\(x\\)’s\nin \\(X\\) that were greater than
Warning: When it comes to defining sets,\nMechanism Designers really like to move variables around or remove them\nentirely. They do this not to confuse you but to confuse each other -\npresumably to increase their job security. Take, for example,
\\(\\mathbf{card}(X)\\) or
There are a handful of prestigious sets that you should know:
\n\\(\\mathbb{Z}\\) is the set of all\nintegers
\\(\\mathbb{R}\\) is the set of all\nreal numbers
\\(\\mathbb{E}\\) isn’t a set of\nnumbers at all - it means \"the expectation of\" and is used in\nprobability. But it looks similar to these fancy sets, so be careful not\nto get it mixed up. That’s how they get you.
\\(\\mathbb{C}\\) is the set of\nendless agony. If you see it, run.
The Mechanism Designers will typically use these fancy sets when\ndefining a new set. For example, they might say
Two things that Mechanism Designers simply can’t get enough of are\nintuitions and expectations.
\n\"Intuitively...\" or \"The intuition is...\" means that\nthe Mechanism Designer is about to tell you something that they think is\nso obvious that they won’t explain it because only a moron would\ndisagree. Unfortunately, for a Mechanism Designer
\n\"The expectation is...\" or \"... in expectation.\" means\nthat the Mechanism Designer is about to do some math, and we can expect\nthat the math will probably involve probabilities.
\\(P(y)\\) is the probability of\nevent y occuring. Example: for a coinflip,
\\(P(y \\cap z)\\) is the\nprobability of event y and event z both occuring. This is also\nabbreviated as \\(P(y, z)\\).
\\(P(y \\cup z)\\) is the\nprobability of event y or event z occuring.
\\(P(y | z) =\\) the probability\nof event \\(y\\) occuring if we\nassume event \\(z\\) has already occured.\nFor example, assume a coinflip, but this time there is a cheater using a\nweighted coin that can change the odds from 50-50 to 80-20. In that\ncase, \\(P(\\text{heads} | \\text{cheater bet on\nheads} | \\text{cheater's flip}) = 0.80\\) and
\\(\\mathbb{E}[X] =\\) The expected\n(or probabalistic, if you want to sound smart while actually being\nwrong) value of X. For example, if there’s a game with a coinflip and\nyou get $0 for tails and $1 for heads then
\\(\\mathbb{E}[X|y] =\\) The value\nof \\(X\\) in expectation if we assume\nthat \\(y\\) happened. For example, if\nthere’s a game with a coin flip and you get $0 for tails and $1 for\nheads, but there’s a cheater who is using a weighted coin that can\nchange the odds from 50-50 to 80-20 (against you) then
Now imagine that the cheater gets to flip some of the time and\nyou get to flip the coin the rest of the time:
\\(\\mathbb{P}(x)\\) is just a\nfancy way of saying \\(P(x)\\). Some\nMechanism Designers insist that if
This sigma may have been an key part of your fraternity or sorority’s\nidentity during college, but it has another, less-important use case:\nmath. \\[\\sum^n_{x=1}f(x) = \\text{ the sum of\n$f(x)$ for all $x$ values from $1$ to $n$}\\] In other words, it’s\na \"for loop\" that sums the different values of
\nMath Example: \\[\\sum^4_{x=1}2x = 2+4+6+8 =\n20\\]
Note that you can replace the range notation of
Mechanism Designers really like talking about whether
This \"pi from the uncanny valley\" is actually a product:
\n\\[\\prod^n_{x=1}f(x) = \\text{ the product\nof $f(x)$ for all $x$ values from $1$ to $n$}\\]
\nThe best way to explain it is through a comparison:
\n\\[\\sum : \\prod :: \\text{addition}:\n\\text{multiplication}\\] If you don’t remember the : :: :\ncomparison format from the SATs then you are beyond saving.
\nUnless \\(x\\) and
Get excited because it’s finally time for everyone’s favorite\nsubject: calculus!
\n\\[f(x)\\frac{d}{dx} = f'(x)\n= \\text{the derivative of} f(x)\\]
\nDerivatives measure the rate that one thing is changing (probably\n\\(x\\)) relative to the rate another\nthing is changing (probably \\(y\\), but\nmaybe \\(t\\) if the Mechanism Designer\nis fully domesticated). If \\(f(x)\\) is\na line, then its derivative is the slope of the line. In other words,\nit’s the rate of change of the line. If there is a line that graphed\n\"time\" on the x-axis and a car’s distance from the starting point on the\ny-axis, then the derivative of that line would be the car’s velocity\n(the rate that the position is changing relative to the rate that time\nis changing). If the velocity of a car is on the y-axis, then the\nderivative of that line would be the car’s rate of acceleration. This is\nwhat they teach in calc 1, but that you haven’t needed to use since\nhighschool because it only recently became cool to discuss \"novel\nmechanisms.\" It looks like your teacher was right all along.
\n
This squigly line is an \"integral.\" Fun fact - there are no integrals\nin the bible.
\n\\[\\int^x_yf(x) = \\text{the integral, aka\n"antiderivative." }\\]
\nIf a function \\(f(x)\\) creates a\nline on a graph, its integral is the area underneath it. Even your\nhighschool teacher would’ve admitted that it’s unlikely that you’ll need\nto use integrals in your day-to-day job. After all, integrals are pretty\nuseless unless you’re either a math teacher or having to deal with the\nprobabilities of expected probabilities in a Mechanism Designer’s white\npaper. Speaking of which...
\n\\(F_X(x)\\) is a cumulative\ndistribution function, aka CDF. If you have a distribution
\nExample: If \\(X = \\{2, 4, 6,\n8, 10, 12, 14, 16, 18, 20 \\}\\) and \\(x\n= 8\\), then \\(F_X(8) = 0.30\\)\nbecause when you draw a random number from
\\(f_X(x)\\) is a probability density\nfunction, aka PDF. It is basically saying the probability that a\nrandomly chosen value from \\(X\\) will\nequal \\(x\\).
\nExample: If \\(X = \\{2, 4, 6,\n8, 10, 12, 14, 16, 18, 20 \\}\\) then
\nExample2: \\(X = \\{2, \\ 2, \\\n6, 8, 10, 12, 14, 16, 18, 20 \\}\\) (note that we replaced the 4\nwith another 2) then \\(f_X(2) = 0.20\\)\nand \\(f_X(4) = 0.0\\).
\nNote that \\(F_X(x)\\) is very useful in\nanalyzing auctions because if \\(X\\) is\nthe set of all bids, \\(F_X(x)\\) is the\nprobability that our bid \\(x\\) is\ngreater than a randomly selected bid, and
\nThe calculus from the previous section comes into play because the\nprobability density function \\(f_X(x)\\)\nis the derivative of the cumulative distribution function
\\[f_X(x) = F_X(x)\\frac{d}{dx}\\]\n\\[F_X(x) = \\int^{\\infty}_{- \\infty}\nf_X(x)\\]
\nWe’ll often have to use calculus to get back and forth between how\nlikely someone is to bid something, and how likely a bid is to be higher\nthan another bid.
\nPeople typically refer to the set of players (so-called) in an\nauction as \\(P\\), and a player in the\nset of players as \\(i\\). Nobody knows\nwhy \\(i\\) was chosen over
\nIf the bids are referred to as \\(b\\)\nthen \\(b_i\\) would be
\n
Sometimes a Mechanism Designer might want to share a new formula with\nyou that is similar to an existing one, but that’s just\nslightly different. If you see weird symbols over or under\nletters, it probably means the equation or variable has had something\nadded to it to make it extra special. Here are some\nexamples:
\nIf \\(i\\) is a player (bidder) in\nan auction, \\(i'\\) might be his\nsworn nemesis.
If \\(b_i\\) is the bid of player\n\\(i\\),
Warning: You might be wondering, \"Aren’t all\nbids optimal bids? Why would player
If \\(g(x)\\) is a function that\nworks for everyone, \\(g_i(x)\\) is a\nfunction that only works for special players like
If \\(t_i^2\\) isn’t meant to be\n\\(t_i\\) squared, it may mean that it’s\nthe second \\(t\\) belong to
Mechanism designers use the
While this may mean multiplication, if you see it by itself inside of\na function then it probably means the Mechanism Designer is being lazy\nand didn’t want to copy and paste their math. You’ll typically see this\nonly after you’ve already seen the full version. For example, if you’re\nunlucky enough to see something like \\(y = z +\ng(x^2+\\mathbb{E}[Z] - \\epsilon )\\), then later on you might see\n\\(a = 2z + g(\\cdot)\\), where the
If the Mechanism Designer wants to prove why something is\nthe way that it is, they might use this arrow thingy. For example, if a\nMechanism Designer wants to show that size of his mechanism proves that\nhe’s really smart, it might look like:
A good exercise is to assess whether or not you actually understood\nthat equation. If you did, it means you’ve been paying attention to the\npaper! Unfortunately, it also means you’re less cool in expectation. The\nactual english translation is \"If the number of things in the\nmechanism made by player i is greater than the number of things in the\nmechanism made by player j, for all possible player j’s in the world who\naren’t player i, then it follows that the IQ of player i has a 100%\nchance (minus a teeny-tiny percent) of being greater than a randomly\nselected IQ from the distribution of all the IQs in the world.\"
\nMechanism Designers love defining variables. Unlike their sworn\nenemies the mathematicians, Mechanism Designers really like for their\nvariables to be exotic, and so they’ll often use lower-case\ngreek letters. It’s a best practice to always have a Greek alphabet\navailable when reading a mechanism’s white paper so that you can quickly\ncheck to see if the designer is referring to a variable - which is\npretty normal - or using some sort of ritualistic-sacrifice-based\nsummoning math - which is a red flag. Intuitively.
\nWhen auction players have to figure out what their bid for an item is\nbefore they know what the value of the item is, the auction is said to\nbe ex ante. If the value of the item is known at bidding time,\nthe auction is said to be ex post. This is one of the rare\ncases in which the obscure auction language is actually less wordy than\nwhat its describing. Way to go, Mechanism Designers! You did it!
\nA first-price auction is one in which the highest bidder pays what\nthey bid. A second-price auction is one in which the highest bidder pays\nwhat the second-highest bidder bid. Mechanism Designers really like\nsecond-price auctions because they pay the beneficiary more than a\nfirst-price would, but they’re also easier to cheat and therefore\nrequire a more robust mechanism.
\nWarning: Never ask a mechanism designer why\nsecond-price auctions are better than first-price auctions. It’s like\nasking your wife if she’s had any interesting dreams recently, or if\nthat girl at work she doesn’t like has caused any more problems. If a\nMechanism Designer ever brings up the subject of first-price vs\nsecond-price, just look them directly in the eyes and then tell them\nwith a firm voice, \"With a properly designed mechanism and sealed\nbids, a second-price auction at equilibrium leads to more auction\nrevenue in expectation, obviously!\" This response is a\nstrictly-dominant strategy.
That’s what the intuition is, anyway.
\nA utility function, often called a payoff function, is how valuable\nsomeone thinks something is. It’s typically measured in\nexpectation, but this was developed by the French so the
\nExample: If \\(U(x)\\)\nis a utility function, then \\(U_i(b_i,\nb_{-i})\\) is the payoff to player
Bid shading occurs when bidders bid less than their true value - in\nother words, \\(v_i > b^*_i\\). This\ntypically happens because the bidder can make more money by bidding\nbelow their true value. Or, in the native tongue of Mechanism Designers,\n\"The utility function of bidders is optimized when their private\nvaluations exceed their equilibrium bid.\"
\nSomething is considered incentive compatible (IC) if the participants\nin an auction are willing to bid their true value. Every bidder
A Bayesian-Nash Equilibrium (or, as the kids say these days, a \"BNE\")\nexists when there are multiple rounds and each bidders’ optimal strategy\n(AKA their \"Best Response\" or \\(br_i\\)\nor \\(s^*_i\\)) stays the same for each\nround. In other words, they won’t benefit from using any \"trick plays\"\nor \"bamboozles.\"
\nNote that a mechanism with incentive compatibility is considered\nsignificantly better than a mechanism with just a bayesian-nash\nequilibrium. If two Mechanism Designers meet in the wild and one of them\nhas an IC mechanism and the other has a BNE mechanism, then the wife and\nchildren of the BNE designer will instinctively join the tribe of the IC\ndesigner and the BNE designer will have to start rebuilding his\nmechanism and his family from scratch. Mother nature is cruel, but\nefficient.
Nobody actually knows what credible neutrality means. This\nhas led to many Mechanism Designers making up their own definitions,\npresumably using their intuition. Unfortunately, these different\ndefinitions of credible neutrality are not credibly neutral,\nwhich is why the term remains undefined.
\nThe fair exchange problem refers to the difficulties of\ngetting the parties of a trade to actually do what they promised they’d\ndo, such as paying a bid or selling an asset at a certain price.\nMechanism Designers love making people do things, so this is\none of their favorite problems to solve.
\nWhen someone refers to a free look problem, know that you’re\ntalking to an actual human being - a Mechanism Designer will always out\nthemselves by calling it a fair exchange problem. Usage of the\nterm \"optionality\" is a red flag but still inconclusive.
The conclusion section of a Mechanism Designer’s white paper is a\nresult of feeding the rest of their paper into a LLM model and then\nasking it to generate a summary. This is why nobody ever actually reads\nit, and neither should you. I’d also like to thank my co-author, Et\nAl.
\n\n\n","comment_id":"675b499d41e24f0001385bc3","feature_image":"https://fastlane.ghost.io/content/images/2025/01/OG-Research--1-.png","featured":false,"visibility":"public","created_at":"2024-12-12T12:37:49.000-08:00","updated_at":"2025-01-04T23:54:24.000-08:00","published_at":"2025-01-03T14:28:21.000-08:00","custom_excerpt":null,"codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":"https://www.fastlane.finance/blog/blockchain-intro","tags":[],"primary_tag":null,"url":"https://fastlane.ghost.io/blockchain-intro/","excerpt":"By Alex Watts et al.\n\nAbstract:\nMechanism Designers working in DeFi really like writing white papers. They like it a lot. Perhaps too much. They also like writing these papers in an ancient, hieroglyphics-based language that is difficult for a normal, socially-adjusted person to decipher. This is unfortunate because most of the math and game theory is actually quite simple once you understand their alien terminology. In this paper, I'll give you the tools you'll need to sound smart when discussi","reading_time":16,"access":true,"comments":false,"og_image":"https://fastlane.ghost.io/content/images/2025/01/OG-Research--1--2.png","og_title":"An Introduction to Blockchain Mechanism Math, Terminology, and Hieroglyphics for Deeply Casual People","og_description":"Abstract:\nMechanism Designers working in DeFi really like writing white papers. They like it a lot. Perhaps too much. They also like writing these papers in an ancient, hieroglyphics-based language that is difficult for a normal, socially-adjusted person to decipher.","twitter_image":"https://fastlane.ghost.io/content/images/2025/01/OG-Research--1--1.png","twitter_title":"An Introduction to Blockchain Mechanism Math, Terminology, and Hieroglyphics for Deeply Casual People","twitter_description":"Abstract:\nMechanism Designers working in DeFi really like writing white papers. They like it a lot. Perhaps too much. They also like writing these papers in an ancient, hieroglyphics-based language that is difficult for a normal, socially-adjusted person to decipher. ","meta_title":"An Introduction to Blockchain Mechanism Math, Terminology, and Hieroglyphics for Deeply Casual People","meta_description":"Abstract:\nMechanism Designers working in DeFi really like writing white papers. They like it a lot. Perhaps too much. They also like writing these papers in an ancient, hieroglyphics-based language that is difficult for a normal, socially-adjusted person to decipher.","email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null},{"id":"66c42e1b554ada0001b29061","uuid":"a82cbe2c-51f3-4d06-9a9b-4127cb6a1ca8","title":"Introducing Rocketboost, powered by Atlas and the world’s first fully onchain DRFQ","slug":"introducing-rocketboost","html":"The Atlas Protocol is the world’s first generalized execution abstraction protocol for the EVM, providing app and frontend developers the ability run intent or MEV orderflow auctions to capture value for their users and stakeholders. Atlas developers can build and configure their “Atlas Module” (an Atlas DappControl contract) for their use case and value flow requirements, including: OEV auctions, backrun OFAs, intents/swap RFQs, rebalancing auctions and LVR resistant AMMs/hooks.
Having successfully concluded our audit of the core Atlas Protocol with the help of Spearbit, we have deployed our Mainnet Beta of Atlas Core 1.0 to Polygon PoS, and soon to all other major EVM chains. We are excited to be working with several exciting launch partners to be announced soon as we rollout Atlas everywhere the EVM shines, but in the meantime, we thought we’d drop something pretty cool for the community to chew on, try out and fork: Rocketboost, our Atlas skunkworks playground for new Atlas modules, featuring Atlas DRFQ - an Atlas module developed by us at Fastlane Labs which implements a fully onchain swap RFQ auction utilizing no external infrastructure other than the Polygon mempool.
![\"\"](\"https://fastlane.ghost.io/content/images/2024/08/dappland--3-.png\")
Available now on Polygon PoS via the Rocketboost.me frontend, Atlas DRFQ enables fully trustless intent-style swap RFQ experience for users, similar to 1inch Fusion or UniswapX, but which solely relies on the public mempool to facilitate the auction instead of trusted infrastructure, and allows for a permissionless solving, with an onchain reputation system for solvers to manage priority and spam. Rocketboost will be our fully MIT-open source UI for showing off all of the cutting edge capabilities of Atlas, like how a frontend can request and fulfill a user’s intent fully onchain, relying only on the Polygon mempool to relay user and solver operations.
Rocketboost is live to use here. Note that this still comes with a beta label for both the contracts and the frontend as we are still battle testing it. You can fork the Atlas DRFQ code and freely run your own version of it by visiting the GitHub repo, all of the code for the app and the contracts are MIT open source and there is no backend.
As cool as we think the frontend is, the onchain RFQ system itself is a little more exciting. Frontrunning of user’s transactions is arguably the “original sin” of MEV and usually the most important attack to guard against, particularly when combined with backrunning to enable a sandwich attack. Searchers know what the user wants and can intervene in a PGA to extract the most value before the user’s transaction in a given block. But with Atlas and the DRFQ module, searchers frontrun user transactions as a way to enter a competitive auction to maximize user welfare: searchers must compete to fill the order at the best possible price, and the smart contract bundles the Atlas transaction with the winning searcher transaction, utilizing Atlas’s core capabilities for censorship resistance guarantees.
After requesting a “baseline” quote via an onchain viewcall to some DEX router (we use Quickswap’s v2 given a desired output amount of tokens from the user in the UI (in our case, from Uniswap pools, but could be made more extensive in future), the Rocketboost frontend creates a transaction on the user’s behalf which encapsulates their Atlas intent to swap X tokens for a minimum of Y tokens. Users submit intents via the Rocketboost frontend to the DRFQ contract (”FastLaneControl.sol”) which implements the Atlas IDappControlinterface. Solvers can submit competitive bids to fill a user’s order with private liquidity or provide a solution to an on-chain route that the frontend wasn’t aware of. These potential solutions are evaluated and sorted using Atlas’s bid sorting mechanism. Once the user submits there transaction to the public mempool, searcher have the ability to frontrun the transaction and submit potential solutions to the “DRFQ” contract. Solver compete for the most optimal intent fulfilment via an onchain auction system. The auction, including bids from multiple solvers, is evaluated atomically all in a single EVM transaction via the Atlas solverOp try/catch loop that sits at the core of the Atlas Protocol. The frontend-controlled FastLane DRFQ module either executes the “baseline swap” with the specified onchain liquidity sources, or via the route/fill that the winning Atlas searcher-solver has submitted, whichever is higher.
When you look more closely at the offchain flow, you’ll see that there isn’t any third party relay involved - we simply use the Polygon p2p mempool to match user orders with searcher solutions:
![\"\"](\"https://fastlane.ghost.io/content/images/2024/08/Screenshot_2024-08-19_at_16.15.21.png\")
It’s important to note that there are some affordances of Polygon (and which apply to other ecosystems) that we are taking advantage of here in this particular configuration of Atlas, namely, the fact that Polygon has a governance appointed set of validators who can be expected not to censor Atlas auctions for the same reasons they are trusted not to censor transactions in general and the vanilla mev-bor Polygon client as well as validators running the FastLane built FastLane on Polygon client (PFL) order transactions based on a priority fee. This is more complicated in fully permissionless validator sets like Ethereum, and warrants a different tradeoff space to consider to mitigate censorship and spam. The DRFQ configuration of Atlas, however, strictly introduces no new trust assumptions for using a blockchain with a public mempool and smart contracts only to conduct a value-maximizing orderflow auction, without additional trust assumptions beyond the validators/economic security of the chain you are already trusting for settlement and finality.
The onchain flow of the DRFQ system and Atlas looks like this:
![\"\"](\"https://fastlane.ghost.io/content/images/2024/08/Screenshot-2024-08-19-at-16.16.21.png\")
Users’ EOAs grant token permits to Atlas through our “permit69” system in Atlas (similar to permit2) through a regular transaction, and then are able to create a transaction via the FastLaneControl contract (the Atlas “Module”) which initiates the Atlas auction, where frontrunner bots will try to execute the transaction by completing it with a their attempted winning SolverOperation which will return the most tokens to the user with the constraint of their desired input and output tokens. If all solver operations fail, the baseline swap is executed for the user at the best available onchain price (in this case, we look at Uniswap v2 pools so that we can more easily demonstrate solvers providing price improvement). If a solver succeeds in beating the baseline quote and all other solvers, they get to fill the user’s order.
We’re excited about Rocketboost as a way for us to push the Atlas Protocol forward, and will be bringing other modules with other capabilities to it in the future to show what permissionless DeFi innovation can look like. While Atlas is a fully modular system which can implement a range of auctions across the trust assumption spectrum given a variety of tradeoff curves, Rocketboost will be where we showcase the “have your cake and eat it too” innovations possible with pushing Atlas as far as it can go in the permissionlessness and decentralization direction.
Decentralization and permissionlessness may not always be the top priority for dapps, but we feel that more and more they should be, and with Atlas we want to show what’s possible. We’re excited to continue our rollout of MEV-aware, value-maximizing apps with our launch partners, so stay tuned and give Rocketboost a spin.
","comment_id":"66c42e1b554ada0001b29061","feature_image":"https://fastlane.ghost.io/content/images/2024/08/rb-beta.png","featured":false,"visibility":"public","created_at":"2024-08-19T22:48:11.000-07:00","updated_at":"2024-08-27T13:11:45.000-07:00","published_at":"2024-08-23T12:06:55.000-07:00","custom_excerpt":null,"codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":"https://rocketboost.me/","tags":[{"id":"648cbd13f9f9fe0001c5d037","name":"BUIDL","slug":"buidl","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/buidl/"},{"id":"6616c1e63db05d0001fa803d","name":"Atlas","slug":"atlas","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/atlas/"}],"primary_tag":{"id":"648cbd13f9f9fe0001c5d037","name":"BUIDL","slug":"buidl","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/buidl/"},"url":"https://fastlane.ghost.io/introducing-rocketboost/","excerpt":"The Atlas Protocol is the world’s first generalized execution abstraction protocol for the EVM, providing app and frontend developers the ability run intent or MEV orderflow auctions to capture value for their users and stakeholders. Atlas developers can build and configure their “Atlas Module” (an Atlas DappControl contract) for their use case and value flow requirements, including: OEV auctions, backrun OFAs, intents/swap RFQs, rebalancing auctions and LVR resistant AMMs/hooks.\n\nHaving success","reading_time":6,"access":true,"comments":false,"og_image":"https://fastlane.ghost.io/content/images/2024/08/dappland--2-.png","og_title":"Introducing Rocketboost, powered by Atlas and the world’s first fully onchain DRFQ","og_description":"The Atlas Protocol is the world’s first generalized execution abstraction protocol for the EVM, providing app and frontend developers the ability run intent or MEV orderflow auctions","twitter_image":"https://fastlane.ghost.io/content/images/2024/08/rb-beta-1.png","twitter_title":"Introducing Rocketboost, powered by Atlas.","twitter_description":"The Atlas Protocol is the world’s first generalized execution abstraction protocol for the EVM, providing app and frontend developers the ability run intent or MEV orderflow auctions","meta_title":"Introducing Rocketboost, powered by Atlas and the world’s first fully onchain DRFQ","meta_description":"The Atlas Protocol is the world’s first generalized execution abstraction protocol for the EVM, providing app and frontend developers the ability run intent or MEV orderflow auctions","email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null},{"id":"667f33fda7296d0001b04cb3","uuid":"31e452cd-7e8d-4208-aeb5-68a6d02678bc","title":"Announcing the Monad MEV Research Group","slug":"announcing-the-monad-mev-research-group","html":"Gmonad. FastLane Labs is excited to announce the Monad MEV Research Group (MMRG), a loose coalition of validators, protocols, applications and MEV researchers who will help us research and test ecosystem-aligned MEV solutions on the Monad Testnet. Many well-known validators including Kiln, Chorus One, Twinstake, Luganodes , P2P, and Figment have agreed to help us research and develop ways of mitigating MEV on Monad, and we are inviting others interested in joining us to get in touch to join the MMRG. From analyzing and operating in other MEV ecosystems, we have some intuition on how MEV may manifest on Monad, but there is still substantial research to be done.
Monad is building one of the most exciting layer one blockchains and building one of the most tight-knit communities in crypto. It will be an EVM-compatible L1 with 1 second block times and finality, 10,000+ tps and extremely cheap transaction fees, achieved through a mix of innovations and pipelining at all layers of the stack, including deferred execution, parallel execution, a new high performance consensus algorithm called MonadBFT, and a new purpose-built blockchain database called MonadDB.
Monad’s cutting-edge design should offer an exciting new set of capabilities for EVM developers and their users. This research group will be committed to preserving the decentralization and censorship resistance of Monad, helping scale the throughput of the network, while mitigating the negative externalities of MEV. Specifically, we’ll focus on the mitigation of negative externalities like spam and sandwich attacks.
With dozens of projects building on it already and testnet fast approaching, Mondalak Nation will need to contend with the problems that come with success and growth, and threats to UX, decentralization and performance. FastLane builds smart contract based MEV protocols to make DeFi usable and maintain it decentralized. Monad is blazing an important path towards a hyper-scale future and FastLane and the MMRG will be there on day one to help the Nads navigate MEV.
To join the community, please fill out this brief form.
","comment_id":"667f33fda7296d0001b04cb3","feature_image":"https://fastlane.ghost.io/content/images/2024/07/kiln-blog-post-1.png","featured":false,"visibility":"public","created_at":"2024-06-28T15:06:53.000-07:00","updated_at":"2024-07-04T11:33:49.000-07:00","published_at":"2024-07-01T10:18:08.000-07:00","custom_excerpt":"Gmonad. FastLane Labs is excited to announce the Monad MEV Research Group (MMRG), a loose coalition of validators, protocols, applications and MEV researchers..","codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":"https://www.fastlane.xyz/blog/announcing-the-monad-mev-research-group","tags":[{"id":"667f3480a7296d0001b04cbb","name":"monad","slug":"monad","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/monad/"}],"primary_tag":{"id":"667f3480a7296d0001b04cbb","name":"monad","slug":"monad","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/monad/"},"url":"https://fastlane.ghost.io/announcing-the-monad-mev-research-group/","excerpt":"Gmonad. FastLane Labs is excited to announce the Monad MEV Research Group (MMRG), a loose coalition of validators, protocols, applications and MEV researchers..","reading_time":1,"access":true,"comments":false,"og_image":"https://fastlane.ghost.io/content/images/2024/07/kiln-2.png","og_title":"Announcing the Monad MEV Research Group","og_description":"Gmonad. FastLane Labs is excited to announce the Monad MEV Research Group (MMRG).","twitter_image":"https://fastlane.ghost.io/content/images/2024/07/kiln-1.png","twitter_title":"Announcing the Monad MEV Research Group","twitter_description":"Gmonad. FastLane Labs is excited to announce the Monad MEV Research Group (MMRG)...","meta_title":"Announcing the Monad MEV Research Group","meta_description":"Gmonad. FastLane Labs is excited to announce the Monad MEV Research Group (MMRG), a loose coalition of validators, protocols, applications and MEV researchers..","email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null},{"id":"662a4b511399ab00015723d4","uuid":"ba7e097e-7db5-42dc-96cf-16096bd8afa5","title":"Introducing Atlas Backruns","slug":"introducing-atlas-backruns","html":"By Jacob Greene - FastLane Labs
Atlas is a generalized execution abstraction protocol for building application-specific order flow auctions on the EVM. Because of its generality and flexibility, Atlas can be used for a number of execution abstraction use-cases such as backrun order flow auctions, OEV auctions, and intent auctions. All of these auction types can be purpose-built by application developers in what we call an Atlas Module. While developers can always write their own modules or fork existing ones, we at FastLane will be supporting the Atlas ecosystem with high quality, first-party modules, and the accompanying implementation infrastructure for out-of-the-box use by anyone. Our first productized Atlas Module is a Backrun OFA, an easy way for swap frontends to capture backrun revenue to be distributed back to swappers, LPs, governance, or some mix at the app’s discretion.
An overview of Backrun OFAs
User-activated alternative RPCs at the wallet level such as MEV-Share and MEV-Blocker pioneered permissionless backrun OFAs on Ethereum, and have returned more than 2,000 ETH in rebates to users since launching in April 2023. Both of these OFAs implement a privacy mechanism that prevents users from being frontrun by concealing the real user swap until after settlement. They also both use \"block building time simulations from builders, which serve as the \"auctioneer\" that enables the privacy mechanisms to work with a permissionless solver network. Anyone sending trades to AMMs may be leaving money on the table if they aren’t using a “block building time” OFA, from regular frontend users, to aggregators, and CoWSwap solvers. RPC based backrun OFAs, with their impressive growth on mainnet Ethereum and given the continued proliferation of AMMs in on-chain trading, have proven to be an important tool for delivering DeFi users best execution.
![\"\"](\"https://lh7-us.googleusercontent.com/ysZ1n6h2YzvSnpkCdW77IH5RZDY3YDlOFARHvaBo5N8keXFMAW3_xWYPsHZOuUEe5WxD8L309aMQfTJ3Fu3eFBwE5HczTkmOJSAwz_ODCbg4qwq66MdHVBk8QzOwlyaSqGa_VgfqNI3tM2U3v6rg2hU\")
Block Building Time Simulations
“Block building time” simulations are highly beneficial to backrun OFAs because they deterministically find the best bid. MEV auctions that are not builder-integrated have access to less reliable simulations. This is one of the reasons why CoWSwap solvers likely benefit from sending their transactions to MEV-Blocker, as builders are not natively integrated into the CoWSwap auction. Reliable simulations also prevent solvers from griefing the auction with transactions that trick the simulation by behaving differently when actually executed on-chain. Imagine a transaction showing a bid of 1 eth for the off-chain simulation, and actually only sending .01 eth when executed on-chain. In summary “block building time” simulations enable OFAs to:
Programmable Privacy
Hints, popularized by MEV-Share, is the first in production example of programmable privacy for OFAs. It enables users to send order flow to a permissionless solver network while maintaining sandwich protection. Hints restrict the information shown to solvers which forces them to blindly solve for the backrun on-chain. This prevents solvers from ever having enough information in time to frontrun the user. Only the pool address that the user swap is targeting is revealed publicly to solvers, hiding data like the trade size, direction, and swapper address. Hints further enable collaboration where you otherwise wouldn’t have it that makes the market more efficient, such as the ability for solvers to backrun other solvers like the CowSwap and MEV-Blocker example.
Permissionless Solvers in Backrun OFAs
This paper described how permissionless solver networks for intents auctions like UniswapX may in some cases actually result in worse prices for users than if there was an oligopoly of searchers. This is mainly due to congestion and entry costs. Congestion costs may arise when many solvers compete to purchase the same token in order to fill a user intent. Entry costs represent setting up infrastructure, or any other upfront costs to bid.
Backrun OFAs supporting programmable privacy differ significantly in a few ways from the intents auctions discussed in the paper:
This indicates that backrun OFAs may benefit more from a permissionless solver network than an oligopoly due to their specific market structure, compared to something like swap intents, which may disproportionately benefit from something like a solver reputation system.
Gaps in current backrun OFA market
There are a number of issues, however, with the current backrun OFA landscape.
The Atlas Protocol
Atlas uses execution abstraction to replace the need for trusted “bundles” offered by block builders. Combining user and solver operations into a single transaction makes the order of operation execution, and rebates from solvers to users atomic and trustless. Atlas is also designed to be easily integrated directly into interfaces, turning backrun OFAs from an opt-in feature at the wallet level to a default feature at the application level.
Atlas Backruns
Atlas extends permissionless backrun OFAs to L2s, giving users the ability to receive backrun MEV rebates while maintaining frontrunning/sandwich protection. The Ethereum roadmap has been pushing for activity to move to L2s for a while, and we have just recently started to see this trend really play out. DEX volumes have significantly increased on L2s like Base, Arbitrum, and Zksync. With this, atomic arbitrage opportunities have also significantly increased on these L2s, and are moving away from the L1. We only see this trend continuing and the desire to capture this surplus value for applications and users being inevitable, especially when there are little upfront costs or risks associated with it.
![\"\"](\"https://lh7-us.googleusercontent.com/HkTlLwsQv2hPQ6ui8xWQavtsxH3nDXl02iPdF4Hy7f0Qnug7PKk4tO0tnlfnxb-u8rW-p8ikkFf0GECaSjDbXrMe1WWOzwdZA4Ww93BqypyTlWNwtSQeNiXX1NEE3tLEE-M0fL24jTsxBDnQRayvuNQ\")
Atlas unlocks permissionless backrun OFAs on L2s with “Ex-Post Bids”, our own equivalent for “block building time” simulations on any EVM chain. The “Ex-Post Bids” name comes from the fact that these simulations are “based on actual results rather than a forecast”, they are 100% accurate simulations rather than less reliable off-chain simulations from a non block builder. They enable programmable privacy, allowing users to receive backrun rebates from a permissionless solver network while maintaining frontrun protection.
\"Ex-Post Bids\"
Atlas “Ex-Post Bids” take advantage of cheaper gas costs to simulate and find the highest bid on-chain, providing “block building time” simulations without having to trust an off-chain actor. This is a clear example of cheaper gas fees allowing developers to build more decentralized blockchain applications. On L2s the gas costs of running “simulations” on-chain should for the most part be far outweighed by the MEV rebates. The median rebate from MEV-Share is $13, and it can cost under 1 cent to do a swap on most L2s at the time of writing.
“Ex-Post Bids” uses the ability to include multiple solver operations in a single atlas transaction by looping over the solver operations to find the highest paying one. Each solver operation is executed behind the user operation, the bid amount is recorded, and then they are reverted. Atlas will then go back and re-execute the highest paying solver operation from that loop, essentially providing an on-chain simulation. This Atlas feature allows solvers to submit operations where they do not know the bid amount ahead of time, enabling programmable privacy such that solvers are unaware of their and the users operations until after settlement.
Decentralization and Observability
Atlas \"Ex-Post Bids\" provide more observability into OFAs because there isn’t an opaque process happening inside centralized builders who host the auction, a significant portion happens on-chain instead. With backrun OFAs today you have very little insight into what is happening with your transactions. You don’t know if a refund bundle was ever generated or sent to a block builder, and you must share your full transaction details with the builder. Builders who are also bidders in the OFA have a clear advantage from vertical integration because they receive the full transactions from users, whereas searchers who are not also builders do not. They can even sandwich or backrun users without providing a MEV rebate. This was highlighted by Blair in a case where a vertically-integrated builder was potentially abusing their trusted relationship and backrunning without rebating. It took ~80 days for anyone to notice this, highlighting a need for more observability in Backrun OFAs.
With Atlas Backruns you:
Reputation Filtering
In practice all permissionless MEV auctions with low gas costs, or free reverts, have some kind of filtering in place before solver transactions are allowed to touch hot resources such as a simulation engine. There are more transparent reputation systems like the Flashbots and Titan builders, or more opaque methods such as the “random heuristics” used in Beaver builder. These prioritization techniques are used alongside simulations to select the winning bids in the auction and prevent spam.
Since Atlas Backruns will not utilize block builders for simulations, there needs to be a new filtering mechanism before solvers are allowed access to Atlas on-chain simulations. Similar tools as the ones used by Ethereum block builders can be used by the Atlas Operations Relay to prevent spam. Atlas handles gas accounting atomically on-chain, which will always be the first spam resistance tool for Atlas Backruns. Reputation scoring systems or priority queues can be used as a second barrier of spam resistance when gas costs are not enough. Off-chain simulations can additionally be used to increase assurances that on-chain simulations are only performed when the rebate is greater than the extra gas costs incurred.
Conclusion
Atlas unlocks “block building time” simulations and programmable privacy on any EVM chain. This allows modules like Atlas Backruns to offer L2 users MEV rebates from a permissionless solver network while protecting them from frontruns. Atlas backrun modules are differentiated from current permissionless backrun OFAs because they:
By Ben Basche & Alex Watts - FastLane Labs
MEV, account abstraction and intents represent 3 of the most talked about trends of the cycle, and 3 important pieces of the crypto value proposition and UX puzzle. While each of these supertrends have their own seemingly independent paths of evolution, we at FastLane actually see them converging in important ways, with important design considerations to be made in DeFi as a result.
Now that we’ve sufficiently confused you and blurred the 3 concepts together shown you the high-level overlap, let’s take a deeper look at the account abstraction side and work our way backwards to intents and MEV. ERC-4337 - Account Abstraction Using Alt Mempool - was introduced in 2021, and has succeeded where many other EVM account abstraction efforts have stalled. It introduces a lightweight smart account implementation interface alongside a permissionless userOperation mempool, accessed by applications via the 4337 canonical entrypoint contract. This design allows for \"UserOperations\" - EIP712 signed messages declaring the user’s intent to perform a transaction rather than actually perform it - to be bundled permissionlessly much like the public mempool for Ethereum transactions is today, but without a hard fork on Ethereum mainnet.
While work is still underway on the final implementation of the permissionless mempool(s), we have hundreds of thousands of smart accounts deployed (largely on layer 2s), millions of UserOperations sent, dozens of venture backed infrastructure startups building out the tooling, bundling and SDK layer, and applications finally beginning to adopt smart accounts for reasons of improved onboarding experiences and social recovery, gas abstraction and paymaster flows, and increasingly now module extensions to smart accounts through efforts like ERC 7579. Smart accounts give developers and users great flexibility while maintaining trustlessness and self-custody, and they open the door to even more expressive user automations. The recent push to include EIP-3074's AUTH and AUTHCALL opcodes in the next Ethereum hardfork will bring some of the benefits of account abstraction to EOAs (something which we are extremely excited about and will publish more thoughts on), but smart accounts and ERC-4337 are still going to be critically important for account abstraction innovation.
Permissionless inclusion of cheap, gas abstracted and programmable metatransactions (the old word for user operations/intents) is absolutely a minimum requirement for us to reach the next billion users across mass-market and real world use cases. But all designs have their tradeoff, and we think that when it comes to MEV-rich UserOps like swaps, the 4337 permissionless mempool may not be the best solution for smart accounts to have users’ intents fulfilled.
ERC-4337’s metatransaction inclusion supply chain is focused specifically on maximizing two traits: permissionlessness and decentralization. 4337 Bundlers such as Biconomy and Alchemy will receive UserOperations - typically via a private relay for now until the permissionless 4337 mempool is live - and place these operations inside of a transaction. The Bundlers are willing to pay the gas cost for these transactions because they are reimbursed by the UserOperation, oftentimes with a different currency such as wETH or USDC. When the permissionless 4337 mempool is live, users and apps should have a fully censorship resistant way to get operations included in an eventual Ethereum block, but that may very well come at a high cost for something like an intent to swap X tokens for at least Y tokens: the game theory of the public mempool will drive the user to almost always get the worst price they allow for in their intent. Protecting against this will very likely mean that private relays will continue to need to be involved in intent operations where the user is trying to maximize execution quality, undermining much of the case for 4337's design to begin with for those cases.
What’s behind this? To help us understand how the 4337 permissionless bundling will work on any arbitrary EVM chain, let’s look at a chain which FastLane Labs has plenty of experience with when it comes to MEV: Polygon. FastLane on Polygon (or PFL) is our opt-in, validator-centric MEV solution on Polygon, and is the means by which over 65% of Polygon’s validators receive and process MEV bundles.
When we designed PFL as a way for Polgyon validators to opt-in to a block-level OFA that protects end users, we made a deliberate decision to avoid the creation of any sort of trusted private relay to validator. Although there are many benefits to our approach, such as relay decentralization and validatory security, the primary rationale behind the choice was two-fold:
All transactions in all FastLane MEV bundles (which aren’t the same thing as AA bundles, and are more akin to traditional MEV bundles) are broadcast back into the public memory pool. This allows any searcher to include the transactions of other searchers in their MEV bundles. Consider the following sequential structure of a sandwich attack:
![\"\"](\"https://lh7-us.googleusercontent.com/D5MzBjA1LxzznErpUouQQ5tDYTr3C_VATavPSdgCJqHUCsSDLzcFTcfGJ-9oDgXR72XxeRGNk924zMQXLIInGefqjfMGXfAwRNMKMQMPs9Gf_D_TxAgiAx_EDNpxSkvA49zQ82HYUIrXH0etWr3LArY\")
Note that the first transaction from the searcher - the frontrun - is similar to a “loss leader.” By itself, it will lose money. The searcher only realizes profit when their second transaction is executed. The capacity for these transactions to execute in an “all or none” batch is called MEV bundle atomicity.
But on Polygon with PFL, we intentionally don’t guarantee the atomicity of MEV bundles. All the transactions in an MEV bundle are broadcast to the public mempool, meaning that other Searchers can use them in the construction of their own MEV bundles. Consider a new party, SearcherB, who also wants to make money. What would they do?
![\"\"](\"https://lh7-us.googleusercontent.com/o8ADdzBr1gKEqUBDGDO8pBYX1U1AVREjylF_iOys2O5WVtrTsgZxL8mrihGcWZh4pXYjwXKaPG4B0sJffWS9h2GX5c2IqA8UduXI9fBEzY1THvMBM8PkWUEjTxVw3FYd9UiLIxqLom5qjtFYPn1C2T8\")
SearcherB will combine SearcherA’s frontrun transaction and the User’s transaction with their own backrun transaction. This leads to three important conclusions:
This system has been live on Polygon PoS for roughly a year now, and we still have yet to observe a single sandwich attack succeeding via the FastLane relay or smart contract. While it’s technically possible and we expect to see it happen potentially someday, as described above sandwich attacks are strongly disincentivized because they would be attributable over a period of time and the validator that enabled it would be booted from the valuable PFL block OFA. We see this incentive at work plainly when comparing sandwich attack prevalence on Ethereum to those on Polygon:
\tEthereum sandwiches on the left, Polygon sandwiches on the Right:
![\"\"](\"https://lh7-us.googleusercontent.com/I-zNGifeGvjXgQlFx4GpH54s3dEnbrfhkRrBcPAGxgxbop_nBv0aZVi5ZXVy-338P1Wm3vdcNLbxcpzc3NMf31jiw8oSkitqfnq86FL1pKSYSddcg2yET-Gk2QbYIiNnPk-50auTLoRjVBd4M90aPW8\")
This mechanism of “turning everything into a public auction” doesn’t just work for sandwiches - it also subjects all “private” orderflow to the same auction mechanism, of which the Validator is the beneficiary in the case of PFL, with the end user receiving protection from the most egregious forms of MEV like frontrunning and sandwich attacks. This auction game wasn’t designed for EIP-4337, but what we have been seeing lately with 4337-compliant UserOperations is a fascinating game that rhymes with the PFL auction mechanics:
![\"\"](\"https://lh7-us.googleusercontent.com/lwfzhzMP9frvPbHn75IzxpjIe-iagJICgznMvuo_bJVgm8w0_GAl5QaxVn34ZutMaJxPBb0vOma6P4B0OfO5j2OpJp_Dxg2cQQDvLJPiudkP_lBXhjkO6uar9u7f3T9HKJdvgbZvp7awXfKDKLHVzuM\")
But here begins our problem when it comes to MEV-rich 4337 userOps, or userOps which authorize a more expressive “intent” to do something complex in DeFi. Let’s examine this from the perspective of the validator, who we’ll assume likes money. When 4337 BundlerB frontruns 4337 BundlerA, they must use either a higher GasPrice or some other payment mechanism to incentivize the Validator to place BundlerB’s transaction in front of BundlerA’s. In addition to the higher fee collected from BundlerB, the Validator also receives the transaction fee from BundlerA’s transaction, which will now revert.
As with PFL’s sandwich defense mechanism, two things become clear:
Even if BundlerA has a private relay set up between themselves and the user, they are still likely to lose money when they get frontrun in the public mempool. Because of this, validators are incentivized not to build a private relay, as such a relay would preclude their ability to profit from competition between bundlers. As a result, for BundlerA, the most likely winning move is simply not to play, which means that the UserOperation is less likely to get included in a block by a Validator. This is a problem that ERC-4337 fixes with its permissionless mempool.
This 4337 mempool is crucial - it’s a place for the User (or, more specifically in most cases, the frontend that the User is interacting with to create their userOp) to send their UserOperation without having an additional cost associated with making that data available to bundlers. Due to EIP-4337’s spec of permissionless bundling, an arbitrary set of Bundlers can then assess the UserOperation and compete over which one of them executes it. This is great for liveness and censorship resistance, but - crucially - it’s not so great for MEV-rich o for the user from an execution perspective because one needs to ask the question: when being a Bundler is valuable, and when anyone can do it, who gets the privilege? Well, as we’re already seeing in realtime on Polygon PoS in the PFL construction, the answer is whoever pays the most to the validator.
Bundlers are rational actors. It can be assumed that they won’t offer to pay the validator more than the monetary value of the UserOperation. Different bundlers will assign a different monetary value to each UserOperation depending on their own extraction capabilities, and depending on their own relationship with the users originating these operations. As the value a bundler can extract from the UserOperation increases, so too does that operation’s monetary value to the bundler and therefore that bundler’s bid to the validator. This leads to an unfortunate conclusion: each UserOperation will be bundled by whichever entity can extract the most value from it.
Let’s now bring our attention back to intents. As discussed earlier, an intent is a desired outcome. A regular transaction might specify something along the lines of “Please sell N ElonEth420 tokens on Uniswap V2 and give me the resulting amount of DogTurd9000 tokens,” whereas an intent would be a request to “Please take N ElonEth420 tokens give me the most DogTurd9000 tokens possible.” Note the emphasis on the word “most” in the example of the intent - the User wants to keep as much surplus as possible. After all, why wouldn’t they? Maybe if the User’s intent was “Please take N ElonEth420 tokens and give me M DogTurd9000 tokens, but if you can get more than M DogTurd9000 tokens then definitely keep that surplus for yourself because I want you, the Bundler, to have them, because, gosh golly, you deserve them!” But that’s a bit absurd, isn’t it? The User expects that any value uncovered by the Bundler during the execution of their UserOperation will go back to the User. But as we’ve discussed, with EIP-4337 all value flows straight to the Validator - any value that can be extracted, will be extracted. This is why ERC-4337’s alt mempool and execution-maximizing intents are somewhat incompatible.
As soon as the UserOperation hits the 4337 mempool, it will be detected by multiple potential bundlers - many of whom presumably fill the role of block builder as well. Even if there is an agreement in place between a bundler and a builder to not extract value from users, it won’t matter because the builders are also competing in an auction to extract the most value to bid to the proposer. As long as the 4337 mempool is used, any trusted builder with a non-extraction agreement in place will have a less valuable block than a builder who attempts to extract maximal value from the UserOperation.
Unfortunately, the exact permissionless bundling which 4337 enables subjects its userOperations to the above game theory, resulting in maximal MEV extraction out of a user’s pocket and into the proposer/validator’s. Proposer-builder separation on doesn’t change the outcome here, and while having user’s install custom RPCs with private relays to builders could theoretically help (although even this point is debateable) , not only are custom RPCs an unwieldy MEV protection form factor for the least sophisticated users, but also you are essentially re-adding trusted middlemen and relay infrastructure back into the equation and value chain to enable MEV protection - the exact thing which the 4337 alt mempool was created to avoid to begin with.
To be clear, 4337 is extremely important and serves a critical function for the adoption of smart accounts by billions of users: permissionless inclusion of userOperations with little to no MEV, very likely to constitute the vast majority of transactions/pseudotransactions we need to take web3 to mass adoption. 4337’s specification is very well suited to maximize decentralization, accessibility, and censorship resistance for any and all UserOperations. If a User wants to do a token approval, add someone to a multisig, make a simple payment or transfer, or some other type of UserOperation that won’t generate MEV or that doesn’t involve an adversarial counterparty, 4337 is great and likely optimal for the user. In these interactions, the “intents” are for certain automations, transfers, payments and other non-adversarial uses of public blockspace, and the gas paid (by the end user, in whatever token, or somehow sponsored by the application, wallet or another party) represents the only “MEV” extracted. In the mass adoption endgame where crypto is embedded in all aspects of daily commerce and computing, this might represent 95%+ of \"operations\" users send.
But some UserOperations - such as DeFi intents, swaps, oracle updates, liquidations and other potential sources of MEV where users need to maximize their execution over some price space - are more ill-suited for ERC-4337’s alt mempool because of the value that they leak to validators. Luckily, we are still relatively early in the deployment of smart accounts in DeFi and can design systems which are MEV-aware. In order to enable the adoption of smart accounts in DeFi and all of the recovery, automation, gas abstraction and UX benefits they provide, we also need to have a solution for transaction inclusion that is compatible with intents, one which is capable of enabling OFAs which benefit the end user and application which generate the MEV to begin with.
At FastLane, we’ve built such a solution. It’s called Atlas.
","comment_id":"6613fcd42b428b0001420ffe","feature_image":"https://fastlane.ghost.io/content/images/2024/04/on_intents_2.png","featured":false,"visibility":"public","created_at":"2024-04-08T07:19:00.000-07:00","updated_at":"2024-04-18T14:55:34.000-07:00","published_at":"2024-04-17T02:53:00.000-07:00","custom_excerpt":"A look into the overlap between account abstraction, intents and MEV, and important tradeoffs to consider when designing applications to take advantage of them. ","codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":null,"tags":[{"id":"677896fc29a2210001f31610","name":"#ben","slug":"hash-ben","description":null,"feature_image":null,"visibility":"internal","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/404/"}],"primary_tag":null,"url":"https://fastlane.ghost.io/on-4337-intents-and-mev/","excerpt":"A look into the overlap between account abstraction, intents and MEV, and important tradeoffs to consider when designing applications to take advantage of them. ","reading_time":12,"access":true,"comments":false,"og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null},{"id":"6616bf2b3db05d0001fa8009","uuid":"3efbd327-7032-409c-980f-431f499d1e74","title":"Why we are building Atlas","slug":"why-we-are-building-atlas","html":"Blockchains are governed by cause and effect. Their state only changes when something acts upon them to change it. This cause is usually a transaction.
This means if something changes and we want to represent that in a blockchains state, we’re going to need a transaction. For example a user could decide they want to exchange one of their tokens for another, or the price of a token on another platform could change.
These state changes have consequences. If a user interacts with a liquidity pool to exchange some of their tokens for another token, then afterwards the relative balance between the tokens in that pool will have changed, changing the swap rate for the next transaction When these changes are favorable there will be fierce competition between traders to be the next transaction in the block, allowing them to capture the opportunity created by the previous transaction. This form of trading is known as MEV trading (for Maximal Extractible Value), and we call this type of trader a searcher.
This means that whoever decides in what order transactions are executed is able to arrange them in a way that allows them to make a profit, for example by selling the slot after a users swap transaction to the highest bidder. Typically, it is the block producer who makes this ordering decision.
However it is users and protocols that generate these trading opportunities, and today they have no easy way to capture the value they leak to the rest of the transaction supply chain.
Atlas is a framework to enable protocols to keep this value they create within their ecosystem. It works by allowing protocols to auction off the right to execute a transaction immediately after a user’s, and then bundling these two transactions together into a single atomic transaction.
For existing protocols that weren’t designed with MEV resistance in mind, Atlas is an easy way for them to retain as much of the value as they generate as possible. Proceeds from these auctions could be used to buy and burn a governance token, give rebates to users or be redistributed to liquidity providers who are suffering from impermanent loss.
For new protocols a popular approach has become to allow a user to specify the outcome they are trying to achieve, rather than exactly how they want to achieve it. This is the difference between saying “I want to swap token A for token B using this liquidity pool” and “I want to swap token A for as much token B as possible, and I don’t care where token B comes from”. These are known as intents, and traders compete for the right to be the counterparty to a particular user's intent, and we call this type of trader a solver. Under this model solvers compete not based on how much value they can extract from a user's transaction, but instead on who can best meet the user's desired outcome. Solvers are incentivized to return as much value to the user as possible to win the opportunity, minimizing any value leaking in the first place.
Taken a step further, Atlas has been designed to be used as a general purpose matching engine between two counterparties. For protocols considering an intents based approach to satisfying their users needs, Atlas takes care of most of the undifferentiated heavy lifting of matching counterparties and ensuring they do what they say they will, leaving you to focus on what makes your app unique.
Follow us on X to keep up to date as we get ready to launch. If you're a DApp, protocol or searcher interested in being a launch partner, please get in touch.
","comment_id":"6616bf2b3db05d0001fa8009","feature_image":"https://fastlane.ghost.io/content/images/2024/04/WhyAtlas.png","featured":false,"visibility":"public","created_at":"2024-04-10T09:32:43.000-07:00","updated_at":"2024-04-10T09:44:12.000-07:00","published_at":"2024-04-10T09:43:19.000-07:00","custom_excerpt":null,"codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":null,"tags":[{"id":"6616c1e63db05d0001fa803d","name":"Atlas","slug":"atlas","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/atlas/"}],"primary_tag":{"id":"6616c1e63db05d0001fa803d","name":"Atlas","slug":"atlas","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/atlas/"},"url":"https://fastlane.ghost.io/why-we-are-building-atlas/","excerpt":"Blockchains are governed by cause and effect. Their state only changes when something acts upon them to change it. This cause is usually a transaction.\n\nThis means if something changes and we want to represent that in a blockchains state, we’re going to need a transaction. For example a user could decide they want to exchange one of their tokens for another, or the price of a token on another platform could change.\n\nThese state changes have consequences. If a user interacts with a liquidity pool","reading_time":2,"access":true,"comments":false,"og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null},{"id":"65167ae64687050001ecd24b","uuid":"b5eeb032-6d6f-4801-a65c-954ae36797da","title":"The Top Three Mistakes That Ruin Validators' Trustworthiness on Polygon","slug":"the-top-three-mistakes-that-ruin-validators-trustworthiness-on-polygon","html":"Trust is the bedrock upon which decentralized systems thrive.
For Polygon Validators, maintaining trustworthiness is not just a matter of reputation; it's a critical factor that determines their success in the ecosystem.
However, even the most seasoned validators can sometimes falter, making mistakes that can erode the trust they've painstakingly built.
Let's delve into the top three mistakes that can jeopardize a validator's trustworthiness on the Polygon network.
1. Inadequate Infrastructure and Downtime:
One of the primary responsibilities of a validator is to consistently produce and validate blocks.
Any downtime, whether due to technical glitches, inadequate infrastructure, or poor maintenance, can result in missed blocks.
This not only reduces the rewards for the validator but also impacts the stakers who have delegated their MATIC tokens to them.
Deep Dive: A technically skilled coder understands the nuances of maintaining a robust infrastructure.
However, cutting corners by relying on subpar hardware or not having redundancy measures in place can lead to unexpected downtimes.
In the world of staking, where every second counts, such lapses can be costly and can quickly erode trust.
2. Lack of Transparency and Communication:
In the decentralized space, transparency is paramount. Validators are expected to keep their stakers informed about their operations, performance metrics, and any potential issues. A lack of open communication or withholding of critical information can raise red flags.
Deep Dive: Consider a scenario where a validator is aware of a potential security vulnerability but chooses not to disclose it to their stakers. If this vulnerability is later exploited, the validator's reputation can take a significant hit. Regular updates, open channels of communication, and a proactive approach to addressing concerns can go a long way in building and maintaining trust.
3. Passive Network Participation:
Being a validator on Polygon is not just about validating transactions. Validators are also expected to actively participate in network governance, contribute to protocol upgrades, and be a part of the broader community discussions. A passive approach, where a validator merely performs the bare minimum, can be perceived as a lack of commitment to the network's growth and well-being.
Deep Dive: The Polygon ecosystem is dynamic, with regular protocol upgrades, governance proposals, and community initiatives. Validators who actively participate, voice their opinions, and contribute to the network's betterment are seen as valuable assets. On the other hand, those who remain passive risk being perceived as opportunistic, only in it for the rewards.
For a technically skilled coder running a validator, these pitfalls might seem basic. However, in the daily grind of maintaining nodes, ensuring security, and optimizing for rewards, it's easy to overlook these foundational aspects. The key lies in striking a balance – ensuring technical excellence while also prioritizing transparency, active participation, and stakeholder communication.
In the age of institutional staking, where professional entities with stringent due diligence processes are entering the fray, the margin for error is minimal. Validators who recognize these pitfalls and actively work to avoid them position themselves as trustworthy pillars of the Polygon ecosystem.
Are you a Polygon Validator ready to improve your trustworthiness?
We are currently helping 26 Polygon Validators - who produce 30.75% of all blocks - to protect the Polygon network while earning more MATIC from MEV auctions.
By just patching your sentries with a free one-line code you can collect MATIC while keeping the network clean and safe from harmful activities like frontrunning and sandwich attacks.
On average it takes less than 10 minutes to onboard before you can start making a positive influence on the Polygon user experience and collect MATIC that would otherwise just be collected by Searchers.
We are helping validators make MEV more transparent on Polygon and increasing trust with their delegators by building decentralised infrastructure.
If you would like to know more, please email me at tom@fastlane.finance
The Polygon network is becoming a big player in DeFi, offering scalability and low transaction costs.
However, as the network grows, so do the challenges for validators.
This article aims to shed light on the most pressing issues facing Polygon validators and how a simple solution can significantly improve delegator retention.
Validators are the backbone of the Polygon network, responsible for validating transactions and creating new blocks.
However, the role comes with its set of challenges:
Running a validator node isn't cheap. From server costs to security measures, the financial burden can be significant. This is especially true for smaller validators who don't have the backing of institutional investment funds.
Validators are constant targets for adversarial attacks. Whether it's DDoS attacks or attempts to exploit vulnerabilities, maintaining a secure environment is a full-time job.
Being a validator isn't just about transaction validation; it's about active participation in network governance. Validators are expected to vote on protocol upgrades, which requires a deep understanding of the ecosystem.
Maximal Extractable Value (MEV) is a complex task that requires a deep understanding of the network and smart contract interactions.
Failing to optimize for MEV can result in significant financial losses.
In February of 2022 a serious threat to the Polygon blockchain arose.
The network’s stability was in jeopardy due to nodes being flooded with spam transactions sent by arbitrageurs, liquidators, and gamers looking for Maximal Extractable Value.
These actors, known collectively as ‘searchers,’ look to profit from inefficiencies in the ordering of transactions.
The ultimate goal of the searchers is to extract profit by using bots to ‘search’ for opportunity-creating transactions which can be exploited by quickly placing their own transactions directly after–and sometimes before–said transaction.
In the process of competing over opportunities, searchers can create spam transactions which lead to suboptimal user experiences such as delayed execution, slippage, and network congestion.
These spam transactions can cause instability in validator nodes, as observed during the outages in Q1 of 2022.
From the delegator's point of view, especially institutional ones, the focus is on long-term growth and stability.
They are not interested in validators who offer high returns but can't guarantee security or have a history of poor governance participation.
If a validator isn’t careful to foolproof their node from threats such as arbitrageur spam, this can lead to node instability and potential downtime.
From a delegator’s view, this is a risk that should be avoided and could result in the Validator losing stake.
So, how can validators address these challenges and retain their delegators?
The answer is simpler than you might think: patching your sentries.
With this code:
![\"Patching](\"https://app.gitbook.com/share/space/thumbnail/cdwawPu1WZY0iOUAGHRD/page/PejHOvF97t7eZHRsOirK.png?color=%23346DDB&logo=&theme=default\")
By applying a single line of code to your sentry nodes, you can drastically improve the Polygon network user experience and optimize for MEV.
This process is roughly a quick 2-minute task but will allow you to remove transaction spam from arbitrageurs, increase node stability, collect additional revenue and improve the Polygon User experience.
This simple patch shows delegators that you are committed to upholding a secure and healthy network, thereby increasing their likelihood of sticking with you in the long run.
Being a Polygon validator is challenging but rewarding.
While the hurdles are many, patching your sentries can go a long way in improving delegator retention.
It not only enhances node stability and user experience but also optimizes MEV, offering a win-win situation for both validators and delegators.
Are you a Polygon Validator ready to improve your revenue and node stability?
We are currently helping 26 Polygon Validators - who produce 30.75% of all blocks - to protect the Polygon network while earning more MATIC from MEV auctions.
By just patching your sentries with a free one-line code you can collect MATIC while keeping the network clean and safe from harmful activities like frontrunning and sandwich attacks.
On average it takes less than 10 minutes to onboard before you can start making a positive influence on the Polygon user experience and collect MATIC that would otherwise just be collected by Searchers.
We are helping validators make MEV more transparent on Polygon and increasing trust with their delegators by building decentralised infrastructure.
If you would like to know more, please email me at tom@fastlane.finance
In the rapidly evolving blockchain landscape, validators play a pivotal role.
Their ability to attract delegators can make or break their success.
While many validators excel in their technical capabilities, some overlook simple fixes that can significantly boost their appeal to potential delegators.
In this article, we'll highlight three easy fixes that validators can implement to attract more delegators.
Delegators seek assurance. They want to know that their assets are managed efficiently and securely. A straightforward way to provide this assurance is through transparent operations and clear communication.
Issue: Some validators fall short in regularly updating their delegators, leading to mistrust or uncertainty.
Easy Fix: Establish consistent communication channels. Whether it's through social media, email newsletters, or community forums, regular updates can foster trust. Share insights about performance, fee adjustments, and any potential risks. Remember, an informed delegator is a confident delegator.
The blockchain world is no stranger to security breaches. Delegators are acutely aware of these risks and prioritize validators who demonstrate a commitment to security.
Issue: Inadequate infrastructure or outdated security measures can deter potential delegators, fearing their assets might be vulnerable.
Easy Fix: Regularly update and fortify your infrastructure. Engage with cybersecurity experts to conduct periodic audits and address vulnerabilities. Highlighting your proactive approach to security can serve as a significant attraction point for delegators.
At the end of the day, delegators are driven by returns on their investments. They seek validators who offer optimal performance without exorbitant fees.
Issue: Validators who don't consistently deliver or who charge high fees without clear justification can struggle to attract and retain delegators.
Easy Fix: Continuously monitor and refine your operations to ensure you're delivering the best possible performance. If you're charging a premium fee, ensure you're offering value-added services that justify the cost. A competitive fee structure combined with top-tier performance can be a winning combination.
The world of blockchain offers immense opportunities for validators.
By implementing these easy fixes, validators can enhance their appeal, attract more delegators, and solidify their position in the ecosystem.
It's all about building trust, ensuring security, and delivering value.
We are currently assisting 26 Polygon Validators - who produce 30.75% of all blocks - to earn more MATIC through MEV.
By simply patching your sentries (with a complimentary one-line code), you can amplify your earnings while preserving the network's integrity, shielding it from malicious activities.
Typically, the connection process takes less than 10 minutes, post which you can begin positively influencing the Polygon user experience and accrue MATIC that would otherwise be snapped up by Searchers.
To request more details, email me at: tom@fastlane.finance
","comment_id":"650e62ed2d65f00001cb40ae","feature_image":"https://fastlane.ghost.io/content/images/2023/09/3-Easy-Fixes-Validators-Can-Make.png","featured":false,"visibility":"public","created_at":"2023-09-22T21:00:45.000-07:00","updated_at":"2024-07-01T10:31:03.000-07:00","published_at":"2023-09-22T21:05:36.000-07:00","custom_excerpt":"Validators: Boost appeal with transparency, enhanced security, and optimal performance. Discover 3 fixes to attract more Polygon delegators.","codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":"https://www.fastlane.finance/blog/3-easy-fixes-validators-can-make-to-attract-more-delegators","tags":[{"id":"64fbc03e4a3aee0001c55ac0","name":"Validators","slug":"validators","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/validators/"}],"primary_tag":{"id":"64fbc03e4a3aee0001c55ac0","name":"Validators","slug":"validators","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/validators/"},"url":"https://fastlane.ghost.io/3-easy-fixes-validators-can-make-to-attract-more-delegators/","excerpt":"Validators: Boost appeal with transparency, enhanced security, and optimal performance. Discover 3 fixes to attract more Polygon delegators.","reading_time":2,"access":true,"comments":false,"og_image":"https://fastlane.ghost.io/content/images/2023/09/3-Easy-Fixes-Validators-Can-Make-2.png","og_title":"3 Easy Fixes Validators Can Make to Attract More Delegators","og_description":"Validators: Boost appeal with transparency, enhanced security, and optimal performance. Discover 3 fixes to attract more Polygon delegators.","twitter_image":"https://fastlane.ghost.io/content/images/2023/09/3-Easy-Fixes-Validators-Can-Make-1.png","twitter_title":"3 Easy Fixes Validators Can Make to Attract More Delegators","twitter_description":"Validators: Boost appeal with transparency, enhanced security, and optimal performance. Discover 3 fixes to attract more Polygon delegators.","meta_title":"3 Easy Fixes Validators Can Make to Attract More Delegators","meta_description":"Validators: Boost appeal with transparency, enhanced security, and optimal performance. Discover 3 fixes to attract more Polygon delegators.","email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null},{"id":"650555f9df79c400015f9c73","uuid":"0af0852d-4693-4f86-bb74-0fdfafe6c1a0","title":"The Changing Face of Delegator Preferences in the Age of Institutional Staking","slug":"the-changing-face-of-delegator-preferences","html":"In the ever-evolving landscape of the Polygon network, the dynamics of staking have undergone significant shifts.
As the decentralized finance (DeFi) ecosystem matures, the preferences of delegators are not what they used to be.
The age of institutional staking has dawned, and with it comes a new set of expectations and considerations for Polygon Validators.
Historically, individual delegators prioritized short-term gains, often hopping between validators to chase higher rewards.
The game was simple: find the validator offering the best returns and delegate.
However, as institutional players enter the staking arena, the rules of the game are being rewritten.
Institutional staking is not just about returns; it's about security, reliability, and long-term growth.
Institutional investment funds, with vast amounts of capital at their disposal, are not looking for quick wins.
They seek stability and predictability.
For them, the risk associated with validator downtime, slashing events, or poor network participation can be a deal-breaker.
This shift in delegator profile means validators need to up their game.
It's no longer sufficient to offer competitive staking rewards.
Validators must demonstrate a track record of reliability, invest in top-tier infrastructure, and actively participate in network governance.
For the technically skilled coder running a validator, this evolution presents both challenges and opportunities.
The modern validator must be adept not just in maintaining node uptime but in navigating the complex interplay of network politics, protocol upgrades, and the ever-present threat of adversarial attacks.
Validators are now expected to be at the forefront of protocol development, actively contributing to the improvement of the Polygon network.
This proactive approach is not just about staying relevant; it's about shaping the future of the network in which they have a vested interest.
In the age of institutional staking, understanding the needs and expectations of the new-age delegator is crucial. These are not individuals looking to make a quick buck. They are professional entities, with stringent due diligence processes and a long-term vision.
For validators, the message is clear: adapt or risk obsolescence. The age of institutional staking demands a higher standard of operation, a proactive approach to network participation, and an unwavering commitment to security and transparency.
Validators who recognize these shifts and position themselves accordingly will not only attract institutional delegators but will play a pivotal role in the next phase of Polygon's growth. It's an exciting time to be a part of the Polygon network, and for those validators willing to rise to the challenge, the rewards—both financial and in terms of influence within the network—are significant.
Are you a Polygon Validator ready to make the most of these trends?
Let’s Talk.
We are currently helping 26 Polygon Validators - who produce 30.75% of all blocks - to earn more MATIC through MEV.
By just patching your sentries, (with a free, one-line code) you can boost your earnings while keeping the network clean and safe from harmful activities.
On average it takes less than 10 minutes to onboard before you can start making a positive influence for the Polygon user experience and collect MATIC that would otherwise just be collected by Searchers.
For more details - message me at tom@fastlane.finance
In the world of Web 3, where Polygon continues to make waves through innovation, validators are the linchpin. Their role in ensuring the security and efficiency of the ecosystem is paramount, and they also serve as magnets for stakers who delegate their MATIC tokens in anticipation of rewards. However, even the most technically proficient validators can inadvertently deter potential delegators. Here, we dissect the top three pitfalls that can hinder a validator's chances of attracting more delegators, delve into the \"why\", and offer solutions.
Mistake: Not staying abreast with the nuances of zkEVM and Polygon 2.0, leading to operational inefficiencies.
Why It Matters: The zkEVM is a cornerstone of Polygon 2.0, enhancing transaction throughput and reducing costs. A validator's lack of understanding can result in suboptimal performance, making their node less appealing to potential stakers. This can directly impact the rewards and trust associated with the validator.
Solution: Continuous learning is key. Validators should immerse themselves in the documentation, participate in community discussions, and collaborate with peers to ensure they're leveraging the full potential of zkEVM and Polygon 2.0.
Mistake: Failing to upgrade infrastructure or not tailoring it to the specific requirements of Polygon 2.0, leading to missed blocks or attestations.
Why It Matters: Infrastructure is the backbone of a validator's operations. Any lapse can compromise the security and efficiency of the network. Institutional investment funds, with their vast resources, are particularly discerning and will avoid validators with subpar infrastructure, leading to lost delegation opportunities.
Solution: Regular infrastructure audits and updates are crucial. Validators should ensure their setups are in line with the latest protocols and best practices. Engaging with the developer community can provide insights into optimization strategies tailored for Polygon 2.0.
Mistake: Not aligning operations with the needs and strategies of institutional stakers, leading to potential divestment.
Why It Matters: Institutional stakers bring in substantial delegations, and their trust is paramount. A misalignment can not only result in lost opportunities but can also tarnish a validator's reputation in the broader ecosystem. Building and maintaining trust with these entities is crucial for long-term success.
Solution: Direct engagement is essential. Validators should proactively reach out to institutional stakers, understand their needs, and tailor their operations accordingly. Transparency, efficiency, and clear communication channels can go a long way in building trust with these institutional entities.
Being a validator in the Polygon ecosystem is a role filled with responsibility and potential. By understanding and addressing the significance of the pitfalls outlined above, validators can position themselves as reliable nodes, attracting more delegators and solidifying their stature in the network. In the dynamic world of Web 3.0, understanding the \"why\" behind every action and implementing the right solutions is the key to sustained success.
FastLane Labs is currently assisting 26 Polygon Validators - who produce 30.75% of all blocks - to earn more MATIC through MEV.
By simply patching your sentries (with a complimentary one-line code), you can amplify your earnings while preserving the network's integrity, shielding it from malicious activities.
Typically, the onboarding process takes less than 10 minutes, post which you can begin positively influencing the Polygon user experience and accrue MATIC that would otherwise be snapped up by Searchers.
","comment_id":"64fbc2664a3aee0001c55ae4","feature_image":"https://fastlane.ghost.io/content/images/2023/09/Top-3-Mistakes.png","featured":false,"visibility":"public","created_at":"2023-09-08T17:55:02.000-07:00","updated_at":"2024-04-03T20:08:44.000-07:00","published_at":"2023-09-08T18:05:27.000-07:00","custom_excerpt":"Learn how to navigate the top 3 pitfalls that Polygon Validators face in attracting more delegators. Get insights on zkEVM, improve your infrastructure, and meet institutional staker expectations.","codeinjection_head":null,"codeinjection_foot":null,"custom_template":null,"canonical_url":"https://www.fastlane.finance/blog/top-3-mistakes-costing-validators-delagators","tags":[{"id":"64fbc03e4a3aee0001c55ac0","name":"Validators","slug":"validators","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/validators/"}],"primary_tag":{"id":"64fbc03e4a3aee0001c55ac0","name":"Validators","slug":"validators","description":null,"feature_image":null,"visibility":"public","og_image":null,"og_title":null,"og_description":null,"twitter_image":null,"twitter_title":null,"twitter_description":null,"meta_title":null,"meta_description":null,"codeinjection_head":null,"codeinjection_foot":null,"canonical_url":null,"accent_color":null,"url":"https://fastlane.ghost.io/tag/validators/"},"url":"https://fastlane.ghost.io/top-3-mistakes-costing-validators-delagators/","excerpt":"Learn how to navigate the top 3 pitfalls that Polygon Validators face in attracting more delegators. Get insights on zkEVM, improve your infrastructure, and meet institutional staker expectations.","reading_time":2,"access":true,"comments":false,"og_image":"https://fastlane.ghost.io/content/images/2023/09/Top-3-Mistakes-5.png","og_title":"Top 3 Mistakes Costing Validators Delegators on Polygon","og_description":"Learn how to navigate the top 3 pitfalls that Polygon Validators face in attracting more delegators. Get insights on zkEVM, improve your infrastructure, and meet institutional staker expectations. ","twitter_image":"https://fastlane.ghost.io/content/images/2023/09/Top-3-Mistakes-6.png","twitter_title":"Top 3 Mistakes Costing Validators Delegators on Polygon","twitter_description":"Learn how to navigate the top 3 pitfalls that Polygon Validators face in attracting more delegators. Get insights on zkEVM, improve your infrastructure, and meet institutional staker expectations. ","meta_title":"Top 3 Mistakes Costing Validators Delegators on Polygon","meta_description":"Learn how to navigate the top 3 pitfalls that Polygon Validators face in attracting more delegators. Get insights on zkEVM, improve your infrastructure, and meet institutional staker expectations. ","email_subject":null,"frontmatter":null,"feature_image_alt":null,"feature_image_caption":null}]},"__N_SSG":true}