---
description: PFL Auction Migration Guide
---

# Migration Guide for Searchers

## Updating to the New FastLane Protocol

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


{% hint style="info" %}
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
{% endhint %}

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

{% content-ref url="../searcher-contract-integration/atlassolvercall" %}
[atlassolvercall](../searcher-contract-integration/atlassolvercall)
{% endcontent-ref %}

{% content-ref url="../searcher-contract-integration/solver-concepts" %}
[solver-concepts](../searcher-contract-integration/solver-concepts)
{% endcontent-ref %}

### 2. Transition to EIP-712 Signed Messages

* **Action**: Modify your bid submission process to use [EIP-712](../searcher-contract-integration/solver-concepts) 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.

{% content-ref url="solver-call-data" %}
[solver-call-data](solver-call-data)
{% endcontent-ref %}

### 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  &#x20;

{% content-ref url="../bundles-backruns/bundle-format" %}
[bundle-format](../bundles-backruns/bundle-format)
{% endcontent-ref %}

### 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**:

```solidity
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](../searcher-contract-integration/safety-considerations)
* [Example Solver Repository](https://github.com/FastLane-Labs/atlas-solver-example)

### 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:

```solidity
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 ](../bundles-backruns/bundle-format)
* [Bundle Submission](../bundles-backruns/bid-submission)

\
