Introduction

Welcome to Namada's docs!

About Namada

Namada is a sovereign proof-of-stake blockchain, using Tendermint BFT consensus, that enables multi-asset private transfers for any native or non-native asset using a multi-asset shielded pool derived from the Sapling circuit.

To learn more about the protocol, we recommend the following resources:

• Introducing Namada: Shielded Transfers with Any Assets
• Namada's specifications

This book is written using mdBook, the source can be found in the Namada repository.

Contributions to the contents and the structure of this book should be made via pull requests.

Quick Start - How to run a validator node

About this guide

This guide is aimed at people interested in running a validator node and assumes basic knowledge of the terminal and how commands are used.

• Comments start with #:
  # this is a comment make sure you read them!
• Sample outputs start with an arrow:
  ➜ this is an example command line output useful for comparing

Install Namada

See the install guide for details on installing the Namada binaries. Commands in this guide will assume you have the Namada binaries (namada, namadan, namadaw, namadac) on your path.

Joining a network

See the testnets page for details of how to join a testnet. The rest of this guide will assume you have joined a testnet chain using the namadac utils join-network command.

Run a ledger node

We recommend this step with tmux, as you can keep the node running without needing the terminal open permanently. If not, skip to the subsequent step.

tmux

# inside the tmux/or not

namada ledger

# can detach the tmux (Ctrl-B then D)

This should sync your node to the ledger and will take a while (depending on your computer). Subsequent commands (generating an account, etc.) are unlikely to work until it is fully synced. Enquire the current block height with other participants to make sure you are synced in order to proceed.

Account

Generate a local key on disk

# first, we make a keypair and the implicit account associated with it
# namadaw address gen instead of key gen. Preferred because they both make a keypair but the former stores the implicit address for it too 

namadaw address gen \
  --alias example-implicit

➜ Enter encryption password: 
Successfully added a key and an address with alias: "example-implicit"

# use it to make an established account

To initialize an account operator on chain under the alias "example-established":

namadac init-account \
  --source example-implicit \
  --public-key example-implicit \
  --alias example-established

➜ Jan 06 22:22:19.864  INFO anoma_apps::cli::context: Chain ID: anoma-testnet-1.2.bf0181d9f7e0
Enter decryption password: 
Last committed epoch: 22386
Transaction added to mempool: Response { code: Ok, data: Data([]), log: Log("Mempool validation passed"), hash: transaction::Hash(9193C2B2C56AAB1B081B18DA0FBBD4B26C5EF7CEE4B35812ECCB1CC1D1443C45) }
Transaction applied with result: {
  "info": "Transaction is valid. Gas used: 6080310; Changed keys: #atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw/?, #atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw/ed25519_pk; VPs result: ",
  "height": "650627",
  "hash": "4FCCBCE5D4335C3A265B5CF22D5B8999451715F8146EB13194711B5EC70B612A",
  "code": "0",
  "gas_used": "6080310",
  "initialized_accounts": [
    "atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw"
  ]
}
The transaction initialized 1 new account
➜ Added alias example-established for address atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw

Let's transfer ourselves 1000 NAM from the faucet with the same alias using:

namadac transfer \
  --source faucet \
  --target example-established \
  --token NAM \
  --amount 1000 \
  --signer example-established

➜ Jan 06 22:24:32.926  INFO anoma_apps::cli::context: Chain ID: anoma-testnet-1.2.bf0181d9f7e0
➜ Looking-up public key of atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw from the ledger...
Enter decryption password: 
Last committed epoch: 22388
Transaction added to mempool: Response { code: Ok, data: Data([]), log: Log("Mempool validation passed"), hash: transaction::Hash(3A5CA1790FDF5150EF1478DE1E3B2D2F7189B0E5D396176E5E5BFC7A37C58D00) }
Transaction applied with result: {
  "info": "Transaction is valid. Gas used: 1504228; Changed keys: #atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5/balance/#atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw, #atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5/balance/#atest1v4ehgw36gc6yxvpjxccyzvphxycrxw2xxsuyydesxgcnjs3cg9znwv3cxgmnj32yxy6rssf5tcqjm3; VPs result:  Accepted: atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw, atest1v4ehgw36gc6yxvpjxccyzvphxycrxw2xxsuyydesxgcnjs3cg9znwv3cxgmnj32yxy6rssf5tcqjm3, atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5;",
  "height": "650706",
  "hash": "26AAE9D79F62EE8E62108D8D7689F4FFF12EA613AF29C7D4CDBEA999C28C6224",
  "code": "0",
  "gas_used": "1504228",
  "initialized_accounts": []
}

To get the balance of your account "example-established":

namadac balance \
  --owner example-established

Setting up the validator node

Initialize a validator account under any alias - in this example, "example-validator":

namadac init-validator \
  --alias example-validator \
  --source example-established

➜  Jan 06 22:26:29.927  INFO anoma_apps::cli::context: Chain ID: anoma-testnet-1.2.bf0181d9f7e0
Generating validator account key...

You will be asked to enter encryption passwords to generate a validator account key, consensus key and a staking reward account key. After entering the encryption password and a decryption password for the "example-established" account's key, the transaction should be added to the mempool and applied in a future block.

