Skip to main content

Decentralized Exchanges (DEXs)

info

This guide explores in detail how to integrate an existing app (often a decentralized exchange, or DEX) with the Atlas Backruns module.

Atlas Backruns Integration Guide​

1. Why Atlas Backruns?​

The Atlas Backrun module allows an app to internalize MEV (Maximal Extractable Value) generated from its users' order flow that would otherwise leak to other actors in the transaction supply chain.

Without Atlas Backruns, when a transaction that generates MEV originates from the app, competition occurs within the mempool or at block construction time to capture that value. Typically, this value is divided among searchers, block builders, and block proposers.

With the Atlas Backrun module, the app can auction off the right to backrun a particular user's operation and bundle these backrun operations together into a single atomic transaction (along with the user's operation). The auction proceeds can then be allocated using rules provided by the app—for example, they could be used to buy back and burn a governance token or provide a rebate to the user.

2. How It Works​

Atlas introduces meta-transactions for user operations, replacing the traditional method of sending regular transactions directly to the router contract. This integration is implemented directly within the frontend of a DEX and involves coordination with new components like the Auctioneer, the Operations Relay, and the deployment of a DAppControl module by the DEX team. While there is complexity involved, Atlas aids by providing templates and standard modules for common DEX architectures to simplify the integration process.

Key Steps:

  1. User Operation Creation: Instead of creating a regular transaction, the user signs an EIP712 message known as an operation.
  2. Auction Coordination: The operation is first offered to a solver network via an Auctioneer. Solvers have the opportunity to bid on the right to backrun the user's operation. These bids are also in the form of operations.
  3. Bundling Operations: The app collects these solver bids, sequences them, and creates a metacall transaction that bundles the user's operation with the winning solver's operation.
  4. On-Chain Execution with DAppControl Module: The DEX deploys a DAppControl module that defines how the value from the auction is allocated according to the app's rules. When the transaction executes on-chain, the Atlas entrypoint contract interacts with the DAppControl module to ensure that both the user's and solver's operations are executed in the correct order, the winning solver pays its full bid amount, and the bid value is allocated appropriately.

Important Note: Integrating Atlas involves deploying custom modules and coordinating with new components, which introduces complexity. However, Atlas is actively developing templates and standard modules for common DEX architectures to assist teams in this process. While not everything is finalized and development is ongoing, these resources aim to reduce the integration effort for DEX projects.

3. Integration Overview​

This overview illustrates how integration with Atlas Backruns alters the existing transaction flow. It highlights the differences and aims to reduce perceived challenges by showcasing the standard modules and partnerships available.

3.1 Current State​

3.1.1 Components​

  • Frontend: User interface of the application.
  • Backend: Server-side logic and data processing.
  • Wallet: User's wallet for transaction signing.
  • RPC: Configured RPC API for blockchain communication.

3.1.2 Off-Chain Interactions​

In the current state, the user's transaction flow involves direct interaction between the frontend, backend, wallet, and RPC without any auction mechanism.

3.1.3 On-Chain Interactions​

On-chain, the user's wallet directly interacts with the router to swap tokens, trading against liquidity provided by liquidity providers (LPs) in an Automated Market Maker (AMM) pool.

3.2 Future State with Atlas Integration​

3.2.1 New Components​

  • Auctioneer: Orchestrates the bidding process among solvers.
  • Operations Relay (OR): Facilitates secure and efficient off-chain interactions.
  • Bundler: Entity responsible for submitting the bundled transaction; this can be the user or a third party.
  • Atlas: On-chain entrypoint contract for executing bundled operations.

3.2.2 Off-Chain Interactions​

With Atlas, the off-chain interactions introduce the Auctioneer and Operations Relay to conduct auctions and collect solver bids. The integration is simplified through Atlas's standard modules and partnerships.

