fix a bunch of typos

src/development/messages/registration/overview.md

@@ -2,6 +2,6 @@
 
 This is not strictly required, but when writing xDapps, you want to listen for messages from *specific* apps on other chains, otherwise attacks could create fake applications that emit messages that *look* like what we expect, but have fake payloads. 
 
-To do this, we register the sending contract's addresses with the receving contracts. Because each VAA has the contract address asked the core bridge to *emit* the VAA, we call the sending contracts *emitters*. Also, the emitters you're listening too, *do not* need to be your own contracts. You might want to listen to the emits of a different xDapp, in which case you'd register it's address in your code. 
+To do this, we register the sending contract's addresses with the receiving contracts. Because each VAA has the contract address asked the core bridge to *emit* the VAA, we call the sending contracts *emitters*. Also, the emitters you're listening too, *do not* need to be your own contracts. You might want to listen to the emits of a different xDapp, in which case you'd register it's address in your code. 
 
-Then, when receving messages, we can check the VAA being submitted, and make sure that the VAA being submitted came from one of the contracts we were expecting and *from the chain* we were expecting.
+Then, when receiving messages, we can check the VAA being submitted, and make sure that the VAA being submitted came from one of the contracts we were expecting and *from the chain* we were expecting.

src/development/messages/sending/evm.md

@@ -27,9 +27,9 @@ import "./Structs.sol";
 
 ```
 
-Now, let's create a new contract in our src/ folder `Messenger.sol`. In this contract, we also create a uint32 nonce. You can think of this nonce like a message id, it's just a number that let's the receing contract know if it's already processed a message. 
+Now, let's create a new contract in our src/ folder `Messenger.sol`. In this contract, we also create a uint32 nonce. You can think of this nonce like a message id, it's just a number that let's the receiving contract know if it's already processed a message. 
 
-Also we'll set the consistency level here to 1, because we're just testing and want the Gaurdians to sign this VAA as soon as they see it, but if we were deploying to production, we might want to match this level to the deploy'd chain's finality gaurantees.
+Also we'll set the consistency level here to 1, because we're just testing and want the Guardians to sign this VAA as soon as they see it, but if we were deploying to production, we might want to match this level to the deployed chain's finality guarantees.
 
 ```solidity
 