➜ Transaction added to mempool: Response { code: Ok, data: Data([]), log: Log("Mempool validation passed"), hash: transaction::Hash(F61D3D73CE7EFCC2021940A75B713C499D4942F820F6EC0F7924B70E7F2E751A) }
Transaction applied with result: {
  "info": "Transaction is valid. Gas used: 15139451; Changed keys: #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/voting_power, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/staking_reward_address, #atest1v4ehgw36xppnjsjzx4ryxs2zgc6nx33hxpq5zve4g5u5xdjpgfz5xv2pg3ryy3zrxyenssfcxn02yg/ed25519_pk, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/total_deltas, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/state, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/consensus_key, #atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/?, #atest1v4ehgw36xppnjsjzx4ryxs2zgc6nx33hxpq5zve4g5u5xdjpgfz5xv2pg3ryy3zrxyenssfcxn02yg/?, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator_set, #atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/ed25519_pk, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/address_raw_hash/DB3D27BF31382E6250C06119C3FDF4672BB3DF5A; VPs result:  Accepted: atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7;",
  "height": "650779",
  "hash": "3B6AA8F3E6F1951E21703CABA4CCD24F82F6D5C38674041A7AAA1B7227B1E6B8",
  "code": "0",
  "gas_used": "15139451",
  "initialized_accounts": [
    "atest1v4ehgw36xppnjsjzx4ryxs2zgc6nx33hxpq5zve4g5u5xdjpgfz5xv2pg3ryy3zrxyenssfcxn02yg",
    "atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd"
  ]
}
Added alias example-validator for address atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd.
Added alias example-validator-rewards for address atest1v4ehgw36xppnjsjzx4ryxs2zgc6nx33hxpq5zve4g5u5xdjpgfz5xv2pg3ryy3zrxyenssfcxn02yg.

The validator's addresses and keys were stored in the wallet:
  Validator address "example-validator"
  Staking reward address "example-validator-rewards"
  Validator account key "example-validator-key"
  Consensus key "example-validator-consensus-key"
  Staking reward key "example-validator-rewards-key"
The ledger node has been setup to use this validator's address and consensus key.

Once the init-validator transaction is applied in the block and the on-chain generated validator's address is stored in your wallet, you MUST restart the namada ledger node to start the node as a validator that you've just created.

When you restart the node, you might notice log message "This node is not a validator" from Tendermint. This is expected, because your validator doesn't yet have any stake in the PoS system.

We will now add some stake to your validator account.

Transfer 1000 NAM to your validator account ("example-validator"):

namadac transfer \
  --source example-established \
  --target example-validator \
  --token NAM \
  --amount 1000

➜  Jan 06 22:28:17.624  INFO anoma_apps::cli::context: Chain ID: anoma-testnet-1.2.bf0181d9f7e0
Looking-up public key of atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw from the ledger...
Enter decryption password: 
Last committed epoch: 22392
Transaction added to mempool: Response { code: Ok, data: Data([]), log: Log("Mempool validation passed"), hash: transaction::Hash(7FD43C7573B4A62E24DBB6C99EE6C7A107DF01CC5F947517B91742E6324AE58D) }
Transaction applied with result: {
  "info": "Transaction is valid. Gas used: 1989091; Changed keys: #atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5/balance/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd, #atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5/balance/#atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw; VPs result:  Accepted: atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd, atest1v4ehgw36ggmyzwp5g9prgsekgsu5y32z8ycnsvpeggcnys35gv65yvzxg3zrjwphgcu5gde4lvmstw, atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5;",
  "height": "650842",
  "hash": "D251AAB5D4CD9471DB4E11DA09DEF0F15E2A3EC95EE0EE2C76766839FC352394",
  "code": "0",
  "gas_used": "1989091",
  "initialized_accounts": []
}

Bond the 1000 NAM to "example-validator" using:

namadac bond \
  --validator example-validator \
  --amount 1000

➜ Jan 06 22:29:08.903  INFO anoma_apps::cli::context: Chain ID: anoma-testnet-1.2.bf0181d9f7e0
Looking-up public key of atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd from the ledger...
Enter decryption password: 
Last committed epoch: 22393
Transaction added to mempool: Response { code: Ok, data: Data([]), log: Log("Mempool validation passed"), hash: transaction::Hash(2B814FE404F6F1D8C07CC3A51AA3038C193810251B9C50107B79698ED15A4EDC) }
Transaction applied with result: {
  "info": "Transaction is valid. Gas used: 3734939; Changed keys: #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/total_deltas, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/total_voting_power, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator_set, #atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5/balance/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd, #atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5/balance/#atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/validator/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/voting_power, #atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7/bond/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd/#atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd; VPs result:  Accepted: atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd, atest1v9hx7w362pex7mmxyphkvgznw3skkefqyqszqgpqyqszqgpqyqszqgpqyqszqgpqyqszqgpqq8ylv7, atest1v4ehgw36x3prswzxggunzv6pxqmnvdj9xvcyzvpsggeyvs3cg9qnywf589qnwvfsg5erg3fkl09rg5;",
  "height": "650869",
  "hash": "14F5C67D27E2F9695EA40ABEA2DEC69F5B0FFEF5DFD7CB7D0FC397CC8A618BA8",
  "code": "0",
  "gas_used": "3734939",
  "initialized_accounts": []
}

Check your bond:

namadac bonds \
  --validator example-validator

➜ Jan 06 22:30:42.798  INFO anoma_apps::cli::context: Chain ID: anoma-testnet-1.2.bf0181d9f7e0
Last committed epoch: 22394
Self-bonds:
  Active from epoch 22395: Δ 1000
Bonds total: 1000

Check the voting power - this will be 0 until the active-from epoch is reached (in this case 22395):

namadac voting-power \
  --validator example-validator

➜ Jan 06 22:31:24.908  INFO anoma_apps::cli::context: Chain ID: anoma-testnet-1.2.bf0181d9f7e0
Last committed epoch: 22395
Validator atest1v4ehgw36g3prx3pjxapyvve3xvury3fkxg6nqsesxccnzw2rxdryg335xcmnysjzxdzyvd2pamfmwd is active, voting power: 1
Total voting power: 44

