You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: "Cross Cats is ERC7863 compatible with a few non-breaking changes."
4
+
sidebar:
5
+
order: 2
6
+
---
7
+
8
+
Catalyst is [ERC-7683](https://eips.ethereum.org/EIPS/eip-7683)* compatible. *The implementation differs in 2 ways:
9
+
10
+
1. A Catalyst [OrderKey](https://github.com/catalystdao/cross-cats/blob/7e07281eef10ffadc10f9f75eb42d1c2419224ca/src/interfaces/Structs.sol#L41-L65) is returned on `initiate(...)`. For implementations that wants to verify that orders were correctly collected, this adds options for further data validation. This change is compatible with ERC-7683 since it does not change any function signatures and ERC-7683 specifies that the function has no return.
11
+
2. ERC-7683 defines the 2 elements of `Output`, `token` and `recipient` to be type `address`. The type of both elements have been changed to `bytes32`. Solidity ABI encoding encodes structs elements such that they fill 32 bytes. As a result, all returned objects of `ResolvedCrossChainOrder` remains compatible with implementations that assumes these are `address` (except these values are truncated).
Copy file name to clipboardExpand all lines: src/content/docs/cross-cats/cross-cats.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,13 +2,13 @@
2
2
title: "Cross Cats: Solving Liquidity x Bitcoin"
3
3
description: "Catalyst v2 will support Bitcoin swaps. This is facilitated through intent based swaps that are verified through an on-chain Bitcoin SPV client. This provides: Fast settlement, Competitive rates, and near full security."
4
4
sidebar:
5
-
order: 7
5
+
order: 1
6
6
---
7
7
8
8
Cross-Cats is an intent-based cross-chain swap protocol built with flexibility in mind. The core idea is to allow anyone to create a request for anything provable. At launch, EVM settlements and Bitcoin transactions will be part of the provable set. Bitcoin transactions are proven using a Bitcoin SPV (light client) and allows VM chain payments to be conditional on Bitcoin transactions.
Copy file name to clipboardExpand all lines: src/content/docs/cross-cats/solver.mdx
+49-36Lines changed: 49 additions & 36 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,27 +1,22 @@
1
1
---
2
2
title: "Becoming a Cross Cats solver"
3
-
description: "Cross Cats allows solvers to collect order flow to and from various VM chains and to and from Bitcoin. Compared to competing solution, capital hungry solvers can sacrafise some margin on quick payouts by using the underwriting network to their advantage."
3
+
description: "Cross Cats allows solvers to collect order flow to and from various VM chains and to and from Bitcoin. Compared to competing solution, capital hungry solvers can improve their capital turnaround by using the underwriting network to their advantage."
If you aren't interested in the order structure in Solidity, skip to [From VM](#from-evm). For API documentation, refer to the [API Swagger documentation](https://catalyst-order-server-0140d799e2f7.herokuapp.com/api
12
12
).
13
13
14
-
Catalyst is [ERC-7683](https://www.erc7683.org)* compatible. *The implementation differs in 2 ways:
15
-
16
-
1. A Catalyst [OrderKey](https://github.com/catalystdao/cross-cats/blob/7e07281eef10ffadc10f9f75eb42d1c2419224ca/src/interfaces/Structs.sol#L41-L65) is returned on `initiate(...)`. For implementations that wants to verify that orders were correctly collected, this adds options for further data validation. This change is compatible with ERC-7683 since it does not change any function signatures and ERC-7683 specifies that the function has no return.
17
-
2. ERC-7683 defines the 2 elements of `Output`, `token` and `recipient` to be type `address`. The type of both elements have been changed to `bytes32`. Solidity ABI encoding encodes structs elements such that they fill 32 bytes. As a result, all returned objects of `ResolvedCrossChainOrder` remains compatible with implementations that assumes these are `address` (except these values are truncated).
18
-
19
14
Cross Cats uses 3 order structures:
20
15
1.[CrossChainOrder](https://github.com/catalystdao/cross-cats/blob/7e07281eef10ffadc10f9f75eb42d1c2419224ca/src/interfaces/ISettlementContract.sol#L6-L27) is a generic **input** order with an ERC-7683 compatible structure. Importantly, orderData contains the secret sauce and surely differs between ERC-7683 supporting implementations.
21
-
2.[ResolvedCrossChainOrder](https://github.com/catalystdao/cross-cats/blob/7e07281eef10ffadc10f9f75eb42d1c2419224ca/src/interfaces/ISettlementContract.sol#L29-L52) is a **quote** description that describes the value of a cross-chain order at a specific moment in time. It is ERC-7683 compliant* and allows solvers to easily compare resolution of order across protocols.
22
-
3. Catalyst [OrderKey](https://github.com/catalystdao/cross-cats/blob/7e07281eef10ffadc10f9f75eb42d1c2419224ca/src/interfaces/Structs.sol#L41-L65) are used to keep track of a Catalyst order through its **lifetime**. It contains Catalyst specific context and describes orders in depth. The hash of this struct is used to index the state progress of orders.
16
+
2.[ResolvedCrossChainOrder](https://github.com/catalystdao/cross-cats/blob/7e07281eef10ffadc10f9f75eb42d1c2419224ca/src/interfaces/ISettlementContract.sol#L29-L52) is a **quote** description that describes the value of a cross-chain order at a specific moment in time. It is ERC-7683 compliant[*](/cross-cats/erc7683) and allows solvers to easily compare resolution of order across protocols.
17
+
3. Catalyst [OrderKey](https://github.com/catalystdao/cross-cats/blob/7e07281eef10ffadc10f9f75eb42d1c2419224ca/src/interfaces/Structs.sol#L41-L65) are used to keep track of a Catalyst order through its **lifetime**. It contains Catalyst specific context and describes orders in depth.
23
18
24
-
The generic CrossChainOrder can be seen below. `CrossChainOrder.orderData` is an ABI encoded order struct.
19
+
The generic ERC7683 CrossChainOrder can be seen below. `CrossChainOrder.orderData` is an ABI encoded order struct.
25
20
```solidity
26
21
struct CrossChainOrder {
27
22
address settlementContract;
@@ -34,21 +29,20 @@ struct CrossChainOrder {
34
29
}
35
30
```
36
31
37
-
Currently, Cross-Cats supports 2 order structs:
32
+
Importantly, the field `orderData` is encoded uniquely by Cross-Cats. Currently, 2 order structs are supported:
38
33
```solidity
39
-
/// @notice Supports many inputs (same chain) to many outputs (different chains)
34
+
/// @notice Simpler and slightly cheaper for order types with fixed inputs and outputs.
40
35
struct LimitOrderData {
41
36
uint32 proofDeadline;
42
37
uint32 challengeDeadline;
43
38
address collateralToken;
44
39
uint256 fillerCollateralAmount;
45
40
uint256 challengerCollateralAmount;
46
41
address localOracle;
47
-
bytes32 remoteOracle;
48
42
Input[] inputs;
49
-
Output[] outputs;
43
+
OutputDescription[] outputs;
50
44
}
51
-
/// @notice Supports Dutch Auctions on both input and output (1 to 1).
45
+
/// @notice Supports Dutch Auctions on both input and output and support for additional custom order verification.
52
46
struct DutchOrderData {
53
47
bytes32 verificationContext;
54
48
address verificationContract;
@@ -58,29 +52,39 @@ struct DutchOrderData {
58
52
uint256 fillerCollateralAmount;
59
53
uint256 challengerCollateralAmount;
60
54
address localOracle;
61
-
bytes32 remoteOracle;
62
55
uint32 slopeStartingTime;
63
-
int256 inputSlope;
64
-
int256 outputSlope;
65
-
Input input;
66
-
Output output;
56
+
/// @dev Input rate of change.
57
+
int256[] inputSlopes;
58
+
/// @dev Output rate of change.
59
+
int256[] outputSlopes;
60
+
Input[] inputs;
61
+
OutputDescription[] outputs;
67
62
}
68
63
69
-
// With the input and output struct defined as:
64
+
// With the input and output structs defined as:
70
65
struct Input {
71
66
address token;
72
67
uint256 amount;
73
68
}
74
-
struct Output {
69
+
70
+
struct OutputDescription {
71
+
/// @dev Contract on the destination that tells whether an order was filled.
72
+
/// Format is bytes32() slice of the encoded bytearray from the messaging protocol (or bytes32(0) if local)
73
+
bytes32 remoteOracle;
74
+
/// @dev The address of the ERC20 token on the destination chain
75
+
/// @dev address(0) used as a sentinel for the native token
75
76
bytes32 token;
77
+
/// @dev The amount of the token to be sent
76
78
uint256 amount;
79
+
/// @dev The address to receive the output tokens
77
80
bytes32 recipient;
81
+
/// @dev The destination chain for this output
78
82
uint32 chainId;
83
+
bytes remoteCall;
79
84
}
80
85
```
81
86
82
-
Users will generate a `CrossChainOrder` with the appropriate order data and sign them with Permit2, generating an approval & order description with a single signature. The signed struct with be a new struct where `
83
-
orderData` will be of the order type struct.
87
+
Users will generate a `CrossChainOrder` with the appropriate order data and sign it with Permit2, thus generating an approval & order description with a single signature. The signed struct with be a new struct where `orderData` will be an abi.encoded order type.
84
88
85
89
## From EVM
86
90
@@ -99,17 +103,18 @@ The order server stores orders in their dictionary format. This allows integrato
99
103
// Lets define the 2 Order data types.
100
104
typeDutchAuctionData= {
101
105
type:"DutchAuction", // should not be submitted on-chain but can be used to differentiate order types.
106
+
verificationContext:string;
107
+
verificationContract:string;
102
108
proofDeadline:number,
103
109
challengeDeadline:number,
104
110
collateralToken:string,
105
111
fillerCollateralAmount:string,
106
112
challengerCollateralAmount:string,
107
113
localOracle:string,
108
-
remoteOracle:string,
109
114
slopeStartingTime:number,
110
-
inputSlope:string,
111
-
outputSlope:string,
112
-
inputs: {}[],// Even though `inputs` is provided as an array, to submit on-chain it needs to be provided as a single input named `input`
orderKeyHash:string|undefined, // initially but will become always defined.
148
+
orderKeyHash:string
145
149
quote: {
146
150
fromAssets:string[],
147
151
toAssets:string[],
@@ -334,7 +338,7 @@ Asset delivery depends on whether the destination is a VM chain or Bitcoin. For
334
338
335
339
### EVM deliveries
336
340
337
-
Call the destination chain oracle `GetOrderData.order.orderData.remoteOracle`. You can get remote chain from each output`GetOrderData.order.orderData.outputs[].chainId`.
341
+
Call the destination chain oracle `GetOrderData.order.orderData.outputs[].remoteOracle` on the remote chain `GetOrderData.order.orderData.outputs[].chainId`.
338
342
339
343
<TabssyncKey="lang">
340
344
<TabItemlabel="Typescript">
@@ -350,14 +354,18 @@ const oracleAbi = "...";
350
354
// For simplicity, this function assumes that all outputs goes to
To identify whether an order contains a Bitcoin transaction, check the output token: `GetOrderData.order.orderData.outputs[].token`. If the output is Bitcoin, the following must hold:
422
435
- The first 30bytes should be equal to `0x000000000000000000000000BC0000000000000000000000000000000000`. Notice the 13'th byte is `0xBC`.
423
-
- The 31'th byte is reserved and not checked.
436
+
- The 31'th byte is the number of confirmations before the order can be verified on-chain. 0 implies 1.
424
437
- The 32'th byte contains an address version identifier. Decode as uint8.
425
438
426
439
If the transaction is to Bitcoin, the address (`GetOrderData.order.orderData.outputs[].recipient`) will contain the relevant destination hashor witness which isnot the address!
description: "Security, speed, and cost. Underwriting allows customizing these parameters exactly providing a 2 fold improvement: 1. Faster solver payouts allowing for greater capital velocity. 2. Faster user payouts improving the user experience."
4
+
sidebar:
5
+
order: 21
6
+
---
7
+
8
+
Catalyst will support underwriting. In-code it is referred to as purchasing an order since this is exactly what happens.
9
+
10
+
When a filler is initiating
11
+
12
+
```solidity
13
+
function purchaseOrder(OrderKey calldata orderKey, bytes calldata fillerData, uint256 minDiscount) external;
0 commit comments