Merge pull request #233 from rex4539/typos

Fix typos

packages/docs/pages/integrating-with-namada/sdk.mdx

@@ -6,7 +6,7 @@ The Namada software development kit (SDK) can be found in the `namada` repo unde
 
 ## Quick Start
 
-A good starting point to see the SDK in use is to check-out the [namada interface](https://github.com/anoma/namada-interface/tree/main/packages/shared/lib/src/sdk) repo. This repo contains a simple web application that uses the SDK to interact with the Namada blockchain. However, it is important to note the added complexity arising from the application integrating javascript using [wasm-bindgen](https://rustwasm.github.io/docs/wasm-bindgen/), which is not necesary.
+A good starting point to see the SDK in use is to check-out the [namada interface](https://github.com/anoma/namada-interface/tree/main/packages/shared/lib/src/sdk) repo. This repo contains a simple web application that uses the SDK to interact with the Namada blockchain. However, it is important to note the added complexity arising from the application integrating javascript using [wasm-bindgen](https://rustwasm.github.io/docs/wasm-bindgen/), which is not necessary.
 
 ## Installation
 

packages/docs/pages/operators/networks/genesis-flow/coordinator.mdx

@@ -12,7 +12,7 @@ The network coordinator is responsible for:
 
 ### Setup
 
-The genesis ceremony preperation includes creating a coordinated location for the pre-genesis network participants to submit their public keys. The network coordinator is responsible for setting up this location. Conventionally, the network coordinator will host a git repository that allows the pre-genesis network participants to submit their public keys. The network coordinator must ensure that the git repository is publicly accessible and that the pre-genesis network participants are able to submit their public keys in a secure manner.
+The genesis ceremony preparation includes creating a coordinated location for the pre-genesis network participants to submit their public keys. The network coordinator is responsible for setting up this location. Conventionally, the network coordinator will host a git repository that allows the pre-genesis network participants to submit their public keys. The network coordinator must ensure that the git repository is publicly accessible and that the pre-genesis network participants are able to submit their public keys in a secure manner.
 
 Further, the network coordinator is responsible for making clear timelines for the various steps in the genesis ceremony. The network coordinator must ensure that the pre-genesis network participants are aware of the timelines and that they are able to submit their public keys, transactions, and be online in due time.
 
@@ -26,7 +26,7 @@ Conventionally, the network coordinator hosts a git repository that allows the p
 
 ### Allocating pre-genesis NAM balances
 
-Once the participants have [submitted their keys and addresses](./participants.mdx#submitting-keys-and-addresses) the network coordinator must allocate balances to these addresses/public keys. The coordinator will often have prior identity information associated with desired balances, which they will then associate with the public keys and addresses in order to set the correct balances in `balances.toml`. The coordinaotor must also ensure that the total pre-genesis NAM balances allocated to the pre-genesis network participants is equal to the total NAM supply.
+Once the participants have [submitted their keys and addresses](./participants.mdx#submitting-keys-and-addresses) the network coordinator must allocate balances to these addresses/public keys. The coordinator will often have prior identity information associated with desired balances, which they will then associate with the public keys and addresses in order to set the correct balances in `balances.toml`. The coordinator must also ensure that the total pre-genesis NAM balances allocated to the pre-genesis network participants is equal to the total NAM supply.
 
 After this is completed, the network coordinator will publish the `balances.toml` file that contains the pre-genesis NAM balances allocated to the pre-genesis network participants. The `balances.toml` file should be published in the same location as the pre-genesis public keys were submitted.
 

packages/docs/pages/operators/networks/genesis-flow/participants.mdx

@@ -80,7 +80,7 @@ namadac utils init-genesis-established-account --path $TX_FILE_PATH --aliases $A
 # You can change the `--path` argument to any file path, but the recommended is `$BASE_DIR/pre-genesis/transactions.toml`
 ```
 
-The command will ouptut the generated address of the established account.
+The command will output the generated address of the established account.
 
 ```text
 Derived established account address: tnam1q8lsztqqhpjxdwzw88mqqc2mun7dvpxvas3v2dxk
@@ -114,7 +114,7 @@ TX_FILE_PATH="$BASE_DIR/pre-genesis/transactions.toml"
 namadac utils init-genesis-established-account --path $TX_FILE_PATH --aliases $ALIAS1,$ALIAS2,$ALIAS3
 ```
 
-The command will ouptut the generated address of the multisignature account.
+The command will output the generated address of the multisignature account.
 
 
 ```text

packages/docs/pages/operators/remote-signing.mdx

@@ -219,7 +219,7 @@ If everything is working fine, your node should start signing blocks.
 8. Install 2 Namada Nodes in different servers and edit their config file as we did with node 1 
 
 ###  WARNING :
-FOR ALL RUNNING NODES IN THE CLUSTER  BE SURE YOU ARE USING `priv_validator_laddr = "0.0.0.0:19901"` AND REMOVE THE ORIGNAL `priv_validator_key.json` FROM ALL NODES
+FOR ALL RUNNING NODES IN THE CLUSTER  BE SURE YOU ARE USING `priv_validator_laddr = "0.0.0.0:19901"` AND REMOVE THE ORIGINAL `priv_validator_key.json` FROM ALL NODES
 PLEASE NOTE THAT USING REMOTE SIGNING COULD LEAD TO DOUBLE SIGNING AND SLASHING IF YOUR NODE SIGNED SAME BLOCK TWICE,
 SO BE SURE THAT NEVER USE LOCAL AND REMOTE SIGNING SAME TIME .
 

packages/docs/pages/users/fees.mdx

@@ -62,7 +62,7 @@ namadac transfer \
   --dry-run-wrapper
 ```
 
-Which will ouptut something along the lines of 
+Which will output something along the lines of 
 
 ```md
 Dry-run result: Transaction is valid. Gas used: 1785;

packages/docs/pages/users/governance/on-chain-governance.mdx

@@ -25,7 +25,7 @@ Now, we need to create a json file `proposal.json` holding the content of our pr
 			"discussions-to": "forum.namada.net/t/namada-proposal/1",
 			"created": "2069-04-20T00:04:44Z",
 			"license": "MIT",
-			"abstract": "We present a proposal that will send our community to the moon. This proposal outlines all training necessary to accomplish this goal. All memers are welcome to join.",
+			"abstract": "We present a proposal that will send our community to the moon. This proposal outlines all training necessary to accomplish this goal. All members are welcome to join.",
 			"motivation": "When you think about it, the moon isn't actually that far away.The moon is only 384,400 km. We have not yet brought Namada to the moon, so it is only natural to use 101 as the prime number for our modular arithmetic operations. 384,400 (mod 101) = 95. 95 km is a distance that can be easily covered by a single person in a single day. Namada was produced by more than 100 people. So 95/100 = 0, rounded to the nearest integer. This means that Namada can reach the moon in no time.",
 			"details": "Bringing Namada to the moon in no time is easily achievable. We just need to pass this governance proposal and set the plan in action",
 			"requires": ""
@@ -50,7 +50,7 @@ You should change the value of:
 - `voting_end_epoch` with an epoch greater than `voting_start_epoch`, a multiple of 3, and by which no further votes will be accepted;
 - `grace_epoch` with an epoch greater than `voting_end_epoch` + 6, in which the proposal, if passed, will come into effect.
 
-The `data` field and its structure is dependant on the type of proposal being submitted. Below we outline the structure of the "data" field for each type of proposal. The one given in the example above is for a `Default Proposal`.
+The `data` field and its structure is dependent on the type of proposal being submitted. Below we outline the structure of the "data" field for each type of proposal. The one given in the example above is for a `Default Proposal`.
 
 ### Default Proposal 
 

packages/docs/pages/users/ibc.mdx

@@ -55,7 +55,7 @@ namadac --base-dir ${BASE_DIR_A}
     --node 127.0.0.1:27657
 ```
 
-Once the transaction has been submitted, a relayer will need to relay the packet to the other chain. This is done automatically by the relayer running Hermes. If the packet is never succsesfully relayed, the funds are returned to the sender after a timeout. See more infomation in the [specs](https://specs.namada.net/interoperability/ibc).
+Once the transaction has been submitted, a relayer will need to relay the packet to the other chain. This is done automatically by the relayer running Hermes. If the packet is never successfully relayed, the funds are returned to the sender after a timeout. See more information in the [specs](https://specs.namada.net/interoperability/ibc).
 
 ## Transferring assets back from Cosmos-SDK based chains
 

packages/docs/pages/users/wallet.mdx

@@ -4,7 +4,7 @@ This document describes the different wallet concepts and options that are avail
 
 ## A brief introduction to the Namada wallet
 The purpose of the Namada wallet is to provide a user-interface to store and manage both keys and addresses.
-[Technically speaking](https://vitalik.ca/general/2017/01/14/exploring_ecp.html), keys are just (potentially) very large integers that have some meaning on an eliptic curve.
+[Technically speaking](https://vitalik.ca/general/2017/01/14/exploring_ecp.html), keys are just (potentially) very large integers that have some meaning on an elliptic curve.
 The wallet simply "remembers" these very large numbers on your behalf. Keys are the fundamental building blocks for accounts on Namada.
 Keys come in the form of *pairs* (of secret and public key), and can be used to derive the **account address** (first 40 chars of the SHA256 hash of the public key).
 

packages/specs/pages/base-ledger.mdx

@@ -9,4 +9,4 @@ The consensus mechanism on Namada provides an algorithmic way for validators to
 The validity-predicate based execution mechanism is inherited from the architectural design philosophy of Anoma. The fundamental idea is that a "valid state" is defined as that which satisfies a set of boolean conditions. These boolean conditions are encoded by functional "validity predicates", which are invoked whenever a state is being proposed. If all validity predicates in the system return the boolean `true`, this defines a valid state which validators can vote on. The validity predicate based mechanism differs from the traditional "smart-contract" based execution model, where a valid state is instead defined as that which results from a series of pre-defined valid execution steps. These execution steps are defined within the smart contract, and verifying the validity of the new state requires *each* validator to run the series of execution steps.
 
 ## Replay protection & block space allocator
-In addition to describing the execuction model and consensus, this section  also documents Namada's [replay protection system](./base-ledger/replay-protection.mdx), and [block space allocator](./base-ledger/block-space-allocator.mdx).
+In addition to describing the execution model and consensus, this section  also documents Namada's [replay protection system](./base-ledger/replay-protection.mdx), and [block space allocator](./base-ledger/block-space-allocator.mdx).

packages/specs/pages/base-ledger/replay-protection.mdx

@@ -41,7 +41,7 @@ transaction is composed of two parts: a `WrapperTx` and an inner `Tx`
 {/* TODO: Check that this is up to date. I believe it is not */}
 ```rust
 pub struct WrapperTx {
-  /// The fee to be payed for including the tx
+  /// The fee to be paid for including the tx
   pub fee: Fee,
   /// Used to determine an implicit account of the fee payer
   pub pk: common::PublicKey,
@@ -68,7 +68,7 @@ pub struct Tx {
 
 The wrapper transaction is composed of some metadata, an optional unshielding tx
 for fee payment (see [fee specs](../economics/fee-system.mdx)), the encrypted
-inner transaction itself and the hash of the concatenation of these values. {/* TODO: Ensure that the hash of concatentation statement is as accurate as possible. It could be values, it could be the object (which consists of keys + values)*/}
+inner transaction itself and the hash of the concatenation of these values. {/* TODO: Ensure that the hash of concatenation statement is as accurate as possible. It could be values, it could be the object (which consists of keys + values)*/}
 The inner `Tx` transaction carries the Wasm code to be executed and the associated data.
 
 A transaction is constructed as follows:
@@ -153,7 +153,7 @@ has an internal replay protection mechanism.
 
 Still, since this field represents a valid, `Transaction`, there is a possible
 attack that can be run by leveraging this field: a malicious user could extract
-this data before it makes it to a block, embedd it into a valid, masp signed
+this data before it makes it to a block, embed it into a valid, masp signed
 `Tx` and apply it in advance.
 
 This attack is performed before the original tx is placed in a block and,

packages/specs/pages/base-ledger/replay-protection/optimizations.mdx

@@ -1,6 +1,6 @@
 import { Callout } from 'nextra-theme-docs'
 
-{/* TODO: Maket this section more clear. At the moment I'm not sure what optmisation is what in the "possible optimisations" */}
+{/* TODO: Maket this section more clear. At the moment I'm not sure what optimisation is what in the "possible optimisations" */}
 # Possible optimizations
 
 In this section we describe two alternative solutions that come with some optimizations.
@@ -387,7 +387,7 @@ the following:
 
 ```rust
 pub struct WrapperTx {
-  /// The fee to be payed for including the tx
+  /// The fee to be paid for including the tx
   pub fee: Fee,
   /// Used to determine an implicit account of the fee payer
   pub pk: common::PublicKey,
@@ -495,7 +495,7 @@ validate it. These will involve:
 
 These checks can all be done before executing the transactions themselves. If
 any of these fails, the transaction should be considered invalid and the action
-to take will be one of the followings:
+to take will be one of the following:
 
 1. If the checks fail on the signature, chainId, expiration or transaction
    counter, then this transaction will be forever invalid, regardless of the

packages/specs/pages/economics/proof-of-stake/objects-and-txs.mdx

@@ -297,7 +297,7 @@ type Unbonds = HashMap<BondId, Epoched<Unbond>>;
 
 struct BondId {
   validator: Address,
-  /// The delegator adddress for delegations, or the same as the `validator`
+  /// The delegator address for delegations, or the same as the `validator`
   /// address for self-bonds.
   source: Address,
 }
@@ -310,7 +310,7 @@ struct Bond {
 
 struct Unbond {
   /// A key is a pair of the epoch of the bond from which a unbond was created
-  /// the epoch of unboding. This is needed for slash epoch range check.
+  /// the epoch of unbonding. This is needed for slash epoch range check.
   deltas: HashMap<(Epoch, Epoch), token::Amount>
 }
 ```

packages/specs/pages/economics/public-goods-funding/becoming-a-steward.mdx

@@ -52,7 +52,7 @@ There are 4 ways that a Steward may be removed from the steward set:
 4. They reach the end of their term
 
 Resigning as a Steward is straight-forward. A simple interface is implemented to allow for the established account 
-representing the Steward to lose their priveleges as a PGF Steward.
+representing the Steward to lose their privileges as a PGF Steward.
 
 If a steward's PGF proposal receives a significant number of `Nay` votes ($\frac{2}{3}$ as a fraction of voting-power 
 voted and more than two-thirds of the votes are `Nay`), they will be removed from the steward set. 

packages/specs/pages/economics/public-goods-funding/electing.mdx

@@ -24,7 +24,7 @@ The `id` will correspond to the `id` of the `StewardProposal` that is being vote
 
 
 #### Dealing with ties
-In the rare occurence of a tie, the `StewardProposal` is rejected, i.e. the current steward-set remains the same.
+In the rare occurrence of a tie, the `StewardProposal` is rejected, i.e. the current steward-set remains the same.
 
 
 ## Electing stewards

packages/specs/pages/governance/on-chain.mdx

@@ -100,7 +100,7 @@ Storage writes for a vote transaction are described [here](./storage.mdx#votes).
 If non-validating accounts are allowed to vote, delegates will be able to vote only for $\frac{2}{3}$ of the total voting period, while delegators can vote until the end of the voting period. 
 If only validators are allowed to vote for the `ProposalType` in question, they are allowed to vote for the entire voting window.
 
-If a delegator votes differently to its delegate, the delegate's vote will be *overriden* 
+If a delegator votes differently to its delegate, the delegate's vote will be *overridden* 
 (e.g. if a delegator has a voting power of 200 and votes opposite to the delegate, then 200 will be subtracted from the voting power of the involved delegate).
 
 

packages/specs/pages/index.mdx

@@ -14,7 +14,7 @@ Users of the MASP are [rewarded](./economics/shielded-pool-incentives.mdx) for t
 
 Namada supports a variety of different wallets. One of these wallets is the native wallet, that exists in order to facilitate interacting with the protocol in a safe and private manner. 
 
-Furhter, Namada supports Shielded Actions, which allows users to hold their assets privately on Namada most of the time while occasionally unshielding specific assets in order to interact with existing applications on transparent chains.
+Further, Namada supports Shielded Actions, which allows users to hold their assets privately on Namada most of the time while occasionally unshielding specific assets in order to interact with existing applications on transparent chains.
 
 You can learn more about Namada [here](https://blog.namada.net/introducing-namada-interchain-asset-agnostic-privacy/).
 

packages/specs/pages/interoperability/ethereum-bridge/transfers_to_namada.mdx

@@ -8,7 +8,7 @@ will be two internal accounts with associated native validity predicates:
   ["multitoken"](../../base-ledger/fungible-token.html#multitoken) hierarchy.
   Also contains in escrow Namada tokens which have been sent to Ethereum,
   pertaining to pending wNAM transfers.
-- `#EthBridgePool` - Holds gas fees to be payed to relayers of transfers to Ethereum,
+- `#EthBridgePool` - Holds gas fees to be paid to relayers of transfers to Ethereum,
   as well assets (other than wNAM) in escrow, pertaining to pending transfers to
   Ethereum.
 

packages/specs/pages/masp/ledger-integration.mdx

@@ -315,7 +315,7 @@ The [Multi-Asset Shielded Pool Specification](https://github.com/anoma/masp/blob
   * `HomomorphicPedersenCommit`, `ValueCommit`, and value base must be parameterized by asset type
 * [5.5 Encodings of Note Plaintexts and Memo Fields](https://zips.z.cash/protocol/protocol.pdf#notept)
   * The note plaintext tuple must include asset type
-  * The Sapling note plaintext encoding must use 32 bytes inbetween `d` and `v` to encode asset type
+  * The Sapling note plaintext encoding must use 32 bytes in between `d` and `v` to encode asset type
   * Hence the total size of a note plaintext encoding should be 596 bytes
 * [5.6 Encodings of Addresses and Keys](https://zips.z.cash/protocol/protocol.pdf#addressandkeyencoding)
   * Bech32m \[[BIP-0350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)\] is used instead of Bech32 \[[ZIP-173](https://zips.z.cash/zip-0173)\] to further encode the raw encodings