Book improvements

src/dex/architecture.md

@@ -33,7 +33,7 @@ flowchart LR
     DestContract -.-> |indexes| GraphQL
 ```
 
-We will focus on how to submit orders to `Nexus`, call the Union solidity API, and track order fullfilment. Finally we shall implement a `Voyager` plugin to
+We will focus on how to submit orders to `Nexus`, call the Union solidity API, and track order fulfillment. Finally we shall implement a `Voyager` plugin to
 specifically solve for our protocol.
 
 ## Requirements

src/dex/overview.md

@@ -7,7 +7,7 @@ In this project, we will implement the basics of a multichain decentralized exch
 Our application will have the following functionality:
 
 - Swaps: choose assets.
-- Bridge: choose destination chain.
+- Bridge: choose the destination chain.
 - History: track historic trades
 
 We will focus on implementing the logic only. Frontend, design and UX will not be covered (although we'd gladly accept PRs to expand the guide).

src/dex/sdk.md

@@ -4,7 +4,7 @@ Even though UI and design are out of scope for this guide, we will still go thro
 
 ## Setup
 
-For our Javacript side logic, we will extend our flake.nix with the right tools:
+For our JavaScript side logic, we will extend our flake.nix with the right tools:
 
 ```nix
 {{ #shiftinclude  auto:../../projects/nexus/flake.nix:sdk-flake-nix }}

src/dex/swaps.md

@@ -122,7 +122,7 @@ Right now our code relies on the fact that the relayer is paid by the price of t
 
 ### Supported Assets
 
-Nexus will now create orders for any asset, which means that we might receive invalid orders which will always time out. Limiting the assets that we accept will prevent these errors from occuring.
+Nexus will now create orders for any asset, which means that we might receive invalid orders which will always time out. Limiting the assets that we accept will prevent these errors from occurring.
 
 ### Local Swaps
 

src/dispatching-asset-transfer.md

@@ -242,4 +242,4 @@ This should now return the amount sent in the first `FungibleAssetOrder`.
 
 ## Summary
 
-This was a hands-on way to introduce you to multichain programming. We have ommitted the implementation details of many of the individual steps. You have now experienced the transfer flow that a regular user experiences when interacting through UIs. In the next chapter, we will go deeper into what each trace meant. Later we will write a simple solver, and show orders are filled.
+This was a hands-on way to introduce you to multichain programming. We have omitted the implementation details of many of the individual steps. You have now experienced the transfer flow that a regular user experiences when interacting through UIs. In the next chapter, we will go deeper into what each trace meant. Later we will write a simple solver, and show orders are filled.

src/getting-started/apple/apple.md

@@ -1,8 +1,8 @@
 # Apple
 
-Most developers building on Union use macbooks as their main development machine, in combination with lightweight \*nix VMs.
+Most developers building on Union use MacBooks as their main development machine, in combination with lightweight \*nix VMs.
 
-When locally developing on macbooks, there's a few things to keep in mind:
+When locally developing on MacBooks, there's a few things to keep in mind:
 
 - Docker does not have first class support. We recommend [orbstack](https://orbstack.dev/) and our [guide](./orbstack.md).
-- Some applications need to be cross-compiled. For all Union-related services, we provide cross-compiled binaries. However other projects may not be as widely support.
+- Some applications need to be cross-compiled. For all Union-related services, we provide cross-compiled binaries. However other projects may not be as widely supported.

src/light-clients/inclusion-proofs.md

@@ -38,7 +38,7 @@ The root hash uniquely represents the entire dataset. If any piece of data in th
 def prove(state_root, proof, V) -> Boolean
 ```
 
-For Merkle trees specifically, we construct Merkle Inclusion proofs. Constructing the proof is relatively compute intensive and requires access to the full state and history, so only archive nodes are capable of doing so.
+For Merkle trees specifically, we construct Merkle Inclusion proofs. Constructing the proof is relatively computationally intensive and requires access to the full state and history, so only archive nodes are capable of doing so.
 
 ## Inclusion Proofs
 

src/union/channels.md

@@ -37,7 +37,7 @@ The channel handshake ensures both applications:
 
 Multiple channels can exist over a single connection, each serving different applications. For example, a token transfer application and a governance application could each have their own channel while sharing the underlying secure connection. In general, Union multiplexes traffic over connections and only maintains one connection per chain, while operating many different channels.
 
-## Channel Usecases
+## Channel Use Cases
 
 Whenever a protocol has a structured message format, it should consider using a specific channel. This is useful for indexers, which use `channel.version` to read packets for further analysis.
 
@@ -75,7 +75,7 @@ graph TB
     Chain3 --- B4[Token Bridge] & B5[NFT Bridge] & B6[Governance]
 ```
 
-In legacy channel configurations, there would be 3 individual channels. Multiplexing offers key advantes:
+In legacy channel configurations, there would be 3 individual channels. Multiplexing offers key advantages:
 
 - Applications do not need to relay their own channels.
 - Smart contract developers can leverage enshrined smart contracts.

src/union/clients.md

@@ -13,8 +13,8 @@ Every IBC client must provide:
 
 However, the implementation details can vary depending on the execution environment (EVM or Move for example).
 
-We usually refer to both the code and to the instatiation as a client. The best way to grok this, is to see a client
-as both the ERC20 code implementation, and an actual ERC20 coin. There can be many clients on a chain, and new clients can be trustlessly instatiated after the code has been uploaded.
+We usually refer to both the code and to the instantiation as a client. The best way to grok this, is to see a client
+as both the ERC20 code implementation, and an actual ERC20 coin. There can be many clients on a chain, and new clients can be trustlessly instantiated after the code has been uploaded.
 
 ### State Tracking
 

src/union/connections.md

@@ -33,7 +33,7 @@ This connection effectively acts as a socket to read and write bytes between the
 
 ## Multiple Connections
 
-Usually the relation between chains and connections is one-on-one, meaning that there only exists one connection between two chains. There is nothing preventing multiple from existing however. You will probably see some duplicates for testing reasons: deploying connections while verifiying the actual production one will work.
+Usually the relation between chains and connections is one-on-one, meaning that there only exists one connection between two chains. There is nothing preventing multiple from existing however. You will probably see some duplicates for testing reasons: deploying connections while verifying the actual production one will work.
 
 <div class="tab">
   <button class="tablinks" onclick="openTab(event, 'Command')">Fetch Connections</button>

src/union/open-filling.md

@@ -10,13 +10,13 @@ Traditional bridge protocols typically handle transfers through a single mechani
 
 Each model handles one token type at a time, requiring multiple separate transfers for different assets, and quite often requiring users to switch between various bridges.
 
-One step forward in making the bridge model more flexible, is to separate the relaying of information from the actual fullfilment of an order. The bridge protocol focusses on providing the initial data and relaying the acknowledgement, while different implementations can exist to actually provide the assets. We refer to this model as open filling.
+One step forward in making the bridge model more flexible, is to separate the relaying of information from the actual fulfillment of an order. The bridge protocol focuses on providing the initial data and relaying the acknowledgement, while different implementations can exist to actually provide the assets. We refer to this model as open filling.
 
 We shall see that open filling has advantages in flexibility and can make better use of local optimizations. On some chains, liquidity pools may be abundant, while on others, the solver market is more mature. Open filling allows bridges to adjust to these market realities.
 
 ## Open Filling
 
-Union introduces "open filling" where a the assets in a transfer can be provided in various ways, while still guaranteeing the atomic execution of the packet:
+Union introduces "open filling" where the assets in a transfer can be provided in various ways, while still guaranteeing the atomic execution of the packet:
 
 1. A single transfer can include multiple different tokens
 1. Each token can use its own fill mechanism

src/union/overview.md

@@ -8,6 +8,6 @@ Often in various protocols, we talk about message sending between chains. These
 
 This means that cross-chain communication requires not just moving data, but also proving that the data came from a valid source and was properly authorized. The relayers that facilitate this communication serve a role similar to routers in internet infrastructure, but with the additional responsibility of providing cryptographic proofs and handling consensus verification.
 
-We will go through each layer of Union's protocol and explain how packet semantics, cryptographic verification and guaranteed delivery is implemented. We shall see how (light)clients, connections, channels and packets relate to eachother and inspect the real-life usage of the core general-message passing protocol in asset transfers.
+We will go through each layer of Union's protocol and explain how packet semantics, cryptographic verification and guaranteed delivery is implemented. We shall see how (light)clients, connections, channels and packets relate to each other and inspect the real-life usage of the core general-message passing protocol in asset transfers.
 
 The next sections are heavy on theoretical knowledge, after which we will continue to build a dApp which leverages Union to interact with Bitcoin derivatives.

src/zk/intro.md

@@ -8,7 +8,7 @@ Recall how a light client verifies that a block is canonical. In the case of Eth
 {{ #shiftinclude  auto:../snippets/bls_aggregate.py }}
 ```
 
-For other chains, pre-aggregation might not occur. For example, Tendermint simply has each validator signature (and vote) appended in the block. This means that to verify if the block is canonical, we have to perform a signature verification for each validator individually. Here is a pseudo-Python Tendermint block verifier (it doesn't handle voting correctly and misses some components).
+For other chains, pre-aggregation might not occur. For example, Tendermint simply has each validator's signature (and vote) appended in the block. This means that to verify if the block is canonical, we have to perform a signature verification for each validator individually. Here is a pseudo-Python Tendermint block verifier (it doesn't handle voting correctly and misses some components).
 
 ```python
 {{ #shiftinclude  auto:../snippets/verify_tendermint_votes.py }}