Solving for CrossCats

If you are not interested in the on-chain order structure, skip to Init Orders. For API documentation, refer to the API Swagger documentation.

CrossCats utilizes three main order structures:

1. CrossChainOrder is a generic input order with an ERC-7683 compatible structure. The key component here is orderData, which contains the core functionality and varies significantly across ERC-7683 supporting implementations.
2. ResolvedCrossChainOrder provides a quote description, detailing the value of a cross-chain order at a specific point in time. It is also ERC-7683 compliant*, allowing solvers to efficiently compare the resolution of orders across various protocols.
3. OrderKey is used to monitor a Catalyst order throughout its lifecycle. It includes Catalyst-specific context and provides an in-depth description of an order.

Below is the generic ERC-7683 CrossChainOrder structure. The CrossChainOrder.orderData field is an ABI-encoded order struct.

struct CrossChainOrder {
    address settlementContract;
    address swapper;
    uint256 nonce;
    uint32 originChainId;
    uint32 initiateDeadline;
    uint32 fillDeadline;
    bytes orderData;
}

The orderData field is uniquely encoded by CrossCats. Currently, two orderdata structs are supported:

/// @notice Simpler and slightly cheaper for order types with fixed inputs and outputs.
struct CatalystLimitOrderData {
    uint32 proofDeadline;
    uint32 challengeDeadline;
    address collateralToken;
    uint256 fillerCollateralAmount;
    uint256 challengerCollateralAmount;
    address localOracle;
    Input[] inputs;
    OutputDescription[] outputs;
}
/// @notice Supports Dutch Auctions on both input and output and support for additional custom order verification.
struct CatalystDutchOrderData {
    bytes32 verificationContext;
    address verificationContract;
    uint32 proofDeadline;
    uint32 challengeDeadline;
    address collateralToken;
    uint256 fillerCollateralAmount;
    uint256 challengerCollateralAmount;
    address localOracle;
    uint32 slopeStartingTime;
    /** @dev Input rate of change. */
    int256[] inputSlopes;
    /** @dev Output rate of change. */
    int256[] outputSlopes;
    Input[] inputs;
    OutputDescription[] outputs;
}

// With the input and output structs defined as:
struct Input {
    address token;
    uint256 amount;
}

struct OutputDescription {
    /** @dev Contract on the destination that tells whether an order was filled.
     * Format is bytes32() slice of the encoded bytearray from the messaging protocol.
     * If local: bytes32(uint256(uint160(address(localOracle)))). */
    bytes32 remoteOracle;
    /** @dev The address of the token on the destination chain. */
    bytes32 token;
    /** @dev The amount of the token to be sent. */
    uint256 amount;
    /** @dev The address to receive the output tokens. */
    bytes32 recipient;
    /** @dev The destination chain for this output. */
    uint32 chainId;
    /** @dev Additional data that is relevant for the caller.  */
    bytes remoteCall;
}

Users generate a CrossChainOrder with the appropriate order data and sign it as a Permit2 witness, thereby approving both the order description and its associated inputs with a single signature. The signed struct will be a new structure where orderData is an ABI-encoded order type.

CrossCats has directionality. That means the ways orders are initiated depends on the initiating chain (where the user is swapping out of). In the current iteration, there are 2 important origin types: EVM and Bitcoin. In the future, all virtual machine chains (including EVM) will generally be initiated similarly and all non-VM chains (including Bitcoin) will be initiated similarly but different from VM chains.