Note that with the above command, you can also specify --epoch argument to check a future epoch.

Congratulations, you have set up a validator node!

User Guide

Welcome to Namada user guide!

This guide is intended to help you find how to install, operate and interact with the Namada ledger node, the client and the wallet.

Install Namada

Hardware Requirements

This section covers the minimum and recommended hardware requirements for engaging with the Namada as a validator node.

Minimal Hardware Requirements

There are different ways to install Namada:

• From Source
• From Binaries
• From Docker

From Source

If you'd like to install Namada from source you will have to install some dependencies first: Rust, Git, Clang, OpenSSL and LLVM.

First, install Rust by following the instructions from the official page.

At the end of the installation, make sure that Cargo's bin directory ($HOME/.cargo/bin) is available on your PATH environment variable. You can either restart your shell or run source $HOME/.cargo/env to continue.

If you already have Rust installed, make sure you're using the latest version by running:

rustup update

Then, install the remaining dependencies.

Ubuntu: running the following command should install everything needed:

sudo apt-get install -y make git-core libssl-dev pkg-config libclang-12-dev build-essential

Mac: installing the Xcode command line tools should provide you with almost everything you need:

xcode-select --install

Now, that you have all dependencies installed you can clone the source code from the Namada repository and build it with:

git clone https://github.com/anoma/namada.git
cd namada 
make install

From Binaries

If you'd like to install Namada from binaries you will have to install some dependencies first: Tendermint 0.34.x and GLIBC v2.29 or higher.

Let's install Tendermint.

You can either follow the instructions on the Tendermint guide or download the get_tendermint.sh script from the Namada repository and execute it (will ask you for root access):

curl -LO https://raw.githubusercontent.com/namada/anoma/main/scripts/install/get_tendermint.sh
chmod +x get_tendermint.sh
./get_tendermint.sh

Finally, you should have GLIBC v2.29 or higher.

MacOS: the system-provided glibc should be recent enough.

Ubuntu 20.04: this is installed by default and you don't have to do anything more.

Ubuntu 18.04: glibc has v2.27 by default which is lower than the required version to run Namada. We recommend to directly install from source or upgrade to Ubuntu 19.04, instead of updating glibc to the required version, since the latter way can be a messy and tedious task. In case, updating glibc would interest you this website gives you the steps to build the package from source.

Now, that you have all dependencies installed you can download the latest binary release from our releases page by choosing the appropriate architecture.

From Docker

Go to heliaxdev dockerhub account and pull the image.

Getting started

This guide assumes that the Namada binaries are installed and available on path. These are:

• namada: The main binary that can be used to interact with all the components of Namada
• namadan: The ledger and intent gossiper node
• namadac: The client
• namadaw: The wallet

The main binary namada has sub-commands for all of the other binaries:

• namada client = namadac
• namada node = namadan
• namada wallet = namadaw

To explore the command-line interface, add --help argument at any sub-command level to find out any possible sub-commands and/or arguments.

Join a network

After you installed Namada, you will need to join a live network (e.g. testnet) to be able to interact with a chain and execute most available commands. You can join a network with the following command:

namada client utils join-network --chain-id=<network-chain-id>

To join a testnet, head over to the testnets section for details on how to do this.

Start your node

As soon as you are connected to a network, you can start your local node with:

namada ledger

Learn more about the configuration of the Ledger in The Ledger section

Namada Wallet Guide

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 with NAM tokens on the Namada blockchain.

Check out the different options to generate a wallet:

• File System Wallet
• Web Wallet
• Paper Wallet
• Hardware Wallet

Manage keypairs

Namada uses ed25519 keypairs for signing cryptographic operations on the blockchain.

To manage your keys, various sub-commands are available under:

namada wallet key

Generate a keypair

Generate a keypair with a given alias and derive the implicit address from its public key:

namada wallet key gen --alias my-key

List all known keys

namada wallet key list

Manage addresses

All accounts in Namada have an unique address, exactly one Validity Predicate and optionally any additional data in its dynamic storage sub-space.

There are currently 3 types of account addresses:

• Established: Used for accounts that allow the deployment of custom validation logic. These must be created on-chain via a transaction (e.g. initialize an account). The address is generated on-chain and is not known until the transaction is applied.
• Implicit (not fully supported yet): Derived from your kepair, it can be used to authorize certain transactions from the account. They can be used as recipients of transactions even if the account has not been used on-chain before.
• Internal: Special internal accounts, such as protocol parameters account, PoS and IBC.

To manage addresses, similar to keys, various sub-commands are available:

namada wallet address

Generate an implicit address

namada wallet address gen --alias my-account

List all known addresses

namada wallet address list

File System Wallet

By default, the Namada Wallet is stored under .anoma/{chain_id}/wallet.toml where keys are stored encrypted. You can change the default base directory path with --base-dir and you can allow the storage of unencrypted keypairs with the flag --unsafe-dont-encrypt.

If the wallet doesn't already exist, it will be created for you as soon as you run a command that tries to access the wallet. A newly created wallet will be pre-loaded with some internal addresses like pos, pos_slash_pool, masp and more.

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 ANOMA_WALLET_PASSWORD with value of the actual password.
• File: by exporting an ENV variable called ANOMA_WALLET_PASSWORD_FILE with value containing the path to a file containing the password.

Web Wallet

The Web Wallet for Namada is currently in closed beta.

Paper Wallet

At the moment, the Namada CLI doesn't provide a Paper Wallet.

Hardware Wallet

The Ledger Hardware Wallet is currently in development.

Send and Receive NAM tokens

