Fix typos

docs/basic-sentry-setup.md

@@ -78,7 +78,7 @@ Modify the following lines in your config.toml and save
 
 #### Modify your VALIDATOR config.toml
 
-In this example we are using 3 seperate sentries but you may use any number that you prefer. Please modify the config.toml on your Validator using the example below.
+In this example we are using 3 separate sentries but you may use any number that you prefer. Please modify the config.toml on your Validator using the example below.
 
 ```text
   - config.toml

docs/canto-guide.md

@@ -11,7 +11,7 @@ Be sure your metamask is set to Ethereum network if you wish to bridge from ethe
 ![screenshot of canto bridge interface](/images/canto-image5.png)
 ![screenshot of canto bridge interface](/images/canto-image3.png)
 
-Click “Select Tokens” and choose the tokens you wish to send to Canto. Type the amount to the right of thetoken selection. The maximum amount available will be displayed. Confirm your ethereum and Canto addresses to be sent to and click on “send token”.
+Click “Select Tokens” and choose the tokens you wish to send to Canto. Type the amount to the right of the token selection. The maximum amount available will be displayed. Confirm your ethereum and Canto addresses to be sent to and click on “send token”.
 Confirm the transaction in your metamask wallet. The gas prices displayed are eth fees for sending.
 
 ![screenshot of canto bridge interface](/images/canto-image1.png)
@@ -30,4 +30,4 @@ Click on “select tokens” and choose the tokens you just bridged over to Cant
 
 Make sure the arrow is pointing to the right to send to Canto (select “click to switch” if not). Adjust the amount of tokens you wish to convert to Canto and select “transfer”. You will be then prompted to sign the metamask transfer.
 
-Congratulations! You should now see your balance of converted Canto EVM tokens.
+Congratulations! You should now see your balance of converted Canto EVM tokens.

docs/erc20-representation.md

@@ -2,7 +2,7 @@
 
 One of the main features of Gravity Bridge is to provide an ERC20 representation of a given CosmosSDK token on Ethereum. Once bridged to Ethereum you can use the Cosmos token however you would use any other ERC20.
 
-This opens up exiting use cases like listing Cosmos originated tokens in Uniswap or using them with other DeFi applications.
+This opens up exciting use cases like listing Cosmos originated tokens in Uniswap or using them with other DeFi applications.
 
 ## Requirements
 
@@ -36,7 +36,7 @@ Creating an IBC channel is extensively documented outside of Gravity Bridge, no
 
 For more information on setting up an IBC channel between your chain and Gravity Bridge, see: [https://hermes.informal.systems/](https://hermes.informal.systems/)
 
-Once you have created the channel, send any amount of the token over IBC that you want to create a representation for. This will allow you to see it's `ibc/hash` token name. You will need this value for the governance proposal next.
+Once you have created the channel, send any amount of the token over IBC that you want to create a representation for. This will allow you to see its `ibc/hash` token name. You will need this value for the governance proposal next.
 
 ## Submit an IBCMetadata governance proposal
 

docs/eth-merge-faq.md

@@ -1,8 +1,8 @@
 # Ethereum Merge FAQ
 
-As you probably already know Ethereum is [moving to proof of stake](https://ethereum.org/en/upgrades/merge/) in an event called 'the merge'. As part of this event the current Ethereum chain will change it's consensus mechanism from proof of work to proof of stake on the Ethereum 'becon chain' or now simply 'consensus layer'.
+As you probably already know Ethereum is [moving to proof of stake](https://ethereum.org/en/upgrades/merge/) in an event called 'the merge'. As part of this event the current Ethereum chain will change its consensus mechanism from proof of work to proof of stake on the Ethereum 'beacon chain' or now simply 'consensus layer'.
 
-This document covers how Gravity Bridge will interact with and secure tokenss during the merge and specifically teh precautions the community has chosen to take in the face of low probability, but possible, failures around the merge.
+This document covers how Gravity Bridge will interact with and secure tokens during the merge and specifically the precautions the community has chosen to take in the face of low probability, but possible, failures around the merge.
 
 ## When is the merge
 
@@ -12,17 +12,17 @@ The merge will take place at a 'Terminal Total Difficulty' of `58750000000000000
 
 The 24 hour estimated time range for the merge is an estimate based on the assumption that miners continue to operate normally. Considering their incentives to cause potential chaos around the merge we can not discount potential attacks to either delay or accelerate the merge.
 
-Furthermore the successful transition to becon chain control may not be smooth. Chain halts, re-organizations, and consensus failures are all possible.
+Furthermore the successful transition to beacon chain control may not be smooth. Chain halts, re-organizations, and consensus failures are all possible.
 
-None of these are likley, in all probability the merge will go smoothly, but Gravity Bridge must be prepared regardless.
+None of these are likely, in all probability the merge will go smoothly, but Gravity Bridge must be prepared regardless.
 
 ## How is Gravity Bridge preparing for the merge
 
