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/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
 
@@ -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.
@@ -60,4 +60,4 @@ Over time, the Guardian Set can be expanded beyond 19 with the use of threshold
 
 ---
 
-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.