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
{{ message }}
This repository was archived by the owner on Apr 14, 2026. It is now read-only.
Copy file name to clipboardExpand all lines: src/content/docs/1-system-architecture/100-overview.mdx
+8-9Lines changed: 8 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,11 +21,10 @@ Historically, these components have been intertwined, which presented scaling ch
21
21
22
22
### Input Settlement
23
23
24
-
The input settlement scheme manages user deposits and releases funds to solvers once intents are fulfilled. LI.FI intent currently implements one input settlement scheme:
24
+
The input settlement scheme manages user deposits and releases funds to solvers once intents are fulfilled. The Open Intents Framework currently implements two input settlement scheme:
25
25
26
-
-[**TheCompact**](https://github.com/Uniswap/the-compact) via [`InputSettlerCompact.sol`](https://github.com/openintentsframework/oif-contracts/blob/d238f87d01552986b66d392d0f2ea77bd6e25f2f/src/input/compact/InputSettlerCompact.sol)
27
-
28
-
Resource locks support both fill-first flows and ordinary flows.
26
+
-**Escrow** via [`InputSettlerEscrow.sol`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/escrow/InputSettlerEscrow.sol)
27
+
-[**TheCompact**](https://github.com/Uniswap/the-compact) via [`InputSettlerCompact.sol`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/compact/InputSettlerCompact.sol). The Compact supports both fill-first flows and ordinary flows.
29
28
30
29
The intent system imposes no restrictions on the implementation of input settlements. Input settlements can access proven outputs through validation layers by calling [`efficientRequireProven`](https://github.com/openintentsframework/oif-contracts/blob/main/src/interfaces/IOracle.sol#L19-L27). If an order contains multiple outputs and the outputs are filled by different solvers, **the filler of the first output** in the order specification is considered the canonical solver.
31
30
@@ -83,7 +82,7 @@ interface IValidationLayer {
83
82
* @notice Check if a series of data has been attested to.
84
83
* @dev Does not return a boolean; instead, it reverts if false.
85
84
* This function returns true if proofSeries is empty.
86
-
* @param proofSeries remoteOracle, remoteChainId, and dataHash encoded in chunks of 32*4=128 bytes.
85
+
* @param proofSeries oracle, remoteChainId, and dataHash encoded in chunks of 32*4=128 bytes.
87
86
*/
88
87
function efficientRequireProven(
89
88
bytes calldata proofSeries
@@ -128,14 +127,14 @@ Assuming the output description can be represented as:
The Compact uses resource locks and supports first-fill flows. However, LI.FI intents also support escrow-like flows.
13
+
[Work is in progress](https://github.com/openintentsframework/oif-contracts/pull/49) to support multi chain inpurts settlers.
14
+
15
+
The Compact uses resource locks and supports fill-first flows. For traditional flows without resource locks, the escrow settler can be used. Escrow flows are not safe in fill-first flows and have to be opened before fills.
13
16
14
17
#### Default Output
15
18
The default output for settlement schemes is [`MandateOutput`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/types/MandateOutputType.sol#L4-L18):
@@ -27,31 +30,29 @@ struct MandateOutput {
27
30
```
28
31
To verify if the encoded output description has been validated, send the hashed encoded payload to the appropriate local oracle along with relevant resolution details, such as the solver's identity.
29
32
30
-
## InputSettlerCompact
33
+
## Single Chain Inputs
31
34
32
-
The Compact Settler uses the[`StandardOrder`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/types/StandardOrderType.sol#L6-L15):
35
+
Single Chain Input Settlers uses[`StandardOrder`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/types/StandardOrderType.sol#L6-L15):
33
36
```solidity
34
37
struct StandardOrder {
35
38
address user;
36
39
uint256 nonce;
37
40
uint256 originChainId;
38
41
uint32 expires;
39
42
uint32 fillDeadline;
40
-
address localOracle;
43
+
address inputOracle;
41
44
uint256[2][] inputs;
42
45
MandateOutput[] outputs;
43
46
}
44
47
```
45
48
46
-
The CompactSettler supports two ways to resolve locks once outputs are available for verification by the validation layer:
47
-
48
-
There are two ways to finalize an intent:
49
-
1.[`finalise`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/compact/InputSettlerCompact.sol#L177-L184): Can only be called by the solver. The caller can designate where to send assets and whether to make an external call.
50
-
2.[`finaliseWithSignature`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/compact/InputSettlerCompact.sol#L213-L221): Can be called by anyone with an [`AllowOpen`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/types/AllowOpenType.sol#L5-L9l) signature from the solver, containing the destination and call details.
49
+
To finalise orders to get paid their inputs, the relevant finalise functions have to be called. 2 endpoints are available:
50
+
1.`finalise`: To be called by the solver, the caller can designate where to send assets and whether to make an external call. Note that the Escrow & Compact interfaces are different to optimise for gas.
51
+
2.`finaliseWithSignature`: Can be called by anyone with an [`AllowOpen`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/types/AllowOpenType.sol#L5-L9l) signature from the solver, containing the destination and call details.
51
52
52
-
### Intent Registration
53
+
### Compact Intent Registration
53
54
54
-
While intents are transferred as `StandardOrder` structures, they are signed as a `BatchClaim` with the following structure:
55
+
Intents are transferred as `StandardOrder`, within the Compact they are signed as a `BatchClaim` with the following structure:
55
56
56
57
```solidity
57
58
struct BatchCompact {
@@ -62,12 +63,10 @@ struct BatchCompact {
62
63
uint256[2][] idsAndAmounts;
63
64
Mandate mandate;
64
65
}
65
-
```
66
-
With the Mandate defined as:
67
-
```solidity
66
+
// With the Mandate defined as:
68
67
struct Mandate {
69
68
uint32 fillDeadline;
70
-
address localOracle;
69
+
address inputOracle;
71
70
MandateOutput[] outputs;
72
71
}
73
72
```
@@ -76,6 +75,34 @@ Intents are EIP712-signed `BatchClaim`s using The Compact's domain separator.
76
75
77
76
Alternatively, intents can be registered on-chain. There are two ways to do this: either the sponsor (user) registers it, or someone pays for the entire claim and registers it on their behalf.
78
77
78
+
### Escrow Compact Registration
79
+
80
+
Intents are transferred as `StandardOrder` but can be registered in several ways:
81
+
1. Registered by their owner through ERC-7683 `function open(bytes)`. This emits a ERC-7683 `event Open(bytes32 indexed orderId, bytes order)` and also sets its `function orderStatus(bytes)` to 1.
82
+
2. Registered through ERC-3009 with the orderId as the nonce.. For each input a signature has to be provided and then `0x01, abi.encode(bytes[])`.
83
+
3. Registered through Permit2 with the signature provided as `0x00, bytes` from the EIP-712 signed object `PermitBatchWitnessTransferFrom`:
84
+
85
+
```solidity
86
+
struct PermitBatchWitnessTransferFrom {
87
+
TokenPermissions[] permitted;
88
+
address spender;
89
+
uint256 nonce;
90
+
uint256 deadline;
91
+
Permit2Witness witness;
92
+
}
93
+
// With TokenPermissions as
94
+
TokenPermissions(
95
+
address token;
96
+
uint256 amount;
97
+
)
98
+
// With Permit2Witness as
99
+
Permit2Witness(
100
+
uint32 expires;
101
+
address inputOracle;
102
+
MandateOutput[] outputs;
103
+
)
104
+
```
105
+
79
106
#### Integration Examples
80
107
81
108
- For a smart contract example of registering intents on behalf of someone else, see [`RegisterIntentLib.sol`](https://github.com/catalystsystem/catalyst-intent/blob/27ce0972c150ed113f66ae91069eb953f23d920b/src/libs/RegisterIntentLib.sol#L100-L131).
if (orderType == "dutch") context = abi.encodePacked(0x01, slope, stopTime);
35
35
```
36
36
37
37
Specifically for Dutch auctions, if the order contains multiple outputs, only the first one will function as an auction. The rest will resolve to the worst price. This is because solvers are only incentivized to compete on the first output in an order, since the winner of that output is the winner of the entire order once anyone fills the remaining outputs.
Copy file name to clipboardExpand all lines: src/content/docs/2-devs/200-dev-overview.mdx
+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
@@ -24,7 +24,7 @@ By integrating with Catalyst, you gain access to our network of solvers who comp
24
24
25
25
### Simple Integration
26
26
27
-
Catalyst is designed to work with common resource lock standards like [The Compact](/architecture/input#inputsettlercompact). No custom development is required, significantly reducing the engineering effort needed to support cross-chain functionality.
27
+
Catalyst is designed to work with common resource lock standards like [The Compact](/architecture/input#compact-intent-registration). No custom development is required, significantly reducing the engineering effort needed to support cross-chain functionality.
28
28
29
29
### Flexibility to Expand
30
30
@@ -54,6 +54,6 @@ Our full integration guide provides detailed instructions, code examples, and be
54
54
55
55
By default, Catalyst supports calls on delivery. This allows you to schedule calldata to be executed after the delivery of assets, enabling more complex cross-chain operations.
56
56
57
-
The default output type of Catalyst, called `OutputDescription`, supports secondary calls through its `remoteCall` field, allowing for additional execution logic upon delivery.
57
+
The default output type of Catalyst, called `OutputDescription`, supports secondary calls through its `call` field, allowing for additional execution logic upon delivery.
@@ -112,32 +112,32 @@ For `TheCompact`, the inputs need to be provided as an array of `[uint256 tokenI
112
112
113
113
```solidity
114
114
struct OutputDescription {
115
-
bytes32 remoteOracle;
116
-
bytes32 remoteFiller;
115
+
bytes32 oracle;
116
+
bytes32 settler;
117
117
uint256 chainId;
118
118
bytes32 token;
119
119
uint256 amount;
120
120
bytes32 recipient;
121
-
bytes remoteCall;
122
-
bytes fulfillmentContext;
121
+
bytes call;
122
+
bytes context;
123
123
}
124
124
```
125
125
126
-
Note that `OutputDescription.remoteOracle` and `CatalystCompactOrder.localOracle` need to match. Together, they define the validation layer used. Each order should only use one validation layer, which can be an aggregation of AMBs.
126
+
Note that `OutputDescription.oracle` and `CatalystCompactOrder.inputOracle` need to match. Together, they define the validation layer used. Each order should only use one validation layer, which can be an aggregation of AMBs.
127
127
128
-
`remoteFiller` specifies the output type. For limit orders, use the `CoinFiller` and set `fulfillmentContext` as empty (`0x`). For Dutch auctions, use the `CoinFiller` and set `fulfillmentContext`[appropriately](/solver/auctions#dutch-auction).
128
+
`settler` specifies the output type. For limit orders, use the `CoinFiller` and set `context` as empty (`0x`). For Dutch auctions, use the `CoinFiller` and set `context`[appropriately](/solver/auctions#dutch-auction).
129
129
130
130
Specify the token as the `bytes32` identifier. For EVM, the address is left-padded, e.g., `0x000...00abcdef`.
131
131
132
-
#### RemoteCall
132
+
#### Call
133
133
134
-
You can schedule additional calls to happen after token delivery. Note that if you have configured multiple outputs, the order of execution is not guaranteed (it may happen over multiple blocks). If `remoteCall` is provided, the `recipient` is called using the Catalyst interfaces. For arbitrary calls, the [Catalyst Multicaller](https://github.com/catalystsystem/catalyst-intent/blob/main/src/integrations/CatsMulticallHandler.sol) can be used.
134
+
You can schedule additional calls to happen after token delivery. Note that if you have configured multiple outputs, the order of execution is not guaranteed (it may happen over multiple blocks). If `call` is provided, the `recipient` is called using the Catalyst interfaces. For arbitrary calls, the [Catalyst Multicaller](https://github.com/catalystsystem/catalyst-intent/blob/main/src/integrations/CatsMulticallHandler.sol) can be used.
135
135
136
136
[Learn more about Sub-Calls →](/devs/calls)
137
137
138
138
## Off-chain relay via resource locks
139
139
140
-
Off-chain relaying of swaps assumes that you have an existing [resource lock](/glossary#resource-lock) somewhere. This guide we assumes you use [TheCompact](/architecture/input#inputsettlercompact). When using pure resource lock flow, ensure funds are already deposited into the lock. For alternative integrations, refer to the [on-chain flow](#on-chain-relay).
140
+
Off-chain relaying of swaps assumes that you have an existing [resource lock](/glossary#resource-lock) somewhere. This guide we assumes you use [TheCompact](/architecture/input#compact-intent-registration). When using pure resource lock flow, ensure funds are already deposited into the lock. For alternative integrations, refer to the [on-chain flow](#on-chain-relay).
Copy file name to clipboardExpand all lines: src/content/docs/3-solver/300-introduction.mdx
+12-3Lines changed: 12 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,7 +40,7 @@ import { Steps } from '@astrojs/starlight/components';
40
40
4. The proof is delivered to the input chain through the validation layer.
41
41
42
42
:::note[[Oracle system](/architecture/oracle)]
43
-
is denoted as the `localOracle` and `output.oracle` in the order struct.
43
+
is denoted as the `inputOracle` and `output.oracle` in the order struct.
44
44
:::
45
45
46
46
5. The solver submits the order to the input settlement contract, verifying the delivery and unlocking the associated input tokens.
@@ -73,7 +73,7 @@ struct StandardOrder {
73
73
uint256 originChainId;
74
74
uint32 expires;
75
75
uint32 fillDeadline;
76
-
address localOracle;
76
+
address inputOracle;
77
77
uint256[2][] inputs;
78
78
MandateOutput[] outputs;
79
79
}
@@ -123,13 +123,14 @@ For more information about filling intents [View EVM Order Filling Guide →](/s
123
123
124
124
## Validating Fills
125
125
126
-
After filling intents, the proof of fill has to be sent to the input chain. The oracle system used for the order is specified through `localOracle` and `output.oracle`. These should match. However, validating filled outputs is highly oracle specific. For more, [View Oracle System Architecture ->](/architecture/oracle/#implemented-validation-interfaces) ->
126
+
After filling intents, the proof of fill has to be sent to the input chain. The oracle system used for the order is specified through `inputOracle` and `output.oracle`. These should match. However, validating filled outputs is highly oracle specific. For more, [View Oracle System Architecture ->](/architecture/oracle/#implemented-validation-interfaces) ->
127
127
128
128
## Settling Orders
129
129
130
130
Lastly, intents have to be settled before their expiry. This is achieved by calling `finalise[withSignature]` on the designated InputSettler. The caller has to be the designated solver set on fill.
131
131
132
132
```solidity
133
+
// For the Compact Input Settler
133
134
function finalise(
134
135
StandardOrder calldata order,
135
136
bytes calldata signatures,
@@ -138,6 +139,14 @@ function finalise(
138
139
bytes32 destination,
139
140
bytes calldata call
140
141
) external;
142
+
// Or for the Escrow Input Settler
143
+
function finalise(
144
+
StandardOrder calldata order,
145
+
uint32[] calldata timestamps,
146
+
bytes32[] memory solvers,
147
+
bytes32 destination,
148
+
bytes calldata call
149
+
) external;
141
150
```
142
151
143
152
For more information about settling orders [View Order Settlement Guide →](/solver/settlement)
0 commit comments