Atlas

The Execution Abstraction Protocol by FastLane Labs

Introduction

Execution Abstraction allows front-end apps, wallets, and other entities to define and expand the context in which operations are executed within a transaction.

Execution itself is an abstract notion, as there is no single, granular form, design, or requirement for it. This inherent abstraction makes it challenging to explain execution abstraction, as it involves abstracting an already abstract concept. Execution Abstraction involves multiple layers of execution context, such as defining what happens before, during, and after operations, as well as the relationships between operations within the same transaction. These layers can be difficult to convey concisely and clearly.

Despite the challenges, execution abstraction offers several key benefits that address current issues in the DeFi ecosystem:

1. Expanded control over operation execution enables sophisticated and tailored transaction processing, protecting users from predatory practices like MEV exploitation.

2. The ability to capture and internalize value generated by operations ensures a more equitable distribution of value and promotes sustainability.

3. Execution Abstraction maintains decentralization and trustlessness by bundling operations into a single transaction and using smart contracts, potentially eliminating the need for whitelisting and trusted infrastructure.

4. By defining intents and verifying their fulfillment within the execution context, Execution Abstraction can be used as a fully generalized intent engine.

All of which, we’ll discuss in detail in the context of Atlas. 

What is Atlas?

Atlas, built and developed by FastLane Labs, is based on a subset of account abstraction called Execution Abstraction. The core idea behind Atlas is to create a generalized Execution Abstraction protocol that reduces the complexity and cost associated with deploying application-specific order flow auctions (OFAs). These OFAs are auctions used to determine the order of transactions or operations based on bids from participants, which can be prone to MEV-related issues.

Key features

One of Atlas's key features is its ability to capture and internalize the value generated by operations. In the current DeFi ecosystem, a significant portion of the value created by user transactions is extracted by miners, validators, and other third parties. Atlas allows apps and wallets to control who can capture and internalize this value, redirecting it to users, DAO treasuries, or public goods funding, thus promoting a more equitable value distribution. 

Atlas achieves this through the use of operations, which are EIP 712 messages (signed code, not full transactions) that are bundled into a single transaction by a bundler. This is one of the most impressive aspects of the Atlas architecture’s use of operations as the fundamental building blocks of transactions. This bundling process is crucial for maintaining decentralization and trustlessness, as it prevents block builders, validators, and other parties from manipulating the execution order of operations within a transaction (which is truly the whole point).  While validators and block builders can sequence transactions in a block, Atlas prevents them from sequencing operations inside a transaction. This ensures the intended execution order is maintained and protects against value leakage, even in the event of chain reorganizations.

Unlike traditional MEV bundles, Atlas allows operations to reference other operations in any direction within the same transaction, providing atomicity and protection against chain reorganizations. This ensures that the intended execution order is maintained and value is not leaked, even if there are chain reorganizations.

Another important aspect of Atlas is its use of smart contracts to determine operation interactions and auction winners. This eliminates the need for whitelisting solvers and trusted infrastructure, maintaining the protocol's permissionless and decentralized nature. By using smart contracts, Atlas ensures that the trust assumptions are handled within the protocol itself, preventing centralization and protecting users from potential manipulation by malicious actors.

Atlas Architecture

The main roles in the Atlas architecture include:

• Originator: The party that initiates the Atlas process by generating a signed operation representing their desired transaction(s). This is typically the User; the party perceived as having intrinsic value. But this role can also be designated more flexibly to other entities like contracts, block builders etc. 

  • Who: users, oracles, bridges, or co-processors initiating action requests

• Solvers: Entities that respond to originator operations by proposing solutions to internalize MEV or fulfill intents. Solvers compete in an auction to provide the best outcome for the Originator.

• Auctioneer: Responsible for aggregating the Originator’s operation  and the Solvers’ operations (solutions), and sorting them using the bid valuation function. To maintain incentive compatibility, the Auctioneer is typically the beneficiary of the auction, which is usually the Originator.

