fix: typos (#1347)

* fix typo

* fix typos

* fix typo

* fix typos

Author: omahs

price_pusher/README.md

@@ -207,9 +207,9 @@ It will take a few minutes until all the services are up and running.
 ## Reliability
 
 You can run multiple instances of the price pusher to increase the reliability. It is better to use
-difference RPCs to get better reliability in case an RPC goes down. **If you use the same payer account
+different RPCs to get better reliability in case an RPC goes down. **If you use the same payer account
 in different pushers, then due to blockchains nonce or sequence for accounts, a transaction won't be
-pushed twiced and you won't pay additional costs most of the time.** However, there might be some race
-condiitons in the RPCs because they are often behind a load balancer than can sometimes cause rejected
-transactions land on-chain. You can reduce the chances of additional cost overhead by reducing the
+pushed twice and you won't pay additional costs most of the time.** However, there might be some race
+conditions in the RPCs because they are often behind a load balancer which can sometimes cause rejected
+transactions to land on-chain. You can reduce the chances of additional cost overhead by reducing the
 pushing frequency.

target_chains/README.md

@@ -27,7 +27,7 @@ A basic implementation of pyth on a target chain includes the following pieces o
 
 ## What is stored on each contract
 
-In terms of contract configuration the following states exists on all the implementations:
+In terms of contract configuration the following states exist on all the implementations:
 
 1. Price feeds: each contract stores the latest values for each price feed
 2. Wormhole address: wormhole contract to be used for verifying the VAAs
@@ -40,7 +40,7 @@ In terms of contract configuration the following states exists on all the implem
 ## Wormhole deployments
 
 In the case that wormhole is not deployed on a new chain we want to deploy pyth on, we need to deploy wormhole too.
-The deployment process is chain dependant, but should be very similar to how pyth is deployed on the target chain.
+The deployment process is chain dependent, but should be very similar to how pyth is deployed on the target chain.
 After the initial deployment, we need to make sure wormhole configuration is also on the latest version.
 This is done by running a set of fixed, known VAAs that update the wormhole configurations (guardians sets) on all chains.
 

target_chains/ethereum/contracts/VERIFY.md

@@ -34,7 +34,7 @@ ETHERSCAN_KEY=... npm run verify --module=PythUpgradable --contract_address=0x0e
 (Note: the network name comes from the `truffle-config.json`).
 (Note: In this case, the `ETHERSCAN_KEY` is your snowtrace API key).
 
-**You might need to add the the explorer api keys in [the truffle config](./truffle-config.js) `api_keys`.** Please look at
+**You might need to add the explorer api keys in [the truffle config](./truffle-config.js) `api_keys`.** Please look at
 `truffle-plugin-verify/utils.js` to find the key names. Here is an example:
 
 ```js

target_chains/sui/cli/README.md

@@ -46,7 +46,7 @@ The following steps are needed to upgrade our sui contracts:
 
 ## Generating the new contract hash:
 
-Run the following command to generate the new hash, make sure the contract addresses are idential to the deployed ones:
+Run the following command to generate the new hash, make sure the contract addresses are identical to the deployed ones:
 
 ```bash
 npm run cli -- generate-digest
@@ -65,5 +65,5 @@ Since clients try to fetch the latest version of the package automatically, it's
 
 ### FAQ:
 
-- I'm seeting the error `Transaction has non recoverable errors from at least 1/3 of validators`. What should I do?
+- I'm seeing the error `Transaction has non recoverable errors from at least 1/3 of validators`. What should I do?
   Make sure you have enough funding in the wallet and try again. Usually a more descriptive error message is available in the returned value of the transaction.