Merge branch 'master' into yuji/ibc-multitoken

.env

@@ -0,0 +1 @@
+NEXT_TELEMETRY_DISABLED=1

README.md

@@ -4,6 +4,6 @@ This documentation uses [Nextra](https://nextra.site/) and [NextJS](https://next
 
 ## Local Development
 
-1. You need to install [NodeJS](https://nodejs.org/en) >= 16 and [PNPM](https://pnpm.io/).
-2. Run `pnpm i` to install the dependencies.
-3. Run `pnpm dev` to start the development server and visit `http://localhost:3000` .
+1. You need to install [NodeJS](https://nodejs.org/en) >= 16.
+2. Run `npm i` to install the dependencies.
+3. To run Docs, you can use the command `npm run dev:docs`. To run Specs, you can use the command `npm run dev:specs`. The default development server URL is `http://localhost:3000` but if for some reason it's used by other application, the console will display on which port the server is started.

packages/docs/next.config.js

@@ -9,4 +9,14 @@ module.exports = {
   images: {
     unoptimized: true,
   },
+  markdown: {
+    // options for markdown-it-anchor
+    anchor: { permalink: false },
+    // options for markdown-it-toc
+    toc: { includeLevel: [1, 2] },
+    extendMarkdown: md => {
+      // use more markdown-it plugins!
+      md.use(require('markdown-it-xxx'))
+    }
+  }
 };

packages/docs/pages/_meta.json

@@ -7,10 +7,10 @@
   "delegators": "Delegators",
   "users": "(Power) Users",
   "public-goods-stewards": "Public goods stewards",
-  "proof-of-stake": "Cubic Proof-of-stake",
+  "proof-of-stake": "Cubic Proof-of-Stake",
   "governance": "Governance",
   "wallet": "Wallet guide",
-  "experimental": "Experimenting with namada",
+  "experimental": "Experimenting with Namada",
   "troubleshooting": "Troubleshooting",
   "faq": "FAQ"
 }

packages/docs/pages/delegators.md → packages/docs/pages/delegators.mdx

@@ -3,11 +3,11 @@
 ## Delegators vs Delegates
 All accounts on Namada with any amount of *bonded* NAM, is by definition, either a delegator or a delegate. 
 
-#### What is a deleagtor?
-A delegator is an account that has bonded NAM to a delegate. 
+#### What is a delegator?
+> A delegator is an account that has bonded NAM to a delegate. 
 
 #### What is a delegate?
-A delegate is an account that has been bonded to by a delegator.
+> A delegate is an account that has been bonded to by a delegator.
 
 ## Becoming a delegator
 In order to become a delegator, you must first have an account with positive NAM balance. If you do not have an account, you can follow the instructions [here](../users/an-introduction-to-namada-addresses.md) to create one.
@@ -18,13 +18,13 @@ Delegating to a validator is the same as [staking with a validator](../validator
 
 First, you may want to list the available validators you can stake to:
 
-```bash
+```bash copy
 namadac bonded-stake
 ```
 
 Once you've found the address of your favourite validator, you can bond to them with the following command:
 
-```bash
+```bash copy
 namadac bond --validator <validator-address> --amount <amount> --signer <account-alias>
 ```
 
@@ -34,4 +34,4 @@ If you have the alias saved in your wallet, you can also pass `<validator-alias>
 Redelegating is the process of changing the delegate you have bonded to. This process takes 4 epochs, after which your NAM will be redelegated.
 
 ## Unbonding
-Unbonding is the process of removing your bonded NAM from a delegate. This process is identical to [unbonding tokens from a validator](../validators/staking.md).
+Unbonding is the process of removing your bonded NAM from a delegate. This process is identical to [unbonding tokens from a validator](../validators/staking.md#unbonding).

packages/docs/pages/ledger/customize.md → packages/docs/pages/experimental/customize.mdx

@@ -1,5 +1,13 @@
+import { Callout } from 'nextra-theme-docs'
+
 # Customize accounts and transactions
 
+<Callout type="warning">
+Note that these features are still a work in progress.
+At the time of writing, Namada does not allow for custom validity predicates (as there is a whitelist).
+Custom transactions are possible in certain cases (e.g., governance proposals).
+</Callout>
+
 On this page, we'll cover how to tailor your account(s) to your use-case with custom-made validity predicates and transactions.
 
 We currently only support Rust for custom validity predicates and transactions via WASM, but expect many more options to be available in the future!
@@ -20,9 +28,9 @@ To illustrate with an example storage key used for fungible tokens (with address
   #atest1v4ehgw36x3prs.../balance/#atest1v4ehgw36xvcyy...
   ```
 
-Any transaction can attempt to make changes to the storage of any account(s). Only if all the involved accounts accept, the transaction will it be committed. Otherwise, the transaction is rejected and its modifications discarded.
+Any transaction can attempt to make changes to the storage of any account(s). Only if all the involved accounts accept, the transaction will be committed. Otherwise, the transaction is rejected and its modifications discarded.
 
-This approach allows multiparty transactions to be applied atomically, without any a priority coordination. It also gives accounts complete and fine-grained control over how they can be used in transactions in themselves and in relation to other accounts.
+This approach allows multiparty transactions to be applied atomically, without any prior coordination. It also gives accounts complete and fine-grained control over how they can be used in transactions in relation to themselves and other accounts.
 
 In fact, most of the functionality in the Namada ledger is being built leveraging the simplicity and flexibility of this account system, from a simple fungible token to more complex accounts that integrate the Inter-blockchain Communication protocol and the Proof of Stake system.
 
@@ -65,23 +73,23 @@ To find out about the host interface available in a validity predicate, please c
 
 To compile the validity predicate's code from the template:
 
-```shell
+```shell copy
 make -C wasm/vp_template
 ```
 
 This will output a WASM file that can be found in `wasm/vp_template/target/wasm32-unknown-unknown/release/vp_template.wasm`.
 
 You can, for example, copy it into your `wasm` directory (the default directory used by the ledger's node and the client, which can be changed with `--wasm-dir` global argument or `NAMADA_WASM_DIR`):
 
-```shell
+```shell copy
 cp \
   wasm/vp_template/target/wasm32-unknown-unknown/release/vp_template.wasm \
   wasm/my_vp.wasm
 ```
 
 To submit a transaction that updates an account's validity predicate:
 
-```shell
+```shell copy
 namada client update --address my-new-acc --code-path my_vp.wasm
 ```
 
@@ -110,15 +118,15 @@ To find out about the interface available in a transaction, please check out [Ru
 
 Compile the transaction's code from the template:
 
-```shell
+```shell copy
 make -C wasm/tx_template
 ```
 
 This will output a WASM file that can be found in `wasm/tx_template/target/wasm32-unknown-unknown/release/tx_template.wasm`.
 
 Submit the transaction to the ledger:
 
-```shell
+```shell copy
 namada client tx --code-path tx_template/tx.wasm
 ```
 

packages/docs/pages/experimental/ibc.md → packages/docs/pages/experimental/ibc.mdx

@@ -1,22 +1,27 @@
+import { Callout } from 'nextra-theme-docs'
+
 # Using IBC with Namada
 
 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
@@ -25,7 +30,7 @@ Before packet relay, we need the following step to configure and start Hermes.
 ### Make Hermes config file
 One essential piece of the puzzle is to create a `config.toml` file that describes what connections will be set up that the relayer will be responsible for.
 
-```bash!
+```bash copy
 export HERMES_CONFIG="<choose path for hermes config>/config.toml"
 touch $HERMES_CONFIG
 ``` 
@@ -36,26 +41,25 @@ You can find an example of the config file [here](https://hackmd.io/l6HNSqJmQt6Q
 
 The path to the config file, which is is saved in the variable `$HERMES_CONFIG` will be useful later.
 
-```admonish note
-
- **Interpreting the toml**
 
- Each chain configuration is specified under the `[[chains]]` object.
+<Callout type="info" emoji="🧩"> 
+**Interpreting the toml**
 
- These are the pieces of this puzzle you want to keep your 👀 on:
+Each chain configuration is specified under the `[[chains]]` object.
+These are the pieces of this puzzle you want to keep your 👀 on:
  - `chains.id` is the name of the chain
  - `chains.rpc_address` specifies the port that the channel is communicating through, and will be the argument for the `ledger_address` of Namada when interacting with the ledger (will become clearer later)
      - Make sure to change the IP address to the IP address of your local machine that is running this node!
  - `chains.key_name` specifies the key of the signer who signs a transaction from the relayer. The key should be generated before starting the relayer.
-```
+</Callout>
 
 ### Create IBC client/connection/channel between instances
 Hermes CLI has commands to create them. Before the creation, a node of each instance should be running.
 
 #### Install Hermes
 Before conducting any IBC operations, we build Heliax's Hermes fork from source.
 
-```bash
+```bash copy
 export COMMIT="470137e845b997228f9bcda8eec8bc02bd0be6da"
 git clone [email protected]:heliaxdev/ibc-rs.git
 git checkout $COMMIT
@@ -64,22 +68,22 @@ cargo build --release --bin hermes
 export IBC_RS=$(pwd) # if needed
 ```
 Check the binary:
-```bash
+```bash copy
 ./target/release/hermes --version
 ```
 
-````admonish note
+<Callout type="info">
 It is recommended to now add hermes to `$PATH` such that it is callable without any pre-fixes.
 For ubuntu users, this can be achieved by
-```bash
+```bash copy
 cp ./target/release/hermes /usr/local/bin/
 ```
-````
+</Callout>
 
 ### Create IBC channel
 The "create channel" command (below) creates not only the IBC channel but also the necessary IBC client connection.
 
-```bash
+```bash copy
 hermes -c $HERMES_CONFIG \
   create channel $CHAIN_A_ID \
   --chain-b $CHAIN_B_ID \
@@ -88,13 +92,13 @@ hermes -c $HERMES_CONFIG \
   --new-client-connection
 ```
 
-```admonish note
+<Callout type="info">
 Note that the above `CHAIN_IDs` will depend on your own setup, so do check this for yourself!
-```
+</Callout>
 
 This command will ask you with the following message. You can continue with `y`.
 ```
-to re-use a pre-existing connection. [y/n]
+Would you like to re-use a pre-existing connection? [y/n]
 ```
 
 When the creation has been completed, you can see the channel IDs. For example, the following text shows that a channel with ID `7` has been created on Chain A `namada-test.0a4c6786dbda39f786`, and a channel with ID `12` has been created on Chain B `namada-test.647287156defa8728c`. You will need the channel IDs for a transfer over IBC. It means that you have to specify `channel-7` as a channel ID (The prefix `channel-` is always required) for a transfer from Chain A to Chain B. Also, you have to specify `channel-12` as a channel ID for a transfer from Chain B to Chain A.
@@ -155,7 +159,7 @@ Success: Channel {
 
 ### Run Hermes
 Once you run Hermes, it monitors instances via the nodes and relays packets according to monitored events.
-```bash
+```bash copy
 hermes -c $HERMES_CONFIG start
 ```
 
@@ -167,7 +171,7 @@ We will explain for two cases:
 - Set up local Namada instances for testing purposes
 
 Before running the following scripts, you have to build Namada and wasm.
-```bash
+```bash copy
 git clone [email protected]:anoma/namada.git
 cd namada
 git checkout v0.12.2
@@ -182,7 +186,7 @@ You can use scripts in [our Hermes branch](https://github.com/heliaxdev/ibc-rs/t
 The script `join-namada.sh` will set up two nodes for two instances, copy necessary files for Hermes, and make an account for Hermes on each ledger. Also, it will make a Hermes' config file `config_for_namada.toml` in the `ibc-rs` directory.
 
 The script requires the Namada directory path and chain IDs.
-```bash
+```bash copy
 git clone [email protected]:heliaxdev/ibc-rs.git
 git checkout $COMMIT # The branch is the same as our Hermes
 cd ibc-rs
@@ -191,7 +195,7 @@ cd ibc-rs
 
 You need to wait to sync each node with the corresponding instance.
 And, you have to transfer NAM token to the relayer account (the script will make an alias `relayer`) from the faucet or others on each instance because the fee for IBC transactions should be charged. For example, the following command transfers NAM from the faucet for namada-a instance which is created by the script. You can refer to [here](#transferring-assets-over-ibc) about `--base-dir` and `--ledger-address`.
-```bash
+```bash copy
 ${NAMADA_DIR}/target/release/namadac transfer \
   --base-dir ${IBC_RS}/data/namada-a/.namada \
   --source faucet \
@@ -203,7 +207,7 @@ ${NAMADA_DIR}/target/release/namadac transfer \
 ```
 
 After the sync, you can create the channel and start Hermes as we explain [above](#create-ibc-channel).
-```bash
+```bash copy
 # create a channel
 hermes -c $HERMES_CONFIG \
   create channel $CHAIN_A_ID \
@@ -219,21 +223,21 @@ hermes -c $HERMES_CONFIG start
 Each node data and configuration files are in `${IBC_RS}/data/namada-*/.namada`.
 
 In order to close any ledgers setup by the script, one can run
-```bash
+```bash copy
 killall namadan
 ```
 
 ### Set up local Namada instances
 The script `setup-namada.sh` will set up two instances with one validator node, copy necessary files for Hermes, and make an account for Hermes on each ledger. Also, it will make a Hermes' config file `config_for_namada.toml` in the `ibc-rs` directory.
-```bash
+```bash copy
 git clone [email protected]:heliaxdev/ibc-rs.git
 git checkout $COMMIT # The branch is the same as our Hermes
 cd ibc-rs
 ./scripts/setup-namada.sh $NAMADA_DIR $CHAIN_ID_A $CHAIN_ID_B
 ```
 
 In this case, we don't have to wait for sync. If the relayer account on each instance has enough balance, you can create a channel and start Hermes immediately as we explain [above](#create-ibc-channel). You find these chain IDs of the instances in the config file `config_for_namada.toml`. One can run `grep "id" ${HERMES_CONFIG}`.
-```bash
+```bash copy
 # create a channel
 hermes -c $HERMES_CONFIG \
   create channel $CHAIN_A_ID \
@@ -249,7 +253,7 @@ hermes -c $HERMES_CONFIG start
 Each node data and configuration files are in `ibc-rs/data/namada-*/.namada`.
 
 In order to close any ledgers setup by the script, one can run
-```bash
+```bash copy
 killall namadan
 ```
 
@@ -262,26 +266,26 @@ In order to do this by Namada's `ibc-transfer` command, we will need to know the
 One can run `grep "rpc_addr" ${HERMES_CONFIG}`.
 
 
-````admonish note
+<Callout>
  **For the local node ONLY**
 
  To find your ledger address for Chain A, you can run the following command
- ```bash
+ ```bash copy
  export BASE_DIR_A = "${IBC_RS}/data/namada-a/.namada"
  export LEDGER_ADDRESS_A = "$(grep "rpc_address" ${BASE_DIR_A}/${CHAIN_A_ID}/setup/validator-0/.namada/${CHAIN_A_ID}/config.toml)"
  ```
-````
+</Callout>
 
 And then the channel ID for this chain will depend on the order in which one created the channel. Since we have only opened one channel, the `channel-id` is `channel-0`, but as more are created, these increase by index incremented by 1. Please refer to [here](#create-ibc-channel).
 
 So one can go ahead and run
-```bash
+```bash copy
 export CHANNEL_ID = "channel-0"
 ```
 
 Such transfers from Chain A can be achieved by
 
-```bash
+```bash copy
 namadac --base-dir ${BASE_DIR_A}
     ibc-transfer \
         --amount ${AMOUNT} \
@@ -295,7 +299,7 @@ Where the above variables in `${VARIABLE}` must be substituted with appropriate
 
 E.g
 
-```bash
+```bash copy
 namadac --base-dir ${BASE_DIR_A}
     ibc-transfer \
     --amount 100 \