In Namada, tokens are implemented as accounts with the Token Validity Predicate. It checks that its total supply is preserved in any transaction that uses this token. Your wallet will be pre-loaded with some token addresses that are initialized in the genesis block.

Initialize an established account

If you already have a key in your wallet, you can skip this step. Otherwise, generate a new keypair now.

Then, send a transaction to initialize your new established account and save its address with the alias my-new-acc. The my-key public key will be written into the account's storage for authorizing future transactions. We also sign this transaction with my-key.

namada client init-account \
  --alias my-new-acc \
  --public-key my-key \
  --source my-key

Once this transaction has been applied, the client will automatically see the new address created by the transaction and add it to your Wallet with the chosen alias my-new-acc.

This command uses the prebuilt User Validity Predicate.

Send a Payment

To submit a regular token transfer from your account to the validator-1 address:

namada client transfer \
  --source my-new-acc \
  --target validator-1 \
  --token NAM \
  --amount 10

This command will attempt to find and use the key of the source address to sign the transaction.

See your balance

To query token balances for a specific token and/or owner:

namada client balance --token NAM --owner my-new-acc

See every known addresses' balance

You can see the token's addresses known by the client when you query all tokens balances:

namada client balance

The Namada Ledger

To start a local Namada ledger node, run:

namada ledger

Note that you need to have joined a network before you start the ledger. It throws an error if no network has been configured.

The node will attempt to connect to the persistent validator nodes and other peers in the network, and synchronize to the latest block.

By default, the ledger will store its configuration and state in the .anoma directory relative to the current working directory. You can use the --base-dir CLI global argument or ANOMA_BASE_DIR environment variable to change it.

The ledger also needs access to the built WASM files that are used in the genesis block. These files are included in release and shouldn't be modified, otherwise your node will fail with a consensus error on the genesis block. By default, these are expected to be in the wasm directory, relative to the current working directory. This can also be set with the --wasm-dir CLI global argument, ANOMA_WASM_DIR environment variable or the configuration file.