• Operations Relay (OR): An infrastructure layer that facilitates communication between Originators, Auctioneers, and Solvers. Choice of OR impacts factors like decentralization, privacy, etc.  In many cases, the Operations Relay is a smart contract on the same chain as the main Atlas smart contract.

• Bundler: Generates the full Atlas transaction after compiling the Originator’s, Solvers’, and Auctioneer’s operations and ensures the transaction’s inclusion on-chain. It can be permissionless or permissioned, depending on the dApp’s needs. 

To maintain trustlessness and decentralization, Atlas aims to handle these roles through smart contracts whenever possible. For example, the auctioneer role is often assigned to the auction beneficiary, as they have a vested interest in selecting the best solution.

One of the standout features is the separation of concerns among the various actors involved. The originator, solvers, auctioneer, and bundler each have distinct responsibilities, allowing for specialization and optimization at each stage of the process. This modular design promotes flexibility and adaptability, as different implementations or strategies can be employed for each role without disrupting the overall flow.

The Atlas SDK allows parties to easily sign a “CallChainHash”, which is verified by the Atlas smart contract to ensure the integrity of the execution order. Native bundling, using Execution Abstraction, enables permissionless, multi-chain OFAs without relying on guarantees from block builders or private relays. It enhances the likelihood of favorable execution outcomes and supports various enforcement techniques to increase the likelihood of successful execution.

atlETH, a wrapped representation of ETH within Atlas, enables solvers to escrow funds for gas consumption and supports an Atlas-native cross-operation flash loan system. The extra checks Atlas requires do consume more gas compared to builder-integrated OFAs. But solvers typically cover these higher fees. 

This is a visualization of atlETH in action

The diagram above is an example of a use case in the Atlas protocol involving the submission and execution of Solver operations using atlETH’s escrow. Specifically, it illustrates the process of Solvers participating in the Atlas ecosystem by submitting their proposed solutions to solve an Originator’s operation (User intent), while escrowing atlETH to cover the gas costs associated with executing their solutions.

We have simplified a few terms for better understanding. Here's a brief explanation of the diagram:

1. The Solvers deposit gas (atlETH) in the Atlas escrow system.

2. The Solver network submits proposed solutions to the Atlas contract  (Atlas EntryPoint Contract).

3. The Atlas contract verifies if the escrowed gas tokens are sufficient to cover the associated costs.

4. If the Solver’s solution is successful:

   • The Atlas contract executes the proposed solution by interacting with the specific application.

   • The application handles the necessary logic and value allocation based on the executed solution.

   • The Atlas contract releases or adjusts the escrowed gas token balances of the Solvers based on the actual costs incurred.

5. If the Solver’s solution  fails:

   • The Atlas contract cancels the Solver’s operation.

   • The gas cost of the Solver’s failed operation is deducted as a penalty.

   • The remaining escrowed gas tokens can be withdrawn or used for the Solver’s next operation.

The atlETH escrow mechanism ensures Solver accountability, covers gas costs, and incentivizes Solvers to submit valid and efficient solutions. By simplifying the escrow mechanism we have shown how the Atlas protocol leverages atlETH escrow to facilitate Solvers' participation in the ecosystem while maintaining the system's integrity and efficiency.

How to Integrate Atlas?

One of the most powerful features of the Atlas architecture is its modular design, which allows developers to create custom Atlas modules that define the specific rules and behaviors for their DeFi applications. 

To start using Execution Abstraction, an app or wallet must publish an Atlas module (a smart contract) that defines specific rules and behaviors for the execution context surrounding their use case, for example:

1. How solver bids are valued (e.g., based on amount, reputation, or other criteria)

2. Who can be the Auctioneer and Bundler

3. The hook functions that determine how the Originator and Solvers interact

