fix: Corrected Typos Across Documentation and Code Comments

README.md

@@ -1,6 +1,6 @@
 <img alt="Banner" src="docs/images/banner.jpg"/>
 
-This monorepo contains the reference implementation of the [Wormhole protocol](https://wormholenetwork.com).
+This monorepo contains the reference implementation of the [Wormhole protocol](https://wormhole.com).
 
 To learn about how to use and build on Wormhole read the [docs](https://docs.wormhole.com/).
 

docs/guardian.md

@@ -48,7 +48,7 @@ processes requests from a select set of peers.
 
 ### Processor
 
-The processor takes messages observed from the watchers and observations gossipped by other guardians. It aggregates these
+The processor takes messages observed from the watchers and observations gossiped by other guardians. It aggregates these
 until an observation is seen by a quorum of guardians, including itself. It then publishes the signed VAA. The processor
 stores signed VAAs in an on-disk badgerDB instance. The processor also interfaces with the governor and accountant packages
 before publishing an observation.

terra/docs/token_upgrades.md

@@ -56,5 +56,5 @@ Currently there is no implementation of a token contract migration function that
 
 ## Historical note:
 
-In Aug 2022, an attempt to upgrade the the token contracts was made, but failed due to the gas error:
+In Aug 2022, an attempt to upgrade the token contracts was made, but failed due to the gas error:
 https://finder.terra.money/classic/tx/FE39E9549770F59E2AAA1C6B0B86DDF36A4C56CED0CFB0CA4C9D4CC9FBE1E5BA. A subsequent upgrade changed the code id of *new* wrapped contracts to 767, but did not perform the migration for old contracts. This means that currently (as of Dec 2023), some wrapped tokens are still on the old code id, and some (the ones deployed after Aug 2022) are on the new code. This discrepancy is fine in the current case, because it only affects the rendering of the token name (https://github.com/wormhole-foundation/wormhole/commit/c832b123fcfb017d55086cb4d71241370ed270c6).

whitepapers/0003_token_bridge.md

@@ -237,7 +237,7 @@ NewContract [32]uint8
 ## Caveats
 
 ### Transfer completion
-A user who initiated a transfer should call `completeTransfer` within 24 hours. Guardian Sets are guaranteed to be valid for at least 24 hours. If the user waits longer, it could be that the Guardian Set has changed between the time where the transfer was initiated and the the time the user attempts to redeem the VAA. Let's call the Guardian Set at the time of signing `setA` and the Guardian Set at the time of redeeming on the target chain `setB`.
+A user who initiated a transfer should call `completeTransfer` within 24 hours. Guardian Sets are guaranteed to be valid for at least 24 hours. If the user waits longer, it could be that the Guardian Set has changed between the time where the transfer was initiated and the time the user attempts to redeem the VAA. Let's call the Guardian Set at the time of signing `setA` and the Guardian Set at the time of redeeming on the target chain `setB`.
 
 If `setA != setB` and more than 24 hours have passed, there are multiple options for still redeeming the VAA on the target chain:
 1. The quorum of Guardians that signed the VAA may still be part of `setB`. In this case, the VAA merely needs to be modified to have the new Guardian Set Index along with any `setA` only guardian signatures removed to make a valid VAA. The updated VAA can then be be redeemed. The typescript sdk includes a [`repairVaa()`](../sdk/js/src/utils/repairVaa.ts) function to perform this automatically.

whitepapers/0006_nft_bridge.md

@@ -66,7 +66,7 @@ message digests for replay prevention.
 Since the method for posting a VAA to the NFT bridge is authorized by the message signature itself, anyone can post any
 message.
 
-Since every NFT has unique metadata the Transfer messages contain all metadata, a transfer (even the first on per NFT)
+Since every NFT has unique metadata the Transfer messages contain all metadata, a transfer (even the first one per NFT)
 only requires a single Wormhole message to be passed compared to the Token Bridge. On the first transfer action of an
 NFT (address / symbol / name) a wrapped asset (i.e. master edition or new contract) is created. When the wrapped asset (
 contract) is already initialized or was just initialized, the (new) token_id and metadata URI are registered.
@@ -130,10 +130,10 @@ NewContract [32]uint8
 ## Caveats
 
 ### Transfer completion
-A user who initiated a transfer should call `completeTransfer` within 24 hours. Guardian Sets are guaranteed to be valid for at least 24 hours. If the user waits longer, it could be that the Guardian Set has changed between the time where the transfer was initiated and the the time the user attempts to redeem the VAA. Let's call the Guardian Set at the time of signing `setA` and the Guardian Set at the time of redeeming on the target chain `setB`.
+A user who initiated a transfer should call `completeTransfer` within 24 hours. Guardian Sets are guaranteed to be valid for at least 24 hours. If the user waits longer, it could be that the Guardian Set has changed between the time where the transfer was initiated and the time the user attempts to redeem the VAA. Let's call the Guardian Set at the time of signing `setA` and the Guardian Set at the time of redeeming on the target chain `setB`.
 
 If `setA != setB` and more than 24 hours have passed, there are multiple options for still redeeming the VAA on the target chain:
-1. The quorum of Guardians that signed the VAA may still be part of `setB`. In this case, the VAA merely needs to be modified to have the new Guardian Set Index along with any `setA` only guardian signatures removed to make a valid VAA. The updated VAA can then be be redeemed. The typescript sdk includes a [`repairVaa()`](../sdk/js/src/utils/repairVaa.ts) function to perform this automatically.
+1. The quorum of Guardians that signed the VAA may still be part of `setB`. In this case, the VAA merely needs to be modified to have the new Guardian Set Index along with any `setA` only guardian signatures removed to make a valid VAA. The updated VAA can then be redeemed. The typescript sdk includes a [`repairVaa()`](../sdk/js/src/utils/repairVaa.ts) function to perform this automatically.
 2. The intersection between `setA` and `setB` is greater than 2/3 of `setB`, but not all signatures of the VAA are from Guardians in `setB`. Then it may be possible to gather signatures from the other Guardians from other sources. E.g. Wormholescan provides an API under (/api/v1/observations/:chain/:emitter/:sequence)[https://docs.wormholescan.io/#/Wormscan/find-observations-by-sequence].
 3. A Guardian may send a signed re-observation request to the network using the `send-observation-request` admin command. A new valid VAA with an updated Guardian Set Index is generated once enough Guardians have re-observed the old message. Note that this is only possible if a quorum of Guardians is running archive nodes that still include this transaction.
 

whitepapers/0013_ccq.md

@@ -114,7 +114,7 @@ devnet_query_request_0000000000000|
 
 #### Solana Support
 
-An experimental implementation of queries for Solana is being added as of January, 2024. This implementation is considered experimental because Solana does not natively support reading account data for a specific slot number, meaning each guardiand watcher will return data for its version of the most recent slot, possibly making it difficult to reach consensus. The plan is to deploy this to mainnet so that we can experiment with various ways to achieve consensus.
+An experimental implementation of queries for Solana is being added as of January, 2024. This implementation is considered experimental because Solana does not natively support reading account data for a specific slot number, meaning each guardian watcher will return data for its version of the most recent slot, possibly making it difficult to reach consensus. The plan is to deploy this to mainnet so that we can experiment with various ways to achieve consensus.
 
 ### Request Execution
 

wormchain/x/ibc-hooks/README.md

@@ -160,7 +160,7 @@ pub enum IBCLifecycleComplete {
         sequence: u64,
         /// String encoded version of the ack as seen by OnAcknowledgementPacket(..)
         ack: String,
-        /// Weather an ack is a success of failure according to the transfer spec
+        /// Whether an ack is a success or failure according to the transfer spec
         success: bool,
     },
     #[serde(rename = "ibc_timeout")]