The ledger configuration is stored in .anoma/{chain_id}/config.toml (with default --base-dir). It is created when you join the network. You can modify that file to change the configuration of your node. All values can also be set via environment variables. Names of the recognized environment variables are derived from the configuration keys by: uppercase every letter of the key, insert . or __ for each nested value and prepend ANOMA_. For example, option p2p_pex in [ledger.tendermint] can be set by ANOMA_LEDGER__TENDERMINT__P2P_PEX=true|false or ANOMA_LEDGER.TENDERMINT.P2P_PEX=true|false in the environment (Note: only the double underscore form can be used in Bash, because Bash doesn't allow dots in environment variable names).

🔏 Interacting with the Proof-of-Stake system

The Namada Proof of Stake system uses the NAM token as the staking token. It features delegation to any number of validators and customizable validator validity predicates.

PoS Validity Predicate

The PoS system is implemented as an account with the PoS Validity Predicate that governs the rules of the system. You can find its address in your wallet:

namada wallet address find --alias PoS

Epochs

The system relies on the concept of epochs. An epoch is a range of consecutive blocks identified by consecutive natural numbers. Each epoch lasts a minimum duration and includes a minimum number of blocks since the beginning of the last epoch. These are defined by protocol parameters.

To query the current epoch:

namada client epoch

Delegating

You can delegate to any number of validators at any time. When you delegate tokens, the delegation won't count towards the validator's stake (which in turn determines its voting power) until the beginning of epoch n + 2 in the current epoch n (the literal 2 is set by PoS parameter pipeline_len). The delegated amount of tokens will be deducted from your account immediately, and will be credited to the PoS system's account.

To submit a delegation that bonds tokens from the source address to a validator with alias validator-1:

namada client bond \
  --source my-new-acc \
  --validator validator-1 \
  --amount 12.34

You can query your delegations:

namada client bonds --owner my-new-acc

The result of this query will inform the epoch from which your delegations will be active.

Because the PoS system is just an account, you can query its balance, which is the sum of all staked tokens:

namada client balance --owner PoS

Slashes

Should a validator exhibit punishable behavior, the delegations towards this validator are also liable for slashing. Only the delegations that were active in the epoch in which the fault occurred will be slashed by the slash rate of the fault type. If any of your delegations have been slashed, this will be displayed in the bonds query. You can also find all the slashes applied with:

namada client slashes

Unbounding

While your tokens are being delegated, they are locked-in the PoS system and hence are not liquid until you withdraw them. To do that, you first need to send a transaction to “unbond” your tokens. You can unbond any amount, up to the sum of all your delegations to the given validator, even before they become active.

To submit an unbonding of a delegation of tokens from a source address to the validator:

namada client unbond \
  --source my-new-acc \
  --validator validator-1 \
  --amount 1.2

When you unbond tokens, you won't be able to withdraw them immediately. Instead, tokens unbonded in the epoch n will be withdrawable starting from the epoch n + 6 (the literal 6 is set by PoS parameter unbonding_len). After you unbond some tokens, you will be able to see when you can withdraw them via bonds query:

namada client bonds --owner my-new-acc

When the chain reaches the epoch in which you can withdraw the tokens (or anytime after), you can submit a withdrawal of unbonded delegation of tokens back to your account:

namada client withdraw \
  --source my-new-acc \
  --validator validator-1

Upon success, the withdrawn tokens will be credited back your account and debited from the PoS system.

Validators' Voting Power

To see all validators and their voting power, you can query:

namada client voting-power

With this command, you can specify --epoch to find the voting powers at some future epoch. Note that only the voting powers for the current and the next epoch are final.

📒 PoS Validators

Generate a validator account

To register a new validator account, run:

namada client init-validator \
  --alias my-validator \
  --source my-new-acc

This command will generate the keys required for running a validator:

• Consensus key, which is used in signing blocks in Tendermint.
• Validator account key for signing transactions on the validator account, such as token self-bonding, unbonding and withdrawal, validator keys, validity predicate, state and metadata updates.
• Staking reward account key for signing transactions on the staking reward accounts. More on this account below.

Then, it submits a transaction to the ledger that generates two new accounts with established addresses:

• A validator account with the main validator address, which can be used to receive new delegations
• A staking reward account, which will receive rewards for participation in the PoS system. In the future, the validity predicate of this account will be able to control how the rewards are to be distributed to the validator's delegators. Staking rewards are not yet implemented.

These keys and aliases of the addresses will be saved in your wallet. Your local ledger node will also be setup to run this validator, you just have to shut it down with e.g. Ctrl + C, then start it again with the same command:

namada ledger

The ledger will then use the validator consensus key to sign blocks, should your validator account acquire enough voting power to be included in the active validator set. The size of the active validator set is limited to 128 (the limit is set by the PoS max_validator_slots parameter).

Note that the balance of NAM tokens that is in your validator account does not count towards your validator's stake and voting power:

namada client balance --owner my-validator --token NAM

That is, the balance of your account's address is a regular liquid balance that you can transfer using your validator account key, depending on the rules of the validator account's validity predicate. The default validity predicate allows you to transfer it with a signed transaction and/or stake it in the PoS system.

Self-bonding

You can submit a self-bonding transaction of tokens from a validator account to the PoS system with:

namada client bond \
  --validator my-validator \
  --amount 3.3

Determine your voting power

A validator's voting power is determined by the sum of all their active self-bonds and delegations of tokens, with slashes applied, if any, divided by 1000 (PoS votes_per_token parameter, with the current value set to 10‱ in parts per ten thousand).

The same rules apply to delegations. When you self-bond tokens, the bonded amount won't count towards your validator's stake (which in turn determines your power) until the beginning of epoch n + 2 in the current epoch n. The bonded amount of tokens will be deducted from the validator's account immediately and will be credited to the PoS system's account.

While your tokens are being self-bonded, they are locked-in the PoS system and hence are not liquid until you withdraw them. To do that, you first need to send a transaction to “unbond” your tokens. You can unbond any amount, up to the sum of all your self-bonds, even before they become active.

Self-unbounding

To submit an unbonding of self-bonded tokens from your validator:

namada client unbond \
  --validator my-validator \
  --amount 0.3

Again, when you unbond tokens, you won't be able to withdraw them immediately. Instead, tokens unbonded in the epoch n will be withdrawable starting from the epoch n + 6. After you unbond some tokens, you will be able to see when you can withdraw them via bonds query:

namada client bonds --validator my-validator

When the chain reaches the epoch in which you can withdraw the tokens (or anytime after), you can submit a withdrawal of unbonded tokens back to your validator account:

namada client withdraw --validator my-validator

Governance

The Namada governance mechanism gives users the possibility to upgrade the protocol dynamically.

There are two different mechanism to create a proposal:

• On-chain proposals: Proposal is voted on and tallied on-chain. This can optionally include proposal code to be executed if the proposal is accepted.
• Off-chain proposals

On-chain proposals

Create a proposal

Assuming you have an account with at least 500 NAM token (in this example we are going to use my-new-acc), lets get the corresponding address

namada wallet address find --alias `my-new-acc`

Now, we need to create a json file proposal.json holding the content of our proposal. Copy the below text into a json file.

{
    "content": {
        "title": "Proposal title",
        "authors": "email@proposal.n",
        "discussions-to": "www.github.com/anoma/aip/1",
        "created": "2022-03-10T08:54:37Z",
        "license": "MIT",
        "abstract": "Ut convallis eleifend orci vel venenatis. Duis vulputate metus in lacus sollicitudin vestibulum. Suspendisse vel velit ac est consectetur feugiat nec ac urna. Ut faucibus ex nec dictum fermentum. Morbi aliquet purus at sollicitudin ultrices. Quisque viverra varius cursus. Praesent sed mauris gravida, pharetra turpis non, gravida eros. Nullam sed ex justo. Ut at placerat ipsum, sit amet rhoncus libero. Sed blandit non purus non suscipit. Phasellus sed quam nec augue bibendum bibendum ut vitae urna. Sed odio diam, ornare nec sapien eget, congue viverra enim.",
        "motivation": "Ut convallis eleifend orci vel venenatis. Duis vulputate metus in lacus sollicitudin vestibulum. Suspendisse vel velit ac est consectetur feugiat nec ac urna. Ut faucibus ex nec dictum fermentum. Morbi aliquet purus at sollicitudin ultrices.",
        "details": "Ut convallis eleifend orci vel venenatis. Duis vulputate metus in lacus sollicitudin vestibulum. Suspendisse vel velit ac est consectetur feugiat nec ac urna. Ut faucibus ex nec dictum fermentum. Morbi aliquet purus at sollicitudin ultrices. Quisque viverra varius cursus. Praesent sed mauris gravida, pharetra turpis non, gravida eros.",
        "requires": "2"
    },
    "author": "TODO",
    "voting_start_epoch": 3,
    "voting_end_epoch": 6,
    "grace_epoch": 12,
    "proposal_code_path": "./wasm_for_tests/tx_no_op.wasm"
}

You should change the value of:

• Author field with the address of my-new-acc.
• voting_start_epoch with future epoch (must be a multiple of 3)
• voting_end_epoch with an epoch greater of voting_start_epoch, multiple of 3.
• grace_epoch with an epoch greater of voting_end_epoch + 6
• proposal_code_path with the absolute path of the wasm file to execute (or remove the field completely)

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):

