catalystsystem · reednaa · Jun 24, 2025 · Jun 24, 2025 · Jun 24, 2025 · Jun 24, 2025
diff --git a/README.md b/README.md
@@ -1,4 +1,4 @@
-## Catalyst Documentation
+## Intent Documentation
 
 [![Built with Starlight](https://astro.badg.es/v2/built-with-starlight/tiny.svg)](https://starlight.astro.build)
 

diff --git a/_typos.toml b/_typos.toml
@@ -1,3 +1,2 @@
 [default.extend-words]
-# Don't correct the surname "Teh"
 OIF = "OIF"
diff --git a/astro.config.mjs b/astro.config.mjs
@@ -24,7 +24,8 @@ export default defineConfig({
   integrations: [
     starlight({
       plugins: [starlightLinksValidator()],
-      title: "Catalyst Documentation",
+      title: "LI.FI Intent Documentation",
+      tableOfContents: false,
       editLink: {
         baseUrl: `https://github.com/catalystsystem/catalyst-documentation/edit/${process.env["CF_PAGES_BRANCH"]}`,
       },
@@ -40,7 +41,7 @@ export default defineConfig({
       favicon: "/favicon.ico",
       sidebar: [
         {
-          label: "Catalyst Intent System",
+          label: "Introduction",
           link: "/",
         },
         {
@@ -49,12 +50,12 @@ export default defineConfig({
             directory: "1-system-architecture",
           },
         },
-        {
-          label: "For Developers",
-          autogenerate: {
-            directory: "2-devs",
-          },
-        },
+        // {
+        //   label: "For Developers",
+        //   autogenerate: {
+        //     directory: "2-devs",
+        //   },
+        // },
         {
           label: "For Solvers",
           autogenerate: {

diff --git a/package.json b/package.json
@@ -11,16 +11,16 @@
   },
   "dependencies": {
     "@astrojs/check": "^0.9.4",
-    "@astrojs/starlight": "^0.34.0",
-    "@astrojs/svelte": "^7.0.10",
-    "astro": "^5.7.3",
-    "astro-d2": "^0.7.0",
+    "@astrojs/starlight": "^0.34.4",
+    "@astrojs/svelte": "^7.1.0",
+    "astro": "^5.9.4",
+    "astro-d2": "^0.8.0",
     "astro-iconify": "^1.2.0",
     "rehype-mathjax": "^7.1.0",
     "remark-math": "^6.0.0",
-    "sharp": "^0.34.1",
-    "starlight-links-validator": "^0.16.0",
-    "svelte": "^5.27.3",
+    "sharp": "^0.34.2",
+    "starlight-links-validator": "^0.17.0",
+    "svelte": "^5.34.5",
     "typescript": "^5.8.3"
   },
   "packageManager": "pnpm@9.11.0+sha256.1c0e33f70e5df9eede84a357bdfa0b1f9dba6e58194628d48a1055756f553754"

diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
diff --git a/public/d2/docs/index-0.svg b/public/d2/docs/index-0.svg
diff --git a/public/d2/docs/protocol/liquidity-pools-0.svg b/public/d2/docs/protocol/liquidity-pools-0.svg
diff --git a/public/d2/docs/protocol/tx-lifecycle-0.svg b/public/d2/docs/protocol/tx-lifecycle-0.svg
diff --git a/src/assets/intent-flow.svg b/src/assets/intent-flow.svg
diff --git a/src/assets/landing.css b/src/assets/landing.css
@@ -1,6 +1,9 @@
 :root {
   --purple-hsl: 234, 85%, 65%;
   --overlay-blurple: hsla(var(--purple-hsl), 0.2);
+  --gray-rgb: 237, 238, 243;
+  --gray-color: rgb(var(--gray-rgb));
+  --sl-color-backdrop-overlay: hsla(0, 0%, 98%, 0.66);
 }
 
 :root[data-theme="light"] {
@@ -40,3 +43,31 @@ mobile-starlight-toc nav {
 [data-has-hero] .hero > img {
   filter: drop-shadow(0 0 3rem var(--overlay-blurple));
 }
+
+.pagination-links {
+  border-top: 1px solid;
+  border-color: var(--gray-color);
+}
+
+div.pagination-links > a {
+  border: 0px;
+  box-shadow: none;
+}
+
+.sl-steps > li:last-child::after {
+  content: none;
+}
+
+
+site-search > dialog  {
+  background-color: hsla(0, 0%, 98%, 0.1);
+  -webkit-backdrop-filter: blur(16px);
+  backdrop-filter: blur(16px);
+  box-shadow: none;
+  border: 1px solid transparent;
+}
+
+site-search > dialog::backdrop {
+  background-color: transparent;
+  backdrop-filter: blur(0.1rem);
+}
diff --git a/src/content/docs/1-system-architecture/100-overview.mdx b/src/content/docs/1-system-architecture/100-overview.mdx
diff --git a/src/content/docs/1-system-architecture/101-input-settlement.md b/src/content/docs/1-system-architecture/101-input-settlement.md
@@ -1,132 +1,83 @@
 ---
 title: "Input Settlement"
 slug: "architecture/input"
-description: "Built with resource locks in mind, Catalyst supports a variety of input settlement schemes. TheCompact and Rhinestone both allow for first-fill flows and sponsored transactions, assuming the user has existing deposits."
+description: "Built with resource locks in mind, LI.FI intents support a variety of input settlement schemes. The Compact and Rhinestone both allow for first-fill flows and sponsored transactions, assuming the user has existing deposits."
 sidebar:
   order: 1
 ---
 
-Catalyst currently implements two input settlement schemes:
-1. [**TheCompact**](https://github.com/Uniswap/the-compact) through [`CompactSettlerWithDeposit.sol`](https://github.com/catalystsystem/catalyst-intent/blob/main/src/settlers/compact/CompactSettlerWithDeposit.sol)
-2. [**Rhinestone**](https://www.rhinestone.wtf) through [`CompactSettler.sol`](https://github.com/catalystsystem/catalyst-intent/blob/main/src/settlers/compact/CompactSettler.sol)
+Currently, only one Input Settler is supported:
+- [**InputSettlerCompact**](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/compact/InputSettlerCompact.sol)
 
-Both TheCompact and Rhinestone are resource locks and thus support first-fill flows. However, Catalyst also supports ordinary flows.
-
-Catalyst provides a base implementation for settlement schemes via [`BaseSettler.sol`](https://github.com/catalystsystem/catalyst-intent/blob/main/src/settlers/BaseSettler.sol). Alternatively, if possible, [`CompactSettler.sol`](https://github.com/catalystsystem/catalyst-intent/blob/main/src/settlers/compact/CompactSettler.sol) can be forked with less effort.
+The Compact uses resource locks and supports first-fill flows. However, LI.FI intents also support escrow-like flows.
 
 #### Default Output
-The default output for settlement schemes is the [`OutputDescription`](https://github.com/catalystsystem/catalyst-intent/blob/fcdbdc6a77734ddc56be0e5de737f324cbba670d/src/libs/OutputEncodingLib.sol#L4-L38):
+The default output for settlement schemes is [`MandateOutput`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/types/MandateOutputType.sol#L4-L18):
 ```solidity
-struct OutputDescription {
-    bytes32 remoteOracle;
-    bytes32 remoteFiller;
+struct MandateOutput {
+    bytes32 oracle;
+    bytes32 settler;
     uint256 chainId;
     bytes32 token;
     uint256 amount;
     bytes32 recipient;
-    bytes remoteCall;
-    bytes fulfillmentContext;
+    bytes call;
+    bytes context;
 }
 ```
-To check if the encoded output description has been validated, the hashed encoded payload should be sent to the appropriate local oracle using the Validation Layer Interface along with relevant resolution details, such as who the solver was.
+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.
 
-## CompactSettler
-Both Rhinestone and TheCompact work through [`CompactSettler.sol`](https://github.com/catalystsystem/catalyst-intent/blob/main/src/settlers/compact/CompactSettler.sol). Being able to solve for one allows you to solve the other, except that signature and lock validation differ slightly.
+## InputSettlerCompact
 
-The Compact Settler uses the [`CatalystCompactOrder`](https://github.com/catalystsystem/catalyst-intent/blob/fcdbdc6a77734ddc56be0e5de737f324cbba670d/src/settlers/compact/TheCompactOrderType.sol#L6-L14):
+The Compact Settler uses the [`StandardOrder`](https://github.com/openintentsframework/oif-contracts/blob/main/src/input/types/StandardOrderType.sol#L6-L15):
 ```solidity
-struct CatalystCompactOrder {
+struct StandardOrder {
     address user;
     uint256 nonce;
     uint256 originChainId;
+    uint32 expires;
     uint32 fillDeadline;
     address localOracle;
     uint256[2][] inputs;
-    OutputDescription[] outputs;
+    MandateOutput[] outputs;
 }
 ```
-Notice that the `fillDeadline` is also used as the expiry for the timelock. As a result, when filling outputs of `CatalystCompactOrder`, ensure there is sufficient time for validation as well.
-
-The CompactSettler supports [five ways](https://github.com/catalystsystem/catalyst-intent/blob/fcdbdc6a77734ddc56be0e5de737f324cbba670d/src/settlers/compact/CompactSettler.sol#L149-L265) to resolve locks once the outputs have been made available for verification by the validation layer:
 
-```solidity
-function finaliseSelf(CatalystCompactOrder calldata order, bytes calldata signatures, uint32[] calldata timestamps, bytes32 solver) external;
-
-function finaliseTo(CatalystCompactOrder calldata order, bytes calldata signatures, uint32[] calldata timestamps, bytes32 solver, address destination, bytes calldata call) external;
+The CompactSettler supports two ways to resolve locks once outputs are available for verification by the validation layer:
 
-function finaliseFor(
-    CatalystCompactOrder calldata order,
-    bytes calldata signatures,
-    uint32[] calldata timestamps,
-    bytes32 solver,
-    address destination,
-    bytes calldata call,
-    bytes calldata orderOwnerSignature
-) external;
+There are two ways to finalize an intent:
+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.
+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.
 
-// -- Fallback Finalise Functions -- //
+### Intent Registration
 
-function finaliseTo(CatalystCompactOrder calldata order, bytes calldata signatures, uint32[] calldata timestamps, bytes32[] calldata solvers, address destination, bytes calldata call) external;
+While intents are transferred as `StandardOrder` structures, they are signed as a `BatchClaim` with the following structure:
 
-function finaliseFor(
-    CatalystCompactOrder calldata order,
-    bytes calldata signatures,
-    uint32[] calldata timestamps,
-    bytes32[] calldata solvers,
-    address destination,
-    bytes calldata call,
-    bytes calldata orderOwnerSignature
-) external;
-```
-
-Notice that the fallback functions exist to fix orders that have been solved by multiple solvers. This is required because we need to hydrate the `OutputDescription` with the solver to check if the output has been filled on the Validation Layer.
-
-The three ways to finalize an intent:
-1. [`finaliseSelf`](https://github.com/catalystsystem/catalyst-intent/blob/fcdbdc6a77734ddc56be0e5de737f324cbba670d/src/settlers/compact/CompactSettler.sol#L149): Self-serve, called by the solver with the tokens paid to the solver. 
-2. [`finaliseTo`](https://github.com/catalystsystem/catalyst-intent/blob/fcdbdc6a77734ddc56be0e5de737f324cbba670d/src/settlers/compact/CompactSettler.sol#L162): Self-serve, custom delivery. Called by the solver with the tokens paid to a specific address. 
-3. [`finaliseFor`](https://github.com/catalystsystem/catalyst-intent/blob/fcdbdc6a77734ddc56be0e5de737f324cbba670d/src/settlers/compact/CompactSettler.sol#L188-L196): External finalization with a signed message by the solver designating where assets are to be delivered. 
-
-To use external finalization, the struct [`AllowOpen`](https://github.com/catalystsystem/catalyst-intent/blob/main/src/settlers/types/AllowOpenType.sol) must be [EIP712](https://eips.ethereum.org/EIPS/eip-712) signed:
 ```solidity
-struct AllowOpen {
-    bytes32 orderId;
-    address originSettler;
-    address destination;
-    bytes call;
+struct BatchCompact {
+    address arbiter;
+    address sponsor;
+    uint256 nonce;
+    uint256 expires;
+    uint256[2][] idsAndAmounts;
+    Mandate mandate;
 }
 ```
-
-### Registering Intents
-
-For how to register intents with Rhinestone, please refer to their documentation.
-
-For TheCompact, `CompactSettler.sol` supports `BatchClaim` using claim type. The witness is the difference between the `BatchClaim` and `CatalystCompactOrder`:
-
+With the Mandate defined as:
 ```solidity
-struct CatalystWitness {
+struct Mandate {
     uint32 fillDeadline;
     address localOracle;
-    OutputDescription[] outputs;
+    MandateOutput[] outputs;
 }
 ```
 
-Sign the `BatchClaim` with the CatalystWitness using EIP712 with TheCompact domain separator.
-
-For further integration assistance, refer either to [`TestCatalyst.t.sol::test_entire_flow`](https://github.com/catalystsystem/catalyst-intent/blob/main/test/TestCatalyst.t.sol#L214) or reach out to the team.
-
-#### With Deposit
+Intents are EIP712-signed `BatchClaim`s using The Compact's domain separator.
 
-When integrating CompactSettler, if the settler uses the [`withDeposit`](https://github.com/catalystsystem/catalyst-intent/blob/fcdbdc6a77734ddc56be0e5de737f324cbba670d/src/settlers/compact/CompactSettlerWithDeposit.sol#L44-L51) extension, you may use the associated deposit function. This allows you to deposit and register an intent at the same time, reducing the number of user interactions by one.
+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.
 
-```solidity
-function depositFor(CatalystCompactOrder calldata order, ResetPeriod resetPeriod) external;
-```
-
-When this function is called, the `Deposit` event will be emitted for permissionless discovery.
-```solidity
-event Deposited(bytes32 orderId, CatalystCompactOrder order);
-```
+#### Integration Examples
 
-:::note
-Nonces cannot be reused and should be unique for an allocator. Please use your allocator's api to get an appropriate nonce.
-:::
+- 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).
+- For a UI example of signing the Batch Compact, refer to the [lintent.org demo](https://github.com/catalystsystem/lintent/blob/a4aa78cd058cade732b73d83aa2843dd4e9ea24d/src/lib/utils/lifiintent/tx.ts#L144).
+- For a UI example of depositing and registering the intent, see the [lintent.org demo](https://github.com/catalystsystem/lintent/blob/a4aa78cd058cade732b73d83aa2843dd4e9ea24d/src/lib/utils/lifiintent/tx.ts#L199).
diff --git a/src/content/docs/1-system-architecture/102-output-settlement.mdx b/src/content/docs/1-system-architecture/102-output-settlement.mdx
@@ -1,27 +1,27 @@
 ---
 title: "Output Settlement"
 slug: "architecture/output"
-description: "Catalyst currently supports two order types: simple limit orders and Dutch auctions. However, the Catalyst System was designed with flexibility in mind, and more can easily be added."
+description: "LI.FI intent enables on-chain competition and flexible order types, letting solvers optimize settlement and capture cross-chain opportunities."
 sidebar:
   order: 2
 ---
 
-Catalyst's initial filler – [`CoinFiller.sol`](https://github.com/catalystsystem/catalyst-intent/blob/main/src/fillers/coin/CoinFiller.sol) – supports two order types: simple limit orders and Dutch auctions. For more about the specific order details, see the section on [Auctions](/solver/auctions)
+Currently, only one output settler exists: – [`OutputSettlerCoin.sol`](https://github.com/openintentsframework/oif-contracts/blob/main/src/output/coin/OutputSettlerCoin.sol) – which supports four order types: simple limit orders, Dutch auctions, exclusive limit orders, and exclusive Dutch auctions. For more details about specific order types, see the section on [Auctions](/solver/auctions).
 
 ## CoinFiller
 
-To configure whether to use a limit order or a Dutch auction, set the associated `fulfillmentContext` on the `OutputDescription`.
+To configure which auction type is used, set the associated `output.context`.
 
 import { Code } from '@astrojs/starlight/components';
 
-export const outputDescription = `
-struct OutputDescription {
+export const mandateOutput = `
+struct MandateOutput {
     ...
-    bytes remoteCall;
-    bytes fulfillmentContext;
+    bytes call;
+    bytes context;
 }`;
 
-<Code code={outputDescription} lang="solidity" mark={['bytes fulfillmentContext;']} />
+<Code code={mandateOutput} lang="solidity" mark={['bytes context;']} />
 
 Use the following pseudocode:
 
@@ -34,4 +34,4 @@ if (orderType == "limit") fulfillmentContext = "0x" || fulfillmentContext = "0x0
 if (orderType == "dutch") fulfillmentContext = abi.encodePacked(0x01, slope, stopTime);
 ```
 
-Specifically for Dutch auctions, if the order contains multiple outputs, only the first one will work as an auction, and 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 order is the winner of the entire order once anyone fills the rest of the outputs.
+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.