chore: grammar

Author: reednaa

a

@@ -0,0 +1,95 @@
+0,001835
+0,001963
+0,002082
+0,002202
+0,002330
+0,002457
+0,002574
+0,002683
+0,002787
+0,002881
+0,002974
+0,003074
+0,003175
+0,003295
+0,003444
+0,003608
+0,003780
+0,003958
+0,004144
+0,004337
+0,004540
+0,004774
+0,005064
+0,005399
+0,005796
+0,006214
+0,006671
+0,007167
+0,007736
+0,008351
+0,009035
+0,009770
+0,010567
+0,011398
+0,012291
+0,013224
+0,014267
+0,015353
+0,016484
+0,017617
+0,018759
+0,019914
+0,021104
+0,022423
+0,023847
+0,025357
+0,027050
+0,028970
+0,031188
+0,033754
+0,036747
+0,040563
+0,044308
+0,048498
+0,053229
+0,058778
+0,064617
+0,070947
+0,077834
+0,085686
+0,094809
+0,105090
+0,116592
+0,129306
+0,142732
+0,157638
+0,174458
+0,193027
+0,212930
+0,232657
+0,251826
+0,270943
+0,289756
+0,307998
+0,325393
+0,341662
+0,358746
+0,376683
+0,395517
+0,415293
+0,436058
+0,457860
+0,480753
+0,504791
+0,530031
+0,556532
+0,584359
+0,613577
+0,644256
+0,676468
+0,710292
+0,745806
+0,783097
+0,822251
+0,863364

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

@@ -1,11 +1,11 @@
 ---
-title: "ERC7863 Compatible"
+title: "ERC7863 Compatibility"
 description: "Cross Cats is ERC7863 compatible with a few non-breaking changes."
 sidebar:
   order: 2
 ---
 
 Catalyst is [ERC-7683](https://eips.ethereum.org/EIPS/eip-7683)* compatible. *The implementation differs in 2 ways:
 
-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.
-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).
+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 an option 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. For naive implementations this slightly increases gas costs as Solidity always places `RETURNDATACOPY` after external calls.
+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 when read, those values are truncated). When possible, important contextual information is placed in the 20 rightmost bytes. Off-chain listeners should always read the entire 32 bytes.

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

@@ -226,24 +226,24 @@ Cross-Cats is designed for cross-chain intents. Never the less, the majorty of t
 
 ### Initiation (order claim)
 
-An order is initiated by the user signing an order description. An example of an order description is _My 1 Ether (Ethereum) for 3000 USD (Base)_. The signed order is a permit2 witness allowing the solver to submit the order to the Reactor and collect the **input** (1 Ether) from the user. Importantly, during this step some collateral is collected from the solver. This ensures the solver has some skin in the game and goes through with the order. The collateral is paid back when the input is released to the solver.
+An order is initiated by the user signing an order description. An example of an order description is _My 1 Ether (Ethereum) for 3000 USD (Base)_. The signed order is a permit2 witness allowing the solver to submit the order to the Reactor and collect the **input** (1 Ether) from the user. Importantly, during this step some collateral is collected from the solver. This ensures the solver has some skin in the game and settles the order. The collateral is paid back when the input is released to the solver.
 
-To improve the user and solver experience, an order server sits between the user and solver and aids with order validation, propergation, and quoting.
+To improve the user and solver experience, an order server sits between the user and solver and aids with order validation, propagation, and quoting.
 
 ### Output Payment (to user)
 
-The payment pathway depends on the order intent. For a **VM to VM** swap, the solver calls the oracle contract on the destination chain which sends & records the token payment to the user. For **VM to Bitcoin** swap, the solver makes the payment described in the order. In other words, make a Bitcoin transaction that has **a** TXO that matches the order description.
+The payment pathway depends on the order intent. For a **VM to VM** swap, the solver calls the oracle contract on the destination chain which sends & records the token payment to the user. For **VM to Bitcoin** swap, the solver makes the payment described in the order. In other words, make a Bitcoin transaction that has **a** TXO that matches the order description. If needed, the payment can then be validated using an SPV client.
 
 ### Input Payment (to solver)
 
 Cross Cats has 3 payment release schemes to optimise the solver experience.
 