To better understand the Atlas protocol's operational mechanics, let's consider how they are defined and implemented. These components are crucial for ensuring that Atlas operations align with the specific needs and governance structures of different DeFi applications. 

The Atlas module contains three key components that need to be defined by the application developer:

1. Solver Bid Valuation: The first component is the mechanism for valuing Solver bids. Solvers are entities that respond to Originator actions by fulfilling intents or performing triggered actions, and they compete in an auction to provide the best solution or outcome for the Originator.

The Atlas module must define how these Solver bids are evaluated and compared. This can be based on various criteria, such as:

The specific implementation of the Solver bid valuation mechanism is defined in the BidValue function of the Atlas module. This function takes the Solver bids as input and returns a ranking or score for each bid, allowing the Auctioneer to accurately sort Solver operations according to their own preference.

2. Auctioneer and Bundler Assignment: The second component of the Atlas module is the assignment of the Auctioneer and Bundler roles. The Auctioneer is responsible for running the auction process, which involves ranking and sorting the Solver bids based on the valuation mechanism defined in the BidValue function. The Bundler, on the other hand, is responsible for taking the sorted Solver operations, combining them with the originator's operation and any other necessary operations, and submitting the bundled transaction to the blockchain.  By submitting a sorted list of Solver operations, the Auctioneer and Bundler can be confident that at least one of them will successfully fulfill their obligation and pay their bid. 

The Atlas module must specify who can assume these roles for the particular use case. The options include:

The role assignment logic of the Atlas module defines the specific implementation of the Auctioneer and Bundler assignment mechanism.

3. Hook Functions: The third and arguably most critical component of the Atlas module is the definition of the hook functions. Hook functions are special functions that allow developers to customize the interaction between the Originator and Solvers, as well as define the pre-conditions and post-conditions for execution to be considered successful. .

The Atlas module can define several types of hook functions, including:

• Pre-operation hooks: These functions are called before the main operation is executed. They can be used to set up the necessary conditions or perform any required checks or validations. For example, a pre-operation hook could verify that the Originator has sufficient balance to cover the operation or define the Originator’s intent for the Solvers to fulfill.

• User operation hooks: These functions define the main operation that the originator wants to execute, such as a token transfer, swap, deposit, or other smart contract interaction. The user operation hook is where the core logic of the frontend’s application is implemented.  For frontends or wallets looking to internalize their MEV, this operation would simply point to the same smart contract and function that users were interacting with before Atlas was integrated.

• Solver operation hooks: These functions define the specific requirements that Solvers must meet and any assistance that they receive when fulfilling the Originator's intent. Solver operation hooks are where the solvers compete to provide the best solution or outcome for the originator.

• Post-operation hooks: These functions are called after the main operation and Solver operations have been executed. They can be used to perform any necessary cleanup, bookkeeping, or additional actions. For example, a post-operation hook could be used to distribute any earned fees or rewards to the relevant parties.

Developers have a high degree of flexibility in defining the logic and behavior of these hook functions. They can use them to implement custom value capture mechanisms, enforce specific conditions or constraints, or enable complex interactions between the originator and solvers. By allowing customization through hooks in Atlas modules, the Atlas protocol enables developers to build sophisticated and tailored solutions on top of the base execution abstraction layer.  In contrast, the FastLane Labs team has already published multiple simplified modules that can be used by developers looking to rapidly launch an intent-powered application or internalize the MEV created by their existing application.

By carefully designing the hook functions, developers can create powerful and innovative DeFi applications that leverage the full potential of the Atlas protocol's execution abstraction capabilities. The hook functions contain the majority of the application-specific logic, and they are critical for ensuring the desired outcomes and value capture for all parties involved. This flexibility is what makes Atlas particularly powerful for developing sophisticated DeFi applications.

Once the Atlas module is defined and published, it can be used by the DeFi application to enable Execution Abstraction. The application can then route its transactions through the Atlas protocol, which will load the appropriate Atlas module and execute the defined hook functions to facilitate the interaction between the originator, solvers, and other relevant parties.

