Fastlane shBundler
Validator-based bundling. Paymaster. Escrow system
shMonad is probably the only product from Fastlane that people are more familiar with. To be fair, it’s the product users get to interact directly with. However, Fastlane has a suite of other products besides shMonad (the holistic liquid staking protocol). These products are Atlas, shBundler, and Task Manager.
Atlas: Atlas is a protocol that brings the concept of app-specific sequencing to life on Monad. It enables apps that integrate with it to manage transaction order flow and regulate MEV revenue allocation to users.
Fastlane Relay for Smart Accounts (shBundler): shBundler acts as a real-time, high-performance relay network that routes, bundles, and executes smart account transactions (UserOps) between onchain apps and users, enhancing the user experience on Monad.
Our focus in this article will be on shBundler. We’ll take a look at the Task Manager in another piece.
“What is shBundler?”
Fastlane shBundler introduces three innovations: validator-based bundling, asynchronous execution paymaster, and the escrow system.
I’ll explain all of these concepts one after the other. Ready?
Validator-Based Bundling
In account abstraction abstraction, users’ transactions are called UserOps while solvers’ bids are called SolverOps.
Users initiate 4337-transactions (UserOps). Solvers participate in auctions, facilitated by the auctioneer, by placing bids (SolverOps). Solvers with the winning bids earn the right to backrun the user transactions and capture MEV. Bundlers bundle both operations as a single transaction and execute them. You can better understand the roles of each of these actors through this post.
This is where it gets interesting.
In most protocols, bundlers are external operators and are distinct from the validators. So, the bundlers bundle the User & Solver Ops and submit them to other middleware/intermediaries to relay them to the validator for execution. You can imagine that this will introduce some latency in communication between the bundlers and validators. But imagine if the same party who bundles can also execute the User/SolverOps directly, thereby reducing latency in communication.
Exactly! That’s what Fastlane did.
Fastlane created a solution to enable Monad validators directly can act as bundlers. Meaning, they can have dual roles: they can bundle users’ & solvers’ operations as bundlers AND they can execute the bundle as validators. Reduced latency. That’s one of the vital innovations of shBundler: The Validator-based Bundling.
In other words, Monad validators can run Fastlane node software to take the role of bundlers. These validators will earn additional revenue for bundling and executing these transactions.
Asynchronous Execution Paymaster
What’s a paymaster?
One feature that account abstraction introduced is gas sponsorship through fee abstraction.
TLDR: Fee abstraction is being able to pay for gas fees using a non-native token. Gas sponsorship allows users to commit or bond that “non-native token” to a different contract to facilitate the gas fee payment. This “contract” is the Paymaster. Users can self-sponsor, or apps can sponsor gas fees for their users (called third-party gas sponsorship).
Paymasters cover gas fee payments for users and are reimbursed for doing so.
Fastlane is building an account abstraction layer on Monad, so it has a paymaster. Fastlane 4337 Paymaster allows users or apps to commit shMON (the LST for their holistic liquid staking protocol, shMonad) to cover gas fees for transactions.
I’ve discussed it multiple times, but here’s a summarized explanation of account abstraction and how Fastlane Paymaster works.
Escrow System
Unlike most blockchains that use synchronous/interleaved execution, Monad uses asynchronous/deferred execution.
Synchronous execution is when consensus occurs after the transaction has been executed. Consensus won’t happen before execution.
Asynchronous execution, on the other hand, is when consensus happens before the transaction is executed. This is how Monad’s architecture is designed. A transaction is voted upon and executed two blocks later. That’s why it’s often referred to as deferred execution…because execution is delayed. You can read more about Monad asynchronous execution here.
While asynchronous execution is good, it gives rise to an issue for Paymasters. Fastlane calls this issue a Delayed Solvency Attack. Paymasters are vital actors in account abstraction (4337 transactions). They facilitate gas fee payment for users.
Here’s how it works:
Paymasters are like moneylenders. They pay the gas fees to get users’ transactions in the block and get refunded after the transactions have been executed. The fee is refunded to the paymasters from the gas fee + priority fee allocated for that transaction by the users.
ERC-4337 transactions are more costly than regular EOA transactions because they require complex computation and verification, so users would typically set a high priority fee to get their transactions added to the block faster. Usually, the gas fee that paymasters spend to get the users’ transactions in is lower than the fees that’ll be refunded to them, so they pocket the profit. It’s like a “Pay first, I’ll reimburse you” situation where paymasters pay first & users reimburse later.
Now, due to Monad’s deferred execution design, consensus is reached on the block where the transaction resides before the transaction itself is executed. The transaction is finally executed after 2 more blocks have been created {block n+2}. That means there’s a small time frame from when paymasters have already used their funds to pay gas fees for the users to when the transaction is executed, which is when the paymasters should get reimbursed.
If a user is malicious, they can use this delay {block n+2} as an opportunity to remove all the funds from their wallet so the paymasters don’t get reimbursed for their services. By the time the transaction is executed, there won’t be any funds for the paymasters to claim. They ultimately bear the full costs.
“Hey! That’s cheating.”
I know. Fastlane knows as well. That’s why they built the escrow system to prevent situations like this.
Fastlane has a paymaster as well, remember? To prevent negative scenarios like this, they created an escrow system.
This escrow system is where the gas fees that users are supposed to refund to the paymasters are committed to (locked up) immediately they trigger their transactions from the frontend. The escrow will reimburse the paymasters the fees after the transactions have been executed. The escrow is a third party. This method ensures that paymasters are not cheated.
This escrow system solves the delayed solvency attack for paymasters caused by deferred execution.
Fastlane is building Monad's account abstraction layer. It is also one of the infra teams currently providing paymaster & bundler services on Monad testnet. You can check it out on the Monad doc.