Docs fix spelling issues

CONTRIBUTING.md

@@ -6,7 +6,7 @@ We have a grants program where you can get funding to write a custom bridge. You
 
 In the near future, adding a custom bridge to the Aztec network will be permissionless. Currently bridges must be added to the Aztec Rollup processor contract manually by the team. This is a temporary measure as we bootstrap the network.
 
-This repo has been built with Foundry. Given the inter-connected nature of Aztec Connect Bridges with existing mainnet protocols, we decided Foundry / forge offered the best support for testing. This repo should make debugging, mainnet-forking, impersonation and gas profiling simple. It makes sense to test Solidity contracts with Solidty not with the added complication of Ethers / Typescript.
+This repo has been built with Foundry. Given the inter-connected nature of Aztec Connect Bridges with existing mainnet protocols, we decided Foundry / forge offered the best support for testing. This repo should make debugging, mainnet-forking, impersonation and gas profiling simple. It makes sense to test Solidity contracts with Solidity not with the added complication of Ethers / Typescript.
 
 For more information, refer to the [README](./README.md).
 

README.md

@@ -282,7 +282,7 @@ You can also find more information on the [Aztec docs site](https://docs.aztec.n
 
 ### What is Aztec?
 
-Aztec is a privacy focussed L2, that enables cheap private interactions with Layer 1 smart contracts and liquidity, via a process called DeFi Aggregation.
+Aztec is a privacy focused L2, that enables cheap private interactions with Layer 1 smart contracts and liquidity, via a process called DeFi Aggregation.
 We use advanced zero-knowledge technology "zk-zk rollups" to add privacy and significant gas savings any Layer 1 protocol via Aztec Connect bridges.
 
 #### What is a bridge?

specs/aztec/subsidy/readme.md

@@ -1,13 +1,13 @@
 # Aztec Subsidy Module
 Aztec Connect have a [subsidy module](https://etherscan.io/address/0xABc30E831B5Cc173A9Ed5941714A7845c909e7fA) that strives to improve consistency of bridge executions, e.g., how often they are executed. This is done by allowing anyone to setup a subsidy which is paying some amount to the sequencer when executing the bridge. It is essentially a way to make it profitable for the sequencer to include the bridge, even if the users that are queued don't cover the gas entirely themselves. 
 
-The module is primary expected to be used by projects/teams that are added to Aztec who want to give their users a more consistent experience. To give you an example, Yearn subsidises deposits into the Eth and Dai bridges, reducing the time users have to wait until they have their yvEth and yvDai.
+The module is primarily expected to be used by projects/teams that are added to Aztec who want to give their users a more consistent experience. To give you an example, Yearn subsidises deposits into the Eth and Dai bridges, reducing the time users have to wait until they have their yvEth and yvDai.
 
 The module itself is an immutable contract that have no admin keys, allowing anyone to subsidise the bridges. Prior to the module, teams wanting to subsidise bridges would have to send some Eth to the Aztec team and we would manually setup the subsidy within our sequencer software. This was impractical since it required our cooperation.
 
 The idea is relatively simple, the bridge has an upper bound on the gas it consumes. You never want to subsidise more than this amount per "run", as you are then wasting funds, e.g., upper bound of subsidy = upper bound of gas consumed by the bridge. At the same time, you have an idea about how often the bridge should be executed at a minimum, so you let the subsidy grow over this time period. Written as a formula `bridge_gas_cost / time_between_executions = gas_per_time_unit`. In the case of Yearn, they wanted daily execution, so they needed to cover `200K / 24 hours = 140 gas per minute` (200k gas is how much the Yearn bridge call costs - this value is bridge specific). After 24 hours, the subsidy reaches its maximum amount. In such a scenario even one user fee would be enough to make it profitable for the sequencer to include the bridge call in a rollup block. This is because the fee paid by user + the subsidy is bigger than the actual gas cost of the bridge call. When the subsidy is claimed, the amount goes back to 0, and the cycle repeats. 
 
-On the module, the subsidy is accruing to a specific `bridge` and `criteria`. Criteria is an integer which can be used by the bridge to differentiate between different flows. This valuable because different execution flow might have a different gas cost and because it's common that people want to subsidize only a specific flow (for example Yearn wanted to subsidize only deposits to their vaults and not exits). The `criteria` value is being computed by the bridge itself and it is registered by the bridge in the Subsidy contract. This is usually done in the bridge's constructor. Because the subsidy is accruing to a criteria, multiple flows that all have the same criteria will be "fighting" over it. Something you need to consider when building the bridge. 
+On the module, the subsidy is accruing to a specific `bridge` and `criteria`. Criteria is an integer which can be used by the bridge to differentiate between different flows. This is valuable because different execution flow might have a different gas cost and because it's common that people want to subsidize only a specific flow (for example Yearn wanted to subsidize only deposits to their vaults and not exits). The `criteria` value is being computed by the bridge itself and it is registered by the bridge in the Subsidy contract. This is usually done in the bridge's constructor. Because the subsidy is accruing to a criteria, multiple flows that all have the same criteria will be "fighting" over it. Something you need to consider when building the bridge. 
 
 
 ---
@@ -39,4 +39,4 @@ To fund the subsidy using etherscan as an interface do the following:
 4. Send the transaction by clicking “Write”.
 
 > Note: This is a standard contract interaction so feel free to fund the subsidy any other way.
-> If you are using a multi-sig, you can instead propose this transaction in the UI of the multi-sig wallet, with the same parameters.
+> If you are using a multi-sig, you can instead propose this transaction in the UI of the multi-sig wallet, with the same parameters.

specs/bridges/TEMPLATE.md

@@ -22,7 +22,7 @@ You can view an example spec [here](#add-link).
      - All relevant bridge address ids (may fill in after deployment)
      - use of auxData
      - gas usage
-     - cases that that would make the interaction revert (low liquidity etc)
+     - cases that would make the interaction revert (low liquidity etc)
    - Please include any diagrams that would be helpful to understand asset flow.
 
 4. Please list any edge cases that may restrict the usefulness of the bridge or that the bridge prevents explicit.

specs/bridges/lido/readme.md

@@ -22,7 +22,7 @@ There are two flows of Lido Bridge, namely deposits and withdraws.
 
 ### Deposit
 
-If the bridge receives `eth` as the input token it will deposit it into the Lido contract along a referall address. In return, the bridge will receive `stEth` which it will wrap to `wstEth` before return the tuple `(wstEthAmount, 0, false)` and the rollup pulls the `wstEth` tokens.
+If the bridge receives `eth` as the input token it will deposit it into the Lido contract along a referral address. In return, the bridge will receive `stEth` which it will wrap to `wstEth` before return the tuple `(wstEthAmount, 0, false)` and the rollup pulls the `wstEth` tokens.
 
 The gas cost E2E for a deposit is ~175K, this is including the transfers to/from the Rollup Processor.
 
@@ -60,4 +60,4 @@ As we are using the wrapped variation of `stEth` it will not directly be impacte
 
 ## What about withdrawing after the merge and hardfork?
 
-When Lido can support withdraws directly, a new bridge can be made that performs this interaction. Because the bridge don't hold the tokens, the user is free to take his shielded L2 `wstEth` and go to any other bridge to use them to his liking.
+When Lido can support withdraws directly, a new bridge can be made that performs this interaction. Because the bridge doesn't hold the tokens, the user is free to take his shielded L2 `wstEth` and go to any other bridge to use them to his liking.

specs/bridges/yearn/readme.md

@@ -20,7 +20,7 @@ When the bridge proceed to deposit the input token to the output vault.
 
 If the bridge receives `ETH` as the input token it will first wrap into `WETH` and then follow the same flow as any other ERC20.
 
-We check that `auxData` is correct (`0`), `inputValue` is greater that 0 and that the token is an ERC20. After that, the bridge calls the `deposit` function to send the tokens to the vault and receive yvTokens as a receipt for it.
+We check that `auxData` is correct (`0`), `inputValue` is greater than 0 and that the token is an ERC20. After that, the bridge calls the `deposit` function to send the tokens to the vault and receive yvTokens as a receipt for it.
 
 The gas cost for ERC20 deposit is ~230k.
 The gas cost for ETH deposit is ~118k.