Update 5_guardianNetwork.md

#2 The signing scheme of the VAAs can be changed without affecting downstream users, and multiple relay mechanisms can exist independently. xAssets can be implemented purely at the application layer and xDapps can utilize whatever components suits them. 
"suit" updated to "suits"

projects/evm-tokenbridge/treasury.js

@@ -199,7 +199,7 @@ async function main() {
         await targetTokenBridge.createWrapped(Buffer.from(vaaBytes.vaaBytes, "base64"), {
             gasLimit: 2000000
         })
-        await new Promise((r) => setTimeout(r, 5000)); //Time out to let block propogate
+        await new Promise((r) => setTimeout(r, 5000)); //Time out to let block propagate
         const wrappedTokenAddress = await targetTokenBridge.wrappedAsset(network.wormholeChainId, Buffer.from(tryNativeToHexString(network.testToken, "ethereum"), "hex"));
         console.log("Wrapped token created at: ", wrappedTokenAddress);
         targetDeployment["wrappedTestTokenAddress"] = wrappedTokenAddress;
@@ -261,7 +261,7 @@ async function main() {
         await treasury.approveTokenBridge(bridgeAmt, {
             gasLimit: 2000000,
         });
-        await new Promise((r) => setTimeout(r, 5000)); //Time out to let block propogate
+        await new Promise((r) => setTimeout(r, 5000)); //Time out to let block propagate
 
         const targetNetwork = config.networks[process.argv[4]];
         const targetDeployment = deployment[process.argv[4]]

projects/messenger-v2/README.md

@@ -1,5 +1,5 @@
 ## Wormhole Messenger Sample Project
-Simple messeger project that sends a "hellom, world!" message between EVM, Solana and Aptos chains using Wormhole. 
+Simple messenger project that sends a "hello, world!" message between EVM, Solana and Aptos chains using Wormhole. 
 
 ### Dependencies
 This project uses Foundry to compile and deploy EVM contracts. You can find install instructions at [https://getfoundry.sh](https://getfoundry.sh)
@@ -27,4 +27,4 @@ If you see transactions failing due to nonce mismatch errors, restart your local
 This is intermittent and likely caused by the js lib and evm chain being out of sync.
 
 #### Transaction Underpriced Issues
-Transactions failing with the message `transaction underpriced` is an intermittent issue. Restart the evm chains and rerun `npm run test`. If the issue persists, you may need to manually set gas prices when calling the Messenger contract in the `send_msg` logic in `orchestrator.js`.
+Transactions failing with the message `transaction underpriced` is an intermittent issue. Restart the evm chains and rerun `npm run test`. If the issue persists, you may need to manually set gas prices when calling the Messenger contract in the `send_msg` logic in `orchestrator.js`.

src/dapps/1_defiBasics.md

@@ -16,7 +16,7 @@ Now, a rich ecosystem of Dapps exists across an array of smart-contract-enabled
 
 However, Dapps are not without limitations, many of which are tied to their underlying blockchains.
 
-Two notable limitations are that blockchains have no access to off-chain data and no mechanism to interact with other blockchains. These limitations have led to a fractured ecosystem where each blockchain is closed off from the others by default. That means assets native to one chain are not accessible on another, and some services can't be leveraged on particular chains altogether.
+Two notable limitations are that blockchains have no access to off-chain data and no mechanism to interact with other blockchains. These limitations have led to a fractured ecosystem, where each blockchain is closed off from the others by default. That means assets native to one chain are not accessible on another, and some services can't be leveraged on particular chains altogether.
 
 Blockchain developers are now aiming to solve these interoperability problems to create a unified ecosystem. In this new cross-chain ecosystem, people can move beyond being users of individual blockchains and take advantage of Web3 on a broader scale.
 

src/dapps/2_crossChainInteroperability.md

@@ -15,11 +15,11 @@ There are some other essential things you should know about bridges before going
 - Bridges are all mutually incompatible with each other. Using multiple bridges just makes 'double wrapped' tokens.
 - If tokens have become double wrapped after traversing multiple bridges or blockchains, there can be a complex unwrapping process to get back to the original token.
 
-This explains how the ecosystem arrived at its current state -- CEXs are a solution to siloed blockchains, DEXs are a simple response to CEXs, and DEXs have created a demand for bridges. Each solution in this timeline is an ad-hoc patch to the previous problem, and the current landscape of fractured liquidity, double wrapped tokens, isolated userbases and wallet incompatibilities is the result.
+This explains how the ecosystem arrived at its current state -- CEXs are a solution to siloed blockchains, DEXs are a simple response to CEXs, and DEXs have created a demand for bridges. Each solution in this timeline is an ad-hoc patch to the previous problem, and the current landscape of fractured liquidity, double wrapped tokens, isolated user bases and wallet incompatibilities is the result.
 
 Adding to this complexity are blockchains moving toward being general-purpose computing platforms. As such, interoperability will require data structures that are more complex than tokens and operations that are more sophisticated than transfers.
 
-More ad-hoc solutions would only be short-term fixes for long-term problems, so it's critical to design new primatives and core infrastructure that will allow the next generation of decentralized applications to move beyond these lingering limitations.
+More ad-hoc solutions would only be short-term fixes for long-term problems, so it's critical to design new primitives and core infrastructure that will allow the next generation of decentralized applications to move beyond these lingering limitations.
 
 This is why Wormhole exists. Wormhole proposes a new way of developing applications which leverages the strengths of each blockchain while mitigating the problems of the current ecosystem.
 

src/dapps/architecture/3_protocolDesign.md

@@ -1,6 +1,6 @@
 # Protocol Design
 
-They key feature of Wormhole is bringing message passing to the world of blockchain, so it's worthwhile to take some inspiration from other areas of software development that are based on similar principles.
+The key feature of Wormhole is bringing message passing to the world of blockchain, so it's worthwhile to take some inspiration from other areas of software development that are based on similar principles.
 
 Much of the traditional web stack is based on distributed systems that rely on message passing to create interfaces and boundaries for disparate systems to work together. We can think of xDapps as web3 distributed systems founded on similar paradigms.
 
@@ -28,6 +28,6 @@ When dealing with addresses inside your messages, it's recommended to always con
 
 ### Trusted Contract Network
 
-Typically, the first check performed when receiving a message is to validate that it originates from a trusted source. If your protocol has smart contracts deployed to multipe chains, it will be important for your contracts to know which other contracts are 'in network' for your protocol. 
+Typically, the first check performed when receiving a message is to validate that it originates from a trusted source. If your protocol has smart contracts deployed to multiple chains, it will be important for your contracts to know which other contracts are 'in network' for your protocol. 
 
 Generally, this list of trusted contracts is stored in the state of each contract individually. Updating the trusted contracts is tied into the governance mechanism of the protocol.

src/dapps/architecture/4_topology.md

@@ -22,7 +22,7 @@ You can think of the data flow across a xDapp with a Ultra-light Client as follo
 
 - Very little added smart contract risk.
 - Simple to develop.
-- Easiest way to get heterogenous ecosystem support.
+- Easiest way to get heterogeneous ecosystem support.
 
 **_Disadvantages:_**
 

src/development/portal/evm/attestingToken.md

@@ -46,7 +46,7 @@ After the wrapped token is created, you can get the new wrapped token address by
 await targetTokenBridge.createWrapped(Buffer.from(vaaBytes.vaaBytes, "base64"), {
     gasLimit: 2000000
 });
-await new Promise((r) => setTimeout(r, 5000)); //Time out to let block propogate
+await new Promise((r) => setTimeout(r, 5000)); //Time out to let block propagate
 const wrappedTokenAddress = await targetTokenBridge.wrappedAsset(
     network.wormholeChainId,
     Buffer.from(

src/reference/glossary.md

@@ -1,6 +1,6 @@
 # Glossary
 
-_Disclaimer: In some instances, Wormhole uses general terms for decentralized, cross-chain elements as branded verbiage. In most casese, the definition of the general term does not differ from Wormhole's definition though Wormhole's definitions may be more narrow than general interpretations._
+_Disclaimer: In some instances, Wormhole uses general terms for decentralized, cross-chain elements as branded verbiage. In most cases, the definition of the general term does not differ from Wormhole's definition though Wormhole's definitions may be more narrow than general interpretations._
 
 **Guardian** - One of the 19 validators in the Guardian Network that contributes to the VAA multisig.
 
@@ -18,4 +18,4 @@ _Disclaimer: In some instances, Wormhole uses general terms for decentralized, c
 
 [**xDapp**](../dapps/4_whatIsanXdapp.md) - Decentralized application that enables users to create and/or use xData.
 
-[**xData**](../dapps/3_xdataxassets.md) - Data that exists in a layer outside of Layer 1 blockchains, which is accessible by all chains.
+[**xData**](../dapps/3_xdataxassets.md) - Data that exists in a layer outside of Layer 1 blockchains, which is accessible by all chains.

src/technical/env/tilt.md

@@ -22,7 +22,7 @@ Tilt is generally a good starting point for most developers. Here's a succinct l
 
 **Pros**
 
-- Out-of-the-box support for the many components needed to develop across the heterogenous blockchain spaces.
+- Out-of-the-box support for the many components needed to develop across the heterogeneous blockchain spaces.
 - Consistent development environment, where contracts deploy deterministically and everything is already linked up.
 - Ability to easily enable/disable components as needed.
 - Regularly updated as new components join the Wormhole ecosystem.

src/technical/evm/relayer.md

@@ -52,7 +52,7 @@ The WormholeRelayer contract does not directly send messages. Rather, the Wormho
 
 This allows you to easily combine basic messaging along with other modules of the Wormhole ecosystem, such as the Token Bridge or NFT modules. It even allows for other Wormhole integrators to easily compose with your application! (See [best practices](./bestPractices.md) for more info.)
 
-We'll discuss more complex useage later. For now let's just cover how to send a "Hello World" message. The basic mechanism to request delivery of your VAAs is to call the `send` function on the IWormholeRelayer interface. Here's its basic usage:
+We'll discuss more complex usage later. For now let's just cover how to send a "Hello World" message. The basic mechanism to request delivery of your VAAs is to call the `send` function on the IWormholeRelayer interface. Here's its basic usage:
 
 ```solidity
 function sendHelloWorldMessage() public payable {
@@ -265,7 +265,7 @@ Contrary to `maxTransactionFee`, when specifying a `receiverValue` the RelayProv
 
 ## Forwarding
 
-So far we've discussed how to perform a simple delivery from chain A to chain B. However, a fairly common scenario that you may encounter is that you may want to perform a multi-hop delivery from chain A to B to C, or to round-trip a delivery back to the source chain. Forwarding is a feature specifically designed to suit these usecases.
+So far we've discussed how to perform a simple delivery from chain A to chain B. However, a fairly common scenario that you may encounter is that you may want to perform a multi-hop delivery from chain A to B to C, or to round-trip a delivery back to the source chain. Forwarding is a feature specifically designed to suit these use cases.
 
 Forwarding is quite similar to a normal 'send' action, however it has a couple special traits.
 

src/technical/typescript/attestingToken.md

@@ -1,6 +1,6 @@
 # Registering Tokens
 
-Registering tokens with the token bridge can be done from any supported blockchain, and only needs to be done once - globally - per token. This is is typically done via a UI (such as [Portal](portalbridge.com)) rather than done on-chain.
+Registering tokens with the token bridge can be done from any supported blockchain, and only needs to be done once - globally - per token. This is typically done via a UI (such as [Portal](portalbridge.com)) rather than done on-chain.
 
 If you need to do it programmatically, you can also use the Typescript SDK to attest a token.
 

src/technical/typescript/using-relayer.md

@@ -1,6 +1,6 @@
 # Using Relayers
 
-In this example, we’ll utilize the token bridge relayer network to complete a token transfer from Polygon and to Oasis.
+In this example, we’ll utilize the token bridge relayer network to complete a token transfer from Polygon to Oasis.
 
 This code is written for a browser environment. If you're working in node, consider using node-fetch:
 

src/wormhole/5_guardianNetwork.md

@@ -38,11 +38,11 @@ With our perspective on Decentralization laid out, the remaining elements fall i
 
 The Guardian Network is robust and trustworthy by itself, so there's no need for components like the relayer to contribute to the security model. That makes Wormhole able to have simple components that are very good at the one thing they do. That way, Guardians only need to verify on-chain activity and produce VAAs while Relayers only need to interact with blockchains and deliver messages.
 
-The signing scheme of the VAAs can be changed without affecting downstream users, and multiple relay mechanisms can exist independently. xAssets can be implemented purely at the application layer and xDapps can utilize whatever components suit them.
+The signing scheme of the VAAs can be changed without affecting downstream users, and multiple relay mechanisms can exist independently. xAssets can be implemented purely at the application layer and xDapps can utilize whatever components suits them.
 
 ## Chain Agnosticism
 
-Today, Wormhole supports a wider range of ecosystems than any other interoperability protocol because it uses simple tech (t-schnorr signatures), an adaptable, heterogenous relayer model, and a robust validator network.
+Today, Wormhole supports a wider range of ecosystems than any other interoperability protocol because it uses simple tech (t-schnorr signatures), an adaptable, heterogeneous relayer model, and a robust validator network.
 
 Wormhole can expand to new ecosystems as quickly as a Core Contract can be developed for the smart contract runtime. Relayers don't need to be factored into the security model--they just need to be able to upload messages to the blockchain. The Guardians are able to observe every transaction on every chain, without taking shortcuts.
 

src/wormhole/6_relayers.md

@@ -18,7 +18,7 @@ In Wormhole, relayers are neither trusted nor privileged. This means relayers **
 
 From this perspective, relayers are just delivery trucks that deliver VAAs to their destination, and have no capacity to tamper with the delivery outcome. VAAs either get delivered or don't, which makes relayers analogous to the off-chain 'crank turners' of traditional Dapps.
 
-As a result, Wormhole is able to facilitate a variety of heterogeneous relaying mechanisms, and the developer is able to choose whatever best suit their needs.
+As a result, Wormhole is able to facilitate a variety of heterogeneous relaying mechanisms, and the developer is able to choose whatever best suits their needs.
 
 Next, we'll go over a few of the most common relaying strategies.
 

src/wormhole/security.md

@@ -7,7 +7,7 @@ Let's take a moment to pause and spell out the most important security elements
 
 **What are the Core Security Assumptions of Wormhole?**
 
-- Wormhole's core security primative is its signed messages (signed VAAs).
+- Wormhole's core security primitive is its signed messages (signed VAAs).
 
 - The Guardian network is currently secured by a collection of 19 of the world's top validator companies, [listed here](https://wormhole.com/network/).
 - Guardians produce signed state attestations (signed VAAs), when requested by a Core Contract integrator.
@@ -61,7 +61,7 @@ Wormhole has one of the largest bug bounty programs in all of software developme
 
 Wormhole hosts two bug bounty programs:
 
-- An [Immunifi](https://immunefi.com/) program,
+- An [Immunefi](https://immunefi.com/) program,
 - As well as a [self-hosted program](https://wormhole.com/bounty/)
 
 Both platforms have a top payout of **2.5 million dollars**.
@@ -99,7 +99,7 @@ The Governance system is fully open source in the core repository. Here are some
 
 ## Monitoring
 
-A key element of Wormhole's defense-in-depth strategy is that each Guardian is a highly-competent validator company with their own in-house processes for running, monitoring, and securing blockchain operations. This heterogenous approach to monitoring increases the likelihood that fraudulent activity is detected and reduces the number of single failure points in the system.
+A key element of Wormhole's defense-in-depth strategy is that each Guardian is a highly-competent validator company with their own in-house processes for running, monitoring, and securing blockchain operations. This heterogeneous approach to monitoring increases the likelihood that fraudulent activity is detected and reduces the number of single failure points in the system.
 
 Guardians are not just running Wormhole validators, they're running validators for **every blockchain inside of Wormhole as well**, which allows them to perform monitoring **holistically across decentralized computing**, rather than just at a few single points.