diff --git a/src/dex/architecture.md b/src/dex/architecture.md index 6b837f3..dc15e15 100644 --- a/src/dex/architecture.md +++ b/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 diff --git a/src/dex/overview.md b/src/dex/overview.md index 3b4be87..3d810ac 100644 --- a/src/dex/overview.md +++ b/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). diff --git a/src/dex/sdk.md b/src/dex/sdk.md index 2214665..4670381 100644 --- a/src/dex/sdk.md +++ b/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 }} diff --git a/src/dex/swaps.md b/src/dex/swaps.md index 330e4ee..6f31ecd 100644 --- a/src/dex/swaps.md +++ b/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 diff --git a/src/dispatching-asset-transfer.md b/src/dispatching-asset-transfer.md index 46886f5..47a4a72 100644 --- a/src/dispatching-asset-transfer.md +++ b/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. diff --git a/src/getting-started/apple/apple.md b/src/getting-started/apple/apple.md index e62f3ec..1420870 100644 --- a/src/getting-started/apple/apple.md +++ b/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. diff --git a/src/light-clients/inclusion-proofs.md b/src/light-clients/inclusion-proofs.md index d8fe9b1..3b0a613 100644 --- a/src/light-clients/inclusion-proofs.md +++ b/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 diff --git a/src/union/channels.md b/src/union/channels.md index 6e2b58c..b35158c 100644 --- a/src/union/channels.md +++ b/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. diff --git a/src/union/clients.md b/src/union/clients.md index d8dcd67..27b6f54 100644 --- a/src/union/clients.md +++ b/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 diff --git a/src/union/connections.md b/src/union/connections.md index cc1c7a9..ca7a28a 100644 --- a/src/union/connections.md +++ b/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.
diff --git a/src/union/open-filling.md b/src/union/open-filling.md index 03dc69c..5c7b6cd 100644 --- a/src/union/open-filling.md +++ b/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 diff --git a/src/union/overview.md b/src/union/overview.md index e50f8df..1f4d732 100644 --- a/src/union/overview.md +++ b/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. diff --git a/src/zk/intro.md b/src/zk/intro.md index 40548a1..6672c78 100644 --- a/src/zk/intro.md +++ b/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 }}