Migration Guide for Searchers

PFL Auction Migration Guide

Updating to the New FastLane Protocol

FastLane Is changing the PFL system here are the key updates every searcher will have to make:

The term "Searcher" and "Solver" are used Interchangeable here as well as the terms SolverContract or SearchContract refer both to FastLane specific MEV smart contracts which enable back-running opportunities. "Solver" aligns more closely with the Atlas Protocol terminology

This guide will help you transition your existing searcher setup to align with the latest updates in the FastLane Protocol. The protocol has introduced significant changes to enhance efficiency, security, and performance. The key updates include:

1. Implementing a new ISolverContract interface.

2. Switching from signed transactions to EIP-712 signed messages for bid submissions.

3. Updating the bundle structure to include multiple solver operations.

4. Focusing solely on Searcher Bundles (Backrun Auctions) by removing Top-of-Block auctions.

Overview of Changes

1. Implement the New ISolverContract Interface

• Action: Update your searcher contract to implement the new ISolverContract interface.

• Purpose: Ensures compatibility with the updated protocol and enables seamless interaction with the FastLane system.

• Impact: Your smart contract must now include the atlasSolverCall function as defined in the interface. The fastLaneCall is no longer relevant and can be removed from any future searcher contract

atlasSolverCallSolver Concepts

2. Transition to EIP-712 Signed Messages

• Action: Modify your bid submission process to use EIP-712 compliant signed messages instead of signed transactions.
• Purpose: Solver operations (EIP-712 signed messages) as building blocks, bundled into a single transaction by a bundler. Prevents execution order manipulation within transactions.

• Impact: Requires updates to your backend/bots systems to generate and manage EIP-712 signed messages.

Solver Call Data

Update Bundle Structure

• Action: Adjust your bundle creation to include solverOperation rather than solver transaction

• Solver operation need to be serialised as string and bigInts will be expected as hex string

Bundle Format

4. Remove Top-of-Block Auction Logic

• Action: Eliminate any logic related to Top-of-Block auctions from your system.

• Purpose: The protocol now exclusively supports Searcher Bundles (Backrun Auctions).

• Impact: Simplifies your codebase and focuses resources on back-running opportunities.

Detailed Migration Steps

Step 1: Update Your Searcher Contract

Implement the ISolverContract Interface

Interface Definition:

interface ISolverContract {
    function atlasSolverCall(
        address solverOpFrom,
        address executionEnvironment,
        address bidToken,
        uint256 bidAmount,
        bytes calldata solverOpData,
        bytes calldata extraReturnData
    )
        external payable;
}

Actions:

• Modify Contract: Update your smart contract to implement the ISolverContract interface.

• Implement atlasSolverCall: Define the atlasSolverCall function according to the interface requirements.

• Use Modifiers: If available, utilize modifiers like safetyFirst and payBids to handle security checks and bid payments.

Reference:

• ISolverContract Interface Documentation
• Example Solver Repository

Step 2: Transition to EIP-712 Signed Messages

Understanding the New Approach

In the updated FastLane Protocol, Solver Operations are submitted as EIP-712 signed messages. These messages serve as building blocks that are bundled into a single transaction by a bundler. This new approach enhances security by preventing execution order manipulation within transactions, which can be exploited in traditional systems.

Purpose

• Prevent Execution Order Manipulation: By using EIP-712 signed messages for solver operations, the protocol ensures that the execution order within a transaction cannot be manipulated by malicious actors. This is crucial for maintaining the integrity of the bundled operations.

• Enhance Security: The structured nature of EIP-712 messages provides a standardized way to sign and verify data, reducing the risk of certain exploits that could compromise the transaction flow.

• Immutable Bundling: Bundlers can combine multiple solver operations into a single transaction, and the EIP-712 signatures ensure that each operation is executed as intended without alteration.

Actions

• Update Backend Systems: Modify your backend to create EIP-712 compliant signed messages for solver operations instead of submitting signed transactions.

• Construct SolverOperation Structs: Populate the SolverOperation struct with the necessary data for each operation.

• Sign the Operations: Use EIP-712 standards to sign the SolverOperation data, ensuring that the signature can be verified on-chain.

• Bundle Operations: Allow bundlers to collect and bundle multiple solver operations into a single transaction for execution.

• Implement Verification Logic: Update your smart contract to verify EIP-712 signatures and ensure that operations are executed in the correct order.

The SolverOperation Struct

Here is the definition of the SolverOperation struct that you'll use for EIP-712 signed messages:

struct SolverOperation {
    address from;            // Solver's address
    address to;              // FastLane contract address
    uint256 value;           // Amount of ETH (or MATIC) required for the solver operation
    uint256 gas;             // Gas limit for the solver operation
    uint256 maxFeePerGas;    // Maximum fee per gas matching the opportunity tx setting
    uint256 deadline;        // Block number deadline for the solver operation
    address solver;          // Nested "to" address (used in `to` field of the solver call)
    address control;         // FastLane DAppControl contract address
    bytes32 userOpHash;      // Hash of the user's operation, for verification (protects solver from unintended charges)
    address bidToken;        // Address of the bid token (use `address(0)` for ETH/MATIC)
    uint256 bidAmount;       // Amount of the bid in `bidToken`
    bytes data;              // Solver operation calldata (used in `data` field of the solver call)
    bytes signature;         // Solver operation signature signed by `from`
}

Implementation Details

• Populate the Struct: Fill in all the fields of the SolverOperation struct with accurate data representing your solver operation.

• Sign the Struct: Use your private key to sign the struct according to the EIP-712 standard. This signature ensures the integrity and authenticity of the operation.

• Include the Signature: Attach the signature to the struct in the signature field.

• Bundling Process: The bundler collects multiple SolverOperation structs (with signatures), along with the opportunity transaction (userOP), orders them based on bidAmount, and creates a single bundle.

• Verification: On-chain, the FastLane contract verifies the EIP-712 signatures before executing the operations, ensuring that only authorised operations are performed.

References:

• Bundle Format
• Bundle Submission