-tl;dr **Transfers to and from Ethereum will be halted for at least 48 hours leading up to the merge, after the merge valdiators will resume the bridge once ETH2 is deemed stable, probably around 24 hours later**
+tl;dr **Transfers to and from Ethereum will be halted for at least 48 hours leading up to the merge, after the merge validators will resume the bridge once ETH2 is deemed stable, probably around 24 hours later**
 
 As part of the [Gravity Bridge Pleiades Upgrade](https://www.mintscan.io/gravity-bridge/proposals/74) new oracle software is being deployed to halt the bridge once the total difficulty exceeds `58591842390178918929502` this value is estimated to be about 48 hours before the merge. But as previously discussed timing is variable, regardless of when the merge actually occurs the Gravity Bridge oracle will automatically shut down the flow of information from Ethereum to Gravity Bridge around that time.
 
-What this will do is prevent any double spend attacks caused by forks or chain re-organizations. As a secondary saftey measure a governance proposal to halt the bridge, also targted for an estimated 48 hours before the merge, will be submitted shortly after the Pleiades upgrade.
+What this will do is prevent any double spend attacks caused by forks or chain re-organizations. As a secondary safety measure a governance proposal to halt the bridge, also targeted for an estimated 48 hours before the merge, will be submitted shortly after the Pleiades upgrade.
 
 Combined these actions will ensure that Gravity Bridge does not reflect any balance changes on Ethereum until after the merge when the validators have upgraded their Ethereum nodes and have a stable stream of information coming from ETH2.
 
@@ -34,7 +34,7 @@ On the Gravity Bridge side it will be possible to put your funds into the batch
 
 ## How will the bridge be resumed
 
-Gravity Bridge will resume once the governance proposal to re-enable the bridge passes and the validators connect their `gbt` nodes to an updated ETH2 Ethereum RPC. Once this has been done the oracle will resume operaiton and all information about what has occured on Ethereum during the pause will be relayed and reflected on the Gravit Bridge side.
+Gravity Bridge will resume once the governance proposal to re-enable the bridge passes and the validators connect their `gbt` nodes to an updated ETH2 Ethereum RPC. Once this has been done the oracle will resume operation and all information about what has occurred on Ethereum during the pause will be relayed and reflected on the Gravit Bridge side.
 
 In the case of catastrophic failure of the merge it will be up to on chain governance to decide to delay unpausing the bridge or to select which fork to resume the bridge on. This is ultimately decided by which RPC 2/3 of the voting power choses to use for their `gbt` process.
 
@@ -44,13 +44,13 @@ Post merge, USDC.grav (or any .grav tokens for this example) will represent toke
 
 Due to the design of Gravity Bridge any withdraw transactions can be played back on each fork of Ethereum. Meaning an advanced user will be able to claim bridge assets on all forks by sending them to themselves with a normal Gravity Bridge withdraw.
 
-We **strongly recomend against interacting with Ethereum forks post merge** unless you have in-depth blockchain technical knowlege. If you must be sure to initialize a new wallet for each fork and transfer forked assets on each chain to that new wallet. Failure to take this precaution opens you to unexpected cross-chain interactions between the forks, at least until they recieve individual chain-id values.
+We **strongly recommend against interacting with Ethereum forks post merge** unless you have in-depth blockchain technical knowledge. If you must be sure to initialize a new wallet for each fork and transfer forked assets on each chain to that new wallet. Failure to take this precaution opens you to unexpected cross-chain interactions between the forks, at least until they receive individual chain-id values.
 
 ## I'm a validator, how do I make sure everything is ready
 
 First keep a close eye on governance votes, as they will convey more info and will be required to disable and re-enable the bridge.
 
-Make sure `gbt --version` returns `v1.7.0` and start syncing an ETH becon chain node as as lighthouse as quickly as possible. Endpoints like `eth.althea.net` will continue to function but if you are running your own node you will need to run both a execution layer client such as Geth and a consensus layer client such as Lighthouse in order to operate an RPC.
+Make sure `gbt --version` returns `v1.7.0` and start syncing an ETH beacon chain node as lighthouse as quickly as possible. Endpoints like `eth.althea.net` will continue to function but if you are running your own node you will need to run both an execution layer client such as Geth and a consensus layer client such as Lighthouse in order to operate an RPC.
 
 When merge time approaches you will see the following line from `service orchestrator status`
 

docs/evmos.md

@@ -6,7 +6,7 @@ so.
 First visit [bridge.blockscape.network](https://bridge.blockscape.network) and select Evmos from the destination list.
 ![image](https://user-images.githubusercontent.com/19688153/182438709-e9954667-82bf-4b3c-8175-ad9b015675eb.png)
 
-Connect your MetaMask wallet and your Keplr wallet. Alternately you can skip keplr and click the lock button next to transfer address and paste your evmos1 address there.
+Connect your MetaMask wallet and your Keplr wallet. Alternatively you can skip keplr and click the lock button next to transfer address and paste your evmos1 address there.
 
 Click select token and select which token you would like to bridge and the amount.