namada client init-proposal --data-path proposal.json 

The transaction should have been accepted. You can query all the proposals with:

namada client query-proposal

or a single proposal with

namada client query-proposal --proposal-id 0

where 0 is the proposal id.

Vote a proposal

Only validators and delegators can vote. Assuming you have a validator or a delegator account (in this example we are going to use validator), you can send a vote with the following command:

namada client vote-proposal \
    --proposal-id 0 \
    --vote yay \
    --signer validator

where --vote can be either yay or nay.

Check the result

As soon as the ledger reaches epoch definied in the json as voting_end_epoch, you can no longer vote. 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:

namada client query-proposal --proposal-id 0

or to just check the result:

namada client query-proposal-result --proposal-id 0

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.

Create proposal

Create the same json file as in the on-chain proposal and use the following command:

namada client init-proposal \
    --data-path proposal.json \
    --offline

This command will create a proposal file same directory where the command was launched.

Vote proposal

To vote an offline proposal use the following command:

namada client vote-proposal --data-path proposal \
    --vote yay \
    --signer validator \
    --offline

This command will create a proposal-vote-${address} file (where address is the --signer address).

Tally off-chain proposal

To compute the tally for an offline proposal we need to collect

• proposal file (must have this name)
• all the proposal-vote-${address} files

All those files will have to be in a folder (lets call it offline-proposal).

Now you can use the following command:

namada client query-proposal-result \
    --offline \
    --data-path `offline-proposal`

which will tell you the proposal result.

Private transfers

In Namada, private transfers are enabled by the Multi-Asset Shielded Pool (MASP). The MASP is a zero-knowledge circuit (zk-SNARK) that extends the Zcash Sapling circuit to add support for sending arbitrary assets. All assets in the pool share the same anonymity set, this means that the more transactions are issued to MASP, the stronger are the privacity guarantees.

Using MASP

If you are familiar to Zcash, the set of interactions you can execute with the MASP are similar:

• Shielding transfers: transparent to shielded addresses
• Shielded transfers: shielded to shielded addresses
• Deshielding transfers: shielded to transparent addresses

Shielding transfers

To try out shielded transfers, first you need to be in possession of a transparent account with some token balance.

Create your transparent account

Generate an implicit account:

namadaw address gen --alias [your-implicit-account-alias]

Then, create an established account on chain using the implicit account you've just generated:

namadac init-account \
    --source [your-implicit-account-alias] \
    --public-key [your-implicit-account-alias] \
    --alias [your-established-account-alias]

Get tokens from the Testnet Faucet

namadac transfer \
    --token btc \
    --amount 1000 \
    --source faucet \
    --target [your-established-account-alias] \
    --signer [your-established-account-alias]

Now that you have a transparent account with some tokens, you can generate a Spending Key to hold your shielded balances.

Generate your Spending Key

You can randomly generate a new Spending Key with:

namadaw masp gen-key --alias [your-spending-key-alias]

Create a new payment address

To create a payment address from your Spending key, use:

namadaw masp gen-addr \
    --key [your-spending-key-alias] \
    --alias [your-payment-address-alias]

Send your shielding transfer

Once you have a payment address, transfer a balance from your transparent account to your shielded account with something like:

namadac transfer \
    --source [your-established-account-alias] \
    --target [your-payment-address-alias] \
    --token btc \
    --amount 100

View your balance

Once this transfer goes through, you can view your Spending Key's balance:

namadac balance --owner [your-spending-key-alias]

Shielded transfers

Now that you have a shielded balance, it can be transferred to a another shielded address:

namadac transfer \
    --source [your-spending-key-alias] \
    --target [some-payment-address] \
    --token btc \
    --amount 50 \
    --signer [your-established-account-alias]

Deshielding tranfers

You can also transfer back your balance to some transparent account:

namadac transfer \
    --source [your-spending-key-alias] \
    --target [some-transparent-address] \
    --token btc \
    --amount 50 \
    --signer [your-established-account-alias]

Shielded Address/Key Generation

Spending Key Generation

The client should be able to generate a spending key and automatically derive a viewing key for it. The spending key should be usable as the source of a transfer. The viewing key should be usable to determine the total unspent notes that the spending key is authorized to spend. It should not be possible to directly or indirectly use the viewing key to spend funds. Below is an example of how spending keys should be generated:

namadaw --masp gen-key --alias my-sk

Payment Address Generation

The client should be able to generate a payment address from a spending key or viewing key. This payment address should be usable to send notes to the originating spending key. It should not be directly or indirectly usable to either spend notes or view shielded balances. Below are examples of how payment addresses should be generated:

namadaw masp gen-addr --alias my-pa1 --key my-sk
namadaw masp gen-addr --alias my-pa2 --key my-vk

Manual Key/Address Addition

The client should be able to directly add raw spending keys, viewing keys, and payment addresses. Below are examples of how these objects should be added:

