Merge pull request #56 from anoma/aleks/fixes

Fix broken links, typos, writing

packages/docs/pages/experimental/ibc.mdx

@@ -4,21 +4,24 @@ import { Callout } from 'nextra-theme-docs'
 
 This document describes using the inter-blockchain communication (IBC) protocol with Namada. This documentation covers being able to create connections through IBC as well as setting up local instances of Namada for testing purposes.
 
-> **Warning**
->
-> This feature is currently in development. Expect the unexpected.
+<Callout type="warning">
+**Warning** This feature is currently in development. Expect the unexpected.
+</Callout>
 
-This document will cover three essential steps for using IBC with Namada
+This document will cover three essential steps for using IBC with Namada:
 
 1. [Setup Hermes](#setup-hermes)
 2. [Setup nodes for Namada instances](#setup-nodes-for-namada-instances)
 3. [Transferring assets over IBC](#transferring-assets-over-IBC)
 
-The below is intended for those that wish to conduct IBC message transfers between two Namada chains. There is of course the cabablitiy to do this between any two IBC compatible chains (such as a cosmos chain). In this case, it is necessary to have a node of both the destination and the source chain running in order to make any package transfers. Below, we discuss first how to enable this connection between two pre-existing chains by Hermes, and second setting up 2 Namada local instances or joining two pre-existing Namada instances for this purpose.
+The below is intended for those that wish to conduct IBC message transfers between two Namada chains. There is of course the cabablitiy to do this between any two IBC compatible chains (such as a Cosmos chain).
+In this case, it is necessary to have a node of both the destination and the source chain running in order to make any package transfers.
+Below, we discuss first how to enable this connection between two pre-existing chains by Hermes, and second, setting up two Namada local instances or joining two pre-existing Namada instances for this purpose.
 
 ## Setup Hermes
-Hermes is an IBC relayer to relay packets between chains(instances). We have our [Hermes supporting Namada instances](https://github.com/heliaxdev/ibc-rs/tree/yuji/v0.14.0_namada).
-Before packet relay, we need the following step to configure and start Hermes.
+Hermes is an IBC relayer to relay IBC packets between chains (instances).
+We have our [Hermes supporting Namada instances](https://github.com/heliaxdev/ibc-rs/tree/yuji/v0.14.0_namada).
+Before packet relay, we need the following steps to configure and start Hermes.
 
 1. Make Hermes config file
 2. Create IBC client/connection/channel between instances

packages/docs/pages/experimental/local-network.mdx

@@ -2,9 +2,9 @@
 
 ## Prerequisites
 
-Namada must be installed [from source](../introduction/install/from-source.md) in order to run a local network.
+Namada must be installed [from source](../introduction/install/source.md) in order to run a local network.
 
-There is a script that has been written specifically for this purpose, which can be found under `scripts` in the namada repository.
+There is a script that has been written specifically for this purpose, which can be found under `scripts` in the [Namada repository](https://github.com/anoma/namada).
 
 ### Installing script dependencies
 
@@ -25,7 +25,7 @@ The below image shows an example of a genesis configuration file that has been m
 
 ### Building wasm
 
-The script will also require all `wasm` files for txs to be built. This can be done by running the following command (whilst in the namada directory):
+The script will also require all `wasm` files for transactions to be built. This can be done by running the following command (whilst in the namada directory):
 
 ```shell copy
 make build-wasm-scripts
@@ -42,13 +42,12 @@ The script is called `build_network.sh` and can be run with the following comman
 
 More specifically, the script takes three arguments:
 
-1. `config_toml`: the path to the (validator-free) genesis configuration file.
-2. `namada_dir`: the path to the namada BINARIES directory. 
-If the binaries were build using `make build-release` this would imply the `namada/target/release` directory. 
-Otherwise, if they were built using `make build` it would be the `namada/target/debug` directory.
-3. `base_dir`: OPTIONAL ARGUMENT. 
-You can specify the path to the BASE_DIR directory, where all chain-data is stored. 
-This is only necessary if the BASE_DIR is not the default given by `namadac utils default-base-dir` command.
+1. `config_toml`: the path to the ([validator-free](#modifying-the-genesis-configuration-file)) genesis configuration file.
+2. `namada_dir`: the path to the Namada [binaries directory](../introduction/install/binaries/overview-of-binaries).
+   If the binaries were build using `make build-release` this would imply the `namada/target/release` directory. 
+   Otherwise, if they were built using `make build` it would be the `namada/target/debug` directory.
+3. `base_dir`: (optional argument) the path to the BASE_DIR directory, where all chain-data is stored. 
+   This is only necessary if the BASE_DIR is not the default given by `namadac utils default-base-dir` command.
 
 For example, a MacOS user would run something along the lines of:
 
@@ -64,7 +63,7 @@ After the script has been run, a python process will have started in the backgro
 The ledger can be run through the familiar command:
 
 ```shell copy
-target/release/namada ledger #Assuming the binaries were built using `make build-release`
+target/release/namada ledger # Assuming the binaries were built using `make build-release`
 ```
 
 ## Cleaning up

packages/docs/pages/governance/off-chain-governance.mdx

@@ -2,7 +2,7 @@ import { Callout } from 'nextra-theme-docs'
 
 # Off-chain proposals
 
-If for any reason issuing an on-chain proposal is not adequate to your needs, you still have the option to create an off-chain proposal. An off-chain proposal is intended for proposals that do not require any on-chain code execution. The proposal would be distributed on some third-party channel (e.g. a forum) and the voting would be done off-chain. The result of the voting would be computed off-chain and then submitted to the ledger.
+If for any reason issuing an on-chain proposal is not adequate to your needs, you still have the option to create an off-chain proposal. An off-chain proposal is intended for proposals that do not require any on-chain code execution. The proposal would be distributed on some third-party channel (e.g., a forum) and the voting would be done off-chain. The result of the voting would be computed off-chain and then submitted to the ledger.
 
 ## Create proposal
 

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

@@ -39,10 +39,10 @@ In the content field, most of the fields are self-explanatory. The `requires` fi
 
 You should change the value of:
 
-- `Author` field with the address of `my-new-acc`.
-- `voting_start_epoch` with a future epoch (must be a multiple of 3) for which you want the voting to begin
-- `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
+- `Author` field with the address of `my-new-acc`;
+- `voting_start_epoch` with a future epoch (must be a multiple of 3) for which you want the voting to begin;
+- `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`.
 
@@ -124,7 +124,7 @@ the amount specified will be sent immediately.
 </Callout>
 
 ## Submitting the proposal
-As soon as your `proposal.json` file is ready, you can submit the proposal with (making sure to be in the same directory as the `proposal.json` file):
+As soon as your `proposal.json` file is ready, you can submit the proposal with (make sure to be in the same directory as the `proposal.json` file):
 
 ```shell copy
 namada client init-proposal --data-path proposal.json 
@@ -159,7 +159,8 @@ where `--vote` can be either `yay` or `nay`.
 
 ## Check the result
 
-As soon as the ledger reaches the epoch defined in the json as `voting_end_epoch`, no votes will be accepted. The code definied in `proposal_code` json field will be executed at the beginning of `grace_epoch` epoch. You can use the following commands to check the status of a proposal:
+As soon as the ledger reaches the epoch defined in the json as `voting_end_epoch`, no more votes will be accepted.
+The code definied in `proposal_code` json field will be executed at the beginning of `grace_epoch` epoch. You can use the following commands to check the status of a proposal:
 
 ```shell copy
 namada client query-proposal --proposal-id 0

packages/docs/pages/introduction/testnets/post-genesis-validator.mdx

@@ -17,16 +17,11 @@ namadac transfer \
     --target $VALIDATOR_ALIAS \
     --signer $VALIDATOR_ALIAS
 ```
-Note: A maximum amount of 1000 NAM can be sourced from the faucet per transaction, so to get more, run this multiple times
-
-```shell copy
-namada client bond \
-  --validator $VALIDATOR_ALIAS \
-  --amount <enter-amount>
-```
+Note: A maximum amount of 1000 NAM can be sourced from the faucet per transaction, so to get more, run this multiple times.
 
 ## Bonding
-Follow [this guide](../../validators/staking.md) on how to self-bond a validator's tokens.
+
+Follow [this guide](../../validators/staking.md#self-bonding) on how to self-bond a validator's tokens.
 
 ## Check bonded-stake
 In order to vote on blocks, a validator must have enough `bonded-stake` to be included in the validators "consensus-set". A validator is in the consensus set if and only if it has enough `bonded-stake` to be in the top 128 validators by `bonded-stake`.

packages/docs/pages/wallet.mdx

@@ -3,14 +3,17 @@
 This document describes the different wallet concepts and options that are available to users of Namada who want to be able to [send, receive and interact](../users/send-and-receive-nam-tokens.md) with NAM tokens on the Namada blockchain.
 
 ## 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. 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* (secret and public), and can be used to derive the **account address** (first 40 chars of the SHA256 hash of the public key).
+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.
+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).
 
 To read more about addresses see [An introduction to Namada addresses](../users/an-introduction-to-namada-addresses.md).
 
 ## The wallet options on Namada
 
 Check out the different options to generate a wallet:
 
-- [File System Wallet](./file-system-wallet.md)
-- [Web Wallet](./web-wallet.md)
-- [Hardware Wallet](./hardware-wallet.md)
+- [File System Wallet](./wallet/file-system-wallet.md)
+- [Web Wallet](./wallet/web-wallet.md)
+- [Hardware Wallet](./wallet/hardware-wallet.md)

packages/docs/pages/wallet/file-system-wallet.mdx

@@ -7,5 +7,5 @@ If the wallet doesn't already exist, it will be created for you as soon as you r
 Currently, the Namada client can load the password via:
 
 - **Stdin:** the client will prompt for a password.
-- **Env variable:** by exporting a ENV variable called `NAMADA_WALLET_PASSWORD` with value of the actual password.
-- **File:** by exporting an ENV variable called `NAMADA_WALLET_PASSWORD_FILE` with value containing the path to a file containing the password.
+- **Env variable:** by exporting a ENV variable called `NAMADA_WALLET_PASSWORD` with a value of the actual password.
+- **File:** by exporting an ENV variable called `NAMADA_WALLET_PASSWORD_FILE` with a value containing the path to a file containing the password.

packages/docs/pages/wallet/hardware-wallet.mdx

@@ -12,7 +12,7 @@ If this isn't available, one can install the javascript npm package [here](https
 In order to use the ledger with the web wallet, you will need to install the [Namada Web Wallet](./web-wallet.md#install).
 
 ### Connecting your Ledger
-1. Open the Namada web extension
+1. Open the Namada web extension.
 2. Under settings, click on the `Connect Ledger` button.
 3. Set an alias for the account that ledger will control the keys for.
 4. You can choose to connect to the ledger via `USB` (recommended) or `HID` (Human Interface Devices). 
@@ -21,4 +21,4 @@ In order to use the ledger with the web wallet, you will need to install the [Na
 7. You can now close the information window and use the ledger to sign transactions.
 
 ### Sending transactions with the ledger
-See the [web wallet](./web-wallet.md#send-transactions) guide for instructions on how to send transactions with the web wallet.
+See the [web wallet](./web-wallet.md#sending-transactions) guide for instructions on how to send transactions with the web wallet.

packages/docs/pages/wallet/web-wallet.mdx

@@ -1,24 +1,31 @@
 # Web Wallet
 
 ## Install
-When Namada is in mainnet, the web wallet will be available in most browser extension web stores. For now, you can install it from source by following the instructions below.
+When Namada is in `mainnet`, the web wallet will be available in most browser extension web stores. For now, you can install it from source by following the instructions below.
 
-### Installing from source (dev and experiment purposes)
+### Installing from source (for development and experiment purposes)
 
 #### Connect to a testnet or run a local node
-1. Follow the instructions in the [testnets](../introduction/testnets/intro.md) to connect to a testnet or you can set up a local node using [docker](../introduction/install/from-docker.md).
-2. Figure out where the base directory is stored and save it as a variable such as `export BASE_DIR=<path/to/base/dir>`. You can follow [these docs](../introduction/testnets/migrating-testnets.md#after-v0153) to save this variable. Go ahead and save the chain id as a variable as well. You can find the chain id by running `cat $BASE_DIR/global-config.toml`. Save this chain-id to the variable `export CHAIN_ID=<CHAIN_ID>`.
-3. You will need to edit the cometbft config in order to allow the web wallet to connect to your node. The cometbft config will be located in `$BASE_DIR/$CHAIN_ID/cometbft/config/config.toml`. You will need to change the `cors_allowed_origins` field to `["*"]`. You can do this by running `sed -i 's/cors_allowed_origins = \[\]/cors_allowed_origins = ["*"]/' $BASE_DIR/$CHAIN_ID/cometbft/config/config.toml`.
+1. Follow the instructions for the [testnets](../introduction/testnets.md) to connect to a testnet or set up a local node using [docker](../introduction/install/docker.md).
+2. Figure out where the base directory is stored and save its location as a variable such as `export BASE_DIR=<path/to/base/dir>`.
+   You can follow [these docs](../introduction/testnets/migrating-testnets.md#after-v0153) to save this variable. Go ahead and save the chain id as a variable as well. You can find the chain id by running `cat $BASE_DIR/global-config.toml`. Save this chain-id to the variable `export CHAIN_ID=<CHAIN_ID>`.
+3. You will need to edit the CometBFT config in order to allow the web wallet to connect to your node.
+   The CometBFT config will be located in `$BASE_DIR/$CHAIN_ID/cometbft/config/config.toml`. You will need to change the `cors_allowed_origins` field to `["*"]`. You can do this by running
+   ```shell copy
+   sed -i 's/cors_allowed_origins = \[\]/cors_allowed_origins = ["*"]/' \
+           $BASE_DIR/$CHAIN_ID/cometbft/config/config.toml
+   ```
 
 #### Setting up the extension
-1. Clone the [namada-interface repository](https://github.com/anoma/namada-interface)
-2. Follow the installation instructions in the intro.md (which should be visible on the repository page).
+1. Clone the [namada-interface repository](https://github.com/anoma/namada-interface).
+2. Follow the installation instructions in `README.md`.
 3. `cd` into the `namada-interface/apps/extension` directory and run `yarn start:chrome`. This will build the extension and place it in the `namada-interface/apps/extension/build` directory. It also starts the dev server which will watch for changes.
 4. `cd` into the `namada-interface/apps/namada-interface` directory and run `yarn dev:local` in order to launch a local instance of the web wallet.
 4. Add the extension to the browser. For example, in Chrome, you can go to `chrome://extensions/` and click `Load unpacked` and select the `namada-interface/apps/extension/build/chrome/` folder.
 
 ## Receving tokens
-You can show the address of any account by pressing the `Receive` button in the initial view under the "Total Balances" tab. You can copy the address by clicking the copy icon next to the address. This will also display QR code that can be scanned by a mobile wallet.
+You can show the address of any account by pressing the `Receive` button in the initial view under the "Total Balances" tab. You can copy the address by clicking the copy icon next to the address.
+This will also display a QR code that can be scanned by a mobile wallet.
 
 ## Sending Transactions