unionlabs · tudorpintea999 · Dec 13, 2024 · Dec 13, 2024 · Dec 13, 2024 · Dec 13, 2024
diff --git a/docs/src/content/docs/architecture/galois.mdx b/docs/src/content/docs/architecture/galois.mdx
@@ -33,7 +33,7 @@ Galois is built using [Gnark](https://github.com/ConsenSys/gnark), the best-perf
 
 :::note
 
-Depending on validator set drift, Galois may need to generate multiple proofs. This results in $M$ being the last trusted height and $N+1$ being the height to update to.
+Depending on the validator set drift, Galois may need to generate multiple proofs. This results in $M$ being the last trusted height and $N+1$ being the height to update to.
 
 :::
 

diff --git a/docs/src/content/docs/architecture/voyager.mdx b/docs/src/content/docs/architecture/voyager.mdx
@@ -4,8 +4,8 @@ title: "Voyager"
 
 import Mermaid from "#/components/Mermaid.astro";
 
-Voyager is our in-house relayer, allowing us to support new networks without waiting for up-stream support.
+Voyager is our in-house relayer, allowing us to support new networks without waiting for upstream support.
 
 ## Architecture
 
-At it's core, Voyager is a virtual machine. The instructions of the program it executes describe how to fetch data from chains, how to aggregate that data, and how to send messages back to the chains. A postgres-based priority queue is used to store the messages, utilizing postgres' transactional integrity to ensure no invalid state is reached. This allows us to take the "let it fail" approach when it comes to error handling - since no state is held within the application itself, Voyager can crash and restart safely without corrupting it's state or missing packets.
+At its core, Voyager is a virtual machine. The instructions of the program it executes describe how to fetch data from chains, how to aggregate that data, and how to send messages back to the chains. A postgres-based priority queue is used to store the messages, utilizing postgres' transactional integrity to ensure no invalid state is reached. This allows us to take the "let it fail" approach when it comes to error handling - since no state is held within the application itself, Voyager can crash and restart safely without corrupting its state or missing packets.
diff --git a/docs/src/content/docs/concepts/consensus-verification.mdx b/docs/src/content/docs/concepts/consensus-verification.mdx
@@ -21,7 +21,7 @@ Protocols like LayerZero and CCTP use a set of private keys to 'prove' **_1_**.
 
 The next generation of bridging protocols attempts to distribute these private keys over network participants, often using [threshold signatures](https://link.springer.com/referenceworkentry/10.1007/0-387-23483-7_429), also called multi-party computation (MPC). Instead of trusting a single entity or a small group, we move the rights to produce a **PoA** to a larger group. MPC scales poorly to large numbers of validators, so instead of trusting 2 parties, we trust 10 to 20 parties. There are further downsides to this approach that we'll cover later as well.
 
-Consensus verification is the next iteration. Instead of trusting a set of keeper nodes to custody our funds, we trust the chain itself. In the case of Union, as long as $1/3$ of the validators are honest, the network and bridge are secure. [CometBLS](/architecture/cometbls/) can support hundreds of validators, and in conjunction with DVT tech, thousands.
+Consensus verification is the next iteration. Instead of trusting a set of keeper nodes to custody our funds, we trust the chain itself. In the case of Union, as long as $1/3$ of the validators are honest, the network and bridge are secure. [CometBLS](/architecture/cometbls/) can support hundreds of validators and in conjunction with DVT tech, thousands.
 
 The golden standard of bridging is state verification, which is the foundation for rollups as well. The current iteration of zero-knowledge technology is not performant enough for state verification in bridging applications, however, we are actively doing R&D on implementations.
 

diff --git a/docs/src/content/docs/infrastructure/node-operators/getting-started.mdx b/docs/src/content/docs/infrastructure/node-operators/getting-started.mdx
@@ -152,7 +152,7 @@ uniond tx staking create-validator \
 
 :::note
 
-If your own node isn't set up to accept RPC request, you can send them to another node via the `--node` option.
+If your own node isn't set up to accept RPC requests, you can send them to another node via the `--node` option.
 
 :::
 

diff --git a/docs/src/content/docs/integrations/ucs01/cosmwasm/index.mdx b/docs/src/content/docs/integrations/ucs01/cosmwasm/index.mdx
@@ -398,7 +398,7 @@ $HOME/uniond \
         --node $RPC_URL --amount 2muno
 ```
 
-To see the result of your cross chain transfer, go to this query and replace the sender with your `$WALLET_ADDRESS`: [here](https://docs.union.build/reference/graphql/?query=query%20ContractTransfers%20%7B%0A%20%20v1_transfers(%0A%20%20%20%20where%3A%20%7B%0A%20%20%20%20%20%20sender%3A%20%7B%0A%20%20%20%20%20%20%20%20_like%3A%20%22union1ekc5agfsj2mhp2em4a9gxz8hag8uh74fwwzfa752lp2f52w3rrsqvdcxcs%22%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20)%20%7B%0A%20%20%20%20sender%0A%20%20%20%20source_chain_id%0A%20%20%20%20source_timestamp%0A%20%20%20%20source_port_id%0A%20%20%20%20source_channel_id%0A%20%20%20%20source_block_hash%0A%20%20%20%20source_connection_id%0A%20%20%20%20source_transaction_hash%0A%0A%20%20%20%20receiver%0A%20%20%20%20destination_chain_id%0A%20%20%20%20destination_timestamp%0A%20%20%20%20destination_port_id%0A%20%20%20%20destination_channel_id%0A%20%20%20%20destination_block_hash%0A%20%20%20%20destination_connection_id%0A%20%20%20%20destination_transaction_hash%0A%20%20%7D%0A%7D)
+To see the result of your cross-chain transfer, go to this query and replace the sender with your `$WALLET_ADDRESS`: [here](https://docs.union.build/reference/graphql/?query=query%20ContractTransfers%20%7B%0A%20%20v1_transfers(%0A%20%20%20%20where%3A%20%7B%0A%20%20%20%20%20%20sender%3A%20%7B%0A%20%20%20%20%20%20%20%20_like%3A%20%22union1ekc5agfsj2mhp2em4a9gxz8hag8uh74fwwzfa752lp2f52w3rrsqvdcxcs%22%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%0A%20%20)%20%7B%0A%20%20%20%20sender%0A%20%20%20%20source_chain_id%0A%20%20%20%20source_timestamp%0A%20%20%20%20source_port_id%0A%20%20%20%20source_channel_id%0A%20%20%20%20source_block_hash%0A%20%20%20%20source_connection_id%0A%20%20%20%20source_transaction_hash%0A%0A%20%20%20%20receiver%0A%20%20%20%20destination_chain_id%0A%20%20%20%20destination_timestamp%0A%20%20%20%20destination_port_id%0A%20%20%20%20destination_channel_id%0A%20%20%20%20destination_block_hash%0A%20%20%20%20destination_connection_id%0A%20%20%20%20destination_transaction_hash%0A%20%20%7D%0A%7D)
 
 ___
 
diff --git a/docs/src/content/docs/integrations/ucs01/solidity/index.mdx b/docs/src/content/docs/integrations/ucs01/solidity/index.mdx
@@ -134,7 +134,7 @@ ETH Sepolia faucets:
 
 USDC faucet: [faucet.circle.com](https://faucet.circle.com)
 
-or pick a different token from faucet list here [app.union.build/faucet](https://app.union.build/faucet)
+or pick a different token from the faucet list here [app.union.build/faucet](https://app.union.build/faucet)
 
 ## Executing the Contract
 

diff --git a/docs/src/content/docs/joining-testnet/creating-validators.mdx b/docs/src/content/docs/joining-testnet/creating-validators.mdx
@@ -29,7 +29,7 @@ Once all of these tasks are finished, you can continue with creating your valida
 
 To ensure quick update cycles of the testnet, we ask that you only have a self delegation of 1 UNO. The Union team will delegate more to you to ensure you and the other validators have a similar delegation. This will enable us to maintain the majority of the total voting power so that we can quickly conduct updates to the network.
 
-As we get closer to a mainnet release, we will update staking and slashing parameters and ask for more realistic self delegations. For the meantime, we will ensure to testnet is configured to change quickly with minimum friction.
+As we get closer to a mainnet release, we will update staking and slashing parameters and ask for more realistic self delegations. In the meantime, we will ensure to the testnet is configured to change quickly with minimum friction.
 
 ## Creating your validator
 
@@ -69,7 +69,7 @@ Replacing:
 
 :::note
 
-This step is currently specific to the Union network, other Cosmos based chains do not currently replicate this process.
+This step is currently specific to the Union network, other Cosmos-based chains do not currently replicate this process.
 
 :::
 
@@ -131,7 +131,7 @@ If your keys are stored on a machine other than your node, you can pass the `--n
 
 :::note
 
-If your own node isn't set up to accept RPC request, you can send them to another node via the `--node` option.
+If your own node isn't set up to accept RPC requests, you can send them to another node via the `--node` option.
 
 :::
 

diff --git a/docs/src/content/docs/joining-testnet/getting-tokens.mdx b/docs/src/content/docs/joining-testnet/getting-tokens.mdx
@@ -8,7 +8,7 @@ To participate in the Union Testnet, you will first need an account with a UNO b
 
 UNO is the primary token denom for the Union Testnet. We technically represent UNO as `muno` a fixed point representation of UNO with six digits of precision. This means that a balance of `1000000muno` is equivalent to 1 UNO.
 
-To ensure a fair initial distribution of Testnet tokens to validators, we will be supplying your accounts with an UNO balance.
+To ensure a fair initial distribution of Testnet tokens to validators, we will be supplying your accounts with a UNO balance.
 
 ## Getting a Testnet Account
 
@@ -60,7 +60,7 @@ The Subo "Union Testnet Validator Intake Form" is set to close on February 19th,
 
 ### Finding your Union Address
 
-To ensure your account will have an UNO balance, please submit the address from your newly created or recovered account.
+To ensure your account will have a UNO balance, please submit the address from your newly created or recovered account.
 
 If you haven't already noted down your address, you can retrieve it with the following command:
 

diff --git a/docs/src/content/docs/joining-testnet/obtaining-uniond.mdx b/docs/src/content/docs/joining-testnet/obtaining-uniond.mdx
@@ -35,7 +35,7 @@ You can create this wherever you would like, but we'll be doing so in our curren
 
 :::caution
 
-It's important that you will be able to edit this contents of this folder.
+It's important that you will be able to edit the contents of this folder.
 
 :::
 

diff --git a/docs/src/content/docs/joining-testnet/unionvisor.mdx b/docs/src/content/docs/joining-testnet/unionvisor.mdx
@@ -32,7 +32,7 @@ You can create this wherever you would like, but we'll be doing so in our curren
 
 :::caution
 
-It's important that you will be able to edit this contents of this folder.
+It's important that you will be able to edit the contents of this folder.
 
 :::
 

diff --git a/docs/src/content/docs/protocol/channels/ucs01-relay.mdx b/docs/src/content/docs/protocol/channels/ucs01-relay.mdx
@@ -10,7 +10,7 @@ import Mermaid from "#/components/Mermaid.astro";
 
 # Overview
 
-`ucs01-relay-1` is an evm compatible, multihop protocol leveraging [packet-forward middleware](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware) (PFM).
+`ucs01-relay-1` is an EVM compatible, multihop protocol leveraging [packet-forward middleware](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware) (PFM).
 A transfer is decomposed into two smaller transfers, and routed through the middleware to the appropriate chain using the `channel` and `port` combination. `ucs01-relay-1` is only supported
 for transfers, as it leverages the memo field to encode routing data. 
 
@@ -48,4 +48,4 @@ The memo field of the transfer must contain a JSON object with a `forward` key,
 }
 ```
 
-On Union, the `PFM` middleware will create a new transfer with a new sequence number using the routing info.
+On Union, the `PFM` middleware will create a new transfer with a new sequence number using the routing info.
-Original file line number
+Diff line change
@@ Expand Up @@
     :::note
-    Depending on validator set drift, Galois may need to generate multiple proofs. This results in $M$ being the last trusted height and $N+1$ being the height to update to.
+    Depending on the validator set drift, Galois may need to generate multiple proofs. This results in $M$ being the last trusted height and $N+1$ being the height to update to.
     :::
@@ Expand Down @@