namadaw masp add --alias my-sk --value xsktest1qqqqqqqqqqqqqq9v0sls5r5de7njx8ehu49pqgmqr9ygelg87l5x8y4s9r0pjlvu69au6gn3su5ewneas486hdccyayx32hxvt64p3d0hfuprpgcgv2q9gdx3jvxrn02f0nnp3jtdd6f5vwscfuyum083cvfv4jun75ak5sdgrm2pthzj3sflxc0jx0edrakx3vdcngrfjmru8ywkguru8mxss2uuqxdlglaz6undx5h8w7g70t2es850g48xzdkqay5qs0yw06rtxcvedhsv
namadaw masp add --alias my-vk --value xfvktest1qqqqqqqqqqqqqqpagte43rsza46v55dlz8cffahv0fnr6eqacvnrkyuf9lmndgal7erg38awgq60r259csg3lxeeyy5355f5nj3ywpeqgd2guqd73uxz46645d0ayt9em88wflka0vsrq29u47x55psw93ly80lvftzdr5ccrzuuedtf6fala4r4nnazm9y9hq5yu6pq24arjskmpv4mdgfn3spffxxv8ugvym36kmnj45jcvvmm227vqjm5fq8882yhjsq97p7xrwqt7n63v
namadaw masp add --alias my-pa --value patest10qy6fuwef9leccl6dfm7wwlyd336x4y32hz62cnrvlrl6r5yk0jnw80kus33x34a5peg2xc4csn

Making Shielded Transactions

Shielding Transactions

The client should be able to make shielding transactions by providing a transparent source address and a shielded payment address. The main transparent effect of such a transaction should be a deduction of the specified amount from the source address, and a corresponding increase in the balance of the MASP validity predicate's address. The gas fee is charged to the source address. Once the transaction is completed, the spending key that was used to generate the payment address will have the authority to spend the amount that was send. Below is an example of how a shielding transacion should be made:

namadac transfer --source Bertha --amount 50 --token BTC --target my-pa

Unshielding Transactions

The client should be able to make unshielding transactions by providing a shielded spending key and a transparent target address. The main transparent effect of such a transaction should be a deduction of the specified amount from the MASP validity predicate's address and a corresponding increase in the transparent target address. The gas fee is charged to the signer's address (which should default to the target address). Once the transaction is complete, the spending key will no longer be able to spend the transferred amount. Below is an example of how an unshielding transaction should be made:

namadac transfer --target Bertha --amount 45 --token BTC --source my-sk

Shielded Transactions

The client should be able to make shielded transactions by providing a shielded spending key and a shielded payment address. There should be no change in the transparent balance of the MASP validity predicate's address. The gas fee is charged to the signer's address. Once the transaction is complete, the spending key will no longer be able to spend the transferred amount, but the spending key that was used to (directly or indirectly) generate the payment address will. Below is an example of how a shielded transaction should be made:

namadac transfer --source my-sk --amount 5 --token BTC --target your-pa

Viewing Shielded Balances

The client should be able to view shielded balances. The most general output should be a list of pairs, each denoting a token type and the unspent amount of that token present at each shielded address whose viewing key is represented in the wallet. Note that it should be possible to restrict the balance query to check only a specific viewing key or for a specific token type. Below are examples of how balance queries should be made:

namadac balance
namadac balance --owner my-key
namadac balance --owner my-key --token BTC
namadac balance --token BTC

Listing Shielded Keys/Addresses

The wallet should be able to list all the spending keys, viewing keys, and payment addresses that it stores. Below are examples of how the wallet's storage should be queried:

namadaw masp list-keys
namadaw masp list-keys --unsafe-show-secret
namadaw masp list-keys --unsafe-show-secret --decrypt
namadaw masp list-addrs

Finding Shielded Keys/Addresses

The wallet should be able to find any spending key, viewing key or payment address when given its alias. Below are examples of how the wallet's storage should be queried:

namadaw masp find --alias my-alias
namadaw masp find --alias my-alias --unsafe-show-secret

Genesis validator setup

A genesis validator is one which is a validator right from the first block of the chain - i.e. at genesis. The details of genesis validators are hardcoded into the genesis file that is distributed to all users who want to interact with a chain.

Prerequisites

• a machine that meets the requirements for running a validator node
• an associated public IPv4 address with ports 26656 reachable from anywhere for P2P connections

Pre-genesis

To setup all the required keys for a genesis validator for an upcoming network, you can execute the following command with an alias of your choice. Note that this alias is public (the address of your validator account will be visible in every wallet) and must be unique within the network.

You must also provide a static {IP:port} to the --net-address argument of your future node's P2P address.

export ALIAS="1337-validator"
namada client utils init-genesis-validator \
    --alias $ALIAS \
    --net-address 1.2.3.4:26656

After generating your keys, the command will print something like this:

Pre-genesis TOML written to .anoma/pre-genesis/1337-validator/validator.toml

This file is the public configuration of your validator. You can safely share this file with the network's organizer, who is responsible for setting up and publishing the finalized genesis file and Namada configuration for the chain.

Note that the wallet containing your private keys will also be written into this directory.

After network config release

Once the network is finalized, a new chain ID will be created and released on anoma-network-config/releases (a custom configs URL can be used instead with ANOMA_NETWORK_CONFIGS_SERVER env var). You can use it to setup your genesis validator node for the --chain-id argument in the command below.

namada client utils join-network \
    --chain-id $CHAIN_ID \
    --genesis-validator $ALIAS

This command will use your pre-genesis wallet for the given chain and take care of setting up Namada with Tendermint.

If you run this command in the same directory that you ran namada client utils init-genesis-validator, it should find the pre-genesis wallet for you, otherwise you can pass the path to the pre-genesis directory using --pre-genesis-path. e.g.

namada client utils join-network \
    --chain-id $CHAIN_ID \
    --pre-genesis-path workspace/.anoma/pre-genesis/$ALIAS

Once setup, you can start the ledger as usual with e.g.:

namada ledger

Required keys

