Skip to main content

Transaction Lifecycle Overview

Flexible Configuration​

The Atlas Protocol is engineered with modularity and adaptability at its core, enabling a wide array of configurations to suit diverse use cases and network requirements. This flexibility allows Atlas to seamlessly integrate with various blockchain ecosystems while upholding its fundamental principles of efficiency and security.

Key aspects of Atlas Protocol's flexibility include:

  • Support for multiple transaction flow configurations
  • Optional components for customized implementations
  • Adaptability to different blockchain environments and operational needs

The protocol supports a spectrum of transaction flow configurations, ranging from minimal infrastructure to complex setups with multiple components. The two configurations presented in this document represent opposite ends of this spectrum:

  1. Frontend-Centric Flow: A streamlined approach where the frontend application manages most of the transaction lifecycle, requiring minimal additional infrastructure.
  2. Operations Relay Flow: A more complex configuration utilizing additional infrastructure components, offering improved speed and flexibility.

These two configurations are examples, not limitations. Atlas Protocol allows for numerous variations and hybrid approaches between these extremes, including:

  • Configurations with partial relayer functionality
  • Setups using custom auctioneer implementations
  • Integrations with specialized solver networks
  • Hybrid models combining on-chain and off-chain components

It's important to note that not all components described in this document are mandatory for every Atlas implementation. The transaction lifecycles presented here showcase specific configurations, demonstrating the protocol's versatility and ability to adapt to various operational requirements and performance needs.

Developers and projects can tailor their Atlas implementation to find the optimal balance between simplicity, speed, decentralization, and customization based on their specific use case and target blockchain ecosystem.

Frontend-Centric Flow​

Transaction Lifecycle Frontend

The Frontend-Centric Flow represents a streamlined approach where the DApp frontend assumes a central role in managing the transaction lifecycle. This configuration minimizes the need for additional off-chain infrastructure, making it ideal for simpler deployments or scenarios where direct control over the process is preferred.

Key characteristics of this flow include:

  • Direct interaction between the frontend and the Searcher Network
  • Frontend-managed auction process and solution aggregation
  • Simplified communication path with fewer intermediaries
  • transaction verification via session keys

1. User Interaction and UserOp Creation​

  • Description: The User initiates the process by interacting with the DApp Frontend.
  • Interaction: The Frontend creates and signs a User Operation (UserOp) based on the user's intent.
  • Flow Reference: Initial step in the frontend-centric flow.
  • Technical Details: The Frontend encapsulates the user's intent into a UserOp, including necessary parameters such as the user's signature, nonce, and other execution details.

2. Auction Initiation and UserOp Propagation​

  • Description: The Frontend starts the auction by sending the UserOp to the Searcher Network.
  • Interaction: Direct communication between the Frontend and Searcher Network.
  • Flow Reference: Corresponds to step 1 in our simplified flow diagram.
  • Technical Details: The Frontend efficiently distributes the UserOp to multiple searchers, ensuring fair and timely access to the transaction opportunity.

3. Searcher Solution Generation​

  • Description: Searchers in the network analyze the UserOp and create their Searcher Operations (solutions).
  • Interaction: Internal process within the Searcher Network.
  • Flow Reference: Part of step 2 in our simplified flow diagram.
  • Technical Details: Searchers optimize the transaction execution, potentially extracting MEV or finding the most efficient path for execution.

4. Solution Submission to Frontend​

  • Description: Searchers submit their solutions back to the Frontend.
  • Interaction: Direct communication from Searcher Network to Frontend.
  • Flow Reference: Corresponds to step 2 in our simplified flow diagram.
  • Technical Details: Solutions are securely transmitted to the Frontend, maintaining the integrity and confidentiality of the searchers' strategies.

5. Solution Aggregation and Optimization​

  • Description: The Frontend aggregates and optimizes the received searcher solutions.
  • Interaction: Internal process within the Frontend.
  • Flow Reference: Part of step 3 in our simplified flow diagram.
  • Technical Details: The Frontend may employ algorithms to select the best solution or combine multiple solutions for optimal execution. This could involve a local implementation of a sortBids-like function.

6. Transaction Preparation​

  • Description: The Frontend prepares the final transaction based on the aggregated solutions.
  • Interaction: Internal process within the Frontend.
  • Flow Reference: Part of step 3 in our simplified flow diagram.
  • Technical Details: The Frontend compiles the selected solutions into a format suitable for on-chain execution, potentially including multiple operations in a single transaction.