@@ -40,7 +40,7 @@ import "./Wormhole/IWormhole.sol";
 
 contract Messenger {
     //This is the Tilt Devnet address constant. 
-    //Replace this address with revelant testnet or mainnet address of the chain you're deploying too.
+    //Replace this address with relevant testnet or mainnet address of the chain you're deploying too.
     address private wormhole_core_bridge_address = address(0xC89Ce4735882C9F0f0FE26686c53074E09B0D550);
 
     IWormhole core_bridge = IWormhole(wormhole_core_bridge_address);
@@ -57,4 +57,4 @@ contract Messenger {
 }
 
 
-```
+```

src/development/messages/sending/overview.md

@@ -5,8 +5,8 @@ While the specific code varies chain by chain, the basic flow of sending a messa
 To emit a VAA requires three pieces of information:
 
 1. Nonce (u32)
-    - The nonce is a random number assigned to each message. This allows the receving contract a way to make sure it doesn't double process messages. 
+    - The nonce is a random number assigned to each message. This allows the receiving contract a way to make sure it doesn't double process messages.
 2. Consistency (u8)
-    - This is the number of blocks for Gaurdians to wait before they sign the message. Higher consistencies mean more security against blockchain reorgs. For example, if this is set too low, and the block you're emitting from reorgs, then it's possible that even though the message was emitted and signed by the Gaurdians and processed on the receving chain, no record of it exists on the emitting chain. If you were sending tokens across, this would allow for double spend attacks. 
+    - This is the number of blocks for Guardians to wait before they sign the message. Higher consistencies mean more security against blockchain reorgs. For example, if this is set too low, and the block you're emitting from reorgs, then it's possible that even though the message was emitted and signed by the Guardians and processed on the receiving chain, no record of it exists on the emitting chain. If you were sending tokens across, this would allow for double spend attacks. 
 3. Payload (bytes[])
     - This is a payload of raw bytes that you want to emit. It's up to the receiving contract to know how to parse it.

src/development/scaffold/overview.md

@@ -2,7 +2,7 @@
 
 To help you get started with cross chain development, we've provided a template project in `projects/xdapp-starter`. All the sample projects will be made using this template, so check them out if you want to get a feel for how the various modules interact with each other.
 
-The template uses npm workspaces to setup a main project with subdirectories for each chain you want to interact with. This allows you to initalize each subdirectory using whatever scaffolding tool you want for each individual chain, and orchestration code in a common directory. 
+The template uses npm workspaces to setup a main project with subdirectories for each chain you want to interact with. This allows you to initialize each subdirectory using whatever scaffolding tool you want for each individual chain, and orchestration code in a common directory. 
 
 Let's break down what's in the `xdapp-starter` project:
 
@@ -18,4 +18,4 @@ They all take in a context object that's made up of the
 This file parses command line args and filters calls to chain management handlers. 
 
 ### xdapp.config.json
-The config file contains all the information about the network rpc nodes, accounts, and other constants used to communicate with contracts deployed to the selected chains.
+The config file contains all the information about the network rpc nodes, accounts, and other constants used to communicate with contracts deployed to the selected chains.

src/development/tilt/linux.md

@@ -1,7 +1,7 @@
 # Linux Devnet Setup
 
 ### Experimental Setup Script
-There's an experimental one command setup script that should install dependencies for you on Linux and configure everything properly. This is only reccomended if you're running headless Linux and unable to use Docker Desktop, as with Docker Desktop you don't need `minikube` and can just enable Kubernetes from Docker.
+There's an experimental one command setup script that should install dependencies for you on Linux and configure everything properly. This is only recommended if you're running headless Linux and unable to use Docker Desktop, as with Docker Desktop you don't need `minikube` and can just enable Kubernetes from Docker.
 
 ```sh
 curl $URL | sh install_linux.sh
@@ -18,7 +18,7 @@ rm -rf /usr/local/go && tar -C /usr/local -xzf go1.18.1.linux-amd64.tar.gz
 ```
 
 ### 2. Install Docker
-If you're using Linxu with a window manager, consider getting Docker Desktop instead of the following command. It comes with Kubernetes built in and you won't need to download `minikube`. It's reccomended to have atleast 4 CPUs and 16GB RAM dedicated to Docker. 
+If you're using Linux with a window manager, consider getting Docker Desktop instead of the following command. It comes with Kubernetes built in and you won't need to download `minikube`. It's recommended to have at least 4 CPUs and 16GB RAM dedicated to Docker. 
 
 Also make sure that you set up docker as a NON ROOT USER! 
 
@@ -65,4 +65,4 @@ tilt up --host=0.0.0.0 -- --webHost=0.0.0.0
 
 You can now access the Tilt UI at either your `localhost:10350` or `vm_external_ip:10350`. 
 
-If the VM's external IP doesn't work, check firewall and port settings to make sure your VM allows incoming traffic. 
+If the VM's external IP doesn't work, check firewall and port settings to make sure your VM allows incoming traffic.

src/development/tilt/mac.md

@@ -1,6 +1,6 @@
-# MacOS Setup
+# macOS Setup
 
-## Prerequistes
+## Prerequisites
 You'll need to have `homebrew` on your system if you don't already. You can grab it with:
 ```sh
 /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
@@ -35,4 +35,4 @@ tilt up
 ```
 
 You'll be able to access the Tilt UI at 
-`localhost:10350`
+`localhost:10350`

src/development/tilt/overview.md

@@ -4,7 +4,7 @@ For a quicker development cycle, specially when developing your own blockchain p
 
 Tilt is a kubernetes and docker orchestration tool that will spin up all the Wormhole supported chains in containers, alongside a Guardian node that will observe and store VAAs. 
 
-This devnet environment can be setup on your computer or in a Linux VM that has atleast 4 CPU cores and 16GB of RAM. 
+This devnet environment can be set up on your computer or in a Linux VM that has at least 4 CPU cores and 16GB of RAM.
 
 If you do decide to host the devnet in a remote VM, remember to pass in the host and webHost flags during the tilt up step and allow incoming traffic on your VM to be able to access the various RPC endpoints on the Pods.
 
@@ -14,7 +14,7 @@ tilt up --host=0.0.0.0 -- --webHost=0.0.0.0
 
 While the exact commands for each environment might differ, the basic setup process for tilt is the following:
 
-1. Insall Go
+1. Install Go
 2. Install Docker Desktop (Or Docker CE)    
     a. Install Minikube if Docker CE
 3. Install Tilt
@@ -26,10 +26,10 @@ While the exact commands for each environment might differ, the basic setup proc
 For all chains that support EVM the smart contract development environment is effectively the same. For changes in gas costs and transaction times, consider testing contract logic on devnet and then using testnet environments to get chain specific answers. 
 
 ### Solana is taking forever!
-Unforetunely, due to Solana's architecture, it often takes 25-40min to build the Solana pod. Consider increasing CPU cores assigned to devnet for a faster build.
+Unfortunately, due to Solana's architecture, it often takes 25-40min to build the Solana pod. Consider increasing CPU cores assigned to devnet for a faster build.
 
 ###  Solana program deploy doesn't work
-Kubernetes doesn't currently allow port forwarding for UDP ports, which is what Solana uses for `solana program deploy`. Instead, we reccomend using [Solana Deployer](https://github.com/acheroncrypto/solana-deployer). Not only does this deploy programs over regular RPC thus bypassing UDP port requirements, it's also much faster than `solana program deploy`.
+Kubernetes doesn't currently allow port forwarding for UDP ports, which is what Solana uses for `solana program deploy`. Instead, we recommend using [Solana Deployer](https://github.com/acheroncrypto/solana-deployer). Not only does this deploy programs over regular RPC thus bypassing UDP port requirements, it's also much faster than `solana program deploy`.
 
 ### Reset state for a pod
 If you want to quickly iterate and don't want to bring tilt down and back up, you can reset state for a pod by clicking the 🔄 button next to the pod name in Tilt UI.

src/introduction/introduction.md

@@ -2,10 +2,10 @@
 
 Welcome to the xDapp Book and beginning your journey to be a cross-chain developer. As crypto ecosystems mature, more and more applications will need to interact with programs outside the infrastructure they are deployed on. In Web2 we see this every day, as infrastructure like Azure, GCP, and AWS is abstracted away from the everyday user and applications can freely talk to each other over HTTP.
 
-For blockchain applications to unlock their true potential, they too must be able to talk to applications on various infrastructure using a common language. These cross chain applications (xDapps) give rise to cross chain data (xData) and cross chain assets (xAssets). With these powerful primitives, blockchain applications can deliver on thier promise of interoperability and composability.  
+For blockchain applications to unlock their true potential, they too must be able to talk to applications on various infrastructure using a common language. These cross chain applications (xDapps) give rise to cross chain data (xData) and cross chain assets (xAssets). With these powerful primitives, blockchain applications can deliver on their promise of interoperability and composability.  
 
 Ready to step *into the wormhole*?
 
 ---
-Check out the [github respoitory](https://www.github.com/certusone/xdapp-book) of these docs to find the accompaning code in the projects/ directory. 
+Check out the [github repository](https://www.github.com/certusone/xdapp-book) of these docs to find the accompanying code in the projects/ directory.