• Account key: Can be used to sign transactions that require authorization in the default validator validity predicate, such as a balance transfer.
• Staking rewards key: Can be used to sign transactions on the PoS staking rewards account.
• Protocol key: This key is used by the validator's ledger itself to sign protocol transaction on behalf of the validator.
• DKG key: Special key needed for participation in the DKG protocol
• Consensus key: Used in Tendermint consensus layer. Currently, this key is written to a file which is read by Tendermint.
• Tendermint node key: This key is used to derive Tendermint node ID for P2P connection authentication. This key is also written to a file which is read by Tendermint.

Applying to be a genesis validator

Before a testnet launches, you can apply to be a genesis validator.

Set up

Follow this guide on how to generate your "pre-genesis" validator files.

After this, you'll have a validator.toml file, the contents of which will look something like the following:

[validator.1337-validator]
consensus_public_key = "00056fff5232da385d88428ca2bb2012a4d83cdf5c697864dde34b393333a72268"
account_public_key = "00f1bd321be2e23b9503653dd50fcd5177ca43a0ade6da60108eaecde0d68abdc8"
staking_reward_public_key = "005725f952115838590fc7c5dd9590bc054ac4bd5af55672a40df4ac7dca50ce97"
protocol_public_key = "0054c213d2f8fe2dd3fc5a41a52fd2839cb49643d960d7f75e993202692c5d8783"
dkg_public_key = "6000000054eafa7320ddebf00c9487e5f7ea5107a8444f042b74caf9ed5679163f854577bf4d0992a8fd301ec4f3438c9934c617a2c71649178e536f7e2a8cdc1f8331139b7fd9b4d36861f0a9915d83f61d7f969219f0eba95bb6fa45595425923d4c0e"
net_address = "1.2.3.4:26656"
tendermint_node_key = "00e1a8fe1abceb700063ab4558baec680b64247e2fd9891962af552b9e49318d8d"

This file contains only public information and is safe to share publicly.

Submitting the config

If you want to be a genesis validator for a testnet, please make a pull request to https://github.com/anoma/namada-testnets adding your validator.toml file to the relevant directory (e.g. namada-close-quarters-testnet-1/ for the namada-cq-1 testnet), renaming it to $alias.toml. e.g. if you chose your alias to be "bertha", submit the file with the name bertha.toml. You can see what an example PR looks like here.

Testnets

This section describes how to connect to the various testnets and to test selected features.

You may need to be using namada binaries built from a specific commit in order to interact with specific testnets. Use the below command with the chain ID of the testnet you want to join.

namada client utils join-network --chain-id=$NAMADA_CHAIN_ID

Current testnets

• Namada Close Quarters Testnet 1

Namada Close Quarters Testnet 1

This testnet introduces the following new features:

• on-chain governance - create and vote for proposals both onchain and offchain
• MASP (multi-asset shielded pool) transfers - make private transfers of any Namada token

Future testnets will include more features as described in the Namada spec, like IBC (inter-blockchain communication protocol), bridging to the Ethereum blockchain and more.

Chain information

Latest values regarding the testnet that would be useful to have in your shell:

export NAMADA_CHAIN_ID='namada-cq-2.a6ebeb093671093b21'
export NAMADA_COMMIT='f1afdffd5e43ad4bb448db7bf5bc1e23464350f7'

You will need to compile the binaries from source yourself, make sure you have checked out the specific commit $NAMADA_COMMIT to build from, then follow the building from source guide.

Status

• 2022-05-05: The chain has been setup to start today at 12:00 CET.
• 2022-05-02: We are currently preparing to launch the chain. Applications are open for people to be genesis validators.

Namada Trusted Setup

The Namada Trusted Setup Ceremony generates the public parameters for the Multi-Asset Shielded Pool (MASP) circuit and guarantees its security. Under the hood, a trusted setup ceremony is a Multi-Party Computation (MPC) that lets many participants contribute randomness to the public parameters in a trustless manner. The setup is secure, as long as one participant is honest.

Participate in Namada Trusted Setup

If you are interested in participating in the ceremony head over to the Namada website to be notified about the launch.

To contribute during the ceremony, you can install and use the canonical client implementation below. It computes the parameters for the MASP and communicates with the ceremony's coordinator. Also, check out the Contribution Flow.

Building and contributing from source

Via command-line, install Rust by entering the following command:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

If you already have Rust installed, make sure it is the most up-to-date version updated:

rustup update

Once Rust is installed, clone the Namada Trusted Setup Ceremony GitHub repository and change directories into namada-setup-ceremony:

git clone https://github.com/anoma/namada-trusted-setup.git
cd namada-trusted-setup

Build the binaries and start your contribution with:

cargo run --release --bin phase1 --features cli contribute https://contribute.namada.net

Contribution Flow

To enforce security, the Namada Trusted Setup accepts as many diverse contributions as possible: anonymous contributions, original source of randomness, alternative client, computation of the parameters on an airgapped or offline machine.

That's why the client gives you the choice of multiple options during your contribution.

The canonical client follows these steps:

1. It generates a BIP39 24 words mnemonic that serves as a seed for your ed25519 key pair. Keep it safely! It's the only way to generate your key pair and claim your rewards if you participate in the incentivized program.
2. You will be asked if you want to participate in the incentivized program. If you want to participate, you will need to provide your legal name and a real email address so you can be contacted in the future for a KYC. The other option is to contribute anonymously.
3. If you agreed to the previous question, you will be asked if you want to participate in the creative contest. If you agree, you will be contacted after the ceremony by email to prove your creative contribution.
4. You will join the ceremony's queue.
5. When it is your turn, the challenge file will be downloaded and you will be asked if you want to contribute on an offline machine or not and if you want to give your own 32 bytes seed of randomness or simply use the default method to generate randomness.
6. If you chose to pursue on the same machine, the client will start contributing and when done it will upload the file to the server.
7. That's all! Thanks for your contribution.