Skip to content
Catalyst Documentation

Solving on Catalyst

As a solver in the cross-chain ecosystem, you’re likely focused on:

  • Accessing reliable order flow
  • Minimizing user escrow unlock times to reduce inventory requirements
  • Having flexibility in your liquidity sources

How Catalyst Helps

Section titled “How Catalyst Helps”
  • Direct access to LI.FI’s significant order flow
  • Freedom to use any liquidity source for solving (e.g., DEXs, CEXs, or your own inventory)
  • Fast user escrow unlock times (typically within 30 minutes)
  • Lower capital requirements due to quick repayment cycles

Solving Catalyst

Section titled “Solving Catalyst”

Catalyst is an entirely permissionless system. Since the system is componentized and components have no inherent trust elements with other components, they can be mixed and matched as desired by users. As a result, it is important that you validate orders in their entirety once received.

The general Catalyst flow is as follows:

  1. The sponsor signs a Catalyst-compatible lock and sends it to the Catalyst order server.

  2. The Catalyst order server preliminarily validates the order and obtains the allocator co-signature for the order. It is then broadcasted to solvers.

  3. A solver submits the order’s output to the output settlement contract, starting the verification layer.

  4. The proof is delivered to the input chain through the validation layer.

  5. The solver submits the order to the input settlement contract, verifying the delivery and unlocking the associated input tokens.

Collecting Orders

Section titled “Collecting Orders”

The Catalyst system supports the CatalystCompactOrder structure across all VMs:

struct CatalystCompactOrder {
    address user;
    uint256 nonce;
    uint256 originChainId;
    uint32 fillDeadline;
    address localOracle;
    uint256[2][] inputs;
    OutputDescription[] outputs;
}

Where uint256[2][] inputs === [uint256 tokenId, uint256 amount][] and OutputDescription:

struct OutputDescription {
    bytes32 remoteOracle;
    bytes32 remoteFiller;
    uint256 chainId;
    bytes32 token;
    uint256 amount;
    bytes32 recipient;
    bytes remoteCall;
    bytes fulfillmentContext;
}

The CatalystCompactOrder will be used to interface all functions on the input chain. Additionally, once hydrated with a signature, it allows one to verify the validity of an order.

Catalyst offers two ways of receiving orders:

  1. Recommended: Connect to the Catalyst order server via WebSocket
  2. Alternative: Monitor on-chain deposits through the deposit interface

The Catalyst order server is the recommended integration surface for most solvers. However, if you are interested in the lowest latency, decentralized, and permissionless order discovery, you can read some orders on-chain. Not all orders will be discoverable on-chain.

View Order Collection Guide →

Filling EVM Orders

Section titled “Filling EVM Orders”

To fill Catalyst orders, you must support the Output Settlement interfaces. Each Output Settlement interface is different, but most support the generic OutputDescription types.

The delivery of assets depends on the Output Settlement Interface associated with an order. The Output Settlement Interface can be read from the order: orderDto.order.remoteFiller.

View EVM Order Filling Guide →

Settling Orders

Section titled “Settling Orders”

Settling Catalyst orders may require up to two transactions:

  1. Submission of self-serve message validation
  2. Finalizing the order on the resource lock

If the validation layer is not self-serve or is being sponsored, only one transaction is needed.

View Order Settlement Guide →