fix: CrossCats references

astro.config.mjs

@@ -12,7 +12,7 @@ export default defineConfig({
   redirects: {
     "/resources/whitepaper": "/resources/audit-whitepaper#Papers",
     "/cross-cats/": "/cross-cats/cross-cats/",
-    "/cross-cats/solver/": "/cross-cats/becoming-a-solver/introduction/"
+    "/cross-cats/solver/": "/cross-cats/becoming-a-solver/introduction/",
   },
   site: `${process.env["CF_PAGES_URL"] ?? "https://docs.catalyst.exchange"}`,
   markdown: {
@@ -55,8 +55,8 @@ export default defineConfig({
           },
         },
         {
-          label: "Cross-Cats: Cross-Chain Intents",
-          badge: "Closed Alpha",
+          label: "CrossCats: Cross-Chain Intents",
+          badge: "Closed Beta",
           autogenerate: {
             directory: "cross-cats",
           },

src/content/docs/cross-cats/Becoming a Solver/btc-fulfilling.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Fulfilling BTC Orders"
-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."
+description: "CrossCats 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."
 sidebar:
   order: 7
 ---

src/content/docs/cross-cats/Becoming a Solver/collecting-orders.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Collecting Orders"
-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."
+description: "CrossCats 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."
 sidebar:
   order: 4
 ---

src/content/docs/cross-cats/Becoming a Solver/evm-fulfilling.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Fulfilling EVM Orders"
-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."
+description: "CrossCats 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."
 sidebar:
   order: 6
 ---

src/content/docs/cross-cats/Becoming a Solver/init-orders.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Initiating Orders"
-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."
+description: "CrossCats 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."
 sidebar:
   order: 5
 ---
@@ -162,7 +162,7 @@ Additionally, as previous chapters have described you cannot pull for BTC -> EVM
 
 ### Encode your Bitcoin address
 
-Your solver must be capable of generating 1 or multiple Bitcoin deposit address. Cross Cats supports all 5 address types in common use: P2PKH, P2SH, P2WPKH, P2WSH, and P2TR. We recommend using either P2WPKH, P2TR, or P2WSH.
+Your solver must be capable of generating 1 or multiple Bitcoin deposit address. CrossCats supports all 5 address types in common use: P2PKH, P2SH, P2WPKH, P2WSH, and P2TR. We recommend using either P2WPKH, P2TR, or P2WSH.
 
 :::caution[Ensure that amount + address is unique]
 To prove if an output has been paid, we look for an exact amount of Bitcoin sent to a specific address. Any transaction that matches both and is included in a block 3 days before the `fillDeadline` allows the order to be proven.
@@ -241,7 +241,7 @@ Once the Order Server has evaluated all quotes from solvers, it selects the most
 
 2. **Order Exclusivity**: It is crucial that the signed order is exclusive to the user and the Order Server’s executor. This exclusivity ensures that the order cannot be fulfilled by other solvers or reused. (TODO)
 
-3. **Asset Delivery Assurance**: The Cross Cats Order Server guarantees asset delivery through a Bitcoin address controlled by the Order Server but owned by the user. This setup ensures that the assets are securely delivered as promised.
+3. **Asset Delivery Assurance**: The CrossCats Order Server guarantees asset delivery through a Bitcoin address controlled by the Order Server but owned by the user. This setup ensures that the assets are securely delivered as promised.
 
 Ensuring these conditions helps maintain the integrity and efficiency of the order fulfillment process. It is essential that solvers adhere strictly to these requirements to ensure smooth operations and avoid any potential issues.
 

src/content/docs/cross-cats/Becoming a Solver/introduction.mdx

@@ -1,6 +1,6 @@
 ---
-title: "Solving for Cross Cats"
-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."
+title: "Solving for CrossCats"
+description: "CrossCats 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."
 sidebar:
   order: 3
 ---
@@ -9,7 +9,7 @@ import { Tabs, TabItem } from "@astrojs/starlight/components";
 
 > If you are not interested in the on-chain order structure, skip to [Init Orders](/cross-cats/becoming-a-solver/init-orders). For API documentation, refer to the [API Swagger documentation](https://catalyst-order-server-0140d799e2f7.herokuapp.com/api).
 
-Cross Cats utilizes three main order structures:
+CrossCats utilizes three main order structures:
 
 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. The key component here is orderData, which contains the core functionality and varies significantly across ERC-7683 supporting implementations.
 2.  [**ResolvedCrossChainOrder**](https://github.com/catalystdao/cross-cats/blob/7e07281eef10ffadc10f9f75eb42d1c2419224ca/src/interfaces/ISettlementContract.sol#L29-L52) provides a quote description, detailing the value of a cross-chain order at a specific point in time. It is also ERC-7683 compliant\*, allowing solvers to efficiently compare the resolution of orders across various protocols.
@@ -29,7 +29,7 @@ struct CrossChainOrder {
 }
 ```
 
-The `orderData` field is uniquely encoded by Cross Cats. Currently, two orderdata structs are supported:
+The `orderData` field is uniquely encoded by CrossCats. Currently, two orderdata structs are supported:
 
 ```solidity
 /// @notice Simpler and slightly cheaper for order types with fixed inputs and outputs.
@@ -88,4 +88,4 @@ struct OutputDescription {
 
 Users generate a `CrossChainOrder` with the appropriate order data and sign it as a Permit2 witness, thereby approving both the order description and its associated inputs with a single signature. The signed struct will be a new structure where `orderData` is an ABI-encoded order type.
 
-Cross Cats has directionality. That means the ways orders are initiated depends on the initiating chain (where the user is swapping out of). In the current iteration, there are 2 important origin types: EVM and Bitcoin. In the future, all virtual machine chains (including EVM) will generally be initiated similarly and all non-VM chains (including Bitcoin) will be initiated similarly but different from VM chains.
+CrossCats has directionality. That means the ways orders are initiated depends on the initiating chain (where the user is swapping out of). In the current iteration, there are 2 important origin types: EVM and Bitcoin. In the future, all virtual machine chains (including EVM) will generally be initiated similarly and all non-VM chains (including Bitcoin) will be initiated similarly but different from VM chains.

src/content/docs/cross-cats/ERC7683.md

@@ -1,6 +1,6 @@
 ---
 title: "ERC7863 Compatibility"
-description: "Cross Cats is ERC7863 compatible with a few non-breaking changes."
+description: "CrossCats is ERC7863 compatible with a few non-breaking changes."
 sidebar:
   order: 1000
 ---

src/content/docs/cross-cats/bitcoin-primer.mdx

@@ -1,6 +1,6 @@
 ---
 title: "Bitcoin Primer"
-description: "What is Bitcoin? What is a Bitcoin Block? What is a Bitcoin transaction?  And how do Cross Cats prove Bitcoin fulfillments? This page contains all information required to understand how Cross Cats interact with BTC."
+description: "What is Bitcoin? What is a Bitcoin Block? What is a Bitcoin transaction?  And how do CrossCats prove Bitcoin fulfillments? This page contains all information required to understand how CrossCats interact with BTC."
 sidebar:
   order: 2
 ---

src/content/docs/cross-cats/callbacks.md

@@ -1,18 +1,18 @@
 ---
 title: "Asset Delivery Callbacks"
-description: "Cross-Cats supports callbacks on both output delivery and input delivery."
+description: "CrossCats supports callbacks on both output delivery and input delivery."
 sidebar:
   order: 101
 ---
 
-Cross-Cats supporting making external on delivery of assets. However, there are several important implementation quirks that you need to be aware of.
+CrossCats supporting making external on delivery of assets. However, there are several important implementation quirks that you need to be aware of.
 
 ```solidity
 // SPDX-License-Identifier: MIT
 pragma solidity >=0.8.0;
 
 /**
- * @notice Implement callback handling for Cross cats payouts, both outputs and inputs.
+ * @notice Implement callback handling for CrossCats payouts, both outputs and inputs.
  * @dev Callbacks are opt-in. If you opt-in, take care to not revert.
  * Funds are likely in danger if the calls revert. Please be careful.
  *

src/content/docs/cross-cats/cross-cats.mdx

@@ -1,13 +1,13 @@
 ---
-title: "Cross Cats: Solving Liquidity x Bitcoin"
+title: "CrossCats: Solving Liquidity x Bitcoin"
 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."
 sidebar:
   order: 1
 ---
 
 import { Tabs, TabItem } from '@astrojs/starlight/components';
 
-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 client and allows VM chain payments to be conditional on Bitcoin transactions.
+CrossCats 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 client and allows VM chain payments to be conditional on Bitcoin transactions.
 <Tabs>
   <TabItem label="Index">
     ```d2 target=root
@@ -1293,7 +1293,7 @@ Cross-Cats is an intent-based cross-chain swap protocol built with flexibility i
 
 ## System Overview
 
-Cross-Cats is designed for cross-chain intents. Nevertheless, the majority of logic exists on the source chain. **Source Chain** here refers to the chain where the order was **Initiated** by a solver. **Remote Chain** refers to the chain (or chains) where proofs are sent from. This includes asset deliveries.
+CrossCats is designed for cross-chain intents. Nevertheless, the majority of logic exists on the source chain. **Source Chain** here refers to the chain where the order was **Initiated** by a solver. **Remote Chain** refers to the chain (or chains) where proofs are sent from. This includes asset deliveries.
 
 ### Initiation (order claim)
 
@@ -1307,7 +1307,7 @@ The payment pathway depends on the order intent. For a **VM to VM** swap, the so
 
 ### Input Payment (to solver)
 
-Cross Cats has 3 payment release schemes to optimise the solver experience.
+CrossCats has 3 payment release schemes to optimise the solver experience.
 
 1. Optimistic resolution. This assumes that the resolver delivered the payment to the user. After a dispute window (configured by the user), the payment will be released. If the order is disputed, the operation falls back to option 2.
 2. Explicit validation. At any time, orders can be proven. This requires that someone send the proof from the remote chains to the source chain. This is more costly than optimistic resolution, but may be significantly faster than optimistic resolution. Additionally, through batch verification, the cost can be reduced at a slight increase in verification speed.
@@ -1336,14 +1336,14 @@ In a future version, VM to Bitcoin swaps will upgrade to an oracle book scheme t
 
 ## Key differentiators
 
-Cross-Cats has been designed to optimise solver integration metrics:
+CrossCats has been designed to optimise solver integration metrics:
 - Cost of capital – Capital is only held for the duration of a swap and can be underwritten to further decrease the lock duration.
 - Speed – Minimizing settlement overhead, users receive their assets immediately, while solvers can opt in to underwriting for quick input payout.
 - Price Risk – Price Risk is minimized by letting solvers commit to swaps & providing strong order guarantees.
 
 ### Locked Capital & Underwriting
 
-Cross-Cats has no concept of pre-locking liquidity. Capital is only locked during the actual order flow. Additionally, Users will immediately receive their assets as deliveries are directly from the solver to the user.
+CrossCats has no concept of pre-locking liquidity. Capital is only locked during the actual order flow. Additionally, Users will immediately receive their assets as deliveries are directly from the solver to the user.
 
 Additionally, for routes supported by underwriters input assets will be available 1-5 minutes after asset delivery. This includes Bitcoin routes for users.
 
@@ -1353,4 +1353,4 @@ For VM to VM swaps and VM to Bitcoin swaps, the price uncertainty window is the
 
 For Bitcoin to VM swaps the price uncertainty window is from when the order is signed to when the user initiates the Bitcoin transaction and it gets your desired number of confirmations. This may vary from 30 seconds to 60 seconds.
 
-Cross-Cats has developed a user owned pseudo escrow, that allows the Order Server to give a soft commitment to solvers that a Bitcoin UTXO will be generated. Given that a solver trusts this promise, the price uncertainty window is as low as 30 seconds or shorter.
+CrossCats has developed a user owned pseudo escrow, that allows the Order Server to give a soft commitment to solvers that a Bitcoin UTXO will be generated. Given that a solver trusts this promise, the price uncertainty window is as low as 30 seconds or shorter.

src/content/docs/cross-cats/underwriting.mdx

@@ -18,16 +18,16 @@ import { Tabs, TabItem } from '@astrojs/starlight/components';
 - 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 cross-cats UI. Creator of Order Flow.
+- 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.
 
-#### Cross Cats 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 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.
+#### 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.
 
-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.
+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