Explanation:

  • The frontend creates a User Operation instead of a transaction.
  • The backend sends the User Operation to the Auctioneer to start the auction.
  • The Operations Relay propagates the User Operation to solvers.
  • Solvers submit bids in the form of Solver Operations to the Auctioneer.
  • The Auctioneer selects the winning bid and returns the Solver Operation to the backend.
  • The backend creates a DAppOperation to ensure integrity and provides it to the frontend.
  • The frontend builds an Atlas metacall transaction bundling the operations.
  • The wallet signs the transaction and sends it to the Bundler.
  • The Bundler submits the bundled transaction to the RPC for on-chain execution.

3.2.3 On-Chain Interactions​

On-chain execution now involves the Atlas contract, which ensures the atomic execution of user and solver operations, adhering to the app's allocation rules.

Explanation:

  • The user grants a token permit through Atlas.
  • The user calls the metacall; Atlas handles the execution.
  • Swap Execution: This section remains the same as the current state, ensuring familiarity.
  • Atlas invokes the Solver Operation for the backrun.
  • The solver executes the backrun operation and pays the bid amount to Atlas.
  • Atlas allocates the value based on the app's predefined rules (e.g., rebates, token burns).
  • The user receives the buy tokens, and the transaction completes successfully.

4. Integration Guide​

Atlas simplifies integration by providing standard modules and partnerships, reducing complexity for DEX projects.

4.1 Frontend Changes​

  1. User Operation Creation: Modify the transaction logic to create a User Operation using the Atlas SDK.
  2. Backend Communication: Update communication to send User Operations for auction and receive bundled results.
  3. Metacall Transaction: Combine bundled results into an Atlas metacall transaction, which the user's wallet signs. The transaction is then sent to the Bundler for submission.

4.2 Backend Changes​

  1. Auctioneer Integration: Integrate with an Auctioneer to conduct auctions for User Operations.
  2. Operations Relay Integration: Ensure the backend can communicate with the Operations Relay to propagate User Operations and receive Solver Operations.
  3. Auction Management: Implement endpoints to initiate auctions and process solver bids.
  4. Bundle Creation: Create and sign a DAppOperation using the Atlas SDK to ensure bundle integrity.

4.3 Operations Relay Options​

  • Self-Hosted Atlas Operations Relay: Repository
  • bloXroute Intent Network: Documentation
  • FastLane Operations Relay: Coming soon

4.4 DAppControl Module Development​

Develop a DAppControl module for Atlas to define allocation rules, typically with assistance from FastLane's mechanism designers.

5. FAQ​

5. How Does Atlas Benefit Your Revenue Model?​

Integrating Atlas Backruns into your application allows you to internalize MEV (Maximal Extractable Value) that would otherwise be captured by external actors like searchers, block builders, and block proposers. By auctioning off the right to backrun user operations, your app can generate additional revenue from orderflow auctions.

5.1 How Can Your App Make Money with Atlas?​

  • Internalizing MEV: Capture the MEV generated from your users' transactions and redirect this value back into your protocol.

  • Orderflow Auctions: By auctioning the right to backrun user operations, you can earn proceeds from solvers bidding for this privilege.

  • Flexible Allocation of Proceeds: Use the auction proceeds according to your app's specific needs and goals. For example:

    • Revenue Generation: Fund protocol development, operations, or treasury.
    • Token Buyback and Burn: Increase the value of your governance token by reducing its supply.
    • User Incentives: Offer rebates, rewards, or reduced fees to enhance user satisfaction and loyalty.
    • Liquidity Provision: Strengthen your platform's liquidity pools or staking mechanisms.

  • Customizable Modules: Deploy a DAppControl module to define precisely how the captured value is allocated, giving you full control over your revenue strategies.

Important Note: While integrating Atlas involves deploying custom modules and coordinating with new components—which introduces some complexity—Atlas provides templates and support to assist you. By internalizing MEV and leveraging orderflow auctions, your protocol can unlock new revenue streams and enhance its economic model.