minor typos

src/dapps/architecture/2_ecosystems.md

@@ -29,11 +29,11 @@ Cosmos is a network of blockchains that share a common ecosystem. Cosmos is a ge
 
 ### Algorand
 
-Algorand is a leading blockchain on the state proof front and repesents the bleeding edge of trustlessness. These contracts are written in Python.
+Algorand is a leading blockchain on the state proof front and represents the bleeding edge of trustlessness. These contracts are written in Python.
 
 ### Aptos
 
-Aptos is characterized by its optimisitic approach to computation parallelization to bring increased performance. These contracts are written in Move.
+Aptos is characterized by its optimistic approach to computation parallelization to bring increased performance. These contracts are written in Move.
 
 ### NEAR
 

src/dapps/architecture/3_protocolDesign.md

@@ -6,9 +6,9 @@ Much of the traditional web stack is based on distributed systems that rely on m
 
 ## Protocol First Design
 
-Protocol first design is a design philosophy where you initially lay out your data types, message formats and supported operations into a well-defined protocol. This creates a solid protocol layer which can serve as the foundation for your application. This way, the code instantiating that protocol can be treated as an implementation detail when reasoning about the protocol itself.
+Protocol first design is a design philosophy where you initially lay out your data types, message formats and supported operations into a well-defined protocol. This creates a solid protocol layer that can serve as the foundation for your application. This way, the code instantiating that protocol can be treated as an implementation detail when reasoning about the protocol itself.
 
-At this stage in the design, you should also consider the incentive structures surrounding your protocol. What is the incentive for each party to engage? Are there economic attack vectors in your application which might jeopardize its security? Do certain market conditions result in perverse outcomes? 
+At this stage in the design, you should also consider the incentive structures surrounding your protocol. What is the incentive for each party to engage? Are there economic attack vectors in your application which might jeopardize its security? Do certain market conditions result in undesirable outcomes? 
 
 Depending on your goals, this stage of the process can be as simple as stating "people will want my NFT" or as difficult as designing an entire ecosystem with multiple competing interested parties. 
 
@@ -24,7 +24,7 @@ A Wormhole address is a tuple containing the 2 byte Wormhole chain ID and a 32 b
 
 Because EVM addresses are only 20 bytes in length, to convert this to a Wormhole address, the address is left-padded with zeros until it's length 32. To transmit as this as a single item, the Wormhole chain ID is usually appended to the front, resulting in a 34 byte address.
 
-When dealing with addresses inside your messages, it's recommended to always convert to Wormhole format and transmit in that format. You will regularly encounter addresses in the Wormhole format when interacting with other parts of the ecosystem, and adopting the format in your protocol will enhance your forward compatibility as you add more chains.
+When dealing with addresses inside your messages, it's recommended to always convert to Wormhole format and transmit in that format. You will regularly encounter addresses in the Wormhole format when interacting with other parts of the ecosystem, and adopting the format in your protocol will enhance your future compatibility as you add more chains.
 
 ### Trusted Contract Network
 

src/dapps/architecture/4_topology.md

@@ -34,7 +34,7 @@ You can think of the data flow across a xDapp with a Ultra-light Client as follo
 
 ![Hub and Spoke](../../diagrams/images/hub_and_spoke.PNG "Hub and Spoke")
 
-Hub and Spoke models can somewhat be thought of as the natural evolution of the ultra-light client. There is still a hub contract which handles all transactions, but there is now also a contract deployed to all the remote chains that is capable of performing some trusted computation.
+Hub-and-Spoke models can somewhat be thought of as the natural evolution of the ultra-light client. There is still a hub contract which handles all transactions, but there is now also a contract deployed to all the remote chains that is capable of performing some trusted computation.
 
 You can think of the data flow across a Hub-and-Spoke system as follows:
 
@@ -72,7 +72,7 @@ This is historically the most popular methodology for going cross-chain. It's ve
 **_Disadvantages:_**
 
 - Complexity: there are now quite a few contracts to manage, especially if they are implemented multiple times across different VMs.