Now, that we understand the architecture in detail, we try to explain in simple terms and visualization how a transaction at Atlas happens:

Based on L2IV internal research and understanding

The process starts with the Originator creating and signing a UserOperation (as mentioned earlier these are either intents or path-defined operations provided by the users), which represents the desired transaction. The signed UserOp is sent to the Operations Relay, which broadcasts it to the permissionless Solver network. Solvers compete to provide the best solution for executing the UserOps, considering factors like gas optimization and transaction ordering. They submit their proposed solutions (SolverOps) back to the OR.

The OR collects all SolverOps and sends them to the Auctioneer, who evaluates and sorts them based on predefined criteria. The sorted SolverOps are then sent to the Bundler (if separate from the Auctioneer), who combines their targeted SolverOp(s) and the UserOp into an Atlas transaction. The Bundler submits this transaction to the Atlas EntryPoint Contract  via their preferred RPC, relay, or even the public mempool.

The Atlas EntryPoint Contract verifies signatures and executes the operations in the specified order, interacting with the Atlas module to perform app-specific logic. The Atlas module processes the hooks surrounding the operations, performs computations or state changes, distributes value according to defined rules, and returns the results to the Atlas EntryPoint Contract.

Finally, the Atlas EntryPoint Contract performs post-execution processing, such as updating state, emitting events, and attributing gas costs to the appropriate parties. Upon completion, the Operations Relay then notifies the Originator about the completion of the requested operation and provides any relevant updates or results.

Comparison with AppChains

Before we delve deeper into the intricacies of Atlas’s use cases, it becomes essential to understand how it compares with other solutions, such as appchains. 

Appchains are standalone blockchain networks that are purpose-built for specific applications, allowing developers to define custom rules, parameters, and functionalities tailored to their app's requirements. This level of control enables appchains to optimize their performance, security, and user experience for their specific use case.

Similarly, Execution Abstraction, as implemented in the Atlas protocol, allows front-end applications, wallets, and other entities to define and expand the context in which operations are executed within a transaction. This includes setting what happens before, during, and after the operations, as well as defining the relationships between operations in the same transaction (as we discussed in earlier sections above). By providing this level of control over the execution environment, Atlas, through Execution Abstraction, enables apps and wallets to tailor the transaction processing to their specific needs, much like appchains.

However, while Appchains and Execution Abstraction share this similarity in terms of control over the execution environment, the specifics emphasize the key advantages of execution abstraction over Appchains.

1. Enhanced Composability and Modularity:

   • Unlike appchains, which may struggle with interoperability and thus lead to ecosystem fragmentation, Execution Abstraction maintains strong composability and modularity. Apps utilizing Atlas can interact seamlessly with other applications on the same blockchain, benefiting from the broader ecosystem without isolation.

2. Lower Infrastructure Demands:

   • Execution Abstraction leverages the existing infrastructure of the underlying chain, avoiding the substantial costs and logistical challenges associated with launching and maintaining an independent appchain. This approach not only simplifies the technical demands but also capitalizes on the established network effects and security of the primary blockchain.

3. Balanced Trade-offs:

   • Appchains often face trade-offs related to decentralization, security, and scalability due to their isolated nature and potentially smaller validator sets. Execution Abstraction, on the other hand, allows applications to enjoy the benefits of a controlled execution environment while still partaking in the decentralization, security, and scalability advantages of a larger, established blockchain network.

This helps us understand the strategic approach that is needed for building the infrastructure for modern applications. 

Practical Applications of Execution Abstraction in Atlas

As we delve deeper into Atlas's potential within Execution Abstraction, Atlas not only reshapes how transactions are handled but also opens up a myriad of applications where Execution Abstraction can be leveraged to enhance functionality, security, and user experience.

