Overview

Catalyst modularizes three components of the cross-chain intent flow:

1. Input settlement scheme – Handles the source chain funds
2. Output settlement scheme – Handles the destination chain funds
3. Validation layer – Connects the input and output settlement

Historically, these components have been intertwined, presenting issues with scaling. Catalyst’s componentized approach allows for greater flexibility and extensibility, allowing for different input and output settlement schemes and validation layers to be matched. This allows Catalyst to support varying degrees of asset technologies: fill first, user as solver, and ordinary swaps.

Input Settlement

The input settlement scheme is responsible for managing user deposits and releasing funds to solvers once intents are fulfilled. Catalyst currently implements two input settlement schemes:

• TheCompact through CompactSettlerWithDeposit.sol
• Rhinestone through CompactSettler.sol

Both are resource locks supporting fill-first flows, though Catalyst also supports ordinary flows.

Catalyst imposes no restrictions on the implementation of input settlements. Input settlements can access proven output through validation layers by either calling isProven or efficientRequireProven. If an order contains multiple outputs and the outputs are filled by different solvers, the filler of the first output in the order specification shall be the canonical solver.

Learn more about Input Settlement →

Output Settlement

The output settlement scheme handles the delivery of assets on destination chains. The output settlement scheme imposes no interface requirements, order structure, or order type except that an interface to validate payloads is provided:

interface IPayloadCreator {
    function arePayloadsValid(
        bytes[] calldata payloads
    ) external view returns (bool);
}

This allows the output settlement scheme to be incredibly flexible; it can support any order type on any virtual machine, as long as the filled order can be expressed as an opaque bytes array.

For simplicity, let’s assume that an output can be expressed as [token, amount, destination]. If this output has been filled, then a valid payload could be bytes(solver | token | amount | destination).

If the input settlement could validate this call, the inputs could be appropriately paid to the solver. However, this information only exists on the output settlement on the output chain.

Learn more about Output Settlement →

Validation Layers

The validation layer ferries valid payloads from the output chain to the input chain. It serves as the bridge that confirms fulfillment has occurred.

Any validation layer can be added to Catalyst as long as it supports validating a payload from a remote chain. Currently implemented validation layers include:

• Wormhole (sponsored by LI.FI)
• Polymer (sponsored by Polymer)
• Bitcoin (self-serve)

It’s expected that before making messages, the validation layer checks if one or more payloads are valid and then ships them to the input chain:

function submit(address proofSource, bytes[] calldata payloads) external payable {
  // Check if the payloads are valid.
  if (!IPayloadCreator(proofSource).arePayloadsValid(payloads)) revert NotAllPayloadsValid();

  // Payloads are good. We can submit them on behalf of proofSource.
  _submit(proofSource, payloads);
}

How validation layers pass the information to the input chain is not scoped. They may use custom message encodings, custom relaying properties, custom interfaces, or other special integration concerns.

On the input chain, it is expected that the validation layer validates the payload(s) through a virtual machine local hash:

interface IValidationLayer {
    /**
     * @notice Check if some data has been attested to.
     * @param remoteChainId Chain the data supposedly originated from.
     * @param remoteOracle Identifier for the remote attestation.
     * @param remoteApplication Identifier for the application that the attestation originated from.
     * @param dataHash Hash of data.
     */
    function isProven(uint256 remoteChainId, bytes32 remoteOracle, bytes32 remoteApplication, bytes32 dataHash) external view returns (bool);

    /**
     * @notice Check if a series of data has been attested to.
     * @dev More efficient implementation of isProven. Does not return a boolean, instead reverts if false.
     * This function returns true if proofSeries is empty.
     * @param proofSeries remoteOracle, remoteChainId, and dataHash encoded in chunks of 32*4=128 bytes.
     */
    function efficientRequireProven(
        bytes calldata proofSeries
    ) external view;
}

Using only the payload hash makes the system more efficient as less data is passed around.

No attempt is made at standardizing the payload. As a result, there may be incompatibilities between the input and output settlement layers.

Learn more about Validation Layers →

Security Assumptions

The Catalyst system includes resource locks which create trust boundaries between key actors:

• Sponsors (users) trust that arbiters won’t fraudulently finalize issued locks.
• Arbiters and solvers trust allocators not to co-sign overlapping locks exceeding user deposits.

No single actor can independently access funds, creating a secure environment for cross-chain transactions.

Integration Points

Catalyst is designed to be highly composable with different components capable of being swapped out as needed:

• Input Settlement: New resource lock standards and standard intent interfaces can be integrated.
• Output Settlement: New order types and fulfillment mechanisms can be added.
• Validation Layer: Different cross-chain messaging protocols and proof layers can be supported.

Integrators can freely pick and choose which components to use for which swaps. This gives intent issuers maximum flexibility to describe their desired endstate.

Unsolved Issues

While the initial version of the Catalyst System is a step function improvement over competing solution at standardizing the intent stack, there are still interopability issues within the standard. For transparency, known specification issues have been listed below.

Standardized Message Format

Currently, the input settlement scheme and the output settlement scheme has to agree on an order-type specific payload. If a new order type or settlement system requires more functionality beyond the implemented message payload, it requires deploying these components over. This break composability between these layers.

Assuming the output description can be represented as:

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

The proposed message format is the following:

Encoded FillDescription
     SOLVER                          0               (32 bytes)
     + ORDERID                       32              (32 bytes)
     + TIMESTAMP                     64              (4 bytes)
     + TOKEN                         68              (32 bytes)
     + AMOUNT                        100             (32 bytes)
     + RECIPIENT                     132             (32 bytes)
     + REMOTE_CALL_LENGTH            164             (2 bytes)
     + REMOTE_CALL                   166             (LENGTH bytes)
     + FULFILLMENT_CONTEXT_LENGTH    166+RC_LENGTH   (2 bytes)
     + FULFILLMENT_CONTEXT           168+RC_LENGTH   (LENGTH bytes)

Note

No assumptions are ever made on how validation layers pass messages between itself. They can pack fill descriptions however they like. Example of a packed payload.

Atomic Swaps and HTLCs as validation layers.

HTCLs works very differently from ordinary intent schemes as they require a round of strong commitments. This pre-bakes certain system assumptions which cannot be abstracted away through the Catalyst Intent System. As a result, these are not considered.

Integration Overheads

As interfaces and validation layers are not standardized, each new order type, validation layer, or settlement scheme presents additional integration overhead. However, since components are eagerly reused the system complexity scales O(n) instead of O(n^3) with n roughly being equal to the number of components.

Optimistic Validation layers

The current validation layers mainly support explicit validation. Optimistic validation can be implemented but requires each output to have an on-chain storage. This increases the gas cost. Ideally the specification should define a way for 1 proof to validate multiple orders, not just outputs.

This would likely involve isProven using merkle trees or similar constructions to pass validated messages