-- Data desync: because each blockchain acts independently, each chain will have independent state. This can open up unwanted arbitrage opportunities and other discrepancies.
+- Data desynchronization: because each blockchain acts independently, each chain will have independent state. This can open up unwanted arbitrage opportunities and other discrepancies.
 - Race conditions: In cases where an event is supposed to propagate through the entire system at a fixed time (for example, when closing a governance vote), it can be difficult to synchronize all the blockchains.
 
 ## Distributed

src/dapps/architecture/5_relayers.md

@@ -16,7 +16,7 @@ A few key properties of VAAs:
 
 Relayers are untrusted as an inherent consequence of these properties. Anyone can pick up a VAA and deliver it anywhere, but no one can alter the content of the VAA without invalidating the signatures.
 
-So, when writing your contracts, it's incredibly important to only trust information which is either inside your contract or inside a VAA. If you trust information provided by a relayer, you are opening yourself up to untrusted input attacks.
+So, when writing your contracts, it's incredibly important to only trust information which is either inside your contract or inside a VAA. If you trust information provided by a relayer, you're opening yourself up to untrusted input attacks.
 
 The easiest and most secure way to interact with relayers then is to only accept the VAA as input. If the relayer can't provide any additional args, then there's no way for them to provide untrusted input.
 
@@ -49,7 +49,7 @@ Specialized Relayers are relayers that are purpose-built to relay messages for a
 **_Advantages:_**
 
 - Specialized relayers can perform off-chain untrusted computation.
-- They are highly customizeable and can perform batching, conditional delivery, multi-chain deliveries, etc.
+- They are highly customizable and can perform batching, conditional delivery, multi-chain deliveries, etc.
 - Can home-roll an incentive structure.
 
 **_Disadvantages_**

src/technical/aptos/overview.md

@@ -1,6 +1,6 @@
 # Aptos
 
