Skip to content

Commit

Permalink
fix: correct user vs filler vs recipient
Browse files Browse the repository at this point in the history
  • Loading branch information
reednaa committed Sep 2, 2024
1 parent 2d4793f commit 2ee1552
Showing 1 changed file with 12 additions and 12 deletions.
24 changes: 12 additions & 12 deletions src/content/docs/cross-cats/underwriting.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -6,16 +6,16 @@ sidebar:
---

Cross Cats manages assets in 2 ways:
- Inputs are collected from the recipient 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 Cross Cats reactor until the necessary resolution criteria are fulfilled.
- Inputs are collected from the signer of an order. For EVM -> BTC the signer is the recipient while for BTC -> VM, the signer is the Solver. These outputs are held in the Cross Cats reactor until the necessary resolution criteria are fulfilled.
- Outputs are sent directly from the filler to the recipient. They are never held by Cross Cats.

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.
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.

Cross Cats 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

In-code underwriting is called purchasing an order since this is exactly what happens. An order has a `fillerAddress` configured. Once an order has been correctly finalized, the `fillerAddress` will be sent the inputs.
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.

Expand All @@ -24,11 +24,11 @@ function purchaseOrder(OrderKey calldata orderKey, bytes calldata fillerData, ui
````
The `purchaseOrder` function is called.
Before an underwriter underwrites/purchases an order, it is important to validate that the outputs have been delivered such that they trust them. The underwriter does not gain the entirety of the outputs and won't be able to pay for sending the outputs to the user out of their slice.
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 Bitcoin Outputs
Bitcoin underwriter has 2 levels:
Bitcoin underwriting has 2 levels:
1. Inclusion probability.
2. Pre-confirmations
Expand All @@ -39,19 +39,19 @@ Initially, Catalyst will operate exclusively on level 1.
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 likelihoods.
- Age: Transactions that have been in the memory pool for longer are more likely to not be replaced.
- Size: 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 can be observed.
- 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 transactions won't be included. Excluding double spending here leans toward weak 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 sorted. 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.
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, 30, and 2 hours.
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.

0 comments on commit 2ee1552

Please sign in to comment.