Below are a few examples of how Execution Abstraction through Atlas can be applied across various sectors within the blockchain ecosystem, each tailored to address specific needs and challenges, including:

1. Protecting users from predatory MEV on DEX front-ends:

   • Atlas, through Execution Abstraction, empowers DEX front-ends to protect users from predatory MEV practices by giving them control over the execution context of transactions.

   • The Atlas module can implement checks to detect and prevent sandwich attacks, front-running, or other exploitative strategies.

2. Internalizing non-predatory MEV and redistributing value to users:

   • Atlas, through Execution Abstraction, allows DEX front-ends or other entities to capture and internalize non-predatory MEV opportunities, such as arbitrage and liquidations, without harming user transactions.

   • The captured value can be redistributed to users in the form of reduced trading fees, token rewards, or other incentives, aligning the interests of users and the platform.

3. Enabling gasless transactions for web3 gaming and dapps:

   • Atlas, through Execution Abstraction, allows gaming dapps and other applications to implement gasless transaction mechanisms by abstracting away the gas payment process.  This is possible even without a smart contract wallet.

   • The Atlas module can handle gas payments on behalf of the user, either by subsidizing fees, using meta-transactions, or other techniques, providing a seamless user experience.

4. Facilitating decentralized swap requests for quotation (RFQs):

   • Atlas, through Execution Abstraction, would allow the creation of decentralized and permissionless RFQ systems, where solvers compete to provide the best quote for a user's swap request.

   • The RFQ process can be managed through smart contracts within the Atlas module, promoting competition, price discovery, and efficiency in the token swapping process.

5. Enabling liquidity pools to internalize loss versus rebalancing (LVR):

   • Atlas, through Execution Abstraction, allows liquidity pools to internalize LVR by implementing custom market maker auctions, rebalancing mechanisms and strategies within the Atlas module.

   • The Atlas module can monitor token ratios, trigger rebalancing operations, and incorporate advanced algorithms to minimize impermanent loss and maintain a stable trading environment.

Conclusion

The journey through the intricacies of Atlas reveals a transformative approach to handling transactions within DeFi. Through the lens of Execution Abstraction, we've explored how Atlas enhances transaction processing by:

• Empowering front-end applications to dictate the operational context, thereby shielding users from predatory practices like MEV.

• Internalizing the value extracted from transactions to ensure a fair and equitable distribution among users, rather than losing it to miners or third-party validators.

• Maintaining the core principles of decentralization and trustlessness, crucial to the ethos of blockchain technology.

Atlas stands out not only for its robust mechanism of operation bundling and the strategic use of smart contracts but also for its atlETH escrow, which is even capable of cross-operation flashloans in which app-initiated flashloans for the Originator are paid back by the Solvers. This native token ensures that operations are financially backed, securing the network against spam and financially insincere actions. Moreover, the protocol's ability to handle complex order flow auctions and the integration of various roles—Originators, Solvers, Auctioneers, and Bundlers—into its architecture exemplifies a sophisticated yet flexible transaction system.

As an L2IV portfolio company, we strongly believe Atlas is poised to redefine the standards of transaction execution within DeFi. As we continue to witness how DeFi evolves and adapts, the role of advanced protocols such as Atlas will undoubtedly become more central with a specific focus on Security, Costs, and Democratizing benefits (through MEV).

---

About FastLane

• Website: FastLane

• Whitepaper: Atlas

• GitHub: Docs

We would like to express our sincere gratitude to Alex Watts for his invaluable insights on this article and cooperation throughout our evaluation of FastLane and Atlas.

---

Find L2IV at l2iterative.com and on Twitter @l2iterative

Author: Arhat Bhagwatkar, Research Analyst, L2IV (@0xArhat)

---

References

• On ERC-4337, Intents, and MEV

• Why we are building Atlas

• EIP-712: Typed structured data hashing and signing

• Execution Abstraction

• What is Execution Abstraction

---

Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services.