-Aptos is currently only supported in testnet.
+Aptos is currently only supported in Testnet.
 
 The official Wormhole integration can be found [here](https://github.com/wormhole-foundation/wormhole/tree/aptos/integration).
 

src/technical/env/testnet.md

@@ -1,6 +1,6 @@
 # Testnet
 
-Wormhole testnet is spread across many of the most popular testnet blockchains.
+The Wormhole testnet is spread across many of the most popular testnet blockchains.
 
 ### Is Testnet right for you?
 

src/technical/evm/relayer.md

@@ -160,7 +160,7 @@ Receiver Failures are not a nebulous 'something went wrong' term in the Wormhole
 
 All three of these scenarios should generally be avoidable by the integrator, and thus it is up to integrator to resolve them.
 
-Any other senario which causes a delivery to not be performed should be considered an **outage** by some component of the system, including potentially the blockchains themselves.
+Any other scenario which causes a delivery to not be performed should be considered an **outage** by some component of the system, including potentially the blockchains themselves.
 
 <br/>
 

src/technical/relayer/specializedRelayers.md

@@ -6,4 +6,4 @@ Additionally there's an extensible relayer (called the [Plugin Relayer](https://
 
 <!-- To aid in the development of relayers, a extensible relayer implementation (called the [plugin relayer]()) has been provided in the Wormhole Core Repository.
 
-It's recommended that integrators create their own plugin for the plugin relayer, rather than home-roll a relayer themselves. Using the plugin relayer allows integrators to take advantage of the robust hot-wallet and scheduling built into the relayer's kernel, as well as leveraging plugins which are built by other integrators.  -->
+It's recommended that integrators create their own plugin for the plugin relayer, rather than home-rolling a relayer themselves. Using the plugin relayer allows integrators to take advantage of the robust hot-wallet and scheduling built into the relayer's kernel, as well as leveraging plugins which are built by other integrators.  -->

src/technical/typescript/attestingToken.md

@@ -1,8 +1,8 @@
 # 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 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](https://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.
+If you need to do it programmatically, you can also use the TypeScript SDK to attest a token.
 
 There are three steps to registering a token:
 

src/technical/typescript/cross-ecosystem-transfer.md

@@ -42,7 +42,7 @@ After we have the receipt token account on Solana, it's time to submit the trans
 
 ```ts
 import {
-  trasnferFromEth,
+  transferFromEth,
   parseSequenceFromLogEth,
   getEmitterAddressEth,
   CHAIN_ID_SOLANA,
@@ -60,7 +60,7 @@ const receipt = await transferFromEth(
   recipientAddress
 );
 // Get the sequence number and emitter address required to fetch the signedVAA of our message
-const sequence = parseSequenceFromLogEth(receipt, ETH_BRIDGE_ADDRESS);
+const sequence = parseSequenceFromLogEth(receipt, ETH_TOKEN_BRIDGE_ADDRESS);
 const emitterAddress = getEmitterAddressEth(ETH_TOKEN_BRIDGE_ADDRESS);
 ```
 

src/technical/typescript/using-relayer.md

@@ -30,11 +30,11 @@ Now, set up the two wallets we’ll be sending and receiving from. While we are
 
 ```ts
 const EmeraldWallet = new ethers.Wallet(
-  privatekey_emerald,
+  privatekey_emerald_wallet,
   new ethers.providers.JsonRpcProvider("https://emerald.oasis.dev")
 );
 const PolygonWallet = new ethers.Wallet(
-  privatekey_polygon,
+  privatekey_polygon_wallet,
   new ethers.providers.JsonRpcProvider("https://polygon-rpc.com/")
 );
 ```
@@ -47,7 +47,7 @@ We will also define the transfer amount in this step. The fee schedule will eith
 
 ```ts
 const transferAmount = BigNumber.from("1000000000000000000"); // We are sending 1 MATIC over the wall to Oasis
-const relayerFeeSchedule = await(
+const relayerFeeSchedule = await (
   await fetch(
     "https://raw.githubusercontent.com/certusone/wormhole-relayer-list/main/relayer.json"
   )
@@ -98,7 +98,7 @@ if (relayerFeeSchedule.feeSchedule[CHAIN_ID_OASIS].type == "flat") {
 
   feeWei = (feeUsd / MATIC_PRICE) * 1e18;
 } else if (relayerFeeSchedule.feeSchedule[CHAIN_ID_OASIS].type == "percent") {
-  let feeWei =
+  feeWei =
     (relayerFeeSchedule.feeSchedule[CHAIN_ID_OASIS].feePercent / 100) *
     transferAmount.toNumber();
 }
@@ -166,12 +166,12 @@ Let’s walk through each of the arguments of this function and what they mean.
 Wait 15 min for finality on Polygon and then check to see if it was submitted. If successful, you’ll be able to fetch a base64 encoded vaaBytes. We need this in the next step where we check if the transaction was successfully relayed.
 
 ```ts
-await new Promise((r) => setTimeout(r, 900000)); //15m in seconds
+await new Promise((r) => setTimeout(r, 900000)); // 15m in seconds
 const WORMHOLE_RPC = "https://wormhole-v2-mainnet-api.certus.one";
 let vaaBytes = undefined;
 while (!vaaBytes) {
   try {
-    vaaBytes = await(
+    vaaBytes = await (
       await fetch(
         `${WORMHOLE_RPC}/v1/signed_vaa/${CHAIN_ID_POLYGON}/${emitterAddress}/${sequence}`
       )
@@ -188,7 +188,7 @@ console.log("VAA Bytes: ", vaaBytes);
 In the final step, use the getIsTransferCompletedEth() method to check if the transfer was completed on the Oasis Emerald chain. If it’s not, wait 5 seconds and check again.
 
 ```ts
-setDefaultWasm("node"); //only needed if running in node.js
+setDefaultWasm("node"); // only needed if running in node.js
 const EMERALD_TOKEN_BRIDGE = "0x5848C791e09901b40A9Ef749f2a6735b418d7564";
 let transferCompleted = await getIsTransferCompletedEth(
   EMERALD_TOKEN_BRIDGE,