Solver Concepts

Solver concept guide

This guide provides an overview of developing Solver contracts within the FastLane Protocol ecosystem. Solvers are essential components that execute operations and can submit bids in relation to opportunity transactions. If a solver’s bid wins the backrun auction, it will be executed immediately after the referenced transaction.

Core Concepts

EIP-712 Signed Messages

Searchers submit their solutions to the FastLane Protocol via EIP-712 signed messages. This standard ensures secure and verifiable communication between searchers and the protocol, allowing for off-chain data signing and on-chain verification.

Auction Type: Searcher Bundles (Backrun Auctions)

FastLane supports one type of auction:

• Searcher Bundles (Backrun Auctions): These auctions enable searchers to submit backrunning opportunities by providing transaction bundles that can capture value from other transactions in the block.

Solver Interfac

Searchers need to implement the following interface in their smart contracts:

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

This interface defines the atlasSolverCall function, which is the entry point for the FastLane Protocol to interact with the searcher's contract.

Sequential Diagram of the Solver

The following diagram illustrates the key interactions between the Searcher, DAppContract, FastLane Protocol, and SolverContract components in the FastLane Protocol ecosystem:

Helper Base Contracts

The FastLane Protocol provides helper base contracts that developers can inherit from to streamline the creation of Solvers.

SolverBase

SolverBase is a foundational contract for Solvers designed to handle:

• Safety checks

• Bid payment processing

• Escrow reconciliation

Important Modifiers

The SolverBase contract includes important modifiers that you should utilize in your atlasSolverCall function implementation:

1. safetyFirst Modifier:

modifier safetyFirst(address executionEnvironment, address solverOpFrom) {
    if (msg.sender != _atlas) revert InvalidEntry();
    if (solverOpFrom != _owner) revert InvalidCaller();

    _;

    uint256 shortfall = IAtlas(_atlas).shortfall();

    if (shortfall < msg.value) shortfall = 0;
    else shortfall -= msg.value;

    if (msg.value > address(this).balance) {
        IWETH9(WETH_ADDRESS).withdraw(msg.value - address(this).balance);
    }

    IAtlas(_atlas).reconcile{ value: msg.value }(shortfall);
}

This modifier:

• Ensures that only the Atlas contract can call the function

• Verifies that the solver operation is from the authorized owner

• Handles any shortfall in the Atlas contract after the main function execution

• Unwraps WETH if necessary to cover the msg.value

• Reconciles the shortfall with the Atlas contract

2. payBids Modifier:

modifier payBids(address executionEnvironment, address bidToken, uint256 bidAmount) {
    _;

    if (bidToken == address(0)) {
        // Pay bid in ETH
        if (bidAmount > address(this).balance) {
            IWETH9(WETH_ADDRESS).withdraw(bidAmount - address(this).balance);
        }
        SafeTransferLib.safeTransferETH(executionEnvironment, bidAmount);
    } else {
        // Pay bid in ERC20 (bidToken)
        SafeTransferLib.safeTransfer(bidToken, executionEnvironment, bidAmount);
    }
}

This modifier:

• Handles the payment of the solver's bid to the Execution Environment

• Supports payments in both POL (Native) and ERC20 tokens

• Unwraps WETH if necessary to cover ETH payments

• Uses SafeTransferLib for secure token transfers

When inheriting from SolverBase, it's crucial to use these modifiers correctly in your atlasSolverCall function implementation to ensure proper security checks and bid payments.