-1. The default operation is 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 anytime, orders can be proven. This requires that someone send the proof from the remote chains to the source chain. This is costly but is in many cases faster than optimistic resolution. Additionally, through batch verification the cost can be reduced at a slight increase in verification speed.
-3. Underwriting. The last release scheme isn't a payment proof scheme as much as it is a responsibility delegration scheme. If configured, an order can be bought by someone else at any point priorer to the release of the input (proof / fraud). This allows the initial solver to immediately get their capital back and off-hand the payment validation to a third party.
+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 anytime, 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.
+3. Underwriting. The last release scheme isn't a payment proof scheme as much as it is a responsibility delegration scheme. If configured, an order can be bought by someone else at any point priorer to the release of the input (proof / fraud). This allows the initial solver to immediately get their capital back and hand off the payment validation to a third party.
 
 
-By using these 3 in conjunction with each other solvers only have to lock liquidity for a small amount of time while the security of the system can remain highly secure. At the same time, speed, security, and cost can be rebalanced based on the specific needs of a user or chain conditions.
+By using these 3 in conjunction with each other, solvers only have to lock liquidity for a small period of time while not sacrificing any system security. At the same time, speed, security, and cost can be rebalanced based on the specific needs of a user or chain conditions.
 
 ## Bitcoin & Pseudo Solving
 
@@ -253,32 +253,32 @@ VM to Bitcoin swaps are relatively straight forward:
 3. Solver delivers assets
 4. Solver is paid.
 
-However this flow breaks on step 2 when the user wants to go from Bitcoin to VM. (sell Bitcoin). There is no way to pull assets from a user. To solve this issue, the user becomes a **pseudo solver** & relying on release scheme 3. Pseudo solving works by asking solvers for short-lived Bitcoin short quotes. These orders are after validation & selection signed by the solver. The user then quickly claims the order.
+However this flow breaks on step 2 when the user wants to go from Bitcoin to VM. (sell Bitcoin). There is no way to pull assets from a user. To solve this issue, the user becomes a **pseudo solver** & relies on release scheme 3. Pseudo solving works by asking solvers for short-lived Bitcoin short quotes. These orders are after validation & selection signed by the solver. The user then quickly claims the order.
 
 Say the user wants to swap 1 Bitcoin for 50000 USDC. Using the order server, they need to collect & claim a signed order of the opposite: 50000 USDC for 1 Bitcoin. Once this order is filled, they get the input (50000 USDC) which matches their desire.
 
 Important to notice, this adds a delay between when the price risk begins for the solver (issuance of signed order) to when it resolves (0-1 block confirmations of Bitcoin TXO). These values are best migrated by the following configuration:
 1. Short initiation time. Using a source chain with a low block time, the initiation time can be kept to an absolute minimum.
 2. Short proof time. The user may only have 1 or 2 Blocks to get their transaction confirmed.
-3. High pseudo solver collateral. By requiring a lot of collateral, the cost of hedging / non-execution can be covered.
+3. Designing a compatibility layer between the UI and the Order Server that only requests binding order when it is known that the user can get their Bitcoins filled.
 
-In a future version, VM to Bitcoin swaps will upgrade to an price oracle book scheme that further minimizes time between start of price risk to end of price risk.
+In a future version, VM to Bitcoin swaps will upgrade to a price oracle book scheme that further minimizes time between start of price risk to end of price risk.
 
 # Key Integration Metrics
 
-Cross-Cats has been designed to optimise integration metrics like cost of capital, speed, human, developer, cost, price risk, capital risk, and more. Below are the most notiable metrics. If any metrics that are important to you are missing reach out and the documentation will be updated.
+Cross-Cats has been designed to optimise integration metrics like cost of capital, speed, human, developer, cost, price risk, and capital risk. Below are the most notiable metrics. If important metrics are missing feel free to reach out and the documentation will be updated.
 
 ## Locked Capital & Underwriting
 
-There is no need to pre-lock capital into Cross-Cats. Capital is only locked during the actual order flow. In the beginning orders will batch verified which will take between 2 and 4 hours (TBD). During this period there is **PRICE CERTANCY** but assets are temporarily locked.
+There is no need to pre-lock capital into Cross-Cats. Capital is only locked during the actual order flow. In the beginning orders will be batch verified which will take between 2 and 4 hours (TBD). During this period there is **PRICE CERTANCY** but assets are temporarily locked.
 
-The user will not experience any these delays.
+The user will not experience any delays.
 
 Additionally, underwriting will be available for some routes in which case assets will be available 1-5 minutes after asset delivery. This includes Bitcoin deliveries.
 
 ### Price (un)Certainty
 
-For VM to VM swaps and VM to Bitcoin swaps, the price uncertainty window is the time it takes from the moment your system commits to the order (or when the claim transaction is initiated) to when the order claim arrives on-chain and is successfully mined. On fast chains this is at most 2-3 seconds but may be up-to 12 seconds. Cleverly timing the commitment can reduce beyond the block time.
+For VM to VM swaps and VM to Bitcoin swaps, the price uncertainty window is the time it takes from the moment your system commits to the order (or when the claim transaction is initiated) to when the order claim arrives on-chain and is successfully mined. On fast chains this is at most 2-3 seconds but may be up-to 12 seconds. Cleverly timing the commitment can reduce the uncertainty period below the block time.
 
 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 10 minutes.