feat: automatically check for simple typos

Author: reednaa

.github/workflows/typos.yml

@@ -0,0 +1,17 @@
+name: Find Typos
+on: [push, pull_request]
+
+jobs:
+  check:
+    strategy:
+      fail-fast: false
+    name: Spell Check with Typos
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout Actions Repository
+        uses: actions/checkout@v4
+
+      - name: Check spelling of source code
+        uses: crate-ci/typos@master
+        with:
+          files: ./src

src/content/docs/generalised-incentives/build-bridge-agnostic.md

@@ -1,6 +1,6 @@
 ---
 title: "Build Bridge Agnostic"
-description: "Are you building a cross-chain application and are you tired of vendor lock-in? So are we! Generalised Incentives allows you to support a wide varity of messaging bridges while standarding the user interface."
+description: "Are you building a cross-chain application and are you tired of vendor lock-in? So are we! Generalised Incentives allows you to support a wide variety of messaging bridges while standarding the user interface."
 sidebar:
   order: 1
 ---

src/content/docs/generalised-incentives/integrate.md

@@ -21,7 +21,7 @@ This will add Generalised Incentives to your repository and you are now ready to
 
 Start by adding import statements to your smart contract file. We need to import 2 files:
 
-- [ICrossChainReceiver](https://github.com/catalystdao/GeneralisedIncentives/blob/main/src/interfaces/ICrossChainReceiver.sol): This will ensure you corretly implement the interfaces for the message callbacks
+- [ICrossChainReceiver](https://github.com/catalystdao/GeneralisedIncentives/blob/main/src/interfaces/ICrossChainReceiver.sol): This will ensure you correctly implement the interfaces for the message callbacks
 - [IIncentivizedMessageEscrow](https://github.com/catalystdao/GeneralisedIncentives/blob/main/src/interfaces/IIncentivizedMessageEscrow.sol): This will ensure you correctly call the message escrow correctly.
 - [Optionally] [IMessageEscrowStructs](https://github.com/catalystdao/GeneralisedIncentives/blob/main/src/interfaces/IMessageEscrowStructs.sol): To simplify struct handling.
 
@@ -44,7 +44,7 @@ contract YourContract is ICrossChainReceiver, IMessageEscrowStructs {
 
 The integration is less opinionated than other cross-chain endpoint, as we need to define some boilercode. First, lets set our escrow endpoint. Below we present 2 options
 
-1. Set the escrow explicity. This defines a single escrow which you may interact in. This may be desired to reduce complexity but also introduces some vendor lock-in.
+1. Set the escrow explicitly. This defines a single escrow which you may interact in. This may be desired to reduce complexity but also introduces some vendor lock-in.
 2. Define a list of escrow that are allowed. This allows you to pick and chose which AMB is best suited for a certain connection. This introduces some additional complexity but mitigates vendor lock-in.
 
 ```solidity
@@ -128,7 +128,7 @@ contract YourContract is ICrossChainReceiver, IMessageEscrowStructs {
     // That is because if the message fails for some reason,
     // an error code is prepended to the message.
     // By always sending back hex"00", we ensure that the first byte is unused.
-    // Alternativly, use this byte as our own failure code.
+    // Alternatively, use this byte as our own failure code.
     return bytes.concat(
       hex"00",
       keccak(message)
@@ -152,7 +152,7 @@ We havn't actually sent any messages yet. Lets do that. For simplicity, this sec
 ```solidity
 
 contract YourContract is ICrossChainReceiver, IMessageEscrowStructs {
-  // If your contract didn't inheirt IMessageEscrowStructs, you may have to
+  // If your contract didn't inherit IMessageEscrowStructs, you may have to
   // set the type of incentive to IIncentivizedMessageEscrow.IncentiveDescription.
   function sendMessage(bytes32 destinationIdentifier, bytes destinationAddress, bytes calldata message, IncentiveDescription calldata incentive, uint64 deadline) payable external {
     // Submit the message to the escrow. Remember to add associated value.

src/content/docs/introduction/how-it-works.md

@@ -1,6 +1,6 @@
 ---
 title: "How Does Catalyst Work?"
-description: "Catalyst uses the Unit Of Liquidity as a liquidity abstraction and that allows Catalyst to evaluate liquidity asyncronously."
+description: "Catalyst uses the Unit Of Liquidity as a liquidity abstraction and that allows Catalyst to evaluate liquidity asynchronously."
 sidebar:
   order: 2
 ---

src/content/docs/protocol/liquidity-pools.md

@@ -1,6 +1,6 @@
 ---
 title: "Liquidity Pools"
-description: "Catalyst liquidity pools can relicate any type of AMM pool such as Curve stableswap, UNI v2, and Balancer all while being nativly cross-chain."
+description: "Catalyst liquidity pools can relicate any type of AMM pool such as Curve stableswap, UNI v2, and Balancer all while being natively cross-chain."
 sidebar:
   order: 3
 ---
@@ -173,4 +173,4 @@ scenarios: {
 ```
 
 Any asset within the pool can be exchanged into any other asset in the pool. This is facilitated by swapping into Units as an intermediary. Units are pricing using an internal price curve which defined a constant operation space.
-For local swaps within the same vaults, swap can be converted into and out of units in a single transaction allowing for full local utilisation of all liquidity contains the in vault. Using a cross-chain messaging layer, Units can be transfered to other connected vaults, where they can be converted into the desired output token.
+For local swaps within the same vaults, swap can be converted into and out of units in a single transaction allowing for full local utilisation of all liquidity contains the in vault. Using a cross-chain messaging layer, Units can be transferred to other connected vaults, where they can be converted into the desired output token.

src/content/docs/protocol/swaps-types.md

@@ -1,6 +1,6 @@
 ---
 title: "Swaps Types"
-description: "Catalyst suports 4 different types of swaps: Local Swaps, Cross-Chain Swaps, Underwritten Cross-chain swaps, and Logic Dependent Swaps. This allows Catalyst to bring the forefront of cross-chain innovation anywhere."
+description: "Catalyst supports 4 different types of swaps: Local Swaps, Cross-Chain Swaps, Underwritten Cross-chain swaps, and Logic Dependent Swaps. This allows Catalyst to bring the forefront of cross-chain innovation anywhere."
 sidebar:
   order: 4
 ---
@@ -25,7 +25,7 @@ Underwriters underwriting their own swaps can get sub second swaps price finalit
 
 ## Logic Dependent Swaps
 
-By only commiting to a swap if a certain logic returns true, Catalyst opens up for a host of new cross-chain applications. Developers can set any condition which can be programmed into a smart contract to determine whether or not to commit to the swap. If not, the swap reverts back to the sending chains.
+By only committing to a swap if a certain logic returns true, Catalyst opens up for a host of new cross-chain applications. Developers can set any condition which can be programmed into a smart contract to determine whether or not to commit to the swap. If not, the swap reverts back to the sending chains.
 
 Examples of use cases for logic dependent swaps:
 
@@ -34,8 +34,8 @@ Examples of use cases for logic dependent swaps:
 - Governance fee collection: Send fees from a chain and only commit to the transfer if it can be exchanged at favorable rates.
 - Rebalance WBTC between AAVE deployment: Only commit to the rebalance if the rate on the destination chain is higher than the sending chain.
 
-Underwriting is conditional on the configured dependent logic. As a result, underwriter will continously try to underwriter swaps if the conditions may change over time.
+Underwriting is conditional on the configured dependent logic. As a result, underwriter will continuously try to underwriter swaps if the conditions may change over time.
 
-## Liquidity boostrapping pools (LBPs)
+## Liquidity bootstrapping pools (LBPs)
 
 Liquidity Bootstrapping Pools (LBPs) are pools that allow for dynamic changes in token weighting over time. The pool owner determines the starting and end weights and times, and has the ability to pause swaps. LBPs use a weighted math model that gradually adjusts the token price until it reaches market equilibrium.

src/content/docs/relayer/setup.md

@@ -1,6 +1,6 @@
 ---
 title: "Setting up a Relayer"
-description: "Setting up the Generalised Relayer is easy for everyone. After installing Docker, the relayer can be installed by pulling the generalised-relayer repo and then configuring the appropiate settings. Fund the relayer and you are off to the races."
+description: "Setting up the Generalised Relayer is easy for everyone. After installing Docker, the relayer can be installed by pulling the generalised-relayer repo and then configuring the appropriate settings. Fund the relayer and you are off to the races."
 sidebar:
   order: 3
 ---
@@ -88,11 +88,11 @@ where `0xf2d04...23d9` is your privatekey.
 
 :::tip[Private Key Format]
 A proper private key begins with **0x**. Metamask does not add 0x to the front of the privatekey and you may have to do that yourself.
-The privatekey should be 64 charactors long without 0x and 66 charactors long with 0x.
+The privatekey should be 64 characters long without 0x and 66 characters long with 0x.
 :::
 
 :::caution
-Do not use this private key for other applications as it could interfear with the operation of the relayer wallet. Use a dedicated private key for the relayer to ensure proper operation.
+Do not use this private key for other applications as it could interfere with the operation of the relayer wallet. Use a dedicated private key for the relayer to ensure proper operation.
 :::
 
 ### RPCs

src/content/docs/resources/audit-whitepaper.md

@@ -1,6 +1,6 @@
 ---
 title: "Audits & Whitepaper"
-description: "Catalyst contracts has been audited a total of 6 seperate times, with Generalised incentives and Catalyst both having been audited thrice. Catalyst has published 1 Whitepaper: Asynchronous Autonomous Market Making via a Unit of Liquidity"
+description: "Catalyst contracts has been audited a total of 6 separate times, with Generalised incentives and Catalyst both having been audited thrice. Catalyst has published 1 Whitepaper: Asynchronous Autonomous Market Making via a Unit of Liquidity"
 sidebar:
   order: 1
 ---

src/content/docs/underwriter/server-requirements.md

@@ -1,13 +1,13 @@
 ---
 title: "Server Requirements"
-description: "Underwriting is dependent on running a relayer and requires slighly higher specifications."
+description: "Underwriting is dependent on running a relayer and requires slightly higher specifications."
 sidebar:
   order: 2
 ---
 
-Underwriting requres running a relayer:
+Underwriting requires running a relayer:
 
-1. The relayer acts as a data engine for the Underwriter. It collects everything related to relaying. It has both packages needed to get relevant underwrite infromation and the bounty which helps with evaluating if underwriting is worth it.
+1. The relayer acts as a data engine for the Underwriter. It collects everything related to relaying. It has both packages needed to get relevant underwrite information and the bounty which helps with evaluating if underwriting is worth it.
 2. The underwriter is very reliant on the underwritten swaps getting relayed. As a result, it needs to be able to force some packages to be relayed.
 
 We recommend running the underwriter on the same VPS as the relayer. Underwriting requires a high degree of stability and as a result, the requirements are slightly higher:

src/content/docs/underwriter/underwriting-swaps.md

@@ -28,7 +28,7 @@ The bought finality risk is the following:
    - If this happens the underwriter loses 100% of their fronted tokens.
    - The underwriter can recover part of their collateral if they expire their own underwrite.
 3. The underwriter also pays gas to execute the logic associated with the user’s swap. To underwrite a swap is conditional on executing the logic. There is not an associated gas payment included in the underwrite incentive and it will have to also cover the gas cost.
-   - If the underwriter evaluator is unable to correctly asses the profitability of underwrites, it could underwrite swaps such that it is not truely profitable.
+   - If the underwriter evaluator is unable to correctly asses the profitability of underwrites, it could underwrite swaps such that it is not truly profitable.
 4. The messaging bridge finalises the swap within the configured max time. If the message is not relayed within the configured max time, the underwrite may be expired.
    - If this happens the underwriter loses 100% of their fronted tokens.
    - The underwriter can recover part of their collateral if they expire their own underwrite.
@@ -76,10 +76,10 @@ With these information, it can both validate swaps by cross-examining the packag
 :::danger[Validate!]
 `underwrite(...)` is very unlikely to revert. It will generally accept any information and _underwrite_ whatever swap is proposed. But if there is not a messaging bridge hit on the underwrite the fronted tokens will not be refunded.
 
-It is important to throughly verify that swaps before underwriting to ensure the fronted underwrite capital is refunded otherwise there may be a loss of funds.
+It is important to thoroughly verify that swaps before underwriting to ensure the fronted underwrite capital is refunded otherwise there may be a loss of funds.
 :::
 
-### Risk Migration implementaitons
+### Risk Migration implementations
 
 The [reference underwriter](/underwriter/setup/) has built-in risk migrations. Below is a list of the currently implemented risk management features: