fixed typos

src/development/messages/receiving/evm.md

@@ -1,4 +1,4 @@
-# Receving Messages on EVM
+# Receiving Messages on EVM
 
 To receive messages in EVM, first we need to implement a function `receiveMsg`. The name of this function is arbitrary, so any function name will work as long as your relayer knows what to call on the application contract when submitting messages. 
 

src/development/messages/receiving/overview.md

@@ -1,6 +1,6 @@
-# Overview of Receving Messages
+# Overview of Receiving Messages
 
-Receving messages requires you (or a relayer) to submit the VAA to your application contract. This contract then calls the Core Bridge on the receving chain to check the message signatures against the stored Guardian set signatures. 
+Receiving messages requires you (or a relayer) to submit the VAA to your application contract. This contract then calls the Core Bridge on the receiving chain to check the message signatures against the stored Guardian set signatures. 
 
 If those checks pass, then the application can see if it's a message that's already been processed by checking its sequence number against a store list of processed message sequence numbers. 
 

src/development/messages/relaying/overview.md

@@ -4,7 +4,7 @@ Relaying Messages can be done one of three ways:
 
 **_Manual Relaying_**
     
-Manual relaying is usally done on the front end.  Manual relaying requires the front end to fetch the VAA it just created and then submit on the target chain. This means the user ends up paying for the gas fee and has to go through the additional step to submit the tx on the target chain. 
+Manual relaying is usually done on the front end.  Manual relaying requires the front end to fetch the VAA it just created and then submit on the target chain. This means the user ends up paying for the gas fee and has to go through the additional step to submit the tx on the target chain. 
 
 **_Protocol-Specific Relayers_**
 

src/technical/evm/coreLayer.md

@@ -1,8 +1,8 @@
 # Core Message Layer
 
-This section will explain how to properly interact with the Wormhome Core Message Layer in an EVM ecosystem.
+This section will explain how to properly interact with the Wormhole Core Message Layer in an EVM ecosystem.
 
-Messages in Wormhole take the form of a Verified Action Approval (VAA) and both terms can be used interchangably. The rest of this section will only use the term VAA.
+Messages in Wormhole take the form of a Verified Action Approval (VAA) and both terms can be used interchangeably. The rest of this section will only use the term VAA.
 
 ## Configuring the Interface
 
@@ -42,7 +42,7 @@ To emit a VAA, always use `publishMessage` which takes in the following argument
 3.  `Payload` (bytes[]): raw bytes to emit
     - It is up to the emitting contract to properly define this arbitrary set of bytes.
 
-`publishMessage` will output a `sequence` (uint64) that is used in conjunction with `emitterChainID` and `emitterAddress` to retrive the generated VAA from the Guardian Network.
+`publishMessage` will output a `sequence` (uint64) that is used in conjunction with `emitterChainID` and `emitterAddress` to retrieve the generated VAA from the Guardian Network.
 
 > How Batch VAAs are generated
 >

src/technical/evm/nftLayer.md

@@ -59,5 +59,5 @@ completeTransfer(VAA);
 <!---
 TODO
 
-additional usecases, most specifically how to grab the origin address of the wrapped NFT
+additional use cases, most specifically how to grab the origin address of the wrapped NFT
 -->

src/technical/evm/tokenLayer.md

@@ -1,6 +1,6 @@
 # Token Bridge
 
-This section will explain how to properly interact with the Wormhome Token Bridge Module in an EVM ecosystem.
+This section will explain how to properly interact with the Wormhole Token Bridge Module in an EVM ecosystem.
 
 ## Configuring the interface
 
@@ -19,7 +19,7 @@ ITokenBridge token_bridge = ITokenBridge(wormhole_token_bridge_address);
 
 Attesting a token from EVM needs to happen once per token as it will not be claimable until so. However, there are no restrictions to reattesting a token; repeat attestations will update the metadata.
 
-It is not advised to attest tokens on-chain for most usecases. To attest a token by an off-chain process, you can either do it by hand through one of the Token Bridge UIs (for example [Portal](https://www.portalbridge.com/#/register)) or using the [Typescript SDK](https://www.npmjs.com/package/@certusone/wormhole-sdk).
+It is not advised to attest tokens on-chain for most use cases. To attest a token by an off-chain process, you can either do it by hand through one of the Token Bridge UIs (for example [Portal](https://www.portalbridge.com/#/register)) or using the [Typescript SDK](https://www.npmjs.com/package/@certusone/wormhole-sdk).
 
 _[Here](../../development/portal/evm/attestingToken.md) is an example of how to attest a token using the Typescript SDK._
 
@@ -98,11 +98,11 @@ contractAddress.approve(token_bridge_address, amt);
 
 2. Transfer the token to create the transfer VAA.
    - This function call will return a `sequence` (uint64) that is used in the VAA retrieval step.
-   - _Note: For the recipient addres, Wormhole addresses are 32 bytes for standardization across the different blockchains within the Wormhole ecosystem._
+   - _Note: For the recipient address, Wormhole addresses are 32 bytes for standardization across the different blockchains within the Wormhole ecosystem._
 
 ```
 // To initiate transfer of normal ERC-20s
-token_bridge.transferTokesWithPayload(tokenAddress, amount, recipientChain, recipient, nonce, payload);
+token_bridge.transferTokensWithPayload(tokenAddress, amount, recipientChain, recipient, nonce, payload);
 
 // To initiate transfer of native currency
 token_bridge.wrapAndTransferETHWithPayload(recipientChain, recipient, nonce, payload);

src/technical/typescript/attestingToken.md

@@ -4,7 +4,7 @@ Registering tokens with the token bridge can be done from any supported blockcha
 
 If you need to do it programmatically, you can also use the Typescript SDK to attest a token.
 
-There are three steps to registerring a token:
+There are three steps to registering a token:
 
 1. Create an AttestMeta VAA by calling `attest()` function from the SDK and passing in the Token Bridge address, and the address of the Token we want to attest.
 
@@ -55,7 +55,7 @@ await targetTokenBridge.createWrapped(
     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")

src/technical/typescript/tokenTransfer.md

@@ -9,7 +9,7 @@ There are four steps to transferring a token:
 1. If not already done, complete a standard ERC-20 token approval prior to performing a bridge action if you're in the EVM ecosystem.
 
 ```js
-// Here we are approving and transfering 50 tokens. The ERC20 token we are transfering has 18 decimal places.
+// Here we are approving and transferring 50 tokens. The ERC20 token we are transferring has 18 decimal places.
 const bridgeAmt = ethers.utils.parseUnits("50", "18");
 
 await treasury.approveTokenBridge(bridgeAmt, {

src/wormhole/2_architectureOverview.md

@@ -18,7 +18,7 @@ Wormhole is a complex ecosystem with several noteworthy components. Before we go
 
   - **Gas Oracle** - _in development\*_ - Oracle for recommended fair gas prices across the ecosystem.
 
-  - **Worm Router Contracts** - _in development\*_ - Contracts that allow developers to make their Dapp an xDapp that users on any Wormhole supported chain can interac with purely through clientside code.
+  - **Worm Router Contracts** - _in development\*_ - Contracts that allow developers to make their Dapp an xDapp that users on any Wormhole supported chain can interact with purely through client-side code.
 
 ### Off-Chain Components
 

src/wormhole/3_coreLayerContracts.md

@@ -73,8 +73,8 @@ This multicast-by-default model is integral to the design. Having this multicast
 
 Use cases where the message has an intended recipient or is only meant to be consumed a single time must be handled in logic outside the Core Contract. There are standard practices for accomplishing these features later on in the code examples, and some ecosystem contracts (namely Token Bridge & the Relaying contract) handle this on behalf of downstream consumers.
 
-Lastly, because the VAA creation is separate from relaying, there is _no additional cost_ to the multicast model when a single chain is being targetted. If the data isn't needed on a certain blockchain, don't relay it there, and it won't cost anything.
+Lastly, because the VAA creation is separate from relaying, there is _no additional cost_ to the multicast model when a single chain is being targeted. If the data isn't needed on a certain blockchain, don't relay it there, and it won't cost anything.
 
 ---
 
-In our next section, we'll dive into the technical specfications of the VAA.
+In our next section, we'll dive into the technical specifications of the VAA.

src/wormhole/5_guardianNetwork.md

@@ -7,7 +7,7 @@ To understand not just _how_ the Guardian Network works, but _why_ it works the
 1. **Decentralization** - Control of the network needs to be distributed amongst many parties.
 2. **Modularity** - Disparate parts of the ecosystem such as the oracle, relayer, applications, etc, should be kept as separate and modular as possible so they can be designed, modified and upgraded independently.
 3. **Chain Agnosticism** - Wormhole should be able to support not only EVM, but also chains like Solana, Algorand, Cosmos, and even platforms that haven't been created yet. It also should not have any one chain as a single point of failure.
-4. **Scalablity** - Wormhole should be able to secure a large amount of value immediately and be able to handle the large transaction volume.
+4. **Scalability** - Wormhole should be able to secure a large amount of value immediately and be able to handle the large transaction volume.
 5. **Upgradeability** - As the decentralized computing ecosystem evolves, Wormhole will need to be able to change the implementation of its existing modules without breaking integrators.
 
 Next, let's go into how Wormhole achieves these one at a time.
@@ -56,8 +56,8 @@ However, once all the full nodes are running, the actual computation and network
 
 ## Upgradability
 
-Over time, the Guardian Set can be expanded beyond 19 with the use of threshold signatures. A variety of relaying models will emerge, each with their own strengths and weaknesses. ZKPs can be used on chains where they are well supported. The xDapp ecosystem will grow, and xDapps will become increasingly intermingled with eachother. There are very few APIs in Wormhole, and most items are implementation details from the perspective of an integrator. This creates a clear pathway towards a fully trustlessness interoperability layer which spans the entirety of decentralized computing.
+Over time, the Guardian Set can be expanded beyond 19 with the use of threshold signatures. A variety of relaying models will emerge, each with their own strengths and weaknesses. ZKPs can be used on chains where they are well supported. The xDapp ecosystem will grow, and xDapps will become increasingly intermingled with each other. There are very few APIs in Wormhole, and most items are implementation details from the perspective of an integrator. This creates a clear pathway towards a fully trustlessness interoperability layer which spans the entirety of decentralized computing.
 
 ---
 
-In the next section, we will talk about the role and responsbilities of relayers in the Wormhole ecosystem.
+In the next section, we will talk about the role and responsibilities of relayers in the Wormhole ecosystem.

src/wormhole/6_relayers.md

@@ -16,7 +16,7 @@ In most designs there is a dedicated relaying mechanism which operates inside th
 
 In Wormhole, relayers are neither trusted nor privileged. This means relayers **cannot jeopardize security, only liveness**. Because Wormhole is designed to have a firm trust boundary at the level of the VAA, relayers have exactly the same capabilities as any regular, untrusted blockchain user.
 
-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 analagous to the off-chain 'crank turners' of traditional Dapps.
+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.
 
@@ -77,7 +77,7 @@ _Note: this feature is not yet available in mainnet_
 
 Because relaying is such an integral component to xDapps, Wormhole has built a protocol which allows developers to utilize a decentralized network of untrusted relayers to deliver their messages, removing the specialized relayer as an infrastructure responsibility.
 
-In order to utilize the generic relayer network, developers must request delivery from the Wormhole Relay Ecosystem Contract and must also implement a "receiveRelay" function in their contracts, which will be called by the relayer. Once a delivery has been requested, the VAA is guaranteed to be delivered within a certain timeframe. The specifics of this vary by blockchain and smart contract runtime.
+In order to utilize the generic relayer network, developers must request delivery from the Wormhole Relay Ecosystem Contract and must also implement a "receiveRelay" function in their contracts, which will be called by the relayer. Once a delivery has been requested, the VAA is guaranteed to be delivered within a certain time frame. The specifics of this vary by blockchain and smart contract runtime.
 
 Generic relayers have the following benefits:
 
@@ -90,7 +90,7 @@ And potential downsides:
     - They sometimes have less gas efficiency
     - They may not be supported on all chains
 
-Overall, Generic Relayers simplify both the developer and user experience. They're a great choice if they cover all your usecases.
+Overall, Generic Relayers simplify both the developer and user experience. They're a great choice if they cover all your use cases.
 
 ---