7. Submission to Atlas Entrypoint​

  • Description: The Frontend submits the prepared transaction to the Atlas Entrypoint.
  • Interaction: Direct communication from Frontend to Atlas Entrypoint.
  • Flow Reference: Final part of step 3 in our simplified flow diagram.
  • Technical Details: The transaction is sent to the Atlas Entrypoint for on-chain execution. This step may involve calling an execute() function or similar method on the Entrypoint contract.

Operations Relay Flow​

Transaction Lifecycle with Bundler

The Operations Relay Flow showcases a more complex but highly flexible configuration of the Atlas Protocol. This setup introduces additional components such as the Operations Relay and Auctioneer, enabling more sophisticated auction mechanisms and potential integration with external services.

Key features of this flow include:

  • Utilization of an Operations Relay for efficient message propagation
  • Dedicated Auctioneer component for managing the bidding process
  • Optional integration with third-party bundlers for transaction submission
  • Enhanced flexibility for customization and scaling

1. User Operation Initiation​

  • Description: The User initiates the process by signing and sending a User Operation (UserOp).
  • Interaction: The signed UserOp is sent directly to the Auctioneer.
  • Flow Reference: Corresponds to Step 1 in the updated flow.
  • Technical Details: The UserOp includes essential data such as the user's intent, signature, nonce, and other parameters required for execution. This ensures that the operation is authenticated and can be tracked throughout its lifecycle.

2. User Operation Propagation​

  • Description: The Operations Relay (OR) propagates the UserOp to the Solver Network.
  • Interaction: Ensures that the UserOp is available to all potential Solvers.
  • Flow Reference: Corresponds to Step 2 in the updated flow.
  • Technical Details: The OR efficiently distributes the UserOp to the Solver Network, allowing Solvers to analyze and prepare their proposals.

3. Solver Operation Submission​

  • Description: Solvers in the network submit their proposed Solver Operations (SolverOps) to the Operations Relay.
  • Interaction: SolverOps are sent from the Solver Network to the Operations Relay.
  • Flow Reference: Corresponds to Step 3 in the updated flow.
  • Technical Details: Solvers analyze the UserOps to identify opportunities for optimizing transaction execution or extracting Maximum Extractable Value (MEV). They submit SolverOps that propose enhancements or alternative execution paths.

4. Relay of Solver Operations​

  • Description: The Operations Relay (OR) forwards the received SolverOps to the Auctioneer.
  • Interaction: Ensures that SolverOps are available for the bidding process.
  • Flow Reference: Corresponds to Step 4 in the updated flow.
  • Technical Details: The relay maintains the integrity and confidentiality of SolverOps during transmission, utilizing secure communication protocols to prevent tampering or unauthorized access.

5. Bid Sorting and Selection​

  • Description: The Auctioneer performs a sortBids view call to the Atlas Entrypoint Contract (AEC) with SolverOps as input.
  • Interaction: Utilizes the AEC to determine the best bid based on predefined criteria.
  • Flow Reference: Corresponds to Step 5 in the updated flow.
  • Technical Details: The sortBids function in the AEC evaluates and ranks the SolverOps based on factors such as efficiency, cost, potential MEV extraction, and compliance with protocol rules.

6. Routing to Bundler (If Necessary)​

  • Description: If required, the Auctioneer routes the selected SolverOps to a third-party Bundler.
  • Interaction: Facilitates additional processing or compilation of operations.
  • Flow Reference: Corresponds to Step 6 in the updated flow.
  • Technical Details: This step is optional and depends on the specific requirements of the transaction. It may involve aggregating multiple SolverOps or optimizing the transaction for efficient on-chain execution.

7. Transaction Compilation and Execution​

  • Description: The Bundler compiles the Atlas transaction and calls the execute() function on the Atlas Entrypoint Contract (AEC).
  • Interaction: Ensures that the compiled transaction is executed on-chain, finalizing the process.
  • Flow Reference: Corresponds to Step 7 in the updated flow.
  • Technical Details: The metacall() function in the AEC handles the atomic execution of the aggregated transaction, ensuring that all included operations are processed consistently and securely on the blockchain. This step finalizes the transaction lifecycle, updating the state as per the executed operations.

Conclusion​

By offering these diverse transaction flows, Atlas Protocol demonstrates its ability to cater to a wide range of DApp requirements and operational preferences. Whether opting for the streamlined Frontend-Centric approach or the more elaborate Operations Relay configuration, developers can choose the setup that best aligns with their specific needs and ecosystem considerations.

The flexibility of Atlas allows for various other configurations, such as:

  • Direct submission of solver operations without a bundler
  • Integration with different types of relayers or auctioning mechanisms
  • Custom solver networks or single-solver setups

This adaptability ensures that Atlas can meet the evolving demands of the blockchain landscape while providing efficient and secure transaction processing.