Skip to content
Catalyst Documentation

Underwriting & Purchasing Orders

Glossary

  • Reactor: Escrow contract for orders.
  • Order: A ERC-7683 CrossChainOrder
  • Signed Order: An order & its signature.
  • Input: Funds pulled into the Reactor. In exchange for outputs.
  • Output: Fund sent directly from filler to signer. In exchange for inputs.
  • Signer: Signer of an Order. Inputs are always pulled from signer. USDC -> BTC, the signer is a User. BTC -> USDC the signer is a solver.
  • Filler: Entity that sends outputs to the Signer. Will receive inputs
  • Order Key: Specific order structure that is used to move storage into calldata. Contains the vast majority of all information relevant for the order. Importantly, it contains the registered inputs & outputs.
  • Quote: Qualified guess for what the best order that will be accepted.
  • Solver: Entity collecting order flow and completing orders.
  • User: The person interacting with the CrossCats UI. Creator of Order Flow.
  • Recipient: Will receive outputs. Is likely to be either a solver or a user but may be neither.

CrossCats manages assets in 2 ways:

  • Inputs are collected from the signer of an order. For EVM -> BTC the signer is the user while for BTC -> VM, the signer is the Solver. These outputs are held in the CrossCats reactor until the necessary resolution criteria are fulfilled.
  • Outputs are sent directly from the filler to the recipient. They are never held by CrossCats.

An important differentiator is that VM assets can be inputs and outputs while non-VM assets like Bitcoin can only be outputs. As a result, non-VM to non-VM swaps are not supported since they would require VM assets to be input. Since Outputs are never held by Catalyst and are directly delivered, there is no need to underwrite deliveries. The recipient is already getting their assets at the highest speed possible.

CrossCats support underwriting inputs, this allows the filler to receive the inputs before full finality is reached. This is helpful for users going from a non-VM chain like Bitcoin to a VM chain since the Bitcoin has to be in the outputs. As a result, the user becomes the filler and has to wait for finality before they receive their tokens. For solvers, they have access to their capital faster which improves their capital utilisation.

Quick Overview

Diagram

In-code underwriting is called purchaseOrder since this is exactly what happens. Orders have a fillerAddress configured. The fillerAddress is the destination for the inputs once an order has been correctly finalized.

Purchasing the order from the fillerAddress requires sending the inputs (minus a discount) to fillerAddress. In exchange, the underwriter gets to set fillerAddress to their address thus when the order is finalized they receive the inputs and they gain the discount. Any collateral is exchanged 1:1.

function purchaseOrder(OrderKey calldata orderKey, bytes calldata fillerData, uint256 minDiscount) external;

The purchaseOrder function is called.

Before an underwriter underwrites/purchases an order, it is important to validate that the outputs have been delivered. The underwriter does not gain the entirety of the outputs and won’t be able to pay for delivering the outputs based on the discount.

Underwriting an Order

Underwriting a BTC -> EVM swap and EVM -> BTC swap works in the same way. From an underwriter’s perspective there is no difference.

For an underwriter, the flow starts when an order is initiated. On order initiation, the event OrderInitiated is emitted. It contains the order key along with important relevant information for an underwriter. Importantly, the order key contains a description of the outputs of the order. The underwriter needs to monitor for a payment of the outputs after which they can call purchaseOrder to underwrite the order.

Underwriting Bitcoin Outputs

Bitcoin underwriting has 2 levels:

  1. Inclusion probability.
  2. Pre-confirmations

Initially, Catalyst will operate exclusively on level 1.

Inclusion probability

Bitcoin transactions have several parameters that describe how and when a transaction may be included:

  • RBF: If a transaction has replace-by-fee enabled it can easily be double spent. As a result, this should always be disabled.
  • Transaction fee, sat/vB: A higher fee increases the inclusion likelihood. Additionally, If RBF is disabled miners are less incentivized to cheat by including a transaction that has a higher fee since the fee is already high.
  • Parents / Children: If the transaction has several children that pay for parents or unconfirmed parents it changes the inclusion likelihood.
  • Age: Transactions that have been in the memory pool for longer are more likely to not be replaced. Additionally, in the first 3 minutes of a transaction’s life, it miss a mined block.
  • Amount: Replacing transactions has a cost and for smaller transactions, it isn’t worth it.
  • Propagation: By monitoring memory pools all over the world, double spending transactions can be observed.

By evaluating these parameters over time along with pen-testing, a configuration that leads to a high likelihood of inclusion can be found.

Pre-confirmations

The “public memory” pool isn’t the be-all and end-all. Transactions are only included if miners include them and miners have their only memory pool that they rely on. By searching miner memory pools for double spends, it can be guaranteed to a higher degree that invalidating transactions won’t be included. Excluding double spending here achieves weak pre-confirmation.

Strong pre-confirmations are achieved when whole blocks are managed. This requires excluding blocks that include private double spends. This requires on-boarding a significant amount of miners to ensure the blockchain without double spending remains the highest and also increases miner costs because of orphaned blocks.

Underwriting VM Outputs.

Most virtual machine chains have significantly faster block times than Bitcoin. As a result, there is no need to worry about pre-confirmations. Additionally, the biggest time-saving component is the delay between the delivery of outputs and to finality/messaging delay. This may be between 12 minutes, 30 minutes, and 2 hours.