# Introduction # What is PundiX (Pundi X Chain) `PundiX` is the name of the Cosmos SDK application for Pundi X Chain. About the PundiX Core: The PundiX Core also known as a Hub is the first Core to be launched on the PundiX Network. The role of a Core is to facilitate transfers between blockchains. If a blockchain connects to a Core via inter blockchain communication (IBC), it automatically gains access to all the other blockchains that are connected to that Core. The PundiX Core is a public Proof-of-Stake chain. It's native coin is the PUNDIX. * `pundixd`: The PundiX Daemon and command-line interface (CLI) runs a full-node of the `pundixd` application. Next, learn how to [install Pundi X Chain](/getting-started/installation-pundix). # Install PundiX (Pundi X Chain) This guide will explain how to install the `pundixd` CLI onto your system. With this installed on a server, you can participate on the mainnet as either a [Full Node](https://github.com/pundix/docs/blob/main/getting-started/setup-node/README.md) or a [Validator](https://github.com/pundix/docs/blob/main/validators/setting-up-a-validator-for-pundix.md). ## Hardware Requirements We recommend the following for running PundiX: * 4 or more CPU cores * At least 500G of disk storage * At least 8G of memory * At least 10mbps network bandwidth To see a [quick cloud setup](/pundix-tutorials/cloud-setup) on how to setup and deploy it on the cloud. ## Install build requirements Install `make` and `gcc`. On Ubuntu this can be done with the following commands: {% tabs %} {% tab title="Ubuntu" %} ``` sudo apt-get update sudo apt-get install -y make gcc ``` {% hint style="info" %} `sudo apt-get install -y make gcc` may have encountered a problem with locked files, just try `sudo apt-get install -y make gcc` again. {% endhint %} {% endtab %} {% tab title="Mac" %} Ensure you have [Homebrew](https://brew.sh/) installed. Once you have Homebrew installed, you may run the following commands to install `make` and `gcc`: ```bash brew install make brew install gcc ``` We'll be needing these commands later so let's install the necessary packages: ```bash brew install git brew install wget ``` {% endtab %} {% tab title="Windows" %} Ensure you have `make` and `gcc` installed and that the paths are set correctly for git bash. One option for installing `gcc` can be found [here](https://jmeubank.github.io/tdm-gcc/articles/2021-05/10.3.0-release). {% hint style="info" %} You may select tdm64-gcc-10.3.0-2 Restart gitbash after installing {% endhint %} One option for installing `make` is using `chocolate` , more information can be found [here](https://chocolatey.org/install). Once you have chocolate installed, run this command: {% hint style="info" %} make sure to run gitbash as administrator mode if the following commands DO NOT work {% endhint %} ``` choco install make ``` Ensure you have all the necessary dependencies and compilers. ``` gcc --version ``` It will return: ``` gcc.exe (tdm64-1) 10.3.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE ``` For make: ``` make --version ``` It will return: ``` GNU Make 4.3 Built for Windows32 Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ``` {% endtab %} {% endtabs %} ## Install Go {% tabs %} {% tab title="All other environments" %} Install `go` by following the [official docs](https://golang.org/doc/install). Please select your respective environment❗ {% hint style="info" %} For Ubuntu environment, there may be `permissions denied` issues with unzipping the go zip file, try using `sudo su` to resolve it. {% endhint %} {% endtab %} {% tab title="If you are remoting into a terminal" %} Especially if you are remoting into a Ubuntu terminal, run this command to download the `go` installer: ``` wget https://dl.google.com/go/go1.18.3.linux-amd64.tar.gz ``` {% hint style="info" %} After you have downloaded the package and you may proceed to step 2 of the [official docs](https://golang.org/doc/install). Choose your system OS and follow the instructions stated. {% endhint %} {% endtab %} {% endtabs %} {% hint style="info" %} **Go 1.18+** or later is required for the PundiX. If you are remoting into a terminal, you may input the following command: {% endhint %} Setting environment variables: ``` mkdir -p $HOME/go/bin echo "export PATH=$PATH:/usr/local/go/bin" >> ~/.profile echo "export PATH=$PATH:$(go env GOPATH)/bin" >> ~/.profile source ~/.profile ``` ## Install the binaries Next, let's install the latest version of PundiX. Make sure you have git installed if not you will be prompted to `install git`. Follow the instruction in the terminal. {% tabs %} {% tab title="All Other Environments" %} ``` git clone --branch release/v0.2.x https://github.com/pundix/pundix.git cd pundix make go.sum make install ``` {% endtab %} {% tab title="Windows" %} {% hint style="info" %} You should run your commands in gitbash. But open pundixd.exe file using cmd prompt Make sure the name of your folder does not have whitespaces! {% endhint %} ``` git clone --branch release/v0.2.x https://github.com/pundix/pundix.git cd pundix make go.sum make build-win ``` {% hint style="info" %} use cmd prompt to open the pundixd.exe file in the path ./build/bin/pundixd.exe {% endhint %} {% endtab %} {% endtabs %} Verify version: ``` # Long version pundixd version --long # Short version pundixd version ``` `pundixd version --long` should output something similar to: ``` name: pundix server_name: pundixd version: main-82a9ac1f21783bc4b2838026b1742a2bbdf0bcb0 commit: 82a9ac1f21783bc4b2838026b1742a2bbdf0bcb0 build_tags: netgo,ledger go: go version go1.18.1 darwin/amd64 build_deps: ... cosmos_sdk_version: v0.45.5 ``` ### Build Tags Build tags indicate special features that have been enabled in the binary. | Build Tag | Description | | --------- | ----------------------------------------------- | | netgo | Name resolution will use pure Go code | | ledger | Ledger devices are supported (hardware wallets) | # Setup Node Here are the articles of this section: {% content-ref url="/pages/ujmJyoumvPO4at0Rxo3x" %} [Full node with Binaries](/getting-started/setup-node/full-node-with-binaries) {% endcontent-ref %} {% content-ref url="/pages/n4ZYuyjVYYcRk6lc2wId" %} [Full node with Docker](/getting-started/setup-node/full-node-with-docker) {% endcontent-ref %} {% content-ref url="/pages/K7dgyl7nEbtAGlbs6Ed9" %} [Snapshot Guide](/getting-started/setup-node/snapshot-guide) {% endcontent-ref %} {% content-ref url="/pages/591Od76Hxe2ginVHEjBU" %} [Node Monitoring Device](/getting-started/setup-node/node-monitoring-device) {% endcontent-ref %} {% content-ref url="/pages/vjI9sfOYEy736ZDMf52Z" %} [Node Peers](/getting-started/setup-node/node-peers) {% endcontent-ref %} # Full node with Binaries This guide will explain how to install the `pundixd` command line interface (CLI) on your system with `Binaries` option. With these installed on a server, you can participate on the mainnet or testnet as a [Validator](https://github.com/pundix/docs/blob/main/validators/setting-up-a-validator-for-pundix.md). ## Install PundiX (Pundi X Chain) {% hint style="info" %} **You need to** [**install PundiX**](/getting-started/installation-pundix) **before you go further.** {% endhint %} ### Setup PundiX Initializing PundiX: {% tabs %} {% tab title="Mainnet" %} ```shell pundixd init ``` {% endtab %} {% tab title="Testnet" %} ```shell pundixd init --chain-id payalebar ``` {% endtab %} {% endtabs %} Initializing pundixd will result in the creation of a few directories and most importantly the `.pundix` directory (for more information on the directory tree, refer to the validator-recovery section). This will be where your validator keys are stored and this is important for recovery of your validator. Fetching **`genesis`** file (copy this entire line of code and hit ENTER): {% tabs %} {% tab title="Mainnet" %} ```shell wget https://raw.githubusercontent.com/pundix/pundix/main/public/mainnet/genesis.json -O ~/.pundix/config/genesis.json ``` {% endtab %} {% tab title="Testnet" %} ```shell wget https://raw.githubusercontent.com/pundix/pundix/main/public/testnet/genesis.json -O ~/.pundix/config/genesis.json ``` {% endtab %} {% endtabs %} Set Peers {% tabs %} {% tab title="Mainnet" %} ```shell pundixd config config.toml p2p.seeds 78d3eb3f15a20ab1d567660d35776abe0dee71d0@pundix-mainnet-seed-node-1.pundix.com:26656,3c37c6c42dfd9094117549794299a62d49c122eb@pundix-mainnet-seed-node-2.pundix.com:26656 pundixd config config.toml p2p.persistent_peers 8bd41ea9f8ba7cfee4d19887cab487cdfc1177f4@pundix-mainnet-node-1.pundix.com:26656,6c1738220234a5e1b3caf94403ecd651e9759952@pundix-mainnet-node-2.pundix.com:26656,23abe2346d40f82cf0606e47931e58752f8b9348@pundix-mainnet-node-3.pundix.com:26656,20d275af6d025be144765291db5337ea059cce18@pundix-mainnet-node-4.pundix.com:26656,47f97d7baf028ddfd3b223baab0fa062eae75310@pundix-mainnet-node-5.pundix.com:26656 ``` {% endtab %} {% tab title="Testnet" %} ``` pundixd config config.toml p2p.seeds c77303a511a90a41c562d5925b170d7a68975569@payalebar-seed-node-1.pundix.com:26656,777fba974bb085daea6b83b6e76c6619d96eed50@payalebar-node-1.pundix.com:26656,9a296821d069a3c599ea2be5cd8698ec927ca5ce@payalebar-node-2.pundix.com:26656 pundixd config config.toml p2p.persistent_peers "" ``` {% endtab %} {% endtabs %} {% hint style="info" %} **IMPORTANT** At this stage **BEFORE** starting the node, please download the latest snapshot, refer to this [link](/getting-started/setup-node/snapshot-guide). Additionally, what is important is that your validator keys that is stored in a `.json` file for you to do a recovery in the future. For more [information](/validators/validator-recovery) how to access the files. Also, you can consider generating a new consensus key and [backing it up using a pin](#secret-and-updating-consensus-key). For a more stable way of setting up via [running a daemon](#running-server-as-a-daemon) {% endhint %} Start Node: ```bash nohup pundixd start 2>&1 > pundix.log & ``` Check logs: ```bash tail -f pundix.log ``` Open another terminal in the same folder. View more startup configurations: ```bash pundixd start -h ``` For example, Start and open the 1317 restful service port: ```bash nohup pundixd start --api.enable true --address 0.0.0.0:1317 2>&1 > pundix.log & ``` Then excute the command line in terminal: ```bash tail pundix.log ``` The execution of the previous command will return something like this (this is to check the status of nodes and which blocks are being synced/are syncing): ```bash 6:08PM INF indexed block height=3698 module=txindex server=node 6:08PM INF Timed out dur=945.515 height=3699 module=consensus round=0 server=node step=1 6:08PM INF received proposal module=consensus proposal={"Type":32,"block_id":{"hash":"51E98FF8FB0F6F5D4A37BEDFFDB37F849657A19D786FD89E0521A8BBFAD54733","parts":{"hash":"5108094CA9248288944168931AE1B5D9BF87EB253DEDECA60982EE2FDF253265","total":1}},"height":3699,"pol_round":-1,"round":0,"signature":"/77Seq+zrpzpjoUIofqB2/+xCRDKcUf0ekW3dXGjlgn8nWqkbfxuuS2XUhU5p2FxSEbs436f5vwOlVRJK+dHAw==","timestamp":"2022-08-25T10:08:40.924827Z"} server=node 6:08PM INF received complete proposal block hash=51E98FF8FB0F6F5D4A37BEDFFDB37F849657A19D786FD89E0521A8BBFAD54733 height=3699 module=consensus server=node 6:08PM INF finalizing commit of block hash={} height=3699 module=consensus num_txs=0 root=739ACDF1321A8A3DFACDD78CA62C056C1463DCF80C840439BD6242EDEFF3682F server=node 6:08PM INF minted coins from module account amount=4753287822151504purse from=mint module=x/bank 6:08PM INF executed block height=3699 module=state num_invalid_txs=0 num_valid_txs=0 server=node 6:08PM INF commit synced commit=436F6D6D697449447B5B313537203134322036203838203139352031383720323431203131332031383220313332203232352031333420313935203633203330203733203136362032372035312032313620363420353220323133203132382031353420383020313933203132392031303220313520313930203233305D3A4537337D 6:08PM INF committed state app_hash=9D8E0658C3BBF171B684E186C33F1E49A61B33D84034D5809A50C181660FBEE6 height=3699 module=state num_txs=0 server=node 6:08PM INF indexed block height=3699 module=txindex server=node ``` To check if pundix is synced: ```bash curl localhost:26657/status # or pundixd status ``` Return: ```bash { "jsonrpc": "2.0", "id": -1, "result": { "node_info": { "protocol_version": { "p2p": "8", "block": "11", "app": "0" }, "id": "26097a71ea65ee78b3b985563a4f55fe2bbedaf3", "listen_addr": "tcp://0.0.0.0:26656", "network": "PUNDIX", "version": "release/v0.2.0-be6a7eb51777e533f9b2dc22e8a9d8e5529dacbd", "channels": "40202122233038606100", "moniker": "local", "other": { "tx_index": "on", "rpc_address": "tcp://0.0.0.0:26657" } }, "sync_info": { "latest_block_hash": "F56E19ECB420A07AD483313AA2D4B5ACA002EBB2DDE2E6224B3140B6D8309D18", "latest_app_hash": "9EB77207A9927FDE2F5A393C8A67B137235FBCFD2A0754FD6CDB678A4B4673C3", "latest_block_height": "4381", "latest_block_time": "2022-08-25T10:20:51.144946Z", "earliest_block_hash": "793E56EC43863D0EAE8A758DFC64E6E17F3680F085D721763D8C26C56522CDB0", "earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "earliest_block_height": "1", "earliest_block_time": "2022-08-25T09:01:59.798536Z", "catching_up": false }, "validator_info": { "address": "7C4B956EA6A2EDCA58AAF2FE21C1D7405E0A9F19", "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "r/smZpiVw+bcV2f4e+xqV9j9P7SDtpthCv3nmVUS2qk=" }, "voting_power": "1" } } } ``` To ensure that the blocks are synced up with your node, under `"sync_info"`, `"catching_up value"` should be false `"catching_up value": false`. This may take a few hours and your node has to be fully synced up before proceeding to the next step. You may cross reference the latest block you are synced to `"sync_info": "latest_block_height"` and the latest block height of our Testnet blockchain on our [Testnet blockchain explorer](https://payalebar-explorer.pundix.com/pundix/blocks) or our [Mainnet](https://explorer.pundix.com/pundix/proposals). Stop Node (will be running in the background if not stopped): ```bash ps -ef | grep pundixd kill -9 PID ``` ## Running Server It is important to keep `pundixd` running at all times. There are several ways to achieve this, and the simplest solution we recommend is to register `pundixd` as a `systemd` service so that it will automatically get started upon system reboots and other events. ### Register `pundixd` as a service First, create a service definition file in `/etc/systemd/system`. Run this command to create the sample file above in the file path`/etc/systemd/system/pundixd.service` (if you are in the pundix directory): ```bash cat > /etc/systemd/system/pundixd.service ``` hit the ENTER button on your keyboard and `copy` and `paste` the contents of the file below into the command line: ### Sample file {% code title="pundixd.service" %} ```bash [Unit] Description=PundiX Node After=network.target [Service] Type=simple User=root WorkingDirectory=/root ExecStart=/root/go/bin/pundixd start --home /root/.pundix Restart=on-failure RestartSec=3 LimitNOFILE=4096 [Install] WantedBy=multi-user.target ``` {% endcode %} Then hit the ENTER button on your keyboard before using Ctrl+D on your keyboard, your file with the above contents will be created. It should look like this: {% hint style="info" %} run the command:`which pundixd` and replace the `ExecStart` file path with the return value of the command {% endhint %} ```bash root@XXXXXXXXXXXXXXX:~# cat > /etc/systemd/system/pundixd.service [Unit] Description=pundix Node After=network.target [Service] Type=simple User=root WorkingDirectory=/root ExecStart=/root/go/bin/pundixd start --home /root/.pundix Restart=on-failure RestartSec=3 LimitNOFILE=4096 [Install] WantedBy=multi-user.target ``` Modify the `Service` section from the given sample above to suit your settings. Note that even if we raised the number of open files for a process, we still need to include `LimitNOFILE`. After creating a service definition file, you should execute: ```bash systemctl daemon-reload systemctl enable pundixd ``` ### Controlling the service Use `systemctl` to control (start, stop, restart) in Linux/Ubuntu: ```bash # start sudo systemctl start pundixd # stop sudo systemctl stop pundixd # restart sudo systemctl restart pundixd # status sudo systemctl status pundixd ``` To start the node, run `sudo systemctl start pundixd`, and thereafter run `journalctl -u pundixd -n 100 -f` to see the latest and continuous logs. ### Accessing logs ```bash # entire log journalctl -u pundixd -n 100 # entire log reversed journalctl -u pundixd -r # latest and continuous log journalctl -u pundixd -n 100 -f ``` Concluding tips: It is always better to sync PundiX using the Daemon method because this ensures stability and that your syncing is continuously running in the background. ## Secret and updating consensus key {% hint style="danger" %} Use this at your own risk❗ I suggest trying it out on testnet first and also backing up your `priv_validator_key.json` if you already have this set up for a validator. The file can be found in this file path `~/.pundix/config/priv_validator_key.json`. {% endhint %} ### Updating your consensus key and tagging it to a pin Before setting up your validator if you would like to have a backup of your keys with a pin. You may run the following command: ```bash pundixd tendermint unsafe-reset-priv-validator ``` {% hint style="info" %} the `` key here must be longer than 32 characters {% endhint %} Running the above command will return: ```bash WARNING: The consensus private key of the node will be replaced. Ensure that the backup is complete. USE AT YOUR OWN RISK. Continue? [y/N] ``` After inputting `y`, your `priv_validator_key.json` will be replaced with a new file. This means you will have a new consensus private key and it will be tagged to your `` pin. ### Checking to see if the pin works If your `.pundix` folder is in the root directory ```bash cat ~/.pundix/config/priv_validator_key.json ``` {% hint style="danger" %} **Record the previous output before running the next command!** {% endhint %} Remove this file: ```bash rm ~/.pundix/config/priv_validator_key.json ``` The following command will recover your original consensus key: ```bash pundixd tendermint unsafe-reset-priv-validator ``` Match this output with the previous output above: ```bash cat ~/.pundix/config/priv_validator_key.json ``` # Full node with Docker {% hint style="info" %} **If you DO NOT already have docker installed, there will be a prompt for you to install it. Follow the instructions given.** {% endhint %} * Pull docker images ```bash docker pull ghcr.io/pundix/pundix:latest ``` * Initializing pundix ```bash docker run -v $HOME/.pundix:/root/.pundix ghcr.io/pundix/pundix:latest init pxlocal ``` * Download genesis (copy and run each line, line by line) {% tabs %} {% tab title="Mainnet" %} ``` wget https://raw.githubusercontent.com/pundix/pundix/main/public/mainnet/genesis.json -O ~/.pundix/config/genesis.json wget https://raw.githubusercontent.com/pundix/pundix/main/public/mainnet/config.toml -O ~/.pundix/config/config.toml wget https://raw.githubusercontent.com/pundix/pundix/main/public/mainnet/app.toml -O ~/.pundix/config/app.toml ``` {% endtab %} {% tab title="Testnet" %} ``` wget https://raw.githubusercontent.com/pundix/pundix/main/public/testnet/genesis.json -O ~/.pundix/config/genesis.json wget https://raw.githubusercontent.com/pundix/pundix/main/public/testnet/config.toml -O ~/.pundix/config/config.toml wget https://raw.githubusercontent.com/pundix/pundix/main/public/testnet/app.toml -O ~/.pundix/config/app.toml ``` {% endtab %} {% endtabs %} {% hint style="info" %} **IMPORTANT** At this stage **BEFORE** starting the node, please download the latest snapshot, refer to this [link](/getting-started/setup-node/snapshot-guide). And at this stage, what is important is your validator keys that is stored in a `.json` file for you to do a recovery in the future. For more [information](/validators/validator-recovery) how to access the files. {% endhint %} * Run docker ```bash docker run --name pundix -d --restart=always -p 26656:26656 -p 26657:26657 -p 1317:1317 -p 26660:26660 -v $HOME/.pundix:/root/.pundix ghcr.io/pundix/pundix:latest start ``` To check if pundix is synced: ```bash docker exec -it pundix /bin/sh # the docker name is pundix and CLI is pundixd pundixd status ``` It will return something like this: ```bash { "NodeInfo": { "protocol_version": { "p2p": 8, "block": 11, "app": 0 }, "id": "e62e783f567dff9f78c092c170f5902636c54fe2", "listen_addr": "tcp://0.0.0.0:26656", "network": "PUNDIX", "version": "release/v0.1.0-e5dda26dbdb1971704002bfc731f76db177d4922", "channels": "40202122233038606100", "moniker": "local", "other": { "tx_index": "on", "rpc_address": "tcp://0.0.0.0:26657" } }, "SyncInfo": { "latest_block_hash": "576F5764F3F12AB54FAFCC81690F5652D21E1F39DFDD43ECAE9DD34BA52F4F0A", "latest_app_hash": "30D0F93166E4A5F3127F1434CE39DE663D775CCCFADEF2B080E71D987964AC2C", "latest_block_height": "926", "latest_block_time": "2022-09-02T06:08:34.464451878Z", "earliest_block_hash": "350B1B6341D5B190AB8F12137D14D8C1FD6A2FCA4B8620D30CBDE0166104570F", "earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "earliest_block_height": "1", "earliest_block_time": "2022-09-02T05:51:52.914224Z", "catching_up": false }, "ValidatorInfo": { "Address": "B4E7FA9D1A617CDAF3D4B68E7C15748E49DA4554", "PubKey": { "key": "nthpdBmgr1fGMZ+DPt0qrDRZJPtopSWlq2OTsieYkq0=" }, "VotingPower": 1 } } ``` To ensure that the blocks are synced up with your node, under `"SyncInfo"`, `"catching_up"` should be false `"catching_up": false`. This may take a few hours and your node has to be fully synced up before proceeding to the next step. You may cross reference the latest block you are synced to `"SyncInfo": "latest_block_height"` and the latest block height of our Testnet blockchain on our [Testnet blockchain explorer](https://testnet-explorer.pundix.com/pundix/blocks) or our [Mainnet](https://explorer.pundix.com/pundix/proposals). {% hint style="danger" %} **Make sure that every node has a unique `priv_validator.json`. DO NOT copy the `priv_validator.json` from an old node to multiple new nodes. Running two nodes with the same `priv_validator.json` will cause you to double sign.** {% endhint %} # Snapshot Guide {% hint style="danger" %} **WARNING** 1. First, you need to setup your node up with the pre-requisites as per the node **setup guide** 2. **Before you start** your node for pundix to sync, follow the steps below to use snapshot 3. If your pundix node has already started, **please stop it** and then follow the steps below to use the snapshot 4. Once unpacking is complete, you can start the pundix service again {% endhint %} ## Types of PundiX Snapshots 1. A pruned-snapshot, which contains only the most recent day's data * Only data for the most recent day, no earlier data * Small amount of data and footprint 2. A full-node snapshot, which contains all the transaction data * Contains all transaction data, as well as current state data * Large amount of data and footprint 3. An archive-snapshot, which contains all transaction data as well as all state data (**syncing, not open yet**) * Contains all transaction and status data * The amount of data is very large and takes up a lot of space * In general, you DO NOT need to use an archive node The greater the blockchain data, the more evident the reduction is syncing time will be. If the current state of the blockchain will take about 2 days to sync, this method of syncing will reduce the time to sync by at least 12 hours. ## Available snapshots **Snapshots are performed based on its type as per below**, keeping a record of recent snapshot for as per below. If the date on the file is not yet updated and more than a week has lapsed since the last snapshot, you may replace the date in the file name to get the latest snapshot. **If the date or day of the month are single digits, make sure to prepend a 0 in front of the single digit number. Date format will be in YYYY-MM-DD.** {% tabs %} {% tab title="Mainnet" %} * Pruned-shapshot (light node) * Snapshot frequency: once a day (10am GMT +8) * Snapshot record keeping: 7 most recent * Shapshot link: [https://px-mainnet.s3.amazonaws.com/pundix-pruned-snapshot-mainnet-2023-MM-DD.tar.gz](https://px-mainnet.s3.amazonaws.com/pundix-pruned-snapshot-mainnet-2022-08-01.tar.gz) * Md5 link: [https://px-mainnet.s3.amazonaws.com/pundix-pruned-snapshot-mainnet-2023-MM-DD.tar.gz.md5](https://px-mainnet.s3.amazonaws.com/pundix-pruned-snapshot-mainnet-2022-08-01.tar.gz.md5) * Full-node snapshot (full node) * Snapshot frequency: every Monday (10am GMT +8) * Snapshot record keeping: 3 most recent * Shapshot link: [https://px-mainnet.s3.amazonaws.com/pundix-snapshot-mainnet-2023-MM-DD.tar.gz](https://px-mainnet.s3.amazonaws.com/pundix-snapshot-mainnet-2022-08-01.tar.gz) * Md5 link: [https://px-mainnet.s3.amazonaws.com/pundix-snapshot-mainnet-2023-MM-DD.tar.gz.md5](https://px-mainnet.s3.amazonaws.com/pundix-snapshot-mainnet-2022-08-01.tar.gz.md5) * Archive node - **synchronising** * Snapshot frequency: once a day (10am GMT +8) * Snapshot record keeping: 3 most recent * ~~Shapshot link:~~ [~~https://px-mainnet.s3.amazonaws.com/pundix-archive-snapshot-mainnet-2023-MM-DD.tar.gz~~](https://px-mainnet.s3.amazonaws.com/pundix-archive-snapshot-mainnet-2022-08-01.tar.gz) * ~~Md5 link:~~ [~~https://px-mainnet.s3.amazonaws.com/pundix-archive-snapshot-mainnet-2023-MM-DD.tar.gz.md5~~](https://px-mainnet.s3.amazonaws.com/pundix-archive-snapshot-mainnet-2022-08-01.tar.gz.md5) {% endtab %} {% tab title="Testnet" %} * Status data (pruned node) * Snapshot frequency: once a day (10am GMT +8) * Snapshot record keeping: 7 most recent * Shapshot link: [https://testnet-px.s3.amazonaws.com/pundix-pruned-snapshot-testnet-2023-MM-DD.tar.gz](https://testnet-px.s3.amazonaws.com/pundix-pruned-snapshot-testnet-2022-08-01.tar.gz) * Md5 link: [https://testnet-px.s3.amazonaws.com/pundix-pruned-snapshot-testnet-2023-MM-DD.tar.gz.md5](https://testnet-px.s3.amazonaws.com/pundix-pruned-snapshot-testnet-2022-08-01.tar.gz.md5) * Data (full node) * Snapshot frequency: every Monday (10am GMT +8) * Snapshot record keeping: 3 most recent * Shapshot link: [https://testnet-px.s3.amazonaws.com/pundix-snapshot-testnet-2023-MM-DD.tar.gz](https://testnet-px.s3.amazonaws.com/pundix-snapshot-testnet-2022-08-01.tar.gz) * Md5 link: [https://testnet-px.s3.amazonaws.com/pundix-snapshot-testnet-2023-MM-DD.tar.gz.md5](https://px-testnet.s3.amazonaws.com/pundix-snapshot-testnet-2022-08-01.tar.gz.md5) * Archive node - **synchronising** * Snapshot frequency: once a day (10am GMT +8) * Snapshot record keeping: 3 most recent * ~~Shapshot link:~~ [~~https://testnet-px.s3.amazonaws.com/pundix-archive-snapshot-testnet-2023-MM-DD.tar.gz~~](https://testnet-px.s3.amazonaws.com/pundix-archive-snapshot-testnet-2022-08-01.tar.gz) * ~~Md5 link:~~ [~~https://testnet-px.s3.amazonaws.com/pundix-archive-snapshot-testnet-2023-MM-DD.tar.gz.md5~~](https://testnet-px.s3.amazonaws.com/pundix-archive-snapshot-testnet-2022-08-01.tar.gz.md5) {% endtab %} {% endtabs %} ## Downloading the Snapshots Download the snapshot to your VM. To download the snapshot tar file to your VM you can run the following command: {% tabs %} {% tab title="Mainnet" %} ```bash wget -c https://px-mainnet.s3.amazonaws.com/pundix-snapshot-mainnet-2023-01-01.tar.gz ``` {% endtab %} {% tab title="Testnet" %} ```bash wget -c https://px-testnet.s3.amazonaws.com/pundix-snapshot-testnet-2023-01-01.tar.gz ``` {% endtab %} {% endtabs %} This will download the snapshot of pundix full-node data. Since it's full-node, downloading the snapshot and unpacking the file will take some time. ## MD5 checksum for downloaded file Checksums are often used to verify data integrity but are not relied upon to verify data authenticity, below are example of the `md5sum` command to check whether the file is downloaded correctly using ```bash $ md5sum pundix-snapshot-mainnet-2023-01-01.tar.gz 4269fe416ca2d74d3925449f5ce7d214 pundix-snapshot-mainnet-2023-01-01.tar.gz ``` Compare the md5 hash against `https://px-mainnet.s3.amazonaws.com/pundix-snapshot-mainnet-2023-01-01.tar.gz.md` ## Extracting the Snapshots Now, to unpack the `tar` file in the PundiX Data directory run the following command: {% tabs %} {% tab title="Mainnet" %} ```bash tar -xzvf pundix-snapshot-mainnet-2023-01-01.tar.gz -C ~/.pundix/ ``` {% endtab %} {% tab title="Testnet" %} ```bash tar -xzvf pundix-snapshot-testnet-2023-01-01.tar.gz -C ~/.pundix/ ``` {% endtab %} {% endtabs %} {% hint style="info" %} If your pundix data directory is placed on different directory then please rename to that. When you are unpacking the snapshot, it is already contained in a data folder, you will be replacing the data folder below. Be sure to maintain the integrity of this directory tree structure. {% endhint %} ```bash root@host:~# ls -l ~/.pundix/data/ total 64 drwxr-xr-x 2 root root 36864 Aug 2 16:49 application.db drwxr-xr-x 2 root root 4096 Aug 2 16:26 blockstore.db drwx------ 2 root root 4096 Aug 2 16:44 cs.wal drwxr-xr-x 2 root root 4096 Aug 2 15:32 evidence.db -rw------- 1 root root 46 Aug 1 10:02 priv_validator_state.json drwxr-xr-x 3 root root 4096 Aug 1 10:02 snapshots drwxr-xr-x 2 root root 4096 Aug 2 16:48 state.db drwxr-xr-x 2 root root 4096 Aug 2 16:29 tx_index.db ``` # Node Monitoring Device ## Prerequisites We recommend the following for running a node monitoring device: * 2 or more CPU cores * At least 40G of disk storage * At least 4G of memory * At least 10mbps network bandwidth * Have to be setup in a separate environment from validator nodes/sentry nodes {% hint style="info" %} Before setting up a node monitoring device, you may take a look at the PundiX [installation](/getting-started/installation-pundix) setup to setup the PundiX CLI. {% endhint %} ## Prometheus metrics PundiX also supports the use of Prometheus metrics. This monitoring device allows you to keep up to date with you validator nodes especially the status and performance of your validator nodes. {% hint style="info" %} More information on the list of available metrics and useful queries can be found [here](https://docs.tendermint.com/master/nodes/metrics.html). {% endhint %} ## Deploy and Configure Monitoring Services {% hint style="info" %} Before deploying monitoring program, install docker following the [official docs](https://docs.docker.com/compose/install/). {% endhint %} ### Configure node services {% hint style="info" %} **User should git clone** [**pundix**](https://github.com/pundix/pundix) **from Github first!** The **config.toml** file is in the **/.pundix** directory and the **prometheus.yml** file is in **/pundix** directory. {% endhint %} To enable the Prometheus metrics, set `prometheus=true` in your config file `$HOME/.pundix/config/config.toml`. Through setting the `prometheus_listen_addr` in the config file, you may choose the port for you to monitor your node. It is defaulted to port `26660`. In the file `./pundix/develop/prometheus/prometheus.yml` you can configure the target node(s) IP address, multiple nodes can be added in the following format. For example: ```yaml static_configs: - targets: [ ":26660"] labels: name: validator-01 chain_id: PUNDIX - targets: [ ":26660"] labels: name: sentry-01 chain_id: PUNDIX - targets: [ ":26660"] labels: name: sentry-02 chain_id: PUNDIX ``` ### Telegram Administrator and Bot Configuration In the file `./pundix/develop/docker-compose.yaml` under `alertmanager-bot` - `environment` are the variables `TELEGRAM_ADMIN` and `TELEGRAM_TOKEN`: * For example: ```yaml alertmanager-bot: container_name: alertmanager-bot image: metalmatze/alertmanager-bot:0.4.3 command: - '--alertmanager.url=http://pundix@alertmanager:9093/' - '--store=bolt' - '--bolt.path=/data/bot.db' - '--template.paths=/templates/default.tmpl' - '--listen.addr=0.0.0.0:9091' environment: TELEGRAM_ADMIN: "XXXXXX\nAdmin1USERID\nAdmin2USERID" TELEGRAM_TOKEN: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" ``` * `TELEGRAM_ADMIN`: The Telegram user id for the admin (not the bot itself, you, the user). The bot will only reply to messages sent from an admin. All other messages are dropped and logged on the bot's console. Your can get your user id from `@userinfobot`. * `TELEGRAM_TOKEN`: Token you get from `@botfather` * For more information with regards to the telegram bot, see [here](https://core.telegram.org/bots#creating-a-new-bot) and [here](https://github.com/metalmatze/alertmanager-bot): ### Access the monitoring services Should you not want to change the default username and password, you can start the monitoring service by using the following command: ```yaml docker-compose -f ./pundix/develop/docker-compose.yaml -p pundix-node-monitor up -d ``` * Open port `:9095` (for example `http:// :9095`) and you will see the prometheus page. Here you can see all the defined alarm rules. You can change these rules in the file `./pundix/develop/prometheus/rules/pundix-chain-alerts.yml`. The default username and password are `px` and `pundix` respectively. * Open port `:9093` (for example `http:// :9093`) and you will see the `alertmanager` page. You can manage alarm notifications here. The default username and password are `px` and `pundix` respectively. * Open port `:3000` (for example `http:// :3000`) and you will see the `grafana` page. * The default username and password are both `admin`, once you have logged in you will be asked to set a new password. * After setting a new password, you can go into Dashboards > Manage and select 'PundiX Chain Dashboard'. Here you can see a dashboard of various indicators and information of a selected node. * You may find out the details of [``](https://www.google.com/search?q=what+is+my+ip+address\&rlz=1C5CHFA_enSG996SG996\&oq=what+is\&aqs=chrome.0.69i59j69i57j69i59j35i39j0i433i512j69i60l3.1255j0j7\&sourceid=chrome\&ie=UTF-8)`.` * Authorise inbound traffic for the following ports ranges **9091, 9093, 3000** for `` in node monitoring device. you can also allow the port range **26660** for `` in the validator instance. ### Changing The Default Passwords for Prometheus and Alertmanager {% hint style="info" %} **DO NOT use `$` in any of your passwords, as it will not work with the `alertmanager.url`** {% endhint %} You can change the default username and password in the file `./pundix/develop/prometheus/web-config.yml` with the following format: ```yaml basic_auth_users: : # for example basic_auth_users: px: $2y$10$xCpE/Q5UGHxO1qKR5av2DOJGqTkb6E5G/Dc9VT1AZQxNlQJwQpb0q ``` How to hash with bcrypt: 1. install apache2 2. input this command `htpasswd -nBC 10 "" | tr -d ':\\n'` 3. type in password 4. copy hash For more info on prometheus web-configuration see this [link](https://github.com/prometheus/exporter-toolkit/blob/master/docs/web-configuration.md#about-bcrypt). {% hint style="info" %} If you changed the username and password in the `web-config.yaml`file there are 3 other areas where you need to update as well. {% endhint %} #### Grafana For `grafana` to be able to get data from `prometheus` you will need to update the username and password in the file `./pundix/develop/grafana/provisioning/datasources/datasource.yml` {% hint style="info" %} The password here is in text format and does not need to be hashed. {% endhint %} For example: ```yaml # basic auth username, if used basicAuthUser: px # basic auth password, if used basicAuthPassword: pundix ``` #### Prometheus For `prometheus` to be able to send alerts to `alertmanager` you will need to update the username and password in the file `./pundix/develop/prometheus/prometheus.yml` For example: {% hint style="info" %} The password here is in text format and does not need to be hashed. {% endhint %} ```yaml # Alertmanager configuration alerting: alertmanagers: # Sets the `Authorization` header on every request with the # configured username and password. # password and password_file are mutually exclusive. - scheme: http basic_auth: username: px password: pundix static_configs: - targets: - alertmanager:9093 ``` #### Alertmanager-bot For the telegram bot to be able to obtain information from the `alertmanager` you will need to update the username and password within the `--alertmanager.url` in the `./pundix/develop/docker-compose.yaml` file. Also you may [update](#updating-node-monitoring-services) the alert-manager-bot. For example: {% hint style="info" %} The password here is in text format and does not need to be hashed {% endhint %} Under `alertmanager-bot`, `command` you will find `--alertmanager.url`: ```yaml command: -'--alertmanager.url=http://:@alertmanager:9093/' EXAMPLE alertmanager-bot: container_name: alertmanager-bot image: metalmatze/alertmanager-bot:0.4.3 command: - '--alertmanager.url=http://px:pundix@alertmanager:9093/' ``` {% hint style="info" %} **DO NOT use `$` in any of your passwords, as it will not work with the `alertmanager.url`** {% endhint %} #### Commands Start monitoring service: ```bash docker-compose -f ./pundix/develop/docker-compose.yaml -p pundix-node-monitor up -d ``` Restart monitoring service: ```bash docker-compose -f ./pundix/develop/docker-compose.yaml -p pundix-node-monitor restart ``` Stop monitoring service: ```bash docker-compose -f ./pundix/develop/docker-compose.yaml -p pundix-node-monitor stop ``` ### Updating Node Monitoring Services {% hint style="info" %} Do a update by pulling the latest code with the below command, whenever you are making changes to the telegram configuration under `./pundix/develop/docker-compose.yaml` {% endhint %} ```bash # pull the latest code base docker-compose -f ./pundix/develop/docker-compose.yaml -p pundix-node-monitor pull # start the monitoring device docker-compose -f ./pundix/develop/docker-compose.yaml -p pundix-node-monitor up -d ``` {% hint style="info" %} Ensure you have changed your passwords and also that your data source is configured correctly {% endhint %} ## Prometheus Rules | Metric | Rule | Threshold | explain | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------- | --------------------------------------------------------------------------------------------------------- | | `tendermint_consensus_height` | tendermint\_consensus\_height - (tendermint\_consensus\_height offset 1m) == 0 | 0 | The node did not produce blocks in 1 minute | | `tendermint_consensus_validators` | avg((tendermint\_consensus\_validators{kind="val-node"} - tendermint\_consensus\_validators{kind="val-node"} offset 1m) > 0) by (chain\_id) | 0 | The number of validators has increased compared to the number of validators a minute ago | | `tendermint_consensus_validators` | avg((tendermint\_consensus\_validators{kind="val-node"} offset 1m - tendermint\_consensus\_validators{kind="val-node"}) > 0) by (chain\_id) | 0 | The number of validators is reduced compared to the number of validators one minute ago | | `tendermint_consensus_latest_block_height` | tendermint\_consensus\_latest\_block\_height - (tendermint\_consensus\_latest\_block\_height offset 2m) | 0 | The height of the node does not increase in 2 minutes | | `tendermint_consensus_validator_last_signed_height` | tendermint\_consensus\_validator\_last\_signed\_height - (tendermint\_consensus\_validator\_last\_signed\_height offset 2m) == 0 | 0 | The verifier did not sign in 2 minutes | | `tendermint_consensus_validator_missed_blocks` | tendermint\_consensus\_validator\_missed\_blocks - (tendermint\_consensus\_validator\_missed\_blocks offset 2m) >= 3 | 3 | The total number of blocks with the verifier address not participating in the signature is greater than 3 | | `tendermint_consensus_missing_validators` | tendermint\_consensus\_missing\_validators > 10 | 10 | The number of verifiers not participating in the signature exceeds the threshold of 10 | | `tendermint_consensus_byzantine_validators` | tendermint\_consensus\_byzantine\_validators > 0 | 0 | The number of Byzantine validators exceeds the threshold 0 | | `tendermint_consensus_byzantine_validators` | tendermint\_consensus\_byzantine\_validators > 0 | 0 | The number of Byzantine validators exceeds the threshold 0 | | `tendermint_consensus_block_interval_seconds_sum` | tendermint\_consensus\_block\_interval\_seconds\_sum / tendermint\_consensus\_block\_interval\_seconds\_count > 7 | 7 | The block generation interval exceeds 7 seconds | | `tendermint_consensus_rounds` | tendermint\_consensus\_rounds != 0 | 0 | Consensus round is not equal to 0 | | `tendermint_consensus_num_txs` | tendermint\_consensus\_num\_txs > 100 | 100 | The number of block packaging transactions exceeds the threshold of 100 | | `tendermint_mempool_size` | tendermint\_mempool\_size > 100 | 100 | The number of unchained transactions in the memory pool exceeds the threshold of 100 | | `tendermint_mempool_failed_txs` | tendermint\_mempool\_failed\_txs - (tendermint\_mempool\_failed\_txs offset 1m) > 10 | 10 | The number of failed transactions in the memory pool has increased by more than 10 in 1 minute | | `tendermint_consensus_fast_syncing` | tendermint\_consensus\_fast\_syncing - (tendermint\_consensus\_fast\_syncing offset 5m) != 0 | 0 | The current synchronization status of the node is not 0 | | `tendermint_p2p_peers` | tendermint\_p2p\_peers < 5 | 5 | The number of connected nodes is below the threshold 5 | | `tendermint_p2p_peers` | (tendermint\_p2p\_peers offset 30s) - tendermint\_p2p\_peers > 1 | 1 | The number of currently connected nodes decreases for 1 minute | # Node Peers ## Testnet (payalebar) ### Seeds {% code lineNumbers="true" %} ``` c77303a511a90a41c562d5925b170d7a68975569@payalebar-seed-node-1.pundix.com:26656 777fba974bb085daea6b83b6e76c6619d96eed50@payalebar-node-1.pundix.com:26656 9a296821d069a3c599ea2be5cd8698ec927ca5ce@payalebar-node-2.pundix.com:26656 ``` {% endcode %} ### Persistent Peers {% code lineNumbers="true" %} ``` ``` {% endcode %} ## Mainnet ### Seeds {% code lineNumbers="true" %} ``` 78d3eb3f15a20ab1d567660d35776abe0dee71d0@pundix-mainnet-seed-node-1.pundix.com:26656 3c37c6c42dfd9094117549794299a62d49c122eb@pundix-mainnet-seed-node-2.pundix.com:26656 ``` {% endcode %} ### Persistent Peers {% code lineNumbers="true" %} ``` 8bd41ea9f8ba7cfee4d19887cab487cdfc1177f4@pundix-mainnet-node-1.pundix.com:26656 6c1738220234a5e1b3caf94403ecd651e9759952@pundix-mainnet-node-2.pundix.com:26656 23abe2346d40f82cf0606e47931e58752f8b9348@pundix-mainnet-node-3.pundix.com:26656 20d275af6d025be144765291db5337ea059cce18@pundix-mainnet-node-4.pundix.com:26656 47f97d7baf028ddfd3b223baab0fa062eae75310@pundix-mainnet-node-5.pundix.com:26656 ``` {% endcode %} # Validator Overview ## Introduction PundiX (Pundi X Chain) is built on Tendermint, which relies on a set of validators that are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key. Validators can bond their own PUNDIX and have PUNDIX "delegated", or staked, with them by token holders. The PundiX chain will have 50 validators, but over time this will increase to 100 validators according to a predefined schedule. Validators are ranked according to the amount of PUNDIX staked with them — the top 50 validator candidates with the most stake will become active PundiX validators. Validators and their delegators will earn block rewards and transaction fees through execution of the Tendermint consensus protocol. The Transaction fees will be paid in PUNDIX whilst the block rewards will be in both PUNDIX & PURSE. Note that validators can set the commission on the fees their delegators receive as an additional incentive. If validators double sign, are frequently offline or DO NOT participate in governance, their PUNDIX staked(including PUNDIX of users that delegated to them) may be slashed. The penalty depends on the severity of the violation. ## Hardware There are currently no existing appropriate cloud solution for validator key management. For this reason, validators must set up a physical operation secured with restricted access. A good starting place, for example, would be co-locating in secure data centers. Validators should expect to equip their datacenter location with excess power, connectivity, and storage backups. Expect to have several excess networking boxes for fiber, firewall, switching and small servers with excess hard drives. Hardware can be on the low end of datacenter gear to start out with. We expect network requirements to be low initially. The current testnet requires minimal resources. Then bandwidth, CPU and memory requirements will rise as the network grows. Large hard drives are recommended for storing years of blockchain history. ## Set Up a Website Set up a dedicated validator's website and signal your intention of becoming a validator on our blockchain network. This is important since delegators will want to have more available information about the entity they are delegating their PUNDIX to. ## Seek Legal Advice Seek legal advice if you intend to run a Validator. ## Community Discuss more details on being a validator on our social media platforms: * [Forum](https://forum.pundix.com/) * [Telegram](https://t.me/pundix) * [Twitter](https://twitter.com/PundiXLabs) * [Reddit](https://www.reddit.com/r/PundiX/) * [Gitbook](https://github.com/pundix) # Setting Up a Validator for PundiX Chain {% hint style="info" %} Before setting up your validator node, make sure you've already gone through the `Full Node Setup` guide either with [Binaries](/getting-started/setup-node/full-node-with-binaries) or with [Docker](/getting-started/setup-node/full-node-with-docker). {% endhint %} Information on how to join the mainnet (`genesis.json` file and seeds) is held in our `PundiX CLI Commands` repo. If you plan to use a KMS (key management system), you should go through these steps first. ## What is a Validator? The role of a validator is to run a full-node and participate in consensus by broadcasting votes. Validators commit new blocks in the blockchain and receive rewards in exchange for their work. They must also participate in governance by voting on proposals. Validators are weighted according to their total stake. Before you proceed to the next section, ensure that you have already `set up a full-node`. ## Create Your Validator {% hint style="danger" %} **We support ledger for sending transactions, we recommend using ledger as it is more secure, note that such transactions require PundiX to be** [**installed**](/getting-started/installation-pundix) **on both the remote vm and the host vm, which is a bit of a pain but worth doing.** {% endhint %} ### Create validator's token holding account Here we will create a new token holding account for the validator which we will bind later to the node consensus. {% tabs %} {% tab title="With Ledger" %} ```bash pundixd keys add <_name> --algo secp256k1 --coin-type 118 --ledger --index 0 # for example pundixd keys add v1 --algo secp256k1 --coin-type 118 --ledger --index 5 ``` {% endtab %} {% tab title="Without Ledger" %} ```bash pundixd keys add <_name> --algo secp256k1 --coin-type 118 # for example pundixd keys add v1 --algo secp256k1 --coin-type 118 ``` {% endtab %} {% endtabs %} {% hint style="danger" %} **This creates a new token holding account for you, do record the mnemonic phrase in a safe place. Take note of the address so that you can fund the account. The `_name` will be used again later.** {% endhint %} It returns something like this when adding new account and mnemonic is stored in ledger: ```json { "name":"v1", "type":"ledger", "address":"px1t2sh0a6u36udu9gxs48uc83dmyk57590j9ytjj", "pubkey":"{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"AylVPwWK1KQ6svnp0d5zH1swkN8jHnqGdAwCCWZYs2bg\"}", "algo":"secp256k1" } ``` if you already have an existing f(x)wallet and would like to import it you may run the following command and follow the prompts: ```bash pundixd keys add --recover # for example pundixd keys add v1 --recover ``` ### Bind the node consensus and validator's token holding account Now we will bind the node consensus and validator's token holding account, once this is done you will have successfully set up a validator! **Couple of items to ensure before continuing** * Ensure that entire node has synchronised to the latest block height, to prevent risk of being jailed. Using `curl localhost:26657/status` or `pundixd status` to check `"catching_up":false`. If `"catching_up":true`, please continue to wait until entire node has synchronised, this could take up to a day depending on network usage. * Ensure that your token holding account has enough `PUNDIX tokens` before creating a validator. For `Testnet version`, you may obtain `PUNDIX tokens` via [**PUNDIX Faucet**](https://payalebar-faucet.functionx.io/). For more information on how to obtain `PUNDIX tokens` on [**Testnet**](https://github.com/pundix/docs/blob/main/pundix-tutorials/testnet-faucet.md). A minimum of `100 PUNDIX` is needed to create an active validator. You will need more than `100 testnet PUNDIX` in your account because some is needed to pay for the creation of your validator. PUNDIX has 18 decimal points. Great! You can now bind the node consensus and validator's token holding account. The command to run will be `pundixd tx staking create-validator`, copy the entire command below, after editing the required fields: * `chain-id=payalebar` is set as our pundix testnet chain ie payalebar. for mainnet, set the `chain-id=PUNDIX`. * `gas="auto"` automatically assesses the gas used for this `create-validator` transaction. * `gas-adjustment=1.5` there will be a 20% buffer added to the automatically assessed gas amount. * `gas-prices="0.000002PUNDIX"` this will be the gas price you will be paying for (you may check the gas price you will need to pay for your node). * `from=<_name>` this is the token holding account created above that you will be binding your consensus account to to create a validator. * `amount=100PUNDIX` this is the amount you will be self-delegating for your validator. * `pubkey=$(pundixd tendermint show-validator)` this is your pubkey of your validator. * `commission-rate="0.01"` this is the commission you will be charging as a validator. * `commission-max-rate="0.2"` the maximum commission rate which this validator can charge. This parameter cannot be changed after `create-validator` is processed. * `commission-max-change-rate="0.01"` the maximum daily increase of the validator commission. This parameter cannot be changed after `create-validator` is processed. * `min-self-delegation="10000000000000000000000"` minimum amount of PUNDIX the validator needs to have bonded at all time. If the validator's self-delegated stake falls below this limit, their entire staking pool will unbond. * `moniker="choose a moniker"` this will be the name of your validator for easier identification. * `website="https://pundix.com"` this will be the website for delegators or the public to read more about your validator * `details="To infinity and beyond!"` you can add some additional details about your validator. If this does not work for you, please check the Common Problem section or get help on the [forum](https://forum.pundix.com). Before you proceed and set your validator up, make sure you do some final checks (ensure your `.pundix` path is set correctly). If you are in the root folder: ```bash curl -s 127.0.0.1:26657/status | jq '.result.validator_info.pub_key' # or cat .pundix/config/priv_validator_key.json| jq .pub_key ``` Ensure both these outputs are the same. ```bash pundixd keys parse $(cat .pundix/config/priv_validator_key.json| jq -r '.address') # or pundixd tendermint show-address ``` Ensure the second to the last value from the first command has the same output as the second command before running the following: ```bash pundixd tx staking create-validator \ --chain-id=PUNDIX \ --from=<_name> \ --amount=500PUNDIX \ --pubkey=$(pundixd tendermint show-validator) \ --commission-rate="0.01" \ --commission-max-rate="0.20" \ --commission-max-change"0.01" \ --min-self-delegation="100" \ --moniker="choose a moniker" \ --website="https://pundix.com" \ --details="To infinity and beyond!" # for example pundixd tx staking create-validator \ --chain-id=PUNDIX \ --from=a2 \ --amount=100PUNDIX \ --pubkey='{"@type":"/cosmos.crypto.ed25519.PubKey","key":"c9K95ze0trEtE1KCZ1smjhJQdVqEB8+7Ma6ht64bhDg="}' \ --commission-rate="0.01" \ --commission-max-rate="0.20" \ --commission-max-change-rate="0.01" \ --min-self-delegation="100" \ --moniker="choose a moniker" \ --website="https://pundix.com" \ --details="To infinity and beyond!" ``` Output: {% code overflow="wrap" %} ```bash {"body":{"messages":[{"@type":"/cosmos.staking.v1beta1.MsgCreateValidator","description":{"moniker":"choose a moniker","identity":"","website":"","security_contact":"","details":""},"commission":{"rate":"0.010000000000000000","max_rate":"0.200000000000000000","max_change_rate":"0.010000000000000000"},"min_self_delegation":"1","delegator_address":"px1egmy0ncxzuur504qlz9z0ykfa5cqdk0ap5tgxz","validator_address":"pxvaloper1egmy0ncxzuur504qlz9z0ykfa5cqdk0af9khcz","pubkey":{"@type":"/cosmos.crypto.ed25519.PubKey","key":"c9K95ze0trEtE1KCZ1smjhJQdVqEB8+7Ma6ht64bhDg="},"value":{"denom":"PUNDIX","amount":"500"}}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[{"denom":"PUNDIX","amount":"1.020264"}],"gas_limit":"170044","payer":"","granter":""}},"signatures":[]} confirm transaction before signing and broadcasting [y/N]: ``` {% endcode %} {% hint style="info" %} Do record the `validator_address` as this is the only time you can see it on the terminal, or else you will have to use the explorer [Mainnet](https://explorer.pundix.com)/[Testnet](https://payalebar-explorer.pundix.com) to obtain the `validator_address`. The explorer option can only be done if the binding is successful. {% endhint %} Hit `y` and enter! If successful, You will get an object data from the terminal with `code = 0` similar to what is shown below. Output: ```bash {"height":"729953","txhash":"8FB0EDE90AE37D6603D7FD3278018A7897E243F2DEF69F0592FF71BC58B40AE2","codespace":"","code":0,"data":"0A120A106372656174655F76616C696461746F72","raw_log":"[{\"events\":[{\"type\":\"create_validator\",\"attributes\":[{\"key\":\"validator\",\"value\":\"pxvaloper1egmy0ncxzuur504qlz9z0ykfa5cqdk0af9khcz\"},{\"key\":\"amount\",\"value\":\"500\"}]},{\"type\":\"message\",\"attributes\":[{\"key\":\"action\",\"value\":\"create_validator\"},{\"key\":\"module\",\"value\":\"staking\"},{\"key\":\"sender\",\"value\":\"px1egmy0ncxzuur504qlz9z0ykfa5cqdk0ap5tgxz\"}]}]}]","logs":[{"msg_index":0,"log":"","events":[{"type":"create_validator","attributes":[{"key":"validator","value":"pxvaloper1egmy0ncxzuur504qlz9z0ykfa5cqdk0af9khcz"},{"key":"amount","value":"500"}]},{"type":"message","attributes":[{"key":"action","value":"create_validator"},{"key":"module","value":"staking"},{"key":"sender","value":"px1egmy0ncxzuur504qlz9z0ykfa5cqdk0ap5tgxz"}]}]}],"info":"","gas_wanted":"170044","gas_used":"155067","tx":null,"timestamp":""} ``` {% hint style="info" %} When specifying commission parameters, the `commission-max-change-rate` is used to measure % point change over the `commission-rate`. E.g. 1% to 2% is a 100% rate increase, but only 1 percentage point. {% endhint %} `min-self-delegation` is a stritly positive integer that represents the minimum amount of self-delegated voting power your validator must always have. A `min-self-delegation` of `100000000000000000000` means your validator will never have a self-delegation lower than `100` PUNDIX You can confirm that you are in the validator set by using a third party explorer for [Mainnet](https://explorer.pundix.com)/[Testnet](https://payalebar-explorer.pundix.com). ## Get validator pubkey Your `pxvalconspub` is used to create a new validator by staking tokens (this is the account used by the node consensus). You can find your validator pubkey by running: ```bash pundixd tendermint show-validator ``` {% hint style="info" %} This command is very important for [recovery of your validator](/validators/validator-recovery) in the future. {% endhint %} ## To check if node is running ```bash ps -ef | grep pundixd ``` ## Edit Validator Description You can edit your validator's public description. This info is to identify your validator, and will be relied on by delegators to decide which validators to stake to. Make sure to provide input for every flag below. If a flag is not included in the command the field will default to empty (`--moniker` defaults to the machine name) if the field has never been set or remain the same if it has been set in the past. The `` specifies which validator you are editing. If you choose to not include certain flags, remember that the `--from` flag must be included to identify the validator to update. The `--identity` can be used as to verify identity with systems like Keybase or UPort. When using with Keybase `--identity` should be populated with a 16-digit string that is generated with a [keybase.io](https://keybase.io) account. It's a cryptographically secure method of verifying your identity across multiple online networks. The Keybase API allows us to retrieve your Keybase avatar. This is how you can add a logo to your validator profile. There are only a few parameters that can be edited they are listed below: * `commission-rate string`: The new commission rate percentage * `details string`: The validator's (optional) details (default "\[do-not-modify]") * `identity string`: The (optional) identity signature (ex. UPort or Keybase) (default "\[do-not-modify]") * `moniker string`: The validator's name (default "\[do-not-modify]") * `security-contract string`: The validator's (optional) security contact email (default "\[do-not-modify]") * `website string`: The validator's (optional) website (default "\[do-not-modify]") **Note**: The `commission-rate` value must adhere to the following invariants: * Must be between 0 and the validator's `commission-max-rate` * Must not exceed the validator's `commission-max-change-rate` which is maximum % point change rate **per day**. In other words, a validator can only change its commission once per day and within `commission-max-change-rate` bounds. ```bash pundixd tx staking edit-validator \ --moniker="choose a moniker" \ --website="https://pundix.com" \ --identity= \ --details="To infinity and beyond!" \ --commission-rate="0.10" \ --chain-id=PUNDIX \ --from=<_name> ``` ## View Validator Description View the validator's information with this command: ```bash pundixd query staking validator # for example pundixd query staking validator pxvaloper1egmy0ncxzuur504qlz9z0ykfa5cqdk0af9khcz ``` ## Track Validator Signing Information In order to keep track of a validator's signatures in the past you can do so by using the `signing-info` command: ```bash pundixd query slashing signing-info "$(pundixd tendermint show-validator)" ``` ## Unjail Validator When a validator is "jailed" for downtime, you must submit an `Unjail` transaction from the operator account in order to be able to get block proposer rewards again (depends on the zone fee distribution). ```bash pundixd tx slashing unjail --from= ``` ## Confirm Your Validator is Running Your validator is active if the following command returns anything: ```bash pundixd query tendermint-validator-set | grep "$(pundixd tendermint show-address)" ``` You should now see your validator in one of the PundiX explorers. You are looking for the `bech32` encoded `address` in the `~/.pundix/config/priv_validator.json` file. {% hint style="info" %} To be in the validator set, you need to have more total voting power than the 100th validator. {% endhint %} ## Halting Your Validator When attempting to perform routine maintenance or planning for an upcoming coordinated upgrade, it can be useful to have your validator systematically and gracefully halt. You can achieve this by either setting the `halt-height` to the height at which you want your node to shutdown or by passing the `--halt-height` flag to `pundixd`. The node will shutdown with a zero exit code at that given height after committing the block. ## Common Problems ### Problem #1: Copy pasting the entire `pundixd tx staking create-validator` command does not work for me Get your `_pubkey` using `pundixd tendermint show-validator`. You will have to type out the command as follows: ```bash pundixd tx staking create-validator \ --chain-id PUNDIX \ --from <_name> \ --amount 100PUNDIX \ --pubkey <_pubkey> \ --moniker "choose a moniker" \ --commission-rate 0.01 \ --commission-max-rate 0.20 \ --commission-max-change-rate 0.01 \ --min-self-delegation 1 \ --moniker "choose a moniker" \ --website "https://pundix.com" \ --details "To infinity and beyond!" ``` ### Problem #2: My transaction keeps failing with `insufficient fees` Example of the error as shown: ```bash {"height":"0","txhash":"1BF7A7126EF2650AE66DA211D1EE0C41AF0FCA0EEB0F14503A2371A6541F698C","codespace":"sdk","code":13,"data":"","raw_log":"insufficient fees; got: required: 1.2PUNDIX: insufficient fee","logs":[],"info":"","gas_wanted":"200000","gas_used":"0","tx":null,"timestamp":""} ``` You will have to add `--fees` to your command, to find out how much fees to input you can copy paste from the `required` that is given to you. Example of input: ```bash pundixd tx staking edit-validator --from <_name> --fees="1PUNDIX" --moniker "test test" --gas-prices="" ``` ### Problem #3: My validator has `voting_power: 0` Your validator has become jailed. Validators get jailed, for example get removed from the active validator set, if they DO NOT vote on `500` of the last `10000` blocks, or if they double sign. If you got jailed for downtime, you can get your voting power back to your validator. First, if `pundixd` is not running, start it up again: ```bash pundixd start ``` Wait for your full node to catch up to the latest block. Then, you can [unjail your validator](https://github.com/pundix/docs/blob/main/validators/setting-up-a-validator-for-pundix.md#unjail-validator) Lastly, check your validator again to see if your voting power is back. ```bash pundixd status ``` You may notice that your voting power is less than it used to be. That's because you got slashed for downtime! ### Problem #4: My `pundixd` crashes because of `too many open files` The default number of files Linux can open (per-process) is `1024`. `pundixd` is known to open more than `1024` files. This causes the process to crash. A quick fix is to run `ulimit -n 4096` (increase the number of open files allowed) and then restart the process with `pundixd start`. If you are using `systemd` or another process manager to launch `pundixd` this may require some configuration at that level. A sample `systemd` file to fix this issue is below: ```bash # /etc/systemd/system/pundixd.service [Unit] Description=PundiX Node After=network.target [Service] Type=simple User=ubuntu WorkingDirectory=/home/ubuntu ExecStart=/home/ubuntu/go/bin/pundixd start Restart=on-failure RestartSec=3 LimitNOFILE=4096 [Install] WantedBy=multi-user.target ``` # Validator Recovery Run the following command to open the `priv_validator_key.json` file and store it somewhere for safe keeping: {% hint style="danger" %} **Do ensure that you have a back-up `priv_validator_key.json` file and that it is stored safely! Overriding this `priv_validator_key.json`file and you would have lost your consensus private key and your validator if you have one set up. DO NOT OVERRIDE THIS FILE.** {% endhint %} If you are in the `PundiX` dir, run this command: ```bash cat ../.pundix/config/priv_validator_key.json # this will be your private key to recovery your validator { "address": "XXXXXXXXXXXXXXXXXXxxxxxxxXXXXXX", "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "XXXXXXXXXXXXXXXXXXxxxxxxxXXXXXX" }, "priv_key": { "type": "tendermint/PrivKeyEd25519", "value": "XXXXXXXXXXXXXXXXXXxxxxxxxXXXXXX" }} ``` The directory tree of the .pundix directory should look like this: ```bash tree $HOME/.pundix # it will look like this /home/ubuntu/.pundix ├── config │ ├── app.toml │ ├── config.toml │ ├── genesis.json │ ├── node_key.json │ └── priv_validator_key.json └── data └── priv_validator_state.json 2 directories, 6 files ``` The command after `Initializing PundiX` from setting up node with [Full node with Binaries](/getting-started/setup-node/full-node-with-binaries) or [Full node with Docker](/getting-started/setup-node/full-node-with-docker) is to override the various files that were initialized earlier: {% tabs %} {% tab title="Binaries" %} ``` wget https://raw.githubusercontent.com/pundix/pundix/release/main/public/testnet/genesis.json -O ~/.pundix/config/genesis.json wget https://raw.githubusercontent.com/pundix/pundix/release/main/public/testnet/config.toml -O ~/.pundix/config/config.toml wget https://raw.githubusercontent.com/pundix/pundix/release/main/public/testnet/app.toml -O ~/.pundix/config/app.toml ``` {% endtab %} {% tab title="Docker" %} ``` wget https://raw.githubusercontent.com/pundix/pundix/release/main/public/mainnet/genesis.json -O ~/.pundix/config/genesis.json wget https://raw.githubusercontent.com/pundix/pundix/release/main/public/mainnet/config.toml -O ~/.pundix/config/config.toml wget https://raw.githubusercontent.com/pundix/pundix/release/main/public/mainnet/app.toml -O ~/.pundix/config/app.toml ``` {% endtab %} {% endtabs %} The key file here is `priv_validator_key.json`. After initializing and overriding those files, override the `priv_validator_key.json` with your original `priv_validator_key.json` of the validator you want to recover. You may do this by following the command below (if you are in `.pundix/config` directory): ```bash cat > priv_validator_key.json ``` Hit the ENTER button on your keyboard and `copy` and `paste` the contents of your `priv_validator_key.json` file from your original validator into the command line Your command line should look something like this: ```bash cat > priv_validator_key.json # this will be your private key to recovery your validator { "address": "XXXXXXXXXXXXXXXXXXxxxxxxxXXXXXX", "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "XXXXXXXXXXXXXXXXXXxxxxxxxXXXXXX" }, "priv_key": { "type": "tendermint/PrivKeyEd25519", "value": "XXXXXXXXXXXXXXXXXXxxxxxxxXXXXXX" } } ``` Then hit the ENTER button on your keyboard before using Ctrl+D on your keyboard, your file with the above contents will be created. Run the following command and compare if the public key you generate now matches the old public key. If it does, then you have successfully recovered your original validator. ``` pundixd tendermint show-validator ``` # Validator FAQ ## General Concepts ### What is a validator? [Pundi X Chain](/getting-started/what-is-pundix) is built on Tendermint, which relies on a set of validators to secure the network. The role of validators is to run a full-node and participate in consensus by broadcasting votes which contain cryptographic signatures signed by their private key. Validators commit new blocks in the blockchain and receive revenue in exchange for their work. They must also participate in governance by voting on proposals. Validators are weighted according to their total stake. ### What is 'staking'? The Pundi X Chain is a delgated Proof-Of-Stake (DPoS) blockchain, meaning that the weight of validators is determined by the total amount of staking tokens (PUNDIX) bonded as collateral. These PUNDIX can be self-delegated directly by the validator or delegated to them by other PUNDIX holders. Any user in the system can declare their intention to become a validator by sending a `create-validator` transaction, provided they meet the minimum self-delegated amount of 100PUNDIX. From there, they become validator candidates. The weight (i.e. voting power) of a validator determines whether or not they are an active validator. Initially, only the top 50 validators with the most voting power will be active validators. ### What is a full-node? A full-node is a program that fully validates transactions and blocks of a blockchain. It is distinct from a light-node that only processes block headers and a small subset of transactions. Running a full-node requires more resources than a light-node but is necessary in order to be a validator. In practice, running a full-node only implies running a non-compromised and up-to-date version of the software with low network latency and no downtime. Of course, we encourage users to run full-nodes even if they do not plan to become validators. ### What is a delegator? Delegators are PUNDIX holders who want to participate in protocol governance, but don’t want to carry the burden of becoming a validator. In which case they can delegate PUNDIX to a validator and obtain a slice of their revenue (as well as risks). (for more detail on how revenue is distributed, see [**What is the incentive to stake?**](#what-is-the-incentive-to-stake) and [**What are validators commission?**](#what-are-validators-commission) sections below). Because they share revenue with their validators, delegators also share risks. Should a validator misbehave, each of their delegators will be partially slashed in proportion to their delegated stake. This is why delegators should perform their due diligence on validators before delegating, as well as spreading their stake over multiple validators. Delegators play a critical role in the system, as they are responsible for choosing validators. Being a delegator is not a passive role: Delegators should actively monitor the actions of their validators and participate in governance. For more, read the [delegator's faq](broken://pages/eI3o0VjWXOrcLE7ob1rb). ## Becoming a Validator ### How to become a validator? Any participant in the network can signal that they want to become a validator by sending a `create-validator` transaction, where they must fill out the following parameters: * **Validator's `PubKey`:** The validator's public key is your public key for your `validator's address`. The private key associated with this Tendermint `PubKey` is used to sign *prevotes* and *precommits*. * **Validator's Address:** Application level address. This is the address used to identify your validator publicly. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance. * **Validator's name (moniker):** This is the name of your validator that will be displayed on the interfaces. * **Validator's website (Optional):** This is where delegators can find more information about this particular validator. * **Validator's description (Optional):** Along with the name (moniker), this will be an easier form of identification for delegators. * **Initial commission rate**: The commission rate on block rewards and fees that will be charged by validators and charged to delegators (more information can be found below). * **Maximum commission:** The maximum commission rate which this validator can charge. This parameter cannot be changed after `create-validator` is processed. * **Commission max change rate:** The maximum daily increase of the validator commission. This parameter cannot be changed after `create-validator` is processed. * **Minimum self-delegation:** Minimum amount of PUNDIX the validator needs to have bonded at all time. If the validator's self-delegated stake falls below this limit, their entire staking pool will unbond. You may only increase this later and this makes it a somewhat irreversible change. Once a validator is created, PUNDIX holders can delegate PUNDIX to them, effectively adding stake to their pool. The total stake of an address is the combination of PUNDIX bonded by delegators and PUNDIX self-bonded by the validator. The active validator set is determined solely by the ranking of the total amount staked. The 50 validators with the most total staked are the ones who are designated as **active validators**. If a validator's total stake falls below the top 50 then that validator loses their validator privileges: they don't participate in consensus and generate rewards any more. Over time, the maximum number of validators may increase via on-chain governance proposal. ## Testnet ### How can I join the testnet? The Testnet is a great environment to test your validator setup before launch. We view testnet participation as a great way to signal to the community that you are ready and able to operate a validator. The setup of a testnet is the same as the mainnet with a few minor differences. You can create a testnet validator [here](broken://pages/-Mkl0OUkoVvu-r0pLmNy#create-your-validator). ### What are the different types of keys? In short, there are two types of keys ([for more information on keys](broken://pages/Wx5meKtrckd9w1MWeybP#keys)): * **Operator Key**: This is a unique key used to sign consensus votes. * It is associated with a public key {"@type":"/cosmos.crypto.ed25519.PubKey","key":"XXX...="} (To get the public key, run the command `pundixd tendermint show-validator`). * It is generated when the node is created with pundixd init. * **Account key**: This key is created from `pundixd` and used to sign transactions. * Account keys are associated with a public key prefixed by `pxpub` and an address prefixed by `px`. * Both are generated by `pundixd keys add`. > Note: A validator's operator key is directly tied to an application key, but uses the address (prefixed with`pxvaloper)` and public key (prefixed with `pxvaloperpub)` for consensus and governance purposes. ### What are the different states a validator can be in? After a validator is created with a `create-validator` transaction, they can be in three states: * `Active validator set`: Validator in the active set and participates in consensus. Validator is earning rewards and can be slashed for misbehavior. * `Jailed`: Validator misbehaved and is in jail, i.e. has been kicked out off the validator set. If the reason for being jailed is due to being offline for too long, the validator can send an `unjail` transaction in order to re-enter the active validator set. If the jailing is due to double signing, the validator cannot unjail. * `Inactive`: Validator is not in the active set, and therefore not signing any blocks. Validator cannot be slashed, and does not earn any reward. It is still possible to delegate PUNDIX to this validator. Once a validator becomes inactive, all delegators will start unbonding from this validator automatically. ### What is 'self-delegation'? How can I increase my 'self-delegation'? Self-delegation is delegation of PUNDIX of a validator from his own account. This amount can be increases by sending a `delegate` transaction from your validator's account. ### Is there a minimum amount of PUNDIX that must be delegated to be an active (=bonded) validator? The minimum is `100PUNDIX`. ### How will delegators choose their validators? Delegators are free to delegate to any validators according to their own criteria. Bottom line is that they must **DO YOUR OWN RESEARCH** and carry out their own due diligence on their chosen validator(s). That being said, the criterion we deem to be important include: * **Amount of self-delegated** PUNDIX**:** Amount of self-delegated PUNDIX a validator has. A validator with a higher amount of self-delegated PUNDIX has more skin in the game, making them more accountable for their actions. * **Total amount of delegated** PUNDIX**:** Total amount of PUNDIX delegated to a validator. The higher the amount of PUNDIX delegated to a validator, the higher the voting power of the validator. A higher voting power shows that the community trusts this validator, but it also means that this validator is a bigger target for hackers. Higher weighted validators also decrease the decentralisation of the network. * **Commission rate:** Commission applied to the revenue of validators before it is distributed to their delegators. * **Track record:** Points to note on the track record of a validator inlcudes seniority, past votes on proposals, historical average uptime and how often the node was compromised. Apart from these criterion, validators can add a weblink to their validator account as a form of resume. Validators will need to build rapport within the community to attract delegators. For example, it would be a good practice for validators to have their setup audited by third parties. Note that the PundiX team will not approve or conduct any audit themselves. ## Responsibilities ### Do validators need to be publicly identified? No, they do not. Each delegator will assess validators based on their own criterion. Validators will be able to register a website address when they nominate themselves so that they can advertise their operation as they see fit. Some delegators may prefer a website that clearly displays the team operating the validator and their resume, while others might prefer anonymous validators with positive track records. ### What are the responsibilities of a validator? Validators have two main responsibilities: * **Be able to constantly run a correct version of the software:** Validators need to ensure that they are running an uncompromised and updated version of the software continuously. * **Actively participate in governance:** Validators are required to vote on every proposal. Additionally, validators are expected to be active members of the community. They should always be up-to-date with the current state of the ecosystem and staying abreast of any information on PundiX so that they can make necessary upgrades, and be quick to respond to any changes. ### What does 'participating in governance' entail? Validators and delegators on the Pundi X Chain can vote on proposals to change operational parameters (such as the block gas limit), coordinate upgrades, or make a decision on any given matter. Validators play a special role in the governance system. Being the pillars of the system, they are required to vote on every proposal. It is especially important since validators will vote on behalf of the delegators if the delegators do not vote. ### What does staking imply? Staking PUNDIX can be thought of as a safety deposit for validation activities. When a validator or a delegator wants to retrieve part or all of their deposit, they can send an `unbonding` transaction. Delegators to this validator who unbond their delegation must wait the duration of the UnbondingTime, a **3 weeks unbonding period**, during which time they are liable to being slashed for potential misbehaviors committed by the validator before the unbonding process started. Validators, and their delegators, receive block rewards, fees, and have the right to participate in governance. If a validator misbehaves, a certain portion of their total stake is slashed. This means that every delegator that bonded their PUNDIX with this validator gets penalized in proportion to their bonded stake. Delegators are therefore incentivized to delegate to validators they believe are trustworthy. ### Redelegation You can easily re-allocate your stake from one validator to another without having to wait 21 days to unbond. However, there's a limit or catch to this relegation feature. **21 Day Cooldown: Remember this recurring number** When a user requests to `undelegate` from a validator, the amount of `PUNDIX` that was requested for undelegation will be locked in **unbonding** state for 21 days. For simplicity, we call this the **21 day cooldown**. After the 21 day cooldown passes, a user will be able to make transactions with the `PUNDIX` that was previously in **unbonding** state. This cooldown also applies to certain scenarios in redelegation. In order to **redelegate a portion of delegated PUNDIX from Validator A → Validator B,** there are two options a user could choose from. #### Option #1 Undelegate from **Validator A** and wait for the 21 day unbonding period (cooldown) to pass. Then, delegate the PUNDIX to **Validator B**. * Taking this path may seem un-wise because you’ll have to wait 21 days to delegate that stake with another validator. This is where the **redelegation** feature comes in handy. #### Option #2 Use the redelegation feature to immediately redelegate the PUNDIX from **Validator A → Validator B.** * This **redelegation** feature seems wonderful. You no longer have to wait 21 days to unbond and then delegate that stake to another validator. **But there’s a catch.** #### The 7 Stacks Rule Redelegating from **Validator A → Validator B** using the **same wallet.** Let’s say you want to **redelegate** your PUNDIX from Validator A → Validator B using Wallet #1. With the same wallet address, you are only able to **redelegate from Validator A → Validator B up to 7 times in a 21 day period.** #### Serial Redelegation (Validator Hopping) Redelegating from **Validator A → Validator B**, then redelegating from **Validator B → Validator C** consecutively. **Serial redelegation** is a rule that most delegators would be baffled by when they first try redelegating without looking into the rules. Here’s why. * Redelegating from **Validator A → Validator B**, then consecutively redelegating from **Validator B → Validator C** does not work. * **The 21 day cooldown applies to serial redelegation.** Once you redelegate from Validator A → Validator B, **you will not be able to redelegate from Validator B to another validator for the next 21 days.** In other words, **the validator on the receiving end of redelegation will be on a 21-day redelegation lock** (You will still be able to undelegate from or make some additional delegations to this validator. You just won’t be able to redelegate from the validator.). ***You can’t consecutively do validator-hopping!*** Find more information on redelegation [here](https://medium.com/cosmostation/what-you-need-to-know-about-cosmos-atom-redelegation-e45ca7da6fdf). ### Can a validator run away with their delegators' PUNDIX? In a DPoS blockchain, voting power is associated with the amount of PUNDIX one has. By delegating PUNDIX to a validator, a user delegates voting power. The more voting power a validator has, the more weight they have in the consensus and governance processes. This does not mean that the validator has custody of their delegators' PUNDIX. **By no means can a validator run away with its delegator's funds**. Even though delegated funds cannot be stolen by their validators, delegators are still liable for their validators' misbehaviour. ### How often will a validator be chosen to propose the next block? Does it go up with the quantity of bonded PUNDIX? The validator that is selected to propose the next block is called a proposer. Each proposer is selected deterministically, and the frequency of being chosen is proportional to the voting power (i.e. amount of bonded PUNDIX) of the validator. For example, if the total bonded stake across all validators is 100 PUNDIX and a validator's total stake is 10 PUNDIX, then this validator will proposer `~10%` of the blocks. ## Incentives ### What is the incentive to stake? There are essentailly 2 different types of revenue: * **Block rewards:** The block reward includes PURSE and PUNDIX token, PURSE is the inflation reward and inflated to produce block provisions. PUNDIX is the transaction fee reward. These provisions exist to incentivize PUNDIX holders to bond their stake, as non-bonded PUNDIX will be diluted over time. * **Transaction fees:** Pundi X Chain maintains a whitelist of token that are accepted as fee payment. The initial fee token is the PUNDIX. This total revenue is divided among validators' staking pools according to each validator's weight. Then, within each validator's staking pool the revenue is divided among delegators in proportion to each delegator's stake. A commission on delegators' revenue is applied by the validator before it is distributed. ### What is the incentive to run a validator? Validators earn proportionally more revenue than their delegators because of commissions. Validators also play a major role in governance. If a delegator does not vote, they inherit the vote from their validator. This gives validators a major responsibility in the ecosystem. ### What are validators commission? Revenue received by a validator's pool is split between the validator and their delegators. The validator can apply a commission on the part of the revenue that goes to their delegators. This commission is set as a percentage. Each validator is free to set their initial commission, maximum daily commission change rate and maximum commission. The Pundi X Chain enforces the parameter that each validator sets. Only the commission rate can change after the validator is created. ### How are block rewards distributed? Block rewards are distributed proportionally to all validators relative to their voting power. This means that even though each validator gains PURSE with each reward, all validators will maintain equal weight over time. Let us take an example where we have 10 validators with equal voting power and a commission rate of 1%. Let us also assume that the reward for a block is 1000 PURSE and that each validator has 20% of self-bonded PUNDIX. These tokens do not go directly to the proposer. Instead, they are evenly distributed among validators based on their total weight. So now each validator's pool has 100 PURSE. These 100 PURSE will be distributed according to each participant's stake: * Commission: `100*80%*1% = 0.8` PURSE * Validator gets: `100*20% + Commission = 20.8` PURSE * All delegators get: `100*80% - Commission = 79.2` PURSE Then, each delegator can claim their part of the 79.2 PURSE in proportion to their stake in the validator's staking pool. ### How are fees distributed? Fees are similarly distributed with the exception that the block proposer can get a bonus on the fees of the block they propose if they include more than the minimum number of required precommits. When a validator is selected to propose the next block, they must include at least 2/3 precommits of the previous block. However, there is an incentive to include more than 2/3 precommits in the form of a bonus. The bonus is linear: it ranges from 1% if the proposer includes 2/3rd precommits (minimum for the block to be valid) to 5% if the proposer includes 100% precommits. Of course the proposer should not wait too long or other validators may timeout and move on to the next proposer. As such, validators have to find a balance between the waiting time to get the most signatures and the risk of losing out on proposing the next block. This mechanism aims to incentivize non-empty block proposals, better networking between validators as well as to mitigate censorship. Let's take a concrete example to illustrate the aforementioned concept. In this example, there are 10 validators with equal stake. Each of them applies a 1% commission rate and has 20% of self-delegated PUNDIX. Now comes a successful block that collects a total of 1675 PUNDIX in fees. First, a 40% tax is applied. The corresponding PUNDIX goes to the reserve pool. Reserve pool's funds can be allocated through governance to fund bounties and upgrades. * `40% * 1675 = 670` PUNDIX goes to the reserve pool. 1005 PUNDIX now remain. Let's assume that the proposer included 100% of the signatures in its block. It thus obtains the full bonus of 5%. We have to solve this simple equation to find the reward R for each validator: `9*R + (R + R*5%) = 1005 ⇔ R = 1005/10.05 = 100` * For the proposer validator: * The pool obtains `R + R * 5%`: 105 PUNDIX * Commission: `105 * 80% * 1%` = 0.84 PUNDIX * Validator's reward: `105 * 20% + Commission` = 21.84 PUNDIX * Delegators' rewards: `105 * 80% - Commission` = 83.16 PUNDIX (each delegator will be able to claim its portion of these rewards in proportion to their stake) * For each non-proposer validator: * The pool obtains R: 100 PUNDIX * Commission: `100 * 80% * 1%` = 0.8 PUNDIX * Validator's reward: `100 * 20% + Commission` = 20.8 PUNDIX * Delegators' rewards: `100 * 80% - Commission` = 79.2 PUNDIX (each delegator will be able to claim their portion of these rewards in proportion to their stake) ### How is the Pundi X Chain APR calculated? The reward token PURSE is divided by the delegation token PUNDIX to calculate the APR. Because the delegation token is inconsistent with the reward token ie the numerator is in PURSE and denominator is in PUNDIX, the resulting APR will be very high given the high emission of PURSE per block. ### What are the slashing conditions? If a validator misbehaves, their delegated stake will be partially slashed. There are currently two conditions that can result in slashing of funds for a validator and their delegators: * **Double signing:** If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, and if chain A and chain B share a common ancestor, then this validator will get slashed by 5% on chain A. Validators who double sign will be jailed and CANNOT be unjailed thereafter. * **Downtime:** If a validator misses more than 95% of the last 20000 blocks (\~27.7hours), they will get slashed by 0.1%. Validators may `unjail` their validators after a 600s (10minute) window. {% hint style="info" %} The portion of PUNDIX that is subjected to slashing conditions is the total delegated PUNDIX. The rewards earned will not be subjected to slashing conditions. If a validator is jailed, the same rules apply to redelegation and unbonding. For unbonding, you still have to wait 21 days. While for redelegation, you may do so and the [following rules](broken://pages/aWJyB33Atd23HxUW5rp6#redelegation) will apply. {% endhint %} ### Do validators need to self-delegate PUNDIX? Yes, they do need to self-delegate at least `100PUNDIX`. Even though there is no obligation for validators to self-delegate more than `100PUNDIX`, delegators should want their validator to have more self-delegated PUNDIX in their staking pool. In other words, validators should have skin in the game. In order for delegators to have some guarantee about how much skin-in-the-game their validator has, the latter can signal a minimum amount of self-delegated PUNDIX. If a validator's self-delegation goes below the limit that it predefined, this validator and all of its delegators will unbond. ### How to prevent concentration of stake in the hands of a few top validators? For now the community is expected to behave in a smart and self-preserving way. For example, when a mining pool in Bitcoin gets too much mining power, the community usually stops contributing to that pool. The Pundi X Chain will rely on the same effect initially. Other mechanisms are in place to smoothen this process as much as possible: * **Penalty-free re-delegation:** This is to allow delegators to easily switch from one validator to another, in order to reduce validator stickiness. * **UI warning:** Wallets can implement warnings that will be displayed to users if they want to delegate to a validator that already has a significant amount of staking power. ## Technical Requirements ### What are hardware requirements? Validators should expect to provision one or more data center locations with redundant power, networking, firewalls, HSMs and servers. We expect that a modest level of hardware specifications will be needed initially and that they might rise as network use increases. Participating in the testnet is the best way to learn more. ### What are software requirements? In addition to running a Pundi X Chain node, validators should develop monitoring, alerting and management solutions. ### What are bandwidth requirements? The Cosmos network has the capacity for very high throughput relative to chains like Ethereum or Bitcoin. We recommend that the data center nodes only connect to trusted full-nodes in the cloud or other validators that know each other socially. This relieves the data center node from the burden of mitigating denial-of-service attacks. Eventually, as the network becomes more heavily used, multigigabyte per day bandwidth is very realistic. ### What does running a validator imply in terms of logistics? A successful validator operation will require the efforts of multiple highly skilled individuals and continuous operational attention. This will require considerably more involvement than running a bitcoin miner for instance. ### How to handle key management? Validators should expect to run an HSM that supports ed25519 keys. Here are potential options: * YubiHSM 2 * Ledger Nano S * Ledger BOLOS SGX enclave * Thales nShield support The FunctionX team does not recommend one solution over another. The community is encouraged to bolster the efforts to improve HSMs and the security of key management. ### What can validators expect in terms of operations? Running an effective operation is key to avoiding unexpected unbonding or being slashed. This includes being able to respond to attacks, outages, as well as to maintain security and isolation in your data center. ### What are the maintenance requirements? Validators should expect to perform regular software updates to accommodate upgrades and bug fixes. There will inevitably be issues with the network early in its bootstrapping phase that will require substantial vigilance. ### How can validators protect themselves from denial-of-service attacks? Denial-of-service attacks occur when an attacker sends a flood of internet traffic to an IP address to prevent the server at the IP address from connecting to the internet. An attacker scans the network, tries to learn the IP address of various validator nodes and disconnect them from communication by flooding them with traffic. One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture. Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes, and may require new sentry nodes be spun up or activated to mitigate attacks on existing ones. Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet based attacked cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network. It is expected that good operating procedures on that part of validators will completely mitigate these threats. # Validator Security Each validator is encouraged to run its operations independently, as diverse setups increase the resilience of the network. Validators should be well versed in the setup and maintenance process of a validator to ensure security and stability of their individual validators and the network as a whole. ## Hardware Security Modules (HSM) It is critical that an attacker cannot steal a validator's keys. If this is possible, it compromises the validator's staked assets as well as all its delegated stake. Hardware security modules are an important strategy for mitigating this risk. HSM modules must support `ed25519` signatures for the hub. The PundiX team is also working on extending our Ledger Nano X application to support validator signing. This app can store recent blocks and mitigate double signing attacks. We will update this page when more key storage solutions become available. ## Sentry Nodes (DDOS Protection) Validators are responsible for ensuring that the network can sustain denial of service attacks. One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture. Validator nodes should only connect to full-nodes they trust because they operate them themselves or are run by other validators they can trust or know socially. A validator node will typically run in a data center. Most data centers provide direct links to the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the attack vector of denial-of-service from the validator's node directly to its sentry nodes. This may require new sentry nodes be spun up or activated on the fly to mitigate attacks on existing ones. Sentry nodes can be spun up quickly or have their IP addresses changed. Because the links to the sentry nodes are in private IP space, an internet based attacked will not affect them directly. This will ensure validator block proposals and votes will always be broadcasted to the rest of the network. To setup your sentry node architecture you can follow the instructions below: The `config.toml` file should be stored in `$HOEM/.pundix/config/config.toml` file path. You may run the `vi` command line editor to edit the `config.toml` file. If you were in your root directory where `.pundix` is situated, you may run the following command to launch the `config.toml` file using the Vi command line editor: ```bash vi $HOEM/.pundix/config/config.toml # Validators nodes should edit their `config.toml`: # Comma separated list of nodes to keep persistent connections to # DO NOT add private peers to this list if you don't want them advertised # Example ID: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@node-2.pundix.com:26656 persistent_peers = "list of sentry nodes" # Set true to enable the peer-exchange reactor pex = false # Sentry Nodes should edit their `config.toml`: # Comma separated list of peer IDs to keep private (will not be gossiped to other peers) # Example ID: 3e16af0cead27979e1fc3dac57d03df3c7a77acc@3.87.179.235:26656 private_peer_ids = "node_ids_of_private_peers" ``` Once you have made changes and want to save the file, press `:x` (you must not be in Insert mode. If you are, press ESC to leave it). ## Ports On the note DDOS, remember to ensure you have closed off the ports that should not be made public. You may consider whitelisting the addresses that need access to certain ports that need to be open but not made public. Here are some ports and what they are used for: `26656`: If you turn this off, no one else will be able to connect to your node and you will not be contributing to the network, but you can still connect with others and also synchronize your data. `26657`: This is a json-rpc port used by commands interacting with the node. `26660`: This port is used for your node monitoring device queries. `6060`: Analysis `Golang` program (for debugging use) `22`: ssh port ## Environment Variables Note that while explicit command-line flags will take precedence over environment variables, environment variables will take precedence over any of your configuration files. For this reason, it's imperative that you lock down your environment such that any critical parameters are defined as flags on the CLI or prevent modification of any environment variables. # Sentry Nodes ## Setting up a Validator When setting up a validator there are countless ways to configure your setup. This guide is aimed at showing one of them, the sentry node design. This design is mainly for DDOS prevention. ![](/files/najyTZOoCs49f3OmkSo2) The diagram is based on AWS, other cloud providers will have similar solutions to design a solution. Running nodes is not limited to cloud providers, you can run nodes on bare metal systems as well. The architecture will be the same no matter which setup you decide to go with. The proposed network diagram is similar to the classical backend/frontend separation of services in a corporate environment. The “backend” in this case is the private network of the validator in the data center. The data center network might involve multiple subnets, firewalls and redundancy devices, which is not detailed on this diagram. The important point is that the data center allows direct connectivity to the chosen cloud environment. Amazon AWS has “Direct Connect”, while Google Cloud has “Partner Interconnect”. This is a dedicated connection to the cloud provider (usually directly to your virtual private cloud instance in one of the regions). All sentry nodes (the “frontend”) connect to the validator using this private connection. The validator does not have a public IP address to provide its services. Amazon has multiple availability zones within a region. One can install sentry nodes in other regions too. In this case the second, third and further regions need to have a private connection to the validator node. This can be achieved by VPC Peering (“VPC Network Peering” in Google Cloud). In this case, the second, third and further region sentry nodes will be directed to the first region and through the direct connect to the data center, arriving to the validator. A more persistent solution (not detailed on the diagram) is to have multiple direct connections to different regions from the data center. This way VPC Peering is not mandatory, although still beneficial for the sentry nodes. This overcomes the risk of depending on one region. It is more costly. ![](/files/4fz4GkzxxFptHq2HVosH) The validator will only talk to the sentry that are provided, the sentry nodes will communicate to the validator via a secret connection and the rest of the network through a normal connection. The sentry nodes do have the option of communicating with each other as well. ## Technical Setup {% hint style="info" %} For more information on technical set up, you may refer [here](https://docs.tendermint.com/master/nodes/validators.html). {% endhint %} The main aim of a sentry node is to protect our validator nodes from a huge number of queries thus overloading the port (DDOS). ### Characteristics of a Sentry Node The sentry node has to be a full-node: * It has to be on a different server from the one you have your validator node on * It does not have to be in the same locale as your validator node * Having multiple sentry nodes would have even greater protection against **How you should configure your `config.toml` file for your ****VALIDATOR NODE****/****SENTRY NODE** {% hint style="info" %} You may access your config.toml file in \~/.pundix/config/config.toml {% endhint %} * `pex:` boolean. This turns the peer exchange reactor on or off for a node. When `pex=false`, only the `persistent-peers` list is available for connection. **This should be set to** **`pex=false`** **so it does not gossip to the entire network.** **The sentry nodes should be able to talk to the entire network hence why** `pex=true`. * `seed_mode`: boolean. The main function of the seed\_mode is to provide more node addresses to the network. It will record all the node addresses that have been connected to it, and as long as you connect to it, it will tell you all the node information it records. This way you can connect to a node quickly. The seed node will disconnect from you immediately after giving you all the node information, so it is not recommended that the validator node enable the seed mode. **This should be set to** **`seed_mode=false`. ****This should be set to seed\_mode=false.** * `persistent-peers:` a comma separated list of `nodeID@ip:port` values that define a list of peers that are expected to be online at all times. This is necessary at first startup because by setting `pex=false` the node will not be able to join the network. **This should be configured to a list of sentry nodes.** **This should be configured to your any nodes that you trust, this includes your validator node, the Function X's nodes and other sentry nodes (optional).** * `unconditional_peer_ids:` comma separated list of `nodeID`. These nodes will be connected to no matter the limits of inbound and outbound peers. This is useful for when sentry nodes have full address books. **It can be filled with sentry node IDs (optional).** **Validator node ID, optionally sentry node IDs.** * `private_peer_ids:` comma separated list of `nodeID`. **These nodes will not be gossiped to the network.** This is an important field as you DO NOT want your validator IP gossiped to the network. **This can be left empty as the validator is not trying to hide who it is communicating with.** **This should be configured to your validator node ID to ensure your validator node's ID is hidden.** * `addr_book_strict:` boolean. By default nodes with a routable address will be considered for connection. If this setting is turned off (false), non-routable IP addresses, like addresses in a private network can be added to the address book. **This should be set to** **`addr_book_strict=false`****.**** ****This should be set to** `addr_book_strict=false`. * `double-sign-check-height` int64 height. How many blocks to look back to check existence of the node's consensus votes before joining consensus When non-zero, the node will panic upon restart if the same consensus key was used to sign `{double_sign_check_height}` last blocks. So, validators should stop the state machine, wait for some blocks, and then restart the state machine to avoid panic. **This should be configured to 10.** **This configuration is not important for sentry nodes.** * `seeds`: Linked to the `seed_mode` configuration mentioned above, a seed node is a special node that allows the incorporation of new nodes to the network and maintains the strength of the network at all times, by allowing them to synchronize and obtain a copy of the data from the blockchain, replicating it and adding resistance and security to it. For validator nodes **If you have already configured the**** `persistent-peers`** **to have a list of sentry nodes or nodes that you fully trust, then you can leave the**** `seeds`** **field empty.** **This** **`seeds`** **field should be configured to locate other peers.** ### Validator Node Configuration | Config Option | Setting | | ----------------------------------- | -------------------------- | | seed\_mode | false | | pex | false | | persistent-peers (`nodeID@ip:port`) | list of sentry nodes | | private-peer-ids (`nodeID`) | none | | unconditional-peer-ids (`nodeID`) | optionally sentry node IDs | | addr-book-strict | false | | double-sign-check-height | 10 | ### Sentry Node Configuration | Config Option | Setting | | ----------------------------------- | --------------------------------------------- | | seed\_mode | false | | pex | true | | persistent-peers (`nodeID@ip:port`) | validator node, optionally other sentry nodes | | private-peer-ids (`nodeID`) | validator node ID | | unconditional-peer-ids (`nodeID`) | validator node ID, optionally sentry node IDs | | addr-book-strict | false | ## Obtain Node ID Run this command: ``` pundixd tendermint show-node-id ``` For those fields that require just a Node ID, it will be something similar to (example): `6f55c84d12klmsdf7c4be0dc15b667892aaeea5cd7`. For those fields that require `nodeID@ip:port` (persistent-peers), it will be something similar to (example): `6f55c84d12klmsdf7c4be0dc15b667892aaeea5cd7@127.0.0.1:26656`. # Delegator FAQ ## What is a delegator? People who cannot or do not want to operate [validator nodes](https://docs.pundix.com/validators/validator-overview) can still participate in the staking process as delegators. Active validators are chosen and ranked based on their total overall PUNDIX staked (this is the sum of their self-delegated stake as well as their delegators' stake). They are by no means solely chosen by their self-delegated stake. This is an important property and acts as a safeguard against validators that are bad actors. In a decentralized ecosystem, if a validator is a bad actor, delegators will undelegate their PUNDIX from them to avoid incurring any slashings of their delegated stake. Good actors will invariably have more PUNDIX delegated to them. Game theory dictates that over time, validators who are bad actors will exit the active validator set whilst good actors will remain or climb higher up the ranks, eventually resulting in a stable and secure ecosystem. **Delegators share the revenue of their validators, but they also share the risks.** In terms of revenue, validators and delegators differ in that validators can apply a commission on the revenue that goes to their delegator before it is distributed. This commission is known to delegators beforehand and can only be changed according to predefined constraints (see [section](#choosing-a-validator) below). In terms of risks, delegators' PUNDIX will be slashed if their validator misbehaves. For more, see [Risks](#risks) section. To become delegators, PUNDIX holders need to send a "Delegate transaction" where they specify the amount of PUNDIX they want to stake and with which validator. A list of validators will be displayed in starscan explorers ([mainnet](https://starscan.io/pundix/validators)/[testnet](https://testnet.starscan.io/pundix/validators)). Subsequently, if a delegator wants to unbond part or all of their stake, they will need to send an "Unbond transaction". Delegators will have to wait for 3 weeks to retrieve their PUNDIX after sending an "Unbond Transaction". Delegators can also send a "Redelegate Transaction" to switch from one validator to another, without having to go through the 3 weeks waiting period. {% hint style="info" %} However,there is a limit to how frequent you can redelegate. For more information on [redelegation](#redelegation). {% endhint %} For a technical guide on how to become a delegator, click [here](/delegators/delegator-cli-guide). ## Choosing a validator In order to choose their validators, delegators have access to a range of information directly in starscan block explorers ([mainnet](https://starscan.io/pundix/validators)/[testnet](https://testnet.starscan.io/pundix/validators)). * **Validator's moniker**: Name of the validator. * **Validator's description**: Description provided by the validator's operator. * **Validator's website**: Link to the validator's website. * **Initial commission rate**: The commission rate on revenue charged to any delegator by the validator (see below for more detail). * **Commission max change rate:** The maximum daily increase of the validator's commission. This parameter cannot be changed by the validator operator. * **Maximum commission:** The maximum commission rate this validator candidate can charge. This parameter cannot be changed by the validator operator. * **Minimum self-bond amount**: Minimum amount of PUNDIX the validator candidate need to have bonded at all time. If the validator's self-bonded stake falls below this limit, their entire staking pool (i.e. all its delegators) will unbond. This parameter exists as a safeguard for delegators. Indeed, when a validator misbehaves, part of their total stake gets slashed. This included the validator's self-delegateds stake as well as their delegators' stake. Thus, a validator with a high amount of self-delegated PUNDIX has more skin-in-the-game than a validator with a low amount. The minimum self-bonded parameter guarantees delegators that a validator will never fall below a certain amount of self-bonded stake, thereby ensuring a minimum level of skin-in-the-game. This parameter can only be increased by the validator operator. ## Directives of delegators Being a delegator is not a passive task. Here are the main directives of a delegator: * **Perform careful due diligence on validators before delegating.** If a validator misbehaves, part of their total stake, which includes the stake of their delegators, will be slashed. Delegators should therefore select validators carefully and to their own research on who they are delegating to. * **Actively monitor their validator after having delegated.** Delegators should ensure that the validators they delegate to does not misbehave, meaning that they have good uptime, do not double sign or get compromised, and participate in governance. They should also monitor the commission rate that is being applied to the revenue they are receiving. If a delegator is not satisfied with its validator, they can unbond or rebond and switch to another validator (Note: Delegators do not have to wait for the unbonding period to switch validators. Rebonding takes effect immediately). * **Participate in governance.** Delegators can and are expected to participate actively in governance. A delegator's voting power is proportional to the size of their bonded stake. If a delegator does not vote, they will inherit the vote of their validator(s). If they do vote, they override the vote of their validator(s). ## Revenue Validators and delegators earn revenue in exchange for their services. This revenue is given in three forms: * **Block provisions (PUNDIX):** They are paid in newly created PUNDIX. Block provisions exist to incentivize PUNDIX holders to stake. The yearly inflation rate is calculated to target 2/3 bonded stake. If the total bonded stake in the network is less than 2/3 of the total PUNDIX supply, inflation increases until it reaches 41%. If the total bonded stake is more than 2/3 of the PUNDIX supply, inflation decreases until it reaches 17%. This means that if total bonded stake stays less than 2/3 of the total PUNDIX supply for a prolong period of time, unbonded PUNDIX holders can expect their PUNDIX value to deflate in value by 41% (compounded) per year. * **Transaction fees (various tokens):** Each transfer on the Pundi X Chain comes with transactions fees. These fees can be paid in any currency that is whitelisted by the PundiX governance. Fees are distributed to bonded PUNDIX delegators in proportion to their stake. The first whitelisted token at launch is PUNDIX. ## Validator Commission Each validator receives revenue based on their total stake. Before this revenue is distributed to delegators, the validator can apply a commission. In other words, delegators have to pay a commission to their validators on the revenue they earn. Let us look at a concrete example: We consider a scenario where there are 10 validators in the ecosystem and all have an equal weight. So any one validator's proportion of total stake in the entire ecosystem (i.e. self-delegated stake + delegated stake) is 10%. Take an example of one particular validator that has 20% self-delegated stake and applies a commission of 10%. Now let us consider a block with the following revenue: * 990 PUNDIX in block provisions * 10 PUNDIX in transaction fees. This amounts to a total of 1000 PUNDIX to be distributed among all staking pools. Each validator's staking pool will receive 10% of this total amount which amounts to 100PUNDIX. Now let us look at the internal distribution of revenue: * Commission = `10% * 80% * 100` PUNDIX = 8 PUNDIX * Validator's revenue = `20% * 100` PUNDIX + Commission = 28 PUNDIX * Delegators' total revenue = `80% * 100` PUNDIX - Commission = 72 PUNDIX Then, each delegator in the staking pool can claim their portion of the delegators' total revenue. ## Risks Staking PUNDIX is not a risk-free activity. First, staked PUNDIX are locked up, and retrieving them requires a 3 week waiting period called unbonding period. Additionally, if a validator misbehaves, a portion of their total stake can be slashed. This includes the stake of their delegators. There are currently two conditions that can result in slashing of funds for a validator and their delegators: * **Double signing:** If someone reports on chain A that a validator signed two blocks at the same height on chain A and chain B, and if chain A and chain B share a common ancestor, then this validator will get slashed by 5% on chain A. Validators who double sign will be jailed and CANNOT be unjailed thereafter. * **Downtime:** If a validator misses more than 95% of the last 20000 blocks (\~27.7hours), they will get slashed by 0.1%. Validators may `unjail` their validators after a 600s (10minute) window. {% hint style="info" %} The portion of PUNDIX that is subjected to slashing conditions is the total delegated PUNDIX. The rewards earned will not be subjected to slashing conditions. If a validator is jailed, the same rules apply to redelegation and unbonding. For unbonding, you still have to wait 21 days. While for redelegation, you may do so and the [following rules](broken://pages/eI3o0VjWXOrcLE7ob1rb#redelegation) will apply. {% endhint %} ### Redelegation You can easily re-allocate your stake from one validator to another without having to wait 21 days to unbond. However, there's a limit or catch to this relegation feature. **21 Day Cooldown: Remember this recurring number** When a user requests to `undelegate` from a validator, the amount of `PUNDIX` that was requested for undelegation will be locked in **unbonding** state for 21 days. For simplicity, we call this the **21 day cooldown**. After the 21 day cooldown passes, a user will be able to make transactions with the `PUNDIX` that was previously in **unbonding** state. This cooldown also applies to certain scenarios in redelegation. In order to **redelegate a portion of delegated PUNDIX from Validator A → Validator B,** there are two options a user could choose from. {% hint style="info" %} Do note that during the unboding state, users will cease to earn rewards but will be subjected to slashing conditions if their validators misbehave. {% endhint %} #### Option #1 Undelegate from **Validator A** and wait for the 21 day unbonding period (cooldown) to pass. Then, delegate the PUNDIX to **Validator B**. * Taking this path may seem un-wise because you’ll have to wait 21 days to delegate that stake with another validator. This is where the **redelegation** feature comes in handy. #### Option #2 Use the redelegation feature to immediately redelegate the PUNDIX from **Validator A → Validator B.** * This **redelegation** feature seems wonderful. You no longer have to wait 21 days to unbond and then delegate that stake to another validator. **But there’s a catch.** #### The 7 Stacks Rule Redelegating from **Validator A → Validator B** using the **same wallet.** Let’s say you want to **redelegate** your PUNDIX from Validator A → Validator B using Wallet #1. With the same wallet address, you are only able to **redelegate from Validator A → Validator B up to 7 times in a 21 day period.** #### Serial Redelegation (Validator Hopping) Redelegating from **Validator A → Validator B**, then redelegating from **Validator B → Validator C** consecutively. **Serial redelegation** is a rule that most delegators would be baffled by when they first try redelegating without looking into the rules. Here’s why. * Redelegating from **Validator A → Validator B**, then consecutively redelegating from **Validator B → Validator C** does not work. * **The 21 day cooldown applies to serial redelegation.** Once you redelegate from Validator A → Validator B, **you will not be able to redelegate from Validator B to another validator for the next 21 days.** In other words, **the validator on the receiving end of redelegation will be on a 21-day redelegation lock** (You will still be able to undelegate from or make some additional delegations to this validator. You just won’t be able to redelegate from the validator.). ***You can’t consecutively do validator-hopping!*** Find more information on redelegation [here](https://medium.com/cosmostation/what-you-need-to-know-about-cosmos-atom-redelegation-e45ca7da6fdf). # Delegator Overview {% hint style="info" %} **DISCLAIMER** **Please note that you are about to interact with the PundiX** (Pundi X Chain)**, a blockchain technology containing highly experimental software. While the blockchain has been developed with state of the art technology and audited with utmost care, we may still expect to have issues, updates and bugs. Furthermore, interaction with blockchain technology requires advanced technical skills and always involves risks that are outside our control. By using the software, you confirm that you understand the inherent risks associated with cryptographic software and that the PundiX team will not be held liable for potential damages arising out of the use of the software. Any use of this open source software released under the Apache 2.0 license is done at your own risk and on an "AS IS" basis, without warranties or conditions of any kind.** {% endhint %} ## Community PundiX (Pundi X Chain) delegation is driven by the PundiX community, and much of the documentation in this repo was funded by the community. Delegator discussions happens in a number of places moderated by diverse community members, including: * [Forum](https://forum.pundix.com/) * [Telegram](https://t.me/pundix) * [Twitter](https://twitter.com/PundiXLabs) * [Reddit](https://www.reddit.com/r/PundiX/) * [Gitbook](https://github.com/pundix) # Delegator CLI Guide This document contains all the necessary information for delegators to interact with the PundiX through the Command-Line Interface (CLI). It also contains instructions on how to manage accounts, restore accounts from the fundraiser and use a ledger nano device. ## Installing `pundixd` `pundixd`: This is the command-line interface (CLI) to interact with a `pundixd` full-node. {% hint style="info" %} Please check that you have downloaded the latest stable release of `pundixd` [**Install from source**](https://github.com/pundix/pundix) {% endhint %} `pundixd` can be interacted with via a terminal. To open the terminal, follow these steps: * **Windows**: `Start` > `All Programs` > `Accessories` > `Command Prompt` * **MacOS**: `Finder` > `Applications` > `Utilities` > `Terminal` * **Linux**: `Ctrl` + `Alt` + `T` ## PundiX Accounts At the core of every PundiX account, there is a seed, which takes the form of a 12 or 24-words mnemonic. From this mnemonic, it is possible to create multiple PundiX accounts, for example pairs of private key/public key. This is called an HD wallet (see [BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) for more information on the HD wallet specification). ``` Account 0 Account 1 Account 2 +------------------+ +------------------+ +------------------+ | | | | | | | Address 0 | | Address 1 | | Address 2 | | ^ | | ^ | | ^ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + | | + | | + | | Public key 0 | | Public key 1 | | Public key 2 | | ^ | | ^ | | ^ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + | | + | | + | | Private key 0 | | Private key 1 | | Private key 2 | | ^ | | ^ | | ^ | +------------------+ +------------------+ +------------------+ | | | | | | | | | +--------------------------------------------------------------------+ | | +---------+---------+ | | | Mnemonic (Seed) | | | +-------------------+ ``` The funds stored in an account are controlled by the private key. This private key is generated from the mnemonic using a one-way function. If you lose the private key, you can retrieve it using the mnemonic. However, if you lose the mnemonic, you will lose access to all the derived private keys. Likewise, if someone gains access to your mnemonic, they gain access to all the associated accounts. {% hint style="danger" %} **DO NOT lose or share your 24-word mnemonic with anyone. To prevent theft or loss of funds, it is best to ensure that you keep multiple copies of your mnemonic, and store it in a safe, secure place that only you have access to. If someone has your mnemonic, they will be able to gain access to your private keys and control the accounts associated with them.** {% endhint %} The address is a public string with a human-readable prefix (for example `px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6`) that identifies your account. When someone wants to send you funds, they send it to your address. It is virtually computationally impossible to derive the private key from a public address. ### On Ledger Device At the core of a ledger device, there is a mnemonic used to generate accounts on multiple blockchains (including the PundiX). When you first initialize your ledger device, you will create a new mnemonic. It is possible to import an existing mnemonic into a ledger device instead. Let us go ahead and see how you can import a mnemonic into your ledger device. For more on how to restore from a recovery phrase, refer [here](https://support.ledger.com/hc/en-us/articles/4404382560913-Restore-from-recovery-phrase?support=true). {% hint style="info" %} To import a mnemonic into a ledger, **it is preferable to use a brand new ledger device.** There can only be one mnemonic per ledger device. If you want to use a ledger that is already initialized with a seed, you can reset it by going into `Control Center`>`Settings`>`Security`>`Reset Device`. More on how to reset your ledger device can be found [here](https://support.ledger.com/hc/en-us/articles/360017582434-Reset-to-factory-settings-?docs=true). **Please note that this will wipe out the seed currently stored on the device. If you have not properly secured the associated mnemonic, you could lose your funds!!!** {% endhint %} The following steps need to be performed on an un-initialized ledger device: 1. Ensure ledger live is downloaded and installed. 2. Press the button next to the USB port until the Ledger logo appears to turn on the device. 3. Read the on-screen instructions. Press the right button to proceed or the left button to go back. 4. Press both simultaneously when Set up as new device is displayed. 5. **DO NOT** choose the "Config as a new device" option. Instead, choose "Restore Configuration" 6. Choose a PIN 7. Choose the 24 words option 8. Input each of the words in the correct order. Your ledger is now correctly set up with your imported mnemonic! **DO NOT** lose this mnemonic! If your ledger is compromised, you can always restore a new device again using the same mnemonic. Next, click [here](#using-a-ledger-device) to learn how to generate an account. ### On a Computer {% hint style="info" %} **It is more secure to perform this action on an offline computer.** {% endhint %} To restore an account using a mnemonic and store the associated encrypted private key on a computer, use the following command: ```bash # recover px address pundixd keys add --algo secp256k1 --coin-type 118 --index --recover ``` * `<_key_name>` is the name of the account. It is a reference to the account number used to derive the key pair from the mnemonic. You will use this name to identify your account when you want to send a transaction. * You can add the optional `--index` flag to specify the path (`0`, `1`, `2`, ...) you want to use to generate your account. By default, account `0` is generated. The private key of account `0` will be saved in your operating system's credentials storage. Each time you want to send a transaction, you will need to unlock your system's credentials store. If you lose access to your credentials storage, you can always recover the private key with the mnemonic. {% hint style="danger" %} **You may not be prompted for a password each time you send a transaction since most operating systems unlock a user's credentials store upon login by default. If you want to change your credentials store security policies please refer to your operating system manual.** {% endhint %} ## Creating an Account To create an account, you just need to have `pundixd` installed. Before creating it, you need to know where you intend to store and interact with your private keys. The best options are to store them in a dedicated offline computer or a ledger device. Storing them on your regular online computer involves more risk, since anyone who infiltrates your computer through the internet could gain access to your private keys and steal your funds. ### Using a Ledger Device {% hint style="danger" %} **Only use Ledger devices that you bought brand new or that you know is NOT compromised.** {% endhint %} When you initialize your ledger, a 24-word mnemonic is generated and stored in the device. This mnemonic is compatible with PundiX and PundiX accounts can be derived from it. All you have to do is make your ledger compatible with `pundixd`. To do so, you need to go through the following steps: 1. Download the Ledger Live app [here](https://www.ledger.com/pages/ledger-live). 2. Connect your ledger via USB and update to the latest firmware 3. Go to the ledger live app store, and download the "PundiX" application (this can take a while). **You may have to enable `Dev Mode` in the `Settings` of Ledger Live to be able to download the "PundiX" application**. 4. Navigate to the PundiX app on your ledger device Then, to create an account, run the following command: ```bash # create px address pundixd keys add --algo secp256k1 --coin-type 118 --ledger --index ``` {% hint style="info" %} **This command will only work while the Ledger is plugged in and unlocked.** {% endhint %} * `<_key_name>` is the name of the account. It is a reference to the account number used to derive the key pair from the mnemonic. You will use this name to identify your account when you want to send a transaction. * You can add the optional `--index` flag to specify the path (`0`, `1`, `2`, ...) you want to use to generate your account. By default, account `0` is generated. Just remember to take note of the accounts and index you have stored the keys in your ledger. You can generate more accounts from the same mnemonic using the following command: ```bash pundixd keys add brucebanner<0x_key_name> --algo secp256k1 --coin-type 118 --ledger --index 2 ``` This command will prompt you to input a passphrase as well as your mnemonic. Change the account number to generate an account with a different index. {% hint style="danger" %} **DO NOT lose or share your 24 word mnemonics with anyone. To prevent theft or loss of funds, it is best to ensure that you keep multiple copies of your mnemonic, and store it in a secure place that only you know how to access. If someone is able to gain access to your mnemonic, they will be able to gain access to your private keys and control the accounts associated with them.** {% endhint %} After you have secured your mnemonic (triple check!), you can delete bash history to ensure no one can retrieve it: ```bash history -c rm ~/.bash_history ``` ## Accessing the PundiX Network In order to query the state and send transactions, you need a way to access the network. To do so, you can either run your own full-node, or connect to an available public node. {% hint style="danger" %} **DO NOT share your mnemonic (24 words) with anyone. The only person who should ever need to know it is you. No one from the PundiX team will ever send an email that asks for you to share any kind of account credentials or your mnemonics."** {% endhint %} ### Running Your Own Full-Node This is the most secure option, but comes with relatively high resource requirements and costs. In order to run your own full-node, you need good bandwidth and at least 500GB of disk space. You will find the tutorial on how to install `pundixd` [here](/getting-started/installation-pundix), and the guide to run a full-node [here](/getting-started/setup-node). ### Connecting to a Remote Full-Node If you DO NOT want or cannot run your own node, you can connect to someone else's full-node. You should pick a full-node operator that you trust, because a malicious operator could return incorrect query results or censor your transactions. However, they will never be able to steal your funds, as your private keys are stored locally on your computer or ledger device. Possible options for full-node operators include validators, wallet providers or exchanges. In order to connect to a full-node, you will need an address in the form of: `https://127.0.0.1:26657` (*This is a placeholder*). This address has to be provided by the full-node operator you choose to trust. You will use this address in the [following section](#setting-up-pundixd). ## Setting Up `pundixd` {% hint style="info" %} Before setting up `pundixd`, ensure that you have found a way to [**access the PundiX network**](#accessing-the-pundix-network) Please check that you are always using the latest stable release of `pundixd.` {% endhint %} `pundixd` is the tool that enables you to interact with the node that runs on the PundiX network. In order to set up `pundixd`, use the following command. It allows you to set a default value for each given flag. First, set up the address of the full-node you want to connect to: ```bash pundixd config : # for example pundixd config config.toml rpc.laddr https://127.0.0.1:26657 ``` If you run your own full-node, just use `tcp://localhost:26657` as the address. Then, let us set the default value of the `--trust-node` flag: ```bash # Set to true if you trust the full-node you are connecting to, false otherwise pundixd config trust-node false ``` Finally, let us set the `chain-id` of the blockchain we want to interact with (chain-id for testnet is payalebar): ```bash pundixd config config.toml chain-id pundix ``` ### Querying the State {% hint style="info" %} Before you can bond PUNDIX and withdraw rewards, you need to [**set up `pundixd`**](#setting-up-pundixd) {% endhint %} `pundixd` lets you query all relevant information from the blockchain, like account balances, amount of bonded tokens, outstanding rewards, governance proposals and more. Next is a list of the most useful commands for delegators. ```bash # query account balances and other account-related information pundixd query account # query the list of validators pundixd query staking validators # query the information of a validator given their address (for example pxvaloper1hs3tfedle32zzr5dh38gzzfn9ak2f4a96gg7h6) pundixd query staking validator # query all delegations made from a delegator given their address (for example px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6) pundixd query staking delegations # query a specific delegation made from a delegator (for example px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6) to a validator (for example pxvaloper1hs3tfedle32zzr5dh38gzzfn9ak2f4a96gg7h6) given their addresses pundixd query staking delegation # query the rewards of a delegator given a delegator address (for example px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6) pundixd query distribution rewards ``` For more commands, just type: ```bash pundixd query ``` For each command, you can use the `-h` or `--help` flag to get more information. ## Sending Transactions ### A Note on Gas and Fees Transactions on the PundiX network need to include a transaction fee in order to be processed. This fee pays for the gas required to run the transaction. The formula is as such: ``` fees = ceil(gas * gas-prices) ``` The `gas` is dependent on the transaction. Different transactions require a different amount of `gas`. The amount of `gas` needed for a transaction is calculated when it is being processed, but there is a way to estimate it beforehand by using the `auto` value for the `gas` flag. Of course, this only fills in an estimate for the gas of that particular transaction. You can adjust this estimate with the flag `--gas-adjustment` (default `1.2`) if you want to be sure you have provided enough `gas` for the transaction. For the remainder of this tutorial, we will use a `--gas-adjustment` of `1.5`. The `gas-prices` is the price of each unit of `gas`. Each validator sets a `min-gas-price` value, and will only include transactions that have a `gas-prices` greater than the `min-gas-price` they have set initially. Transaction `fees` is the product of `gas` and `gas-prices`. As a user, you can either just fill in the `fees` required or you have to fill in both the `gas` and `gas-prices`. The higher the `gas-prices`/`fees`, the higher the chance that your transaction will be included in a block. For mainnet, the recommended `gas-prices` is `2000000000000`. ### Sending Tokens Before you can bond PUNDIX and withdraw rewards, you need to [**set up `pundixd`**](#setting-up-pundixd) and [**create an account**](#creating-an-account) {% hint style="danger" %} **These commands need to run on an online computer. It is more secure to perform these commands using a Ledger device. For the offline procedure, click** [**here**](#signing-transactions-from-an-offline-computer)**.** {% endhint %} ```bash # send a certain amount of tokens to an address pundixd tx bank send ``` ### Bonding PUNDIX and Withdrawing Rewards {% hint style="info" %} Before you can bond PUNDIX and withdraw rewards, you need to [**set up `pundixd`**](#setting-up-pundixd) and [**create an account**](#creating-an-account) Before bonding PUNDIX, please read the [**delegator faq**](https://github.com/pundix/docs/blob/main/delegators/delegators-faq.md) to understand the risk and responsibilities involved with delegating. {% endhint %} {% hint style="danger" %} **These commands need to run on an online computer. It is more secure to perform them commands using a ledger device. For the offline procedure, click** [**here**](#signing-transactions-from-an-offline-computer)**.** {% endhint %} ```bash # bond a certain amount of PUNDIX to a given validator pundixd tx staking delegate --from # for example pundixd tx staking delegate pxvaloper1hs3tfedle32zzr5dh38gzzfn9ak2f4a96gg7h6 100 --from px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6 # redelegate a certain amount of PUNDIX from one validator to another # can only be used if already bonded to a validator # redelegation takes effect immediately, there is no waiting period to redelegate # after a redelegation, no other redelegation can be made from the account for the next 3 weeks pundixd tx staking redelegate # for example pundixd tx staking redelegate pxvaloper1hs3tfedle32zzr5dh38gzzfn9ak2f4a96gg7h6 pxvaloper1hs3tfedle32zzr5dh38gzzfn9ak2f4a96gg7h6 100 # withdraw all rewards pundixd tx distribution withdraw-all-rewards --from # for example pundixd tx distribution withdraw-all-rewards --from px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6 # unbond a certain amount of PUNDIX from a given validator # you will have to wait 3 weeks before your PUNDIX is fully unbonded and transferrable pundixd tx staking unbond --from # for example pundixd tx staking unbond pxvaloper1hs3tfedle32zzr5dh38gzzfn9ak2f4a96gg7h6 10 --from px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6 ``` However,there is a limit to how frequent you can redelegate. For more information on [redelegation](https://github.com/pundix/docs/blob/main/delegators/delegators-faq.md#redelegation). {% hint style="danger" %} **If you are using a Ledger, you will be asked to confirm the transaction on the device before it is signed and broadcast to the network. Note that the command will only work while the Ledger is plugged in and unlocked.** {% endhint %} To confirm that your transaction went through, you can use the following queries: ```bash # your balance should change after you bond PUNDIX or withdraw rewards pundixd query account # for example pundixd query account px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6 # you should have delegations after you bond PUNDIX pundixd query staking delegations # for example pundixd query staking delegations px1hs3tfedle32zzr5dh38gzzfn9ak2f4a9je4pf6 # this returns your tx if it has been included # use the tx hash that was displayed when you created the tx pundixd query tx # for example pundixd query tx 9728A0C9D0E50AB2B1BF3DDFAE2D1E002A35B8A0E0420B140C6C4F7F3DD787D8 ``` Double check with a block explorer if you interact with the network through a trusted full-node. ### Signing Transactions From an Offline Computer If you DO NOT have a ledger device and want to interact with your private key on an offline computer, you can use the following procedure. First, generate an unsigned transaction on an **online computer** with the following command (example with a bonding transaction): ```bash pundixd tx staking delegate --from \ --generate-only > unsignedTX.json # for example pundixd tx staking delegate pxvaloper1y582mey4tt7rj4e7j7tz6q6fq6lxn6wwhnjd20 10PUNDIX --from px1sqcamj53swry6hlu3zqd2dkmt3c0je6wwqwhku \ --generate-only > unsignedTX.json ``` In order to sign, you will also need the `chain-id`, `account-number` and `sequence`. The `chain-id` is a unique identifier for the blockchain on which you are submitting the transaction. The `account-number` is an identifier generated when your account first receives funds. The `sequence` number is used to keep track of the number of transactions you have sent and prevent replay attacks. Get the chain-id from the genesis file, and the two other fields using the account query: ```bash pundixd query account --chain-id payalebar # for example pundixd query account px1sqcamj53swry6hlu3zqd2dkmt3c0je6wwqwhku --chain-id payalebar ``` Then, copy `unsignedTx.json` and transfer it (for example via USB) to the offline computer. If it is not done already, create an account on the offline computer. For additional security, you can double check the parameters of your transaction before signing it using the following command: ```bash cat unsignedTx.json ``` Now, sign the transaction using the following command. You will need the `chain-id`, `sequence` and `account-number` obtained earlier: ```bash pundixd tx sign unsignedTx.json --from --offline --chain-id payalebar --sequence --account-number > signedTx.json # for example pundixd tx sign unsignedTx.json --from px1sqcamj53swry6hlu3zqd2dkmt3c0je6wwqwhku --offline --chain-id payalebar --sequence 0 --account-number 11 > signedTx.json ``` Copy `signedTx.json` and transfer it back to the online computer. Finally, use the following command to broadcast the transaction: ```bash pundixd tx broadcast signedTx.json ``` # PundiX CLI Guide ## pundixd `pundixd` is the tool that enables you to interact with the node that runs on the `pundixd`. In order to install it, follow the [installation procedure](/getting-started/installation-pundix). ### Setting Up pundixd The main command used to set up `pundixd` is the following: ```bash pundixd config [value] [flags] ``` This command will change parameters in `client.toml`. It also allows you to set a default value for each given flag. First, set up the address of the full-node you want to connect to: ```bash pundixd config : # for example pundixd config config.toml rpc.laddr https://px-json.pundix.com:26657 # if you run your own full-node, just use tcp://localhost:26657 as the address. pundixd config config.toml rpc.laddr tcp://localhost:26657 ``` Then, let us set the default value of the `--trust-node` flag: ```bash # set to true if you trust the full-node you are connecting to, false otherwise pundixd config config.toml trust-node true ``` Finally, let us set the `chain-id` of the blockchain we want to interact with: ```bash # interact with testnet pundixd config chain-id payalebar # interact with mainnet pundixd config chain-id pundix ``` ### Main Structure of pundixd Commands The `pundixd` help commands are nested. So, in terminal, `pundixd` will output docs for the top level commands (status, config, query, and tx). You can access documentation for sub commands with further help commands. The very first command to generate a list of available commands: ```bash pundixd ``` Return: ```bash PundiX Chain App Usage: pundixd [command] Available Commands: add-genesis-account Add a genesis account to genesis.json collect-gentxs Collect genesis txs and output a genesis.json file config Create or query an application CLI configuration file data modify data or query data in database debug Tool for helping with debugging your application export Export state to JSON gentx Generate a genesis tx carrying a self delegation help Help about any command init Initialize private validator, p2p, genesis, and application configuration files keys Manage your application\'s keys query Querying subcommands rollback rollback cosmos-sdk and tendermint state by one height rosetta spin up a rosetta server start Run the full node status Query remote node for status tendermint Tendermint subcommands tx Transactions subcommands validate-genesis validates the genesis file at the default location or at the location passed as an arg version Print the application binary version information Flags: -h, --help help for pundixd --home string directory for config and data (default "/Users/pundix006/.pundix") --log_filter strings The logging filter can discard custom log type (ABCIQuery) (default "") --log_format string The logging format (json|plain) (default "plain") --log_level string The logging level (trace|debug|info|warn|error|fatal|panic) (default "info") --trace print out full stack trace on errors Use "pundixd [command] --help" for more information about a command. ``` The return value will include: * a header which explains what the command is, for example `PundiX Chain App` * the usage for example `pundixd [command]` where you will need to input pundixd and a follow up command like `pundixd tx` * all available commands * and all flags which might be needed for commands We will be going through a common command along with the various sub commands and flags. Selecting the `tx` command: ```bash pundixd tx ``` Return: ```bash Transactions subcommands Usage: pundixd tx [flags] pundixd tx [command] Available Commands: authz Authorization transactions subcommands bank Bank transaction subcommands broadcast Broadcast transactions generated offline crisis Crisis transactions subcommands decode Decode a binary encoded transaction string distribution Distribution transactions subcommands encode Encode transactions generated offline erc20 ERC20 transaction subcommands ... Additional help topics: pundixd tx upgrade Upgrade transaction subcommands Use "pundixd tx [command] --help" for more information about a command. ``` You may either choose to insert a `flag` or a `command` after `pundixd tx`: ```bash pundixd tx --help ``` ### Example: tx gov If you have already start pundixd, you can use the `gov` command to interact with the governance module. ```bash pundixd tx gov ``` It will return: ```bash Governance transactions subcommands Usage: pundixd tx gov [flags] pundixd tx gov [command] Available Commands: deposit Deposit tokens for an active proposal submit-proposal Submit a proposal along with an initial deposit vote Vote for an active proposal, options: yes/no/no_with_veto/abstain ... Use "pundixd tx gov [command] --help" for more information about a command. ``` Continuing: ```bash pundixd tx gov submit-proposal ``` Return: ```bash Error: invalid message: can\'t proto marshal Usage: pundixd tx gov submit-proposal [flags] pundixd tx gov submit-proposal [command] Available Commands: cancel-software-upgrade Cancel the current software upgrade proposal community-pool-spend Submit a community pool spend proposal param-change Submit a parameter change proposal register-coin Submit a register coin proposal register-erc20 Submit a proposal to register an ERC20 token software-upgrade Submit a software upgrade proposal toggle-token-conversion Submit a toggle token conversion proposal update-denom-alias Submit a update denom alias proposal ... Use "pundixd tx gov submit-proposal [command] --help" for more information about a command. ``` Now if you use the `--help` flag: ```bash pundixd tx gov submit-proposal --help ``` Return: ```bash Submit a proposal along with an initial deposit. Proposal title, description, type and deposit can be given directly or through a proposal JSON file. ``` For example: ```bash pundixd tx gov submit-proposal --proposal="path/to/proposal.json" --from mykey ``` Where proposal.json contains: ```bash { "title": "Test Proposal", "description": "My awesome proposal", "type": "Text", "deposit": "10PUNDIX" } ``` Which is equivalent to: ```bash pundixd tx gov submit-proposal --title="Test Proposal" --description="My awesome proposal" --type="Text" --deposit="10PUNDIX" --from mykey Usage: pundixd tx gov submit-proposal [flags] pundixd tx gov submit-proposal [command] ... Use "pundixd tx gov submit-proposal [command] --help" for more information about a command. ``` ### Denom In general case, users can leave fees and gas price details as default values without input any flags. Otherwise, a transaction fee must be set! So do remember to add `--fees` and `--gas-prices` in your command. If you did not input the `--gas-prices` flag, you will be prompted to add it in your command since you changed all gas cost into fees. This will help people set all fees in one flag. For example transaction is `0.5PUNDIX` which after multiplying by `10^18` is `500000000000000000ibc/55367b7b6572631b78a93c66ef9fdfce87cde372cc4ed7848da78c1eb1dcdd78`. For the mainnet denom, we will use `PUNDIX` in general case. For the number, the `200000000000000000` means the result of multiplying the default value of `gas-prices` and `gas-limit`. The default value of `--gas-prices` is `2000000000000` and `gas-limit` is `100000`. `--gas-adjustment=1.2` means that there will be a 20% buffer added to the automatically assessed gas amount. Beseides, if users want to set gas price mannually, they need to care `gas-prices`, `gas-limit` and `gas-adjustment`. A more universal command is `--gas=auto`. `--gas=auto` automatically assesses the gas used for that transaction. This depends on the transaction itself and also the state of the blockchain. For more details on gas, kindly refer to the section on gas below. ```bash pundixd tx gov submit-proposal --title="gov proposal" --description="try to submit proposal" --type="Text" --deposit="200PUNDIX" --from=admin ``` Return: ```bash {"body":{"messages":[{"@type":"/cosmos.gov.v1beta1.MsgSubmitProposal","content":{"@type":"/cosmos.gov.v1beta1.TextProposal","title":"BLINDGOTCHI","description":"CLAUDIOXBARROS’s pet"},"initial_deposit":[{"denom":"PUNDIX","amount":"200"}],"proposer":"px124n6hpxkkn3r9j3tzwzhax2rd5s3crwq7p94fd"}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[{"denom":"PUNDIX","amount":"1.2"}],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]} confirm transaction before signing and broadcasting [y/N]: ``` After inputting `y`: ```bash {"height":"1632790","txhash":"C25C5A00D7EEEE5E3B7B0557320AE7F1D33992C8ADBFB2539C1F369F2B494725","codespace":"","code":0,"data":"0A160A0F7375626D69745F70726F706F73616C120308A001","raw_log":"[{\"events\":[{\"type\":\"message\",\"attributes\":[{\"key\":\"action\",\"value\":\"submit_proposal\"},{\"key\":\"sender\",\"value\":\"px124n6hpxkkn3r9j3tzwzhax2rd5s3crwq7p94fd\"},{\"key\":\"module\",\"value\":\"governance\"},{\"key\":\"sender\",\"value\":\"px124n6hpxkkn3r9j3tzwzhax2rd5s3crwq7p94fd\"}]},{\"type\":\"proposal_deposit\",\"attributes\":[{\"key\":\"amount\",\"value\":\"200PUNDIX\"},{\"key\":\"proposal_id\",\"value\":\"160\"}]},{\"type\":\"submit_proposal\",\"attributes\":[{\"key\":\"proposal_id\",\"value\":\"160\"},{\"key\":\"proposal_type\",\"value\":\"Text\"}]},{\"type\":\"transfer\",\"attributes\":[{\"key\":\"recipient\",\"value\":\"px10d07y265gmmuvt4z0w9aw880jnsr700jqjzsmz\"},{\"key\":\"sender\",\"value\":\"px124n6hpxkkn3r9j3tzwzhax2rd5s3crwq7p94fd\"},{\"key\":\"amount\",\"value\":\"200PUNDIX\"}]}]}]","logs":[{"msg_index":0,"log":"","events":[{"type":"message","attributes":[{"key":"action","value":"submit_proposal"},{"key":"sender","value":"px124n6hpxkkn3r9j3tzwzhax2rd5s3crwq7p94fd"},{"key":"module","value":"governance"},{"key":"sender","value":"px124n6hpxkkn3r9j3tzwzhax2rd5s3crwq7p94fd"}]},{"type":"proposal_deposit","attributes":[{"key":"amount","value":"200PUNDIX"},{"key":"proposal_id","value":"160"}]},{"type":"submit_proposal","attributes":[{"key":"proposal_id","value":"160"},{"key":"proposal_type","value":"Text"}]},{"type":"transfer","attributes":[{"key":"recipient","value":"px10d07y265gmmuvt4z0w9aw880jnsr700jqjzsmz"},{"key":"sender","value":"px124n6hpxkkn3r9j3tzwzhax2rd5s3crwq7p94fd"},{"key":"amount","value":"200PUNDIX"}]}]}],"info":"","gas_wanted":"200000","gas_used":"91282","tx":null,"timestamp":""} ``` ## Keys ### Key Types There are three types of key representations that are used: * `px`: * Derived from account keys generated by `pundixd keys add` * Used to receive funds * Addresses that only have a preceding `px` are wallet addresses * For example: `px15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc` * `pxvaloper`: * Used to associate a validator to it's operator * Used to invoke staking commands * Addresses preceding with `pxvaloper`are validator consensus address * For example: `pxvaloper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah` ### Generate Keys You'll need an account with a private and public key pair (a.k.a. `sk`,`pk` respectively) to be able to receive funds, send txs, bond tx, etc. To generate an old **secp256k1** key, follow this [guide](https://github.com/pundix/docs/blob/main/pundix-tutorials/account-migration-guide-cli.md#2-prepare-the-0x-prefix-address-account-ethereum-format-address). New **eth\_secp256k1** will be the default key generation scheme when PundiX becomes EVM compatible. To generate a new **eth\_secp256k1** key by default: ```bash pundixd keys add # for example pundixd keys add a1 ``` It returns some information about the key and the address it was generated for: ```bash {"name":"a1","type":"local","eip55_address":"0x8b0591eb1ada09124e87Aca7Fe79A4DAa037c7d7","address":"px13vzer6c6mgy3yn584jnlu7dym2sr037h9vjpt5","pubkey":"{\"@type\":\"/ethermint.crypto.v1.ethsecp256k1.PubKey\",\"key\":\"Az5CsJXBh/Jkid6VNLii7nn05MucDkLmxLY0mYQ+N6KP\"}","mnemonic":"abuse wasp life antenna render fury flip mention zero scorpion congress behave jacket resemble tail bean verify embark drive spread practice museum candy potato","algo":"eth_secp256k1"} ``` The output of the above command will contain a **mnemonic** like \`\`. It is recommended to save the **mnemonic** in a safe place so that in case you forget the password of the operating system's credentials store, you could eventually regenerate the key from the **mnemonic** with the following command: ```bash pundixd keys add --recover # for example pundixd keys add a1 --recover ``` It require to input `y`: ```bash override the existing name a1 [y/N]: y ``` The user need to input mnemonic: ```bash > Enter your bip39 mnemonic abuse wasp life antenna render fury flip mention zero scorpion congress behave jacket resemble tail bean verify embark drive spread practice museum candy potato ``` Then all the account information shows: ```bash {"name":"a1","type":"local","eip55_address":"0x8b0591eb1ada09124e87Aca7Fe79A4DAa037c7d7","address":"px13vzer6c6mgy3yn584jnlu7dym2sr037h9vjpt5","pubkey":"{\"@type\":\"/ethermint.crypto.v1.ethsecp256k1.PubKey\",\"key\":\"Az5CsJXBh/Jkid6VNLii7nn05MucDkLmxLY0mYQ+N6KP\"}","algo":"eth_secp256k1"} ``` If you check your private keys in any time, you'll now see ``: ```bash pundixd keys show # for example pundixd keys show a1 ``` Additionally and importantly, if you wish to have an added layer of protection on your keys, you may add the `--keyring-backend` flag and specify the file name. Setting your key up this way will ensure another layer of protection for signing any transactions. ```bash # \--keyring-backend string Select keyring's backend (os|file|test) (default "file") pundixd keys add \ --ledger \ --index \ --keyring-backend # for example pundixd keys add a4 \ --index 4 \ --keyring-backend file ``` you will be prompted for a keyring passphrase (password must be at least 8 characters) : ```bash Enter keyring passphrase: # for example # the input words will not show and the user need to reinput after first time Enter keyring passphrase: a1password Re-enter keyring passphrase: a1password {"name":"a4","type":"local","eip55_address":"0x020064394AA8Ee00b51d285D4BFE740c9DE047aE","address":"px1qgqxgw224rhqpdga9pw5hln5pjw7q3awj5zhek","pubkey":"{\"@type\":\"/ethermint.crypto.v1.ethsecp256k1.PubKey\",\"key\":\"Ai+/XyVxQQbwwpXQpukA3RYR51ts+IClxHhAPdRNoVWT\"}","mnemonic":"modify portion diamond suggest unhappy what differ youth empty suffer movie vivid jewel session visit friend autumn common ridge tennis plug voyage conduct wrap","algo":"eth_secp256k1"} ``` In the future, whenever you use this account to sign off on a transaction, you will have to add the `--keyring-backend ` flag and enter the keyring passphrase. {% hint style="info" %} Save a backup of your keyring passphrase in a secure place. Losing your keyring passphrase will result in the lost of all your funds created using the keyring passphrase❗ Also to access your keys in the keyring file DO NOT forget to add the `--keyring` flag. {% endhint %} View the validator operator's address via: ```bash pundixd keys show --bech=val # for example pundixd keys show a1 --bech=val ``` You can see all your available keys by typing: ```bash pundixd keys list ``` **Note that this return with account address is quite different with the validator operator's address.** View the validator pubkey for your node by typing: ```bash pundixd tendermint show-validator ``` {% hint style="danger" %} **This is the Tendermint signing key, NOT the operator key you will use in delegation transactions.** **Warning: We strongly recommend NOT using the same passphrase for multiple keys. The PundiX team will not be responsible for the loss of funds.** {% endhint %} ### Generate Multisig Public Keys You can generate and print a multisig public key by typing: ```bash # You need to generate multiple keys before, such as a1, a2 and a3. pundixd keys add --multisig=name1,name2,name3[...] --multisig-threshold=K new_key_name # for example # pundixd keys add a2 # pundixd keys add a3 pundixd keys add --multisig=a1,a2,a3 --multisig-threshold=2 bk ``` {% hint style="info" %} For multisig accounts, if you were to create any transaction, for example `--from=`. The `` needs to be the wallet address ie `px123l3kjltjwlfgjslfg....` not the account name. Only for those non-multisig accounts can you use the name of the account ie `--from=sheldoncooper`. {% endhint %} `K` is the minimum number of private keys that must have signed the transactions that carry the public key's address as signer. The `--multisig` flag must contain the name of public keys that will be combined into a public key that will be generated and stored as `new_key_name` in the local database. All names supplied through `--multisig` must already exist in the local database. Unless the flag `--nosort` is set, the order in which the keys are supplied on the command line does not matter, for example the following commands generate two identical keys: ```bash pundixd keys add --multisig=a1,a2,a3 --multisig-threshold=2 bk1 pundixd keys add --multisig=a3,a1,a2 --multisig-threshold=2 bk2 ``` Multisig addresses can also be generated on-the-fly and printed through the which command: ```bash # The default generated key name will be `multi` pundixd keys show --multisig-threshold K name1 name2 name3 [...] # for example pundixd keys show --multisig-threshold 2 a1 a2 a3 ``` The above command will generate a multisig address and print it to the console. But this time the order of the multisig names does matter. For example the command line with `a1 a2 a3` and `a2 a1 a3` will generate two different multisig addresses. With same `--multisig-threshold=2`, the `bk` key is the same as the order `a3 a1 a2` generated. For more information regarding how to generate, sign and broadcast transactions with a multi signature account see [Multisig Transactions](https://github.com/pundix/docs/blob/main/pundix-tutorials/pundixd-cli-commands.md#multisig-transactions). ### Migrate Keys From Legacy On-Disk Keybase To OS Built-in Secret Store Older versions of `pundixd` used store keys in the user's home directory. If you are migrating from an old version of `pundixd` you will need to migrate your old keys into your operating system's credentials storage by running the following command: ```bash pundixd keys migrate [flags] ``` The command will prompt for each passphrase. If a passphrase is incorrect, it will skip the respective key. The detail information of keys migration is [here](https://github.com/pundix/docs/blob/main/pundix-tutorials/account-migration-guide-cli.md) ## Fees & Gas Each transaction may either use the `--fees` or `--gas` flags, but not both. Validator's have a minimum gas price (multi-denom) configuration and they use this value when determining if they should include the transaction in a block during `CheckTx`, where `gasPrices >= minGasPrices`. Note, your transaction must use fees that are greater than or equal to **any** of the denominations the validator requires. **Note**: With such a mechanism in place, validators may start to prioritize txs by `gas-prices` in the mempool, so providing higher fees or gas prices may yield higher tx priority. ```bash # using the --fees flag must have an empty --gas-prices flag together pundixd tx bank send --fees="0.5PUNDIX" --gas-prices="" # for example, tx from admin to a2 adress with 0.5PUNDIX fees pundixd tx bank send admin px1ejstvlp4294h7ncnxgl8rqatsaj4kf2s4lj3y2 100PUNDIX --fees="0.5PUNDIX" --gas-prices="" # using the gas flag default value pundixd tx bank send # for example, tx from admin to a2 adress pundixd tx bank send admin px1ejstvlp4294h7ncnxgl8rqatsaj4kf2s4lj3y2 300PUNDIX ``` To query the gas price of your current node: ``` pundixd query gas-prices ``` {% hint style="info" %} You may want to cap the maximum gas that can be consumed by the transaction via the `--gas` flag. If you pass `--gas="auto"`, the gas supply will be automatically estimated before executing the transaction. Gas estimate might be inaccurate as state changes could occur in between the end of the simulation and the actual execution of a transaction, thus an adjustment is applied on top of the original estimate in order to ensure the transaction is broadcasted successfully. The adjustment can be controlled via the `--gas-adjustment` flag. The default value is `1.2`. {% endhint %} ## Account ### Get Testnet Tokens On a testnet, getting tokens is usually done via a faucet. You may refer to this [link](/pundix-tutorials/testnet-faucet). ### Query Account Balance After receiving tokens to your address, you can view your account's balance by typing: ```bash pundixd q bank balances # for example pundixd q bank balances px1kyn5tncnnpd8am28zqs3xhllkk5lx9wp4ce6ty ``` If the generated account has no tokens. It shows: ```bash {"balances":[],"pagination":{"next_key":null,"total":"0"}} ``` If the account had no transaction history, the address will not be detected on the chain. ```bash pundixd query auth account px1hfwtzv5twhulwhcf9aa4y3kr6hmhfu866zjjfa ``` It shows: ```bash Error: rpc error: code = NotFound desc = rpc error: code = NotFound desc = account px1hfwtzv5twhulwhcf9aa4y3kr6hmhfu866zjjfa not found: key not found Usage: pundixd query auth account [address] [flags] ... ``` {% hint style="info" %} This can also happen if you fund the account before your node has fully synced with the chain. These are both normal. {% endhint %} ### Send Tokens The following command could be used to send coins from one account to another: ```bash pundixd tx bank send ``` {% hint style="info" %} The `amount` argument accepts the format ``, for example `10PUNDIX` which is equivalent to `10000000000000000000ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78`. {% endhint %} Now, view the updated balances of the origin and destination accounts: ```bash pundixd query account pundixd query account ``` You can also check your balance at a given block by using the `--height` flag: ```bash pundixd query account --height # for example pundixd query account px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 --height 10 ``` Furthermore, you can build a transaction and print its JSON format to STDOUT by appending `--generate-only` to the list of the command line arguments. Running the following command will store build the transaction and store it in a file named "unsignedSendTx.json": ```bash pundixd tx bank send 10PUNDIX \ --chain-id= \ --sequence= \ --generate-only > unsignedSendTx.json # for example # the user has to check account "sequence" first # pundixd query account px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 pundixd tx bank send px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 px1ejstvlp4294h7ncnxgl8rqatsaj4kf2s4lj3y2 10PUNDIX --generate-only --sequence=12 > unsignedSendTx.json pundixd tx sign \ --chain-id= \ --from= \ unsignedSendTx.json > signedSendTx.json # for example pundixd tx sign unsignedSendTx.json --chain-id=PUNDIX --from=admin > signedSendTx.json ``` {% hint style="info" %} The `--generate-only` flag prevents `pundixd` from accessing the local keybase. Thus when such flag is supplied `` must be an address. {% endhint %} You can broadcast the signed transaction to a node by providing the JSON file to the following command: ```bash pundixd tx broadcast # for example pundixd tx broadcast signedSendTx.json ``` ### Tx Broadcasting When broadcasting transactions, `pundixd` accepts a `--broadcast-mode` flag. This flag can have a value of `sync` (default), `async`, or `block`, where `sync` makes the client return a `CheckTx` response, `async` makes the client return immediately, and `block` makes the client wait for the tx to be committed (or timing out). It is important to note that the `block` mode should **NOT** be used in most circumstances. This is because broadcasting can timeout but the tx may still be included in a block. This can result in many undesirable situations. Therefore, it is best to use `sync` or `async` and query by tx hash to determine when the tx is included in a block. ## Query Transactions ### Matching a Set of Events You can use the transaction search command to query for transactions that match a specific set of `events`, which are added on every transaction. Each event is composed by a key-value pair in the form of `{eventType}.{eventAttribute}={value}`. Events can also be combined to query for a more specific result using the `&` symbol. You can query transactions by `events` as follows: ```bash pundixd query txs --events='message.sender=px1...' # for example pundixd query txs --events='message.sender=px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30' ``` And for using multiple `events`: ```bash pundixd query txs --events='message.sender=px1...&message.action=/cosmos.bank.v1beta1.MsgSend' # for example pundixd query txs --events='message.sender=px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30&message.action=/cosmos.bank.v1beta1.MsgSend' ``` The pagination is supported as well via `page` and `limit`: ```bash pundixd query txs --events='message.sender=px1...' --page=1 --limit=20 # for example pundixd query txs --events='message.sender=px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30' --page=1 --limit=20 ``` The action tag always equals the message type returned by the `Type()` function of the relevant message. {% hint style="info" %} You can find a list of available `events` on each of the SDK modules: * [Staking events](https://github.com/cosmos/cosmos-sdk/blob/master/x/staking/spec/07_events.md) * [Governance events](https://github.com/cosmos/cosmos-sdk/blob/master/x/gov/spec/04_events.md) * [Slashing events](https://github.com/cosmos/cosmos-sdk/blob/master/x/slashing/spec/06_events.md) * [Distribution events](https://github.com/cosmos/cosmos-sdk/blob/master/x/distribution/spec/06_events.md) * [Bank events](https://github.com/cosmos/cosmos-sdk/blob/master/x/bank/spec/04_events.md) {% endhint %} ### Matching a Transaction's Hash You can also query a single transaction by its hash using the following command: ```bash pundixd query tx [hash] ``` {% hint style="info" %} tx hash on the block explorer are preceded with `0x`. Please omit the `0x` from the tx hash {% endhint %} ## Staking ### Set up a Validator Please refer to the [Validator Setup](https://github.com/pundix/docs/blob/main/validators/setting-up-a-validator-for-pundix.md) section for a more complete guide on how to set up a validator. ### Delegate to a Validator On the upcoming mainnet, you can delegate `PUNDIX` to a validator. These [delegators](https://github.com/pundix/docs/blob/main/delegators/delegators-faq.md) can receive part of the validator's fee revenue. Read more about the [incentives](https://github.com/pundix/docs/blob/main/delegators/delegators-faq.md#revenue). #### Query Validators You can query the list of all validators of a specific chain: ```bash pundixd query staking validators ``` If you want to get the information of a single validator you can check it with: ```bash pundixd query staking validator # for example pundixd query staking validator pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc ``` ### Bond Tokens On the PundiX mainnet, we delegate `PUNDIX`. Here's how you can bond tokens to a testnet validator (for example, delegate): ```bash pundixd tx staking delegate \ \ \ --from= \ # for example pundixd tx staking delegate pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc 101PUNDIX --from=admin ``` `` is the operator address of the validator to which you intend to delegate. If you are running a local testnet, you can find this with: ```bash pundixd keys show --bech val ``` Where `` is the name of the key you specified when you initialized `pundixd`. While tokens are bonded, they are pooled with all the other bonded tokens in the network. Validators and delegators obtain a percentage of shares that equal their stake in this pool. #### Query Delegations {% hint style="info" %} In this section and the next, do make sure you check if the command has a plural form or not. Adding an (s) behind delegation to delegations results in a different command. {% endhint %} Once submitted a delegation to a validator, you can see it's information by using the following command: ```bash pundixd query staking delegation # for example pundixd query staking delegation px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc ``` Or if you want to check all your current delegations with disctinct validators: ```bash pundixd query staking delegations # for example pundixd query staking delegations px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 ``` You can also query all of the delegations to a particular validator: ```bash pundixd query staking delegations-to # for example pundixd query staking delegations-to pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc ``` ### Unbond Tokens If for any reason the validator misbehaves, or you just want to unbond a certain amount of tokens, use this following command. ```bash pundixd tx staking unbond \ \ 10PUNDIX \ --from= \ # for example pundixd tx staking unbond pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc 10PUNDIX --from=admin ``` The unbonding will be automatically completed when the unbonding period has passed. #### Query Unbonding-Delegations Once you begin an unbonding-delegation, you can see it's information by using the following command: ```bash pundixd query staking unbonding-delegation # for example pundixd query staking unbonding-delegation px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc ``` If you want to check all your current unbonding-delegations with disctinct validators: ```bash pundixd query staking unbonding-delegations # for example pundixd query staking unbonding-delegations px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 ``` Additionally, as you can get all the unbonding-delegations from a particular validator: ```bash pundixd query staking unbonding-delegations-from # for example pundixd query staking unbonding-delegations-from pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc ``` ### Redelegate Tokens A redelegation is a type delegation that allows you to bond illiquid tokens from one validator to another: ```bash pundixd tx staking redelegate \ \ \ 10PUNDIX \ --from= # for example pundixd tx staking redelegate pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc pxvaloper1ejstvlp4294h7ncnxgl8rqatsaj4kf2svn8vda 10PUNDIX --from=admin ``` Here you can also redelegate a specific `shares-amount` or a `shares-fraction` with the corresponding flags. The redelegation will be automatically completed when the unbonding period has passed. #### Query Redelegations Once you begin a redelegation, you can see it's information by using the following command: ```bash pundixd query staking redelegation # for example pundixd query staking redelegation px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc pxvaloper1ejstvlp4294h7ncnxgl8rqatsaj4kf2svn8vda ``` It returns: ```bash {"redelegation_responses":[{"redelegation":{"delegator_address":"px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30","validator_src_address":"pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc","validator_dst_address":"pxvaloper1ejstvlp4294h7ncnxgl8rqatsaj4kf2svn8vda","entries":null},"entries":[{"redelegation_entry":{"creation_height":14019,"completion_time":"2022-09-16T09:41:58.105545Z","initial_balance":"10000000000000000000","shares_dst":"10000000000000000000.000000000000000000"},"balance":"10000000000000000000"}]}],"pagination":null} ``` If you want to check all your current unbonding-delegations with distinct validators: ```bash pundixd query staking redelegations # for example pundixd query staking redelegations px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 ``` It returns: ```bash {"redelegation_responses":[{"redelegation":{"delegator_address":"px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30","validator_src_address":"pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc","validator_dst_address":"pxvaloper1ejstvlp4294h7ncnxgl8rqatsaj4kf2svn8vda","entries":null},"entries":[{"redelegation_entry":{"creation_height":14019,"completion_time":"2022-09-16T09:41:58.105545Z","initial_balance":"10000000000000000000","shares_dst":"10000000000000000000.000000000000000000"},"balance":"10000000000000000000"}]}],"pagination":{"next_key":null,"total":"0"}} ``` Additionally, as you can get all the outgoing redelegations from a particular validator: ```bash pundixd query staking redelegations-from # for example pundixd query staking redelegations-from pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc ``` It returns: ```bash {"redelegation_responses":[{"redelegation":{"delegator_address":"px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30","validator_src_address":"pxvaloper1vhe2w8f9ne8yakhk75usjv2m8txkulagnr7kcc","validator_dst_address":"pxvaloper1ejstvlp4294h7ncnxgl8rqatsaj4kf2svn8vda","entries":null},"entries":[{"redelegation_entry":{"creation_height":14019,"completion_time":"2022-09-16T09:41:58.105545Z","initial_balance":"10000000000000000000","shares_dst":"10000000000000000000.000000000000000000"},"balance":"10000000000000000000"}]}],"pagination":{"next_key":null,"total":"0"}} ``` {% hint style="info" %} However, there is a limit to how frequent you can redelegate. For more information on [redelegation](https://github.com/pundix/docs/blob/main/delegators/delegators-faq.md#redelegation). {% endhint %} #### Query Parameters Parameters define high level settings for staking. You can get the current values by using: ```bash pundixd query staking params ``` It returns: ```bash {"unbonding_time":"1814400s","max_validators":20,"max_entries":7,"historical_entries":20000,"bond_denom":"ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78"} ``` With the above command you will get the values for: * Unbonding time * Maximum numbers of validators * Coin denomination for staking All these values will be subject to updates through a `governance` process by `ParameterChange` proposals. #### Query Pool A staking `Pool` defines the dynamic parameters of the current state. You can query them with the following command: ```bash pundixd query staking pool ``` With the `pool` command you will get the values for: * Bonded tokens * Not-bonded tokens ## Slashing ### Unjailing To unjail your jailed validator: ```bash pundixd tx slashing unjail --from # for example pundixd tx slashing unjail --from px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 ``` ### Signing Info To retrieve a validator's signing info: ```bash pundixd query slashing signing-info # for example pundixd query slashing signing-info c9K95ze0trEtE1KCZ1smjhJQdVqEB8+7Ma6ht64bhDg= ``` #### Query Parameters You can get the current slashing parameters via: ```bash pundixd query slashing params ``` ### Minting You can query for the minting/inflation parameters via: ```bash pundixd query mint params ``` It returns: ```bash {"mint_denom":"bsc0x29a63f4b209c29b4dc47f06ffa896f32667dad2c","inflation_rate_change":"1.000000000000000000","inflation_max":"40.000000000000000000","inflation_min":"20.000000000000000000","goal_bonded":"0.510000000000000000","blocks_per_year":"6311520"} ``` To query for the current inflation value: ```bash pundixd query mint inflation ``` It returns: ```bash 30.000108522380736972 ``` To query for the current annual provisions value: ```bash pundixd query mint annual-provisions ``` It returns: ```bash 30000110305612345326000.000000000000000000 ``` ### Checking Block Information and Validators Signatures The following command will query for a transaction by hash in a committed block: ```bash pundixd query block-results ``` The following command will get verified data for a the block at given height: ```bash pundixd query block ``` {% hint style="info" %} Using these commands and filtering out the necessary information, you will be able to deduce the uptime of other validators by checking if they missed any signatures for that block. {% endhint %} A sample query to check for any missing validator signature given a particular block height: ```bash pundixd query block 644696 --node https://testnet-px-json.pundix.com:26657 | jq '.block.last_commit' ``` ## Governance Governance is the process from which users in the PundiX can come to consensus on software upgrades, parameters of the mainnet or signaling mechanisms through text proposals. This is done through voting on proposals, which will be submitted by `PUNDIX` holders on the mainnet. Some considerations about the voting process: * Voting is done by bonded `PUNDIX` holders on a 100 bonded `PUNDIX` 1 vote basis * Delegators **who DO NOT** vote will inherit the vote of their validator * Votes are tallied at the end of the voting period (2 weeks on mainnet). Addresses can vote multiple times before the end of the voting period to update their `Option` value (incurring transaction fees each time), only the most recently casted vote will count as valid * Voters can choose between options `Yes`, `No`, `NoWithVeto` and `Abstain` * By the end of the voting period, a proposal is accepted if: * `(YesVotes / (YesVotes+NoVotes+NoWithVetoVotes)) > 1/2` * `(NoWithVetoVotes / (YesVotes+NoVotes+NoWithVetoVotes)) < 1/3` * `((YesVotes+NoVotes+NoWithVetoVotes) / totalBondedStake) >= quorum` For more information about the governance process and how it works, please check out the Governance module [specification](https://github.com/cosmos/cosmos-sdk/tree/master/x/gov/spec). {% hint style="info" %} The minimum deposit for a governance proposal is `10,000PUNDIX` (through the command line, this amounts to `10000000000000000000000ibc/55367b7b6572631b78a93c66ef9fdfce87cde372cc4ed7848da78c1eb1dcdd78` after multiplying by `10^18`). Since the ibc token denom is too long, we will only use `PUNDIX` in general case. {% endhint %} ### Create a Governance Proposal In order to create a governance proposal, you must submit an initial deposit along with a title and description. Various modules outside of governance may implement their own proposal types and handlers (for example parameter changes), where the governance module itself supports `Text` proposals. Any module outside of governance has it's command mounted on top of `submit-proposal`. To submit a `Text` proposal (the title and description fields will be string input so enclose the input in `""`): ```bash pundixd tx gov submit-proposal \ --title= \ --description=<description> \ --type="Text" \ --deposit="100PUNDIX" \ --from=<name> \ # for example pundixd tx gov submit-proposal \ --title="Test Proposal" \ --description="This is a test proposal" \ --type="Text" \ --deposit="100PUNDIX" \ --from=admin ``` You may also provide the proposal directly through the `--proposal` flag which points to a JSON file containing the proposal. Create `proposal.json` which contains the following: ```json { "title": "Param JSON", "description": "Update max validators", "changes": [ { "subspace": "staking", "key": "MaxValidators", "value": 105 } ], "deposit": [ { "denom": "stake", "amount": "10" } ] } ``` To submit a parameter change proposal, you must provide a proposal file as its contents are less friendly to CLI input: ```bash pundixd tx gov submit-proposal param-change <path/to/proposal.json> \ --from=<name> # for example pundixd tx gov submit-proposal param-change ./proposal.json \ --from=admin ``` {% hint style="info" %} Currently parameter changes are *evaluated* but not *validated*, so it is very important that any `value` change is valid (for example correct type and within bounds) for its respective parameter, for example `MaxValidators` should be an integer and not a decimal. Proper vetting of a parameter change proposal should prevent this from happening (no deposits should occur during the governance process), but it should be noted regardless. {% endhint %} The `SoftwareUpgrade` command is currently not supported as it's not implemented and currently does not differ from the semantics of a `Text` proposal. #### Query Proposals Once created, you can now query information of the proposal: ```bash pundixd query gov proposal <proposal_id> # for example pundixd query gov proposal 1 ``` It returns: ```bash {"proposal_id":"1","content":{"@type":"/cosmos.gov.v1beta1.TextProposal","title":"Test Proposal","description":"This is a test proposal"},"status":"PROPOSAL_STATUS_DEPOSIT_PERIOD","final_tally_result":{"yes":"0","abstain":"0","no":"0","no_with_veto":"0"},"submit_time":"2022-08-26T10:31:21.557584Z","deposit_end_time":"2022-09-09T10:31:21.557584Z","total_deposit":[{"denom":"ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78","amount":"100000000000000000000"}],"voting_start_time":"0001-01-01T00:00:00Z","voting_end_time":"0001-01-01T00:00:00Z"} ``` Or query all available proposals: ```bash pundixd query gov proposals <proposal_id> ``` You can also query proposals filtered by `voter` or `depositor` by using the corresponding flags. To query for the proposer of a given governance proposal: ```bash pundixd query gov proposer <proposal_id> # for example pundixd query gov proposer 1 ``` It returns: ```bash {"proposal_id":"1","proposer":"px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30"} ``` ### Increase Deposit In order for a proposal to be broadcasted to the network, the amount deposited must be above a `minDeposit` value (initial value: `10000PUNDIX`). If the proposal you previously created didn't meet this requirement, you can still increase the total amount deposited to activate it. Once the minimum deposit is reached, the proposal enters voting period: ```bash pundixd tx gov deposit <proposal_id> "10000PUNDIX" \ --from=<name> # for example pundixd tx gov deposit 1 "1PUNDIX" \ --from=admin ``` {% hint style="info" %} Proposals that don't meet this requirement will be deleted after `MaxDepositPeriod` is reached. {% endhint %} #### Query Deposits Once a new proposal is created, you can query all the deposits submitted to it: ```bash pundixd query gov deposits <proposal_id> # for example pundixd query gov deposits 1 ``` It returns: ```bash {"deposits":[{"proposal_id":"1","depositor":"px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30","amount":[{"denom":"ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78","amount":"100000000000000000000"}]}],"pagination":{"next_key":null,"total":"0"}} ``` You can also query a deposit submitted by a specific address: ```bash pundixd query gov deposit <proposal_id> <depositor_address> # for example pundixd query gov deposit 1 px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30 ``` It returns: ```bash {"proposal_id":"1","depositor":"px1vhe2w8f9ne8yakhk75usjv2m8txkulag20tt30","amount":[{"denom":"ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78","amount":"100000000000000000000"}]} ``` ### Vote on a Proposal After a proposal's deposit reaches the `MinDeposit` value, the voting period opens. Bonded `PUNDIX` holders can then cast vote on it: ```bash pundixd tx gov vote <proposal_id> <Yes/No/NoWithVeto/Abstain> \ --from=<name> # for example pundixd tx gov vote 1 Yes \ --from=admin ``` #### Query Votes Check the vote with the option you just submitted: ```bash pundixd query gov vote <proposal_id> <voter_address> ``` You can also get all the previous votes submitted to the proposal with: ```bash pundixd query gov votes <proposal_id> ``` #### Query proposal tally results To check the current tally of a given proposal you can use the `tally` command: ```bash pundixd query gov tally <proposal_id> ``` #### Query Governance Parameters To check the current governance parameters run: ```bash pundixd query gov params ``` To query subsets of the governance parameters run: ```bash pundixd query gov param voting pundixd query gov param tallying pundixd query gov param deposit ``` ### Fee Distribution #### Query Distribution Parameters To check the current distribution parameters, run: ```bash pundixd query distribution params ``` #### Query Distribution Ecosystem Genesis Fund To query all coins in the Ecosystem Genesis Fund which is under Governance control: ```bash pundixd query distribution community-pool ``` #### Query Outstanding Rewards To check the current total outstanding (un-withdrawn) rewards of a particular validator (validator's + delegators' rewards), run: ```bash pundixd query distribution validator-outstanding-rewards <validator-addr> ``` #### Query Validator Commission To check the current outstanding commission for a validator (excluding the rewards of the wallet tied to that validator address), run: ```bash pundixd query distribution commission <validator_address> ``` #### Query Validator Slashes To check historical slashes for a validator, run: ```bash pundixd query distribution slashes <validator_address> <start_height> <end_height> ``` #### Query Delegator Rewards To check current rewards for a delegation (were they to be withdrawn), run: ```bash pundixd query distribution rewards <delegator_address> <validator_address> ``` #### Query All Delegator Rewards To check all current rewards for a delegation (were they to be withdrawn), run: ```bash pundixd query distribution rewards <delegator_address> ``` ## Claiming Rewards ### Claiming rewards for delegators and validators Withdraw rewards from a given delegation address, and optionally withdraw validator commission (by adding in a `--commission` flag, see below) if the delegation address given is a validator operator: ``` pundixd tx distribution withdraw-rewards <validator-addr> --from <_name> ``` Withdraw the validator's commission in addition to the rewards: ``` pundixd tx distribution withdraw-rewards <validator-addr> --from mykey --commission ``` ### Multisig Transactions Multisig transactions require signatures of multiple private keys. Thus, generating and signing a transaction from a multisig account involve cooperation among the parties involved. A multisig transaction can be initiated by any of the key holders, and at least one of them would need to import other parties' public keys into their Keybase and generate a multisig public key in order to finalize and broadcast the transaction. For example, given a multisig key comprising the keys `p1`, `p2`, and `p3`, each of which is held by a distinct party, the user holding `p1` would require to import both `p2` and `p3` in order to generate the multisig account public key: ```bash pundixd keys add \ --multisig=p1,p2,p3... \ --multisig-threshold=2 \ new_key_name ``` A new multisig public key `bk` has been stored, and its address will be used as signer of multisig transactions: ```bash pundixd keys show --address bk ``` You may also view multisig threshold, pubkey constituents and respective weights by viewing the JSON output of the key or passing the `--show-multisig` flag: ```bash pundixd keys show bk -o json pundixd keys show bk --show-multisig ``` The first step to create a multisig transaction is to initiate it on behalf of the multisig address created above: {% hint style="info" %} For multisig accounts, if you were to create any transaction, for example `--from=<multisig_account>` your `<multisig_account>` needs to be the wallet address ie `px123l3kjltjwlfgjslfg....`. Only for those non-multisig accounts can you use the name of the account ie `--from=heimendinger`. {% endhint %} ```bash pundixd tx bank send px1570v2fq3twt0f0x02vhxpuzc9jc4yl30q2qned px12u8ekfqdd75r4apyqv2xst6qw0n3wvr2asncf5 1PUNDIX \ --generate-only > unsignedTx.json ``` The file `unsignedTx.json` contains the unsigned transaction encoded in JSON. `p1` can now sign the transaction with its own private key: ```bash pundixd tx sign \ unsignedTx.json \ --multisig=<multisig_address> \ --from=p1 \ --output-document=p1signature.json \ --chain-id=payalebar ``` Once the signature is generated, `p1` transmits both `unsignedTx.json` and `p1signature.json` to `p2` or `p3`, which in turn will generate their respective signature: ```bash pundixd tx sign \ unsignedTx.json \ --multisig=<multisig_address> \ --from=p2 \ --output-document=p2signature.json \ --chain-id=payalebar ``` {% hint style="info" %} The Mainnet ChainID should be **pundix** {% endhint %} `bk` is a 2-of-3 multisig key, therefore one additional signature is sufficient. Any the key holders can now generate the multisig transaction by combining the required signature files: ```bash pundixd tx multisign \ unsignedTx.json \ bk \ p1signature.json p2signature.json > signedTx.json ``` The transaction can now be sent to the node: ```bash pundixd tx broadcast signedTx.json ``` ### Shells Completion Scripts Completion scripts for popular UNIX shell interpreters such as `Bash` and `Zsh` can be generated through the `completion` command, which is available for both `pundixd` and `pundixd`. If you want to generate `Bash` completion scripts run the following command: ```bash pundixd completion > pundixd_completion pundixd completion > pundixcli_completion ``` If you want to generate `Zsh` completion scripts run the following command: ```bash pundixd completion --zsh > pundixd_completion pundixd completion --zsh > pundixcli_completion ``` {% hint style="info" %} On most UNIX systems, such scripts may be loaded in `.bashrc` or `.bash_profile` to enable Bash autocompletion: {% endhint %} ```bash echo '. pundixd_completion' >> ~/.bashrc echo '. pundixcli_completion' >> ~/.bashrc ``` {% hint style="info" %} Refer to the user's manual of your interpreter provided by your operating system for information on how to enable shell autocompletion. {% endhint %} # Ledger Integration for pundixd {% hint style="info" %} <mark style="color:blue;">**DISCLAIMER**</mark> Currently, the cosmos app on Ledger only supports the path **m/44/118**. By default, the `pundixd keys add` command is defaulted to `--algo=eth_secp256k1 --coin-type=60` which is compatible with Ethereum accounts. If you want to use ledger to add a cosmos account, you must specify the flag `--algo=secp256k1 --coin-type=118`. Without this flag, running the following command will return the following error: `pundixd keys add mywallet --ledger --index 102 --keyring-backend file` `Error: failed to generate ledger key: failed to recover pubkey: [APDU_CODE_DATA_INVALID] Referenced data reversibly blocked (invalidated): address rejected for path m/44'/60'/0'/0/102` {% endhint %} Using a hardware wallet to store your keys greatly improves the security of your crypto assets. The Ledger device acts as an enclave of the seed and private keys, and the process of signing transaction takes place within it. No private information ever leaves the Ledger device. The following is a short tutorial on using the Cosmos Ledger app with the PundiX CLI. At the core of a Ledger device there is a mnemonic seed phrase that is used to generate private keys. This phrase is generated when you initialize your Ledger. The mnemonic is compatible with Cosmos and can be used to seed new accounts. {% hint style="danger" %} **DO NOT lose or share your 24 words with anyone. To prevent theft or loss of funds, it is best to keep multiple copies of your mnemonic stored in safe, secure places. If someone is able to gain access to your mnemonic, they will fully control the accounts associated with them.** {% endhint %} ## Ledger and Cloud Setup ![Ledger and Cloud Configuration](/files/wJgiC9TOAlwAp7QKVjKZ) Before you use a ledger to set up your validator, do make sure you understand this setup. You will need: 1. Your ledger which has the Cosmos app installed. 2. PundiX CLI installed on your local machine but this does not have to be a full-node or validator-node if you are remoting into a cloud server. Because your ledger is connected to your local machine, you will need PundiX CLI installed locally and we will be using this to send commands to the cloud server. 3. Your cloud server to be a full-node/validator node. 4. To run the [ssh port forwarding command](https://github.com/pundix/docs/blob/main/pundix-tutorials/cloud-setup.md#connecting-your-localhost-to-the-cloud-instance-ssh-port-forwarding) 5. Two terminals opened, first one run the ssh port forwarding command. 6. The other one with pundixd opened locally and we will be using this terminal to run our commands. ## Install the Cosmos Ledger application Installing the `Cosmos` application on your ledger device is required before you can use it with our PundiX CLI. To do so, you need to: ### Before you start * Install [Ledger Live](https://shop.ledger.com/pages/ledger-live) on your machine. * Using Ledger Live, [update your Ledger Nano S with the latest firmware](https://support.ledger.com/hc/en-us/articles/360002731113-Update-device-firmware)/[Ledger Nano X](https://support.ledger.com/hc/en-us/articles/360018784134-Set-up-your-Ledger-Nano-X?docs=true). ### Install the Cosmos (PUNDIX) app on your Ledger device 1. Open **Ledger Live** and navigate to the **Manager** tab. 2. Connect and unlock your Ledger **device**. 3. If asked, allow the manager on your device. 4. Search for the **Cosmos (PUNDIX)** app in the app catalog. 5. Click the **Install** button to install the app on your Ledger device. * Your Ledger device displays **Processing.** * Ledger Live displays **Installed.** 6. More information on how to set up your Ledger device can be found [here](https://support.ledger.com/hc/en-us/articles/360013713840-Cosmos-PUNDIX-?docs=true). {% hint style="info" %} To see the `Cosmos` application when you search for it, you might need to activate the `Developer Mode`, located in the Experimental features tab of the Ledger Live application. {% endhint %} ## PundiX CLI + Ledger Nano **You need to** [**install the Cosmos app**](#install-the-cosmos-ledger-application) **on your Ledger Nano before moving on to this section** The tool used to generate addresses and transactions on the PundiX network is `pundixd`. You will be using pundixd CLI commands for creating transactions and then using your Ledger to sign off before broadcasting the transaction to a specified node using the pundixd CLI. ### Install PundiX {% hint style="info" %} **You need to** [**install PundiX**](/getting-started/installation-pundix) **before you proceed further** {% endhint %} ### Add Ledger key * Connect and unlock your Ledger device. * Open the Cosmos app on your Ledger. * Create an account in pundixd from your ledger key. Be sure to change the `_name` parameter to be a meaningful name. The `--ledger` flag tells `pundixd` to use your Ledger to seed the account. ```bash pundixd keys add <_name> --ledger --algo=secp256k1 --coin-type=118 # for example pundixd keys add a1 --ledger --algo=secp256k1 --coin-type=118 ``` Check the ledger and approve the address. Then, in terminal it returns: ```bash {"name":"a1","type":"ledger","eip55_address":"0xA1D1b968B20A60366731EA94FEA6502D141AeF56","address":"px158gmj69jpfsrvee3a220afjs952p4m6kvm4axj","pubkey":"{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"Auy/TgKCF/HJAkHnDaYv2DkKQNDhCwk1ZcMmf0HzOLaD\"}","algo":"eth_secp256k1"} ``` Cosmos uses [HD Wallets](https://www.ledger.com/academy/crypto/what-are-hierarchical-deterministic-hd-wallets). This means you can setup multiple accounts using the same Ledger seed. To create another account from your Ledger device, run the following, (changing the integer \<i> to some value >= 0 to choose the account for HD derivation): ```bash pundixd keys add <secondKeyName> --ledger --algo=secp256k1 --coin-type=118 --index <i> # for example pundixd keys add a2 --ledger --algo=secp256k1 --coin-type=118 --index 2 ``` Check the ledger and approve the address. Then, in terminal it returns: ```bash {"name":"a2","type":"ledger","eip55_address":"0x66a92b3d0c101a8BE31fFb72679F0D6E2276f79A","address":"px1v65jk0gvzqdghcclldex08cddc38dau63mfk23","pubkey":"{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"A27tmBBfshR4B0LaTKfwXy4fFfLfWeQIxPVq3I+KyewU\"}","algo":"eth_secp256k1"} ``` Additionally and importantly, if you wish to have an added layer of protection on your keys, you may add the `--keyring-backend` flag and specify the file name. Setting your key up this way will ensure another layer of protection for signing any transactions. ```bash # \--keyring-backend string Select keyring's backend (os|file|test) (default "test") pundixd keys add <NewKeyName> \ --ledger \ --index <i> \ --keyring-backend <backend> # for example: pundixd keys add a3 \ --ledger \ --index 3 \ --coin-type 118 \ --keyring-backend file ``` You will be prompted for a keyring passphrase (password must be at least 8 characters) : ```bash Enter keyring passphrase: Re-enter keyring passphrase: {"name":"a3","type":"ledger","eip55_address":"0x5ebC323260dCF8DA222C0ef167bFF1e6f3F7585e","address":"px1t67ryvnqmnud5g3vpmck00l3umelwkz7yv6gg5","pubkey":"{\"@type\":\"/cosmos.crypto.secp256k1.PubKey\",\"key\":\"AtGq1hsem5bGINWNiHsmvQybMfCMMb2XqWBgLqY/mLr2\"}","algo":"eth_secp256k1"} ``` In the future, whenever you use this account to sign off on a transaction, you will have to add the `--keyring-backend <file_name>` flag and enter the keyring passphrase. {% hint style="info" %} Save a backup of your keyring passphrase in a secure place. Losing your keyring passphrase will result in the lost of all your funds created using the keyring passphrase❗ Also to access your keys in the keyring file DO NOT forget to add the --keyring flag {% endhint %} ### Confirm your address Run this command to display your address on your Ledger device. Use the `_name` you gave your ledger key. The `-d` flag is supported in version `1.5.0` and higher. ```bash pundixd keys show <_name> -d # for example pundixd keys show a1 -d ``` Confirm that the address displayed on the device matches the address displayed on the terminal. ### Connect to a full node Next, you need to configure pundixd with the URL of a PundiX full node and the appropriate `chain_id`. In this example we connect to the public load balanced full node operated by Function X on the `payalebar` chain. But you can point your `pundixd` to any `PundiX` full node. Be sure that the `chain-id` is set to the same chain as the full node. ```bash # configuring to a full node pundixd config <config file name> <host>:<port> # for example pundixd config config.toml rpc.laddr https://127.0.0.1:26657 # configuring the chain-id pundixd config chain-id <value> # for example pundixd config chain-id payalebar ``` Test your connection with a query such as: ```bash pundixd query staking validators ``` **To run your own full node locally read more** [**here**](/getting-started/setup-node)**.** ### Sign a transaction You are now ready to start signing and sending transactions. Send a transaction with pundixd using the `tx bank send` command. ```bash # show all available options pundixd tx bank send --help ``` {% hint style="info" %} Be sure to unlock your device with the PIN and open the Cosmos app before trying to run these commands Use the `_name` you set for your Ledger key and PundiX will connect with the Cosmos Ledger app to then sign your transaction. {% endhint %} ```bash pundixd tx bank send <_name> <destinationAddress> <amount> <denomination> ``` Assuming you added the `--keyring-backend <file>` flag earlier, an example of a transaction would look like the following: ```bash pundixd tx bank send a1 px1v65jk0gvzqdghcclldex08cddc38dau63mfk23 10PUNDIX --fees="1PUNDIX" --gas-prices="" \ --keyring-backend file ``` {% hint style="info" %} If you are not running a node, be sure to add in the `--node` flag to specify which node you would like to broadcast your transaction. {% endhint %} You will be prompted to enter the passphrase for the `--keyring-backend` flag: ```bash Enter keyring passphrase: Default sign-mode 'direct' not supported by Ledger, using sign-mode 'amino-json'. gas estimate: 123878 {"body":{"messages":[{"@type":"/cosmos.bank.v1beta1.MsgSend","from_address":"px1t67ryvnqmnud5g3vpmck00l3umelwkz7yv6gg5","to_address":"px1v65jk0gvzqdghcclldex08cddc38dau63mfk23","amount":[{"denom":"ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78","amount":"10000000000000000000"}]}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[{"denom":"ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78","amount":"1000000000000000000"}],"gas_limit":"123878","payer":"","granter":""}},"signatures":[]} confirm transaction before signing and broadcasting [y/N]: ``` After inputting `y`, you will be prompted to review and approve the transaction on your Ledger device.`View Transaction` on your Ledger, be sure to inspect the transaction JSON displayed on the screen. You can scroll through each field and each message. You may refer [here](#the-pundix-standard-transaction) to read more about the data fields of a standard transaction object. When prompted with `confirm transaction before signing`, Answer `y`. ### Receive funds To receive funds to the `pundix` account on your Ledger device, retrieve the address for your Ledger account (the ones with `TYPE ledger`) with this command: ```bash pundixd keys list ``` ### Further documentation Not sure what `pundixd` can do? Simply run the command without arguments to output documentation for the commands in supports. {% hint style="info" %} The `pundixd` help commands are nested. So `$ pundixd` will output docs for the top level commands (status, config, query, and tx). You can access documentation for sub commands with further help commands. {% endhint %} For example, to print the `query` commands: ```bash pundixd query --help # to print the `tx` (transaction) commands: pundixd tx --help ``` ## The PundiX Standard Transaction Transactions in pundix embed the [Standard Transaction type](https://godoc.org/github.com/cosmos/cosmos-sdk/x/auth#StdTx) from the Cosmos SDK. The Ledger device displays a serialized JSON representation of this object for you to review before signing the transaction. Here are the fields and what they mean: * `chain-id`: The chain to which you are broadcasting the tx, such as the `pundix` payalebar or `pundix` mainnet. * `account_number`: The global id of the sending account assigned when the account receives funds for the first time. * `sequence`: The nonce for this account, incremented with each transaction. * `fee`: JSON object describing the transaction fee, its gas amount and coin denomination * `memo`: optional text field used in various ways to tag transactions. * `msgs_<index>/<field>`: The array of messages included in the transaction. Double click to drill down into nested fields of the JSON. # Testnet Faucet ## Request Funds 1. To request for Testnet PUNDIX click on this [link](https://payalebar-faucet.functionx.io/) 2. Input your address (be sure to choose the correct wallet type for the network you wish to receive funds in) 3. Choose from the dropdown the appropriate network and coin/token type ## Viewing your wallet balances * You may view your balance on f(x)wallet which also allows for a more seamless way of transaction. You may download f(x)wallet from the Appstore or Google Play [here](https://download.functionx.io). * Once downloaded, enter into the settings configuration, (the button is on the top right, there is a settings icon) * Under general/Network Configuration, ensure your PundiX is toggled to `Testnet` * You may view your PUNDIX balance from the f(x)Wallet or the [PundiX Testnet Explorer](https://testnet.starscan.io/pundix/blocks)/[PundiX Mainnet Explorer](https://starscan.io/pundix/blocks). * Alternatively, to `query` your validator account balance (token holding account): ```bash pundixd q bank balances <token holding account public address> ``` # Cloud Setup ### Simple SSH * Choose a cloud instance based on the requirements specified in [here](https://docs.pundix.com/getting-started/installation-pundix#hardware-requirements) * The estimated cost is about 80-100 USD per month * Pundi X Chain is system agnostic but Ubuntu is preferred Remoting into the cloud server * For windows users, download [Gitbash](https://www.educative.io/edpresso/how-to-install-git-bash-in-windows) or [Putty](https://www.putty.org) (Gitbash is preferred). * For Mac and linux users, you can connect via the terminal More instructions below: <https://kinsta.com/blog/how-to-use-ssh/> * Once setup, ssh into the cloud instance ssh `<ssh_id>@<IP address>` eg. ```bash ssh root@47.211.41.82 ``` ### Connecting your localhost to the cloud instance (ssh port forwarding) Running the command `ssh -L 127.0.0.1:26657:127.0.0.1:26657<ssh_id>@<IP address>` connects your local port 26657 with your cloud's port 26657. This is just one of the way you can connect your local machine with your cloud instance to connect your HD wallets. The command should look something like: ``` ssh -L 127.0.0.1:26657:127.0.0.1:26657 root@47.211.41.82 ``` {% hint style="info" %} You must ensure you have pundixd installed in your local machine. {% endhint %} > Alternatively, you can add the `--node flag` and ensure that your IP address has either been whitelisted or your port is open. Also you can consider configuring your config.toml file to set your node up. # Cosmovisor Integration - Binaries > `cosmovisor` is a small process manager for Cosmos SDK application binaries that monitors the governance module for incoming chain upgrade proposals. If it sees a proposal that gets approved, cosmovisor can automatically download the new binary, stop the current binary, switch from the old binary to the new one, and finally restart the node with the new binary. ## 1. Setup Cosmovisor Installing cosmovisor: ``` go install cosmossdk.io/tools/cosmovisor/cmd/cosmovisor@latest ``` Set up the Cosmovisor environment variables. We recommend setting these in your `.profile` so it is automatically set in every session. ``` echo "# Setup Cosmovisor" >> ~/.profile echo "export DAEMON_NAME=pundixd" >> ~/.profile echo "export DAEMON_HOME=$HOME/.pundix" >> ~/.profile source ~/.profile ``` After this, you must make the necessary folders for `cosmosvisor` in your `DAEMON_HOME` directory (`~/.pundix`) and copy over the current binary. ``` mkdir -p ~/.pundix/cosmovisor mkdir -p ~/.pundix/cosmovisor/genesis/bin mkdir -p ~/.pundix/cosmovisor/upgrades/pxv2 ``` ## 2. Download the Pundix release {% hint style="info" %} Releases can be found here <https://github.com/pundix/pundix/releases/> {% endhint %} Manually download the binary and extract it to folder: {% tabs %} {% tab title="Build from source" %} ```sh git clone https://github.com/pundix/pundix.git ``` ```sh git checkout release/v0.1.x make build cp ./build/bin/pundixd ~/.pundix/cosmovisor/genesis/bin/ ``` ```sh git checkout release/v0.2.x make build cp ./build/bin/pundixd ~/.pundix/cosmovisor/upgrades/pxv2/bin/ ``` {% endtab %} {% tab title="Ubuntu" %} ```sh wget https://github.com/pundix/pundix/releases/download/v0.1.3/pundix_0.1.3_Linux_x86_64.tar.gz && tar -xvf pundix_0.1.3_Linux_x86_64.tar.gz -C ~/.pundix/cosmovisor/genesis/ wget https://github.com/pundix/pundix/releases/download/v0.2.1/pundix_0.2.1_Linux_x86_64.tar.gz && tar -xvf pundix_0.2.1_Linux_x86_64.tar.gz -C ~/.pundix/cosmovisor/upgrades/pxv2/ ``` {% endtab %} {% endtabs %} Copying the json upgrade info, you do not need to perform this step if there is no `upgrade-info.json` file in the `~/.pundix/data/data` folder ```sh cp ~/.pundix/data/upgrade-info.json ~/.pundix/cosmovisor/genesis/ ``` To check that you did this correctly, ensure your versions of `cosmovisor` are the same: ``` cosmovisor version ``` ## 3. Start your node To keep the process always running. If you're on linux, you can do this by creating a service. ``` sudo tee /etc/systemd/system/pundixd.service > /dev/null <<EOF [Unit] Description=Pundix Daemon After=network-online.target [Service] User=$USER ExecStart=/root/go/bin/cosmovisor run start --home=/root/.pundix Restart=always RestartSec=3 LimitNOFILE=infinity Environment="DAEMON_HOME=/root/.pundix" Environment="DAEMON_NAME=pundixd" Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=false" Environment="DAEMON_RESTART_AFTER_UPGRADE=true" Environment="UNSAFE_SKIP_BACKUP=true" [Install] WantedBy=multi-user.target EOF ``` Reload, enable and restart the node with daemon service file ``` sudo -S systemctl daemon-reload sudo -S systemctl enable pundixd sudo -S systemctl restart pundixd ``` You can check the status with ``` systemctl status pundixd ``` Accessing logs ``` journalctl -u pundixd -n 100 ``` # Cosmovisor Integration - Docker Docker comes with cosmovisor, just start it directly # Support keplr Add [Suggest Chain](https://docs.keplr.app/api/suggest-chain.html) 1. [Install Keplr browser extension.](https://www.keplr.app/download) 2. Open the browser console 3. Run the code below {% tabs %} {% tab title="Mainnet" %} ```javascript await window.keplr.experimentalSuggestChain({ chainId: "PUNDIX", chainName: "Pundi X Chain", rpc: "https://px-json.pundix.com:26657", rest: "https://px-rest.pundix.com", walletUrl: "https://starscan.io/pundix/validators", walletUrlForStaking: "https://starscan.io/pundix/validators", bip44: { coinType: 118, }, bech32Config: { bech32PrefixAccAddr: "px", bech32PrefixAccPub: "pxpub", bech32PrefixValAddr: "pxvaloper", bech32PrefixValPub: "pxvaloperpub", bech32PrefixConsAddr: "pxvalcons", bech32PrefixConsPub: "pxvalconspub", }, currencies: [ { coinDenom: "PUNDIX", coinMinimalDenom: "ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78", coinDecimals: 18, coinGeckoId: "pundi-x-2", coinImageUrl: "https://raw.githubusercontent.com/pundix/keplr-chain-registry/add-pundix-chain/images/pundix/pundi-x-token.png", }, { coinDenom: "PURSE", coinMinimalDenom: "bsc0x29a63F4B209C29B4DC47f06FFA896F32667DAD2C", coinDecimals: 18, coinGeckoId: "pundi-x-purse", coinImageUrl: "https://raw.githubusercontent.com/pundix/keplr-chain-registry/add-pundix-chain/images/pundix/purse-token.png", } ], feeCurrencies: [ { coinDenom: "PUNDIX", coinMinimalDenom: "ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78", coinDecimals: 18, coinGeckoId: "pundi-x-2", coinImageUrl: "https://raw.githubusercontent.com/pundix/keplr-chain-registry/add-pundix-chain/images/pundix/pundi-x-token.png", gasPriceStep: { low: 2000000000000, average: 2500000000000, high: 3000000000000, }, }, ], stakeCurrency: { coinDenom: "PUNDIX", coinMinimalDenom: "ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78", coinDecimals: 18, coinGeckoId: "pundi-x-2", coinImageUrl: "https://raw.githubusercontent.com/pundix/keplr-chain-registry/add-pundix-chain/images/pundix/pundi-x-token.png", }, }); ``` {% endtab %} {% tab title="Testnet" %} ```javascript await window.keplr.experimentalSuggestChain({ chainId: "payalebar", chainName: "Pundi X Chain Testnet", rpc: "https://testnet-px-json.pundix.com:26657", rest: "https://testnet-px-rest.pundix.com", walletUrl: "https://testnet.starscan.io/pundix/validators", walletUrlForStaking: "https://testnet.starscan.io/pundix/validators", bip44: { coinType: 118, }, bech32Config: { bech32PrefixAccAddr: "px", bech32PrefixAccPub: "pxpub", bech32PrefixValAddr: "pxvaloper", bech32PrefixValPub: "pxvaloperpub", bech32PrefixConsAddr: "pxvalcons", bech32PrefixConsPub: "pxvalconspub", }, currencies: [ { coinDenom: "PUNDIX", coinMinimalDenom: "ibc/169A52CA4862329131348484982CE75B3D6CC78AFB94C3107026C70CB66E7B2E", coinDecimals: 18, coinGeckoId: "pundi-x-2", coinImageUrl: "https://raw.githubusercontent.com/pundix/keplr-chain-registry/add-pundix-chain/images/pundix/pundi-x-token.png", }, { coinDenom: "PURSE", coinMinimalDenom: "bsc0x0BEdB58eC8D603E71556ef8aA4014c68DBd57AD7", coinDecimals: 18, coinGeckoId: "pundi-x-purse", coinImageUrl: "https://raw.githubusercontent.com/pundix/keplr-chain-registry/add-pundix-chain/images/pundix/purse-token.png", } ], feeCurrencies: [ { coinDenom: "PUNDIX", coinMinimalDenom: "ibc/169A52CA4862329131348484982CE75B3D6CC78AFB94C3107026C70CB66E7B2E", coinDecimals: 18, coinGeckoId: "pundi-x-2", coinImageUrl: "https://raw.githubusercontent.com/pundix/keplr-chain-registry/add-pundix-chain/images/pundix/pundi-x-token.png", gasPriceStep: { low: 2000000000000, average: 2500000000000, high: 3000000000000, }, }, ], stakeCurrency: { coinDenom: "PUNDIX", coinMinimalDenom: "ibc/169A52CA4862329131348484982CE75B3D6CC78AFB94C3107026C70CB66E7B2E", coinDecimals: 18, coinGeckoId: "pundi-x-2", coinImageUrl: "https://raw.githubusercontent.com/pundix/keplr-chain-registry/add-pundix-chain/images/pundix/pundi-x-token.png", }, }) ``` {% endtab %} {% endtabs %} # PundiX Network The documentation corresponding contains details for the RPC - HTTP, WS and GRPC endpoints PundiX supports different clients in order to support Cosmos transactions and queries | <p><br></p> | Description | Default Port | | ----------------------------------------------------- | ------------------------------------------------------------------------- | ------------ | | **Cosmos gRPC** | Query or send PundiX transactions using gRPC | `9090` | | **Cosmos restAPI** | Query or send PundiX transactions using restAPI | `1317` | | **Tendermint** [**RPC**](/developers/pundix-json-rpc) | Subscribe to PundiX logs and events emitted in smart contracts. | `26657` | | **Tendermint Websocket** | Query transactions, blocks, consensus state, broadcast transactions, etc. | `26657` | Various clients, tools and end points available {% tabs %} {% tab title="PundiX Mainnet" %} | | | | ------------------ | ------------------------------------------------------------------------------------ | | ChainId | `PUNDIX` | | Native Coin | `ibc/55367B7B6572631B78A93C66EF9FDFCE87CDE372CC4ED7848DA78C1EB1DCDD78`(PUNDIX Token) | | Mint Coin | `bsc0x29a63F4B209C29B4DC47f06FFA896F32667DAD2C`(PURSE Token) | | Block Explorer | <https://starscan.io/pundix/blocks> | | JSON RPC | <https://px-json.pundix.com:26657> | | JSON RPC Websocket | wss\://px-json.pundix.com:26657/websocket | | gRPC | <https://px-grpc.pundix.com:9090> | | REST API | <https://px-rest.pundix.com> | | {% endtab %} | | {% tab title="PundiX Testnet" %} | | | | ------------------ | ------------------------------------------------------------------------------------ | | ChainId | `payalebar` | | Native Coin | `ibc/169A52CA4862329131348484982CE75B3D6CC78AFB94C3107026C70CB66E7B2E`(PUNDIX Token) | | Mint Coin | `bsc0x0BEdB58eC8D603E71556ef8aA4014c68DBd57AD7`(PURSE Token) | | Block Explorer | <https://testnet.starscan.io/pundix/blocks> | | JSON RPC | <https://testnet-px-json.pundix.com:26657> | | JSON RPC Websocket | wss\://testnet-px-json.pundix.com:26657/websocket | | gRPC | <https://testnet-px-grpc.pundix.com:9090> | | REST API | <https://testnet-px-rest.pundix.com> | | Testnet Faucet | <https://payalebar-faucet.functionx.io/> | | {% endtab %} | | | {% endtabs %} | | # PundiX JSON RPC ## Support | | [Tendermint-Go](https://github.com/tendermint/tendermint/) | [Tendermint-Rs](https://github.com/informalsystems/tendermint-rs) | | ------------ | :--------------------------------------------------------: | :---------------------------------------------------------------: | | JSON-RPC 2.0 | ✅ | ✅ | | HTTP | ✅ | ✅ | | HTTPS | ✅ | ❌ | | WS | ✅ | ✅ | | Routes | [Tendermint-Go](https://github.com/tendermint/tendermint/) | [Tendermint-Rs](https://github.com/informalsystems/tendermint-rs) | | --------------------------------------- | :--------------------------------------------------------: | :---------------------------------------------------------------: | | [Health](#health) | ✅ | ✅ | | [Status](#status) | ✅ | ✅ | | [NetInfo](#netinfo) | ✅ | ✅ | | [Blockchain](#blockchain) | ✅ | ✅ | | [Block](#block) | ✅ | ✅ | | [BlockByHash](#blockbyhash) | ✅ | ❌ | | [BlockResults](#blockresults) | ✅ | ✅ | | [Commit](#commit) | ✅ | ✅ | | [Validators](#validators) | ✅ | ✅ | | [Genesis](#genesis) | ✅ | ✅ | | [GenesisChunked](#genesischunked) | ✅ | ❌ | | [ConsensusParams](#consensusparams) | ✅ | ❌ | | [UnconfirmedTxs](#unconfirmedtxs) | ✅ | ❌ | | [NumUnconfirmedTxs](#numunconfirmedtxs) | ✅ | ❌ | | [Tx](#tx) | ✅ | ❌ | | [BroadCastTxSync](#broadcasttxsync) | ✅ | ✅ | | [BroadCastTxAsync](#broadcasttxasync) | ✅ | ✅ | | [ABCIInfo](#abciinfo) | ✅ | ✅ | | [ABCIQuery](#abciquery) | ✅ | ✅ | | [BroadcastEvidence](#broadcastevidence) | ✅ | ✅ | ## Info Routes ### Health Node heartbeat #### Parameters (0) #### Requests {% tabs %} {% tab title="HTTP" %} ``` curl http://localhost:26657/health ``` {% endtab %} {% tab title="JSONRPC" %} ``` curl -X POST http://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"health\"}" ``` {% endtab %} {% endtabs %} #### Response ```json { "jsonrpc": "2.0", "id": 2, "result": {} } ``` ### Status Get Tendermint status including node info, pubkey, latest block hash, app hash, block height and time. #### Parameters None #### Request **HTTP** ``` curl http://127.0.0.1:26657/status ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"status\"}" ``` #### Response ```json { "jsonrpc": "2.0", "id": -1, "result": { "node_info": { "protocol_version": { "p2p": "8", "block": "11", "app": "0" }, "id": "b93270b358a72a2db30089f3856475bb1f918d6d", "listen_addr": "tcp://0.0.0.0:26656", "network": "PUNDIX", "version": "v0.34.8", "channels": "40202122233038606100", "moniker": "aib-hub-node", "other": { "tx_index": "on", "rpc_address": "tcp://0.0.0.0:26657" } }, "sync_info": { "latest_block_hash": "50F03C0EAACA8BCA7F9C14189ACE9C05A9A1BBB5268DB63DC6A3C848D1ECFD27", "latest_app_hash": "2316CFF7644219F4F15BEE456435F280E2B38955EEA6D4617CCB6D7ABF781C22", "latest_block_height": "5622165", "latest_block_time": "2021-03-25T14:00:43.356134226Z", "earliest_block_hash": "1455A0C15AC49BB506992EC85A3CD4D32367E53A087689815E01A524231C3ADF", "earliest_app_hash": "E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855", "earliest_block_height": "5200791", "earliest_block_time": "2019-12-11T16:11:34Z", "catching_up": false }, "validator_info": { "address": "38FB765D0092470989360ECA1C89CD06C2C1583C", "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "Z+8kntVegi1sQiWLYwFSVLNWqdAUGEy7lskL78gxLZI=" }, "voting_power": "0" } } } ``` ### NetInfo Network information #### Parameters None #### Request **HTTP** ``` curl http://127.0.0.1:26657/net_info ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"net_info\"}" ``` #### Response ```json { "id": 0, "jsonrpc": "2.0", "result": { "listening": true, "listeners": [ "Listener(@)" ], "n_peers": "1", "peers": [ { "node_info": { "protocol_version": { "p2p": "7", "block": "10", "app": "0" }, "id": "5576458aef205977e18fd50b274e9b5d9014525a", "listen_addr": "tcp://0.0.0.0:26656", "network": "PUNDIX", "version": "0.32.1", "channels": "4020212223303800", "moniker": "moniker-node", "other": { "tx_index": "on", "rpc_address": "tcp://0.0.0.0:26657" } }, "is_outbound": true, "connection_status": { "Duration": "168901057956119", "SendMonitor": { "Active": true, "Start": "2019-07-31T14:31:28.66Z", "Duration": "168901060000000", "Idle": "168901040000000", "Bytes": "5", "Samples": "1", "InstRate": "0", "CurRate": "0", "AvgRate": "0", "PeakRate": "0", "BytesRem": "0", "TimeRem": "0", "Progress": 0 }, "RecvMonitor": { "Active": true, "Start": "2019-07-31T14:31:28.66Z", "Duration": "168901060000000", "Idle": "168901040000000", "Bytes": "5", "Samples": "1", "InstRate": "0", "CurRate": "0", "AvgRate": "0", "PeakRate": "0", "BytesRem": "0", "TimeRem": "0", "Progress": 0 }, "Channels": [ { "ID": 48, "SendQueueCapacity": "1", "SendQueueSize": "0", "Priority": "5", "RecentlySent": "0" } ] }, "remote_ip": "95.179.155.35" } ] } } ``` ### Blockchain Get block headers. Returned in descending order. May be limited in quantity. #### Parameters * `minHeight (integer)`: The lowest block to be returned in the response * `maxHeight (integer)`: The highest block to be returned in the response #### Request **HTTP** ``` curl http://127.0.0.1:26657/blockchain curl http://127.0.0.1:26657/blockchain?minHeight=1&maxHeight=2 ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"blockchain\",\"params\":{\"minHeight\":\"1\", \"maxHeight\":\"2\"}}" ``` #### Response ```json { "id": 0, "jsonrpc": "2.0", "result": { "last_height": "1276718", "block_metas": [ { "block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "block_size": 1000000, "header": { "version": { "block": "10", "app": "0" }, "chain_id": "PUNDIX", "height": "12", "time": "2019-04-22T17:01:51.701356223Z", "last_block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "last_commit_hash": "21B9BC845AD2CB2C4193CDD17BFC506F1EBE5A7402E84AD96E64171287A34812", "data_hash": "970886F99E77ED0D60DA8FCE0447C2676E59F2F77302B0C4AA10E1D02F18EF73", "validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0", "next_validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0", "consensus_hash": "0F2908883A105C793B74495EB7D6DF2EEA479ED7FC9349206A65CB0F9987A0B8", "app_hash": "223BF64D4A01074DC523A80E76B9BBC786C791FB0A1893AC5B14866356FCFD6C", "last_results_hash": "", "evidence_hash": "", "proposer_address": "D540AB022088612AC74B287D076DBFBC4A377A2E" }, "num_txs": "54" } ] } } ``` ### Block Get block at a specified height. #### Parameters * `height (integer)`: height of the requested block. If no height is specified the latest block will be used. #### Request **HTTP** ``` curl http://127.0.0.1:26657/block curl http://127.0.0.1:26657/block?height=1 ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"block\",\"params\":{\"height\":\"1\"}}" ``` #### Response ```json { "id": 0, "jsonrpc": "2.0", "result": { "block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "block": { "header": { "version": { "block": "10", "app": "0" }, "chain_id": "PUNDIX", "height": "12", "time": "2019-04-22T17:01:51.701356223Z", "last_block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "last_commit_hash": "21B9BC845AD2CB2C4193CDD17BFC506F1EBE5A7402E84AD96E64171287A34812", "data_hash": "970886F99E77ED0D60DA8FCE0447C2676E59F2F77302B0C4AA10E1D02F18EF73", "validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0", "next_validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0", "consensus_hash": "0F2908883A105C793B74495EB7D6DF2EEA479ED7FC9349206A65CB0F9987A0B8", "app_hash": "223BF64D4A01074DC523A80E76B9BBC786C791FB0A1893AC5B14866356FCFD6C", "last_results_hash": "", "evidence_hash": "", "proposer_address": "D540AB022088612AC74B287D076DBFBC4A377A2E" }, "data": [ "yQHwYl3uCkKoo2GaChRnd+THLQ2RM87nEZrE19910Z28ABIUWW/t8AtIMwcyU0sT32RcMDI9GF0aEAoFdWF0b20SBzEwMDAwMDASEwoNCgV1YXRvbRIEMzEwMRCd8gEaagom61rphyEDoJPxlcjRoNDtZ9xMdvs+lRzFaHe2dl2P5R2yVCWrsHISQKkqX5H1zXAIJuC57yw0Yb03Fwy75VRip0ZBtLiYsUqkOsPUoQZAhDNP+6LY+RUwz/nVzedkF0S29NZ32QXdGv0=" ], "evidence": [ { "type": "string", "height": 0, "time": 0, "total_voting_power": 0, "validator": { "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "A6DoBUypNtUAyEHWtQ9bFjfNg8Bo9CrnkUGl6k6OHN4=" }, "voting_power": 0, "address": "string" } } ], "last_commit": { "height": 0, "round": 0, "block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "signatures": [ { "type": 2, "height": "1262085", "round": 0, "block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "timestamp": "2019-08-01T11:39:38.867269833Z", "validator_address": "000001E443FD237E4B616E2FA69DF4EE3D49A94F", "validator_index": 0, "signature": "DBchvucTzAUEJnGYpNvMdqLhBAHG4Px8BsOBB3J3mAFCLGeuG7uJqy+nVngKzZdPhPi8RhmE/xcw/M9DOJjEDg==" } ] } } } } ``` ### BlockByHash #### Parameters * `hash (string)`: Hash of the block to query for. #### Request **HTTP** ``` curl http://127.0.0.1:26657/block_by_hash?hash=0xD70952032620CC4E2737EB8AC379806359D8E0B17B0488F627997A0B043ABDED ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"block_by_hash\",\"params\":{\"hash\":\"0xD70952032620CC4E2737EB8AC379806359D8E0B17B0488F627997A0B043ABDED\"}}" ``` #### Response ```json { "id": 0, "jsonrpc": "2.0", "result": { "block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "block": { "header": { "version": { "block": "10", "app": "0" }, "chain_id": "PUNDIX", "height": "12", "time": "2019-04-22T17:01:51.701356223Z", "last_block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "last_commit_hash": "21B9BC845AD2CB2C4193CDD17BFC506F1EBE5A7402E84AD96E64171287A34812", "data_hash": "970886F99E77ED0D60DA8FCE0447C2676E59F2F77302B0C4AA10E1D02F18EF73", "validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0", "next_validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0", "consensus_hash": "0F2908883A105C793B74495EB7D6DF2EEA479ED7FC9349206A65CB0F9987A0B8", "app_hash": "223BF64D4A01074DC523A80E76B9BBC786C791FB0A1893AC5B14866356FCFD6C", "last_results_hash": "", "evidence_hash": "", "proposer_address": "D540AB022088612AC74B287D076DBFBC4A377A2E" }, "data": [ "yQHwYl3uCkKoo2GaChRnd+THLQ2RM87nEZrE19910Z28ABIUWW/t8AtIMwcyU0sT32RcMDI9GF0aEAoFdWF0b20SBzEwMDAwMDASEwoNCgV1YXRvbRIEMzEwMRCd8gEaagom61rphyEDoJPxlcjRoNDtZ9xMdvs+lRzFaHe2dl2P5R2yVCWrsHISQKkqX5H1zXAIJuC57yw0Yb03Fwy75VRip0ZBtLiYsUqkOsPUoQZAhDNP+6LY+RUwz/nVzedkF0S29NZ32QXdGv0=" ], "evidence": [ { "type": "string", "height": 0, "time": 0, "total_voting_power": 0, "validator": { "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "A6DoBUypNtUAyEHWtQ9bFjfNg8Bo9CrnkUGl6k6OHN4=" }, "voting_power": 0, "address": "string" } } ], "last_commit": { "height": 0, "round": 0, "block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "signatures": [ { "type": 2, "height": "1262085", "round": 0, "block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "timestamp": "2019-08-01T11:39:38.867269833Z", "validator_address": "000001E443FD237E4B616E2FA69DF4EE3D49A94F", "validator_index": 0, "signature": "DBchvucTzAUEJnGYpNvMdqLhBAHG4Px8BsOBB3J3mAFCLGeuG7uJqy+nVngKzZdPhPi8RhmE/xcw/M9DOJjEDg==" } ] } } } } ``` ### BlockResults ### Parameters * `height (integer)`: Height of the block which contains the results. If no height is specified, the latest block height will be used #### Request **HTTP** ``` curl http://127.0.0.1:26657/block_results curl http://127.0.0.1:26657/block_results?height=1 ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"block_results\",\"params\":{\"height\":\"1\"}}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "height": "12", "total_gas_used": "100", "txs_results": [ { "code": "0", "data": "", "log": "not enough gas", "info": "", "gas_wanted": "100", "gas_used": "100", "events": [ { "type": "app", "attributes": [ { "key": "YWN0aW9u", "value": "c2VuZA==", "index": false } ] } ], "codespace": "ibc" } ], "begin_block_events": [ { "type": "app", "attributes": [ { "key": "YWN0aW9u", "value": "c2VuZA==", "index": false } ] } ], "end_block": [ { "type": "app", "attributes": [ { "key": "YWN0aW9u", "value": "c2VuZA==", "index": false } ] } ], "validator_updates": [ { "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "9tK9IT+FPdf2qm+5c2qaxi10sWP+3erWTKgftn2PaQM=" }, "power": "300" } ], "consensus_params_updates": { "block": { "max_bytes": "22020096", "max_gas": "1000", "time_iota_ms": "1000" }, "evidence": { "max_age": "100000" }, "validator": { "pub_key_types": [ "ed25519" ] } } } } ``` ### Commit #### Parameters * `height (integer)`: Height of the block the requested commit pertains to. If no height is set the latest commit will be returned. #### Request **HTTP** ``` curl http://127.0.0.1:26657/commit curl http://127.0.0.1:26657/commit?height=1 ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"commit\",\"params\":{\"height\":\"1\"}}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "signed_header": { "header": { "version": { "block": "10", "app": "0" }, "chain_id": "PUNDIX", "height": "12", "time": "2019-04-22T17:01:51.701356223Z", "last_block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "last_commit_hash": "21B9BC845AD2CB2C4193CDD17BFC506F1EBE5A7402E84AD96E64171287A34812", "data_hash": "970886F99E77ED0D60DA8FCE0447C2676E59F2F77302B0C4AA10E1D02F18EF73", "validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0", "next_validators_hash": "D658BFD100CA8025CFD3BECFE86194322731D387286FBD26E059115FD5F2BCA0", "consensus_hash": "0F2908883A105C793B74495EB7D6DF2EEA479ED7FC9349206A65CB0F9987A0B8", "app_hash": "223BF64D4A01074DC523A80E76B9BBC786C791FB0A1893AC5B14866356FCFD6C", "last_results_hash": "", "evidence_hash": "", "proposer_address": "D540AB022088612AC74B287D076DBFBC4A377A2E" }, "commit": { "height": "1311801", "round": 0, "block_id": { "hash": "112BC173FD838FB68EB43476816CD7B4C6661B6884A9E357B417EE957E1CF8F7", "parts": { "total": 1, "hash": "38D4B26B5B725C4F13571EFE022C030390E4C33C8CF6F88EDD142EA769642DBD" } }, "signatures": [ { "block_id_flag": 2, "validator_address": "000001E443FD237E4B616E2FA69DF4EE3D49A94F", "timestamp": "2019-04-22T17:01:58.376629719Z", "signature": "14jaTQXYRt8kbLKEhdHq7AXycrFImiLuZx50uOjs2+Zv+2i7RTG/jnObD07Jo2ubZ8xd7bNBJMqkgtkd0oQHAw==" } ] } }, "canonical": true } } ``` ### Validators #### Parameters * `height (integer)`: Block height at which the validators were present on. If no height is set the latest commit will be returned. * `page (integer)`: * `per_page (integer)`: #### Request **HTTP** ``` curl http://127.0.0.1:26657/validators ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"validators\",\"params\":{\"height\":\"1\", \"page\":\"1\", \"per_page\":\"20\"}}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "block_height": "55", "validators": [ { "address": "000001E443FD237E4B616E2FA69DF4EE3D49A94F", "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "9tK9IT+FPdf2qm+5c2qaxi10sWP+3erWTKgftn2PaQM=" }, "voting_power": "239727", "proposer_priority": "-11896414" } ], "count": "1", "total": "25" } } ``` ### Genesis Get Genesis of the chain. If the response is large, this operation will return an error: use `genesis_chunked` instead. #### Request **HTTP** ``` curl http://127.0.0.1:26657/genesis ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"genesis\"}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "genesis": { "genesis_time": "2019-04-22T17:00:00Z", "chain_id": "PUNDIX", "initial_height": "2", "consensus_params": { "block": { "max_bytes": "22020096", "max_gas": "1000", "time_iota_ms": "1000" }, "evidence": { "max_age": "100000" }, "validator": { "pub_key_types": [ "ed25519" ] } }, "validators": [ { "address": "B00A6323737F321EB0B8D59C6FD497A14B60938A", "pub_key": { "type": "tendermint/PubKeyEd25519", "value": "cOQZvh/h9ZioSeUMZB/1Vy1Xo5x2sjrVjlE/qHnYifM=" }, "power": "9328525", "name": "Certus One" } ], "app_hash": "", "app_state": {} } } } ``` ### GenesisChunked Get the genesis document in a chunks to support easily transfering larger documents. #### Parameters * `chunk` (integer): the index number of the chunk that you wish to fetch. These IDs are 0 indexed. #### Request **HTTP** ``` curl http://127.0.0.1:26657/genesis_chunked?chunk=0 ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"genesis_chunked\",\"params\":{\"chunk\":0}}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "chunk": 0, "total": 10, "data": "dGVuZGVybWludAo=" } } ``` ### ConsensusParams Get the consensus parameters. #### Parameters * `height (integer)`: Block height at which the consensus params would like to be fetched for. #### Request **HTTP** ``` curl http://127.0.0.1:26657/consensus_params ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"consensus_params\"}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "block_height": "1", "consensus_params": { "block": { "max_bytes": "22020096", "max_gas": "1000", "time_iota_ms": "1000" }, "evidence": { "max_age": "100000" }, "validator": { "pub_key_types": [ "ed25519" ] } } } } ``` ### UnconfirmedTxs Get a list of unconfirmed transactions. #### Parameters * `limit (integer)` The amount of txs to respond with. #### Request **HTTP** ``` curl http://127.0.0.1:26657/unconfirmed_txs ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"unconfirmed_txs\, \"params\":{\"limit\":\"20\"}}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "n_txs": "82", "total": "82", "total_bytes": "19974", "txs": [ "gAPwYl3uCjCMTXENChSMnIkb5ZpYHBKIZqecFEV2tuZr7xIUA75/FmYq9WymsOBJ0XSJ8yV8zmQKMIxNcQ0KFIyciRvlmlgcEohmp5wURXa25mvvEhQbrvwbvlNiT+Yjr86G+YQNx7kRVgowjE1xDQoUjJyJG+WaWBwSiGannBRFdrbma+8SFK2m+1oxgILuQLO55n8mWfnbIzyPCjCMTXENChSMnIkb5ZpYHBKIZqecFEV2tuZr7xIUQNGfkmhTNMis4j+dyMDIWXdIPiYKMIxNcQ0KFIyciRvlmlgcEohmp5wURXa25mvvEhS8sL0D0wwgGCItQwVowak5YB38KRIUCg4KBXVhdG9tEgUxMDA1NBDoxRgaagom61rphyECn8x7emhhKdRCB2io7aS/6Cpuq5NbVqbODmqOT3jWw6kSQKUresk+d+Gw0BhjiggTsu8+1voW+VlDCQ1GRYnMaFOHXhyFv7BCLhFWxLxHSAYT8a5XqoMayosZf9mANKdXArA=" ] } } ``` ### NumUnconfirmedTxs Get data about unconfirmed transactions. #### Parameters None #### Request **HTTP** ``` curl http://127.0.0.1:26657/num_unconfirmed_txs ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"num_unconfirmed_txs\"}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "n_txs": "31", "total": "82", "total_bytes": "19974" } } ``` ### Tx #### Parameters * `hash (string)`: The hash of the transaction * `prove (bool)`: If the response should include proof the transaction was included in a block. #### Request **HTTP** ``` curl http://127.0.0.1:26657/num_unconfirmed_txs ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"num_unconfirmed_txs\"}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "hash": "D70952032620CC4E2737EB8AC379806359D8E0B17B0488F627997A0B043ABDED", "height": "1000", "index": 0, "tx_result": { "log": "[{\"msg_index\":\"0\",\"success\":true,\"log\":\"\"}]", "gas_wanted": "200000", "gas_used": "28596", "tags": [ { "key": "YWN0aW9u", "value": "c2VuZA==", "index": false } ] }, "tx": "5wHwYl3uCkaoo2GaChQmSIu8hxpJxLcCuIi8fiHN4TMwrRIU/Af1cEG7Rcs/6LjTl7YjRSymJfYaFAoFdWF0b20SCzE0OTk5OTk1MDAwEhMKDQoFdWF0b20SBDUwMDAQwJoMGmoKJuta6YchAwswBShaB1wkZBctLIhYqBC3JrAI28XGzxP+rVEticGEEkAc+khTkKL9CDE47aDvjEHvUNt+izJfT4KVF2v2JkC+bmlH9K08q3PqHeMI9Z5up+XMusnTqlP985KF+SI5J3ZOIhhNYWRlIGJ5IENpcmNsZSB3aXRoIGxvdmU=" } } ``` ## Transaction Routes ### BroadCastTxSync Returns with the response from CheckTx. Does not wait for DeliverTx result. #### Parameters * `tx (string)`: The transaction encoded #### Request **HTTP** ``` curl http://127.0.0.1:26657/broadcast_tx_sync?tx=encoded_tx ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"broadcast_tx_sync\",\"params\":{\"tx\":\"a/encoded_tx/c\"}}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "code": "0", "data": "", "log": "", "codespace": "ibc", "hash": "0D33F2F03A5234F38706E43004489E061AC40A2E" }, "error": "" } ``` ### BroadCastTxAsync Returns right away, with no response. Does not wait for CheckTx nor DeliverTx results. #### Parameters * `tx (string)`: The transaction encoded #### Request **HTTP** ``` curl http://127.0.0.1:26657/broadcast_tx_async?tx=encoded_tx ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"broadcast_tx_async\",\"params\":{\"tx\":\"a/encoded_tx/c\"}}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "code": "0", "data": "", "log": "", "codespace": "ibc", "hash": "0D33F2F03A5234F38706E43004489E061AC40A2E" }, "error": "" } ``` ### CheckTx Checks the transaction without executing it. #### Parameters * `tx (string)`: String of the encoded transaction #### Request **HTTP** ``` curl http://127.0.0.1:26657/check_tx?tx=encoded_tx ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"check_tx\",\"params\":{\"tx\":\"a/encoded_tx/c\"}}" ``` #### Response ```json { "id": 0, "jsonrpc": "2.0", "error": "", "result": { "code": "0", "data": "", "log": "", "info": "", "gas_wanted": "1", "gas_used": "0", "events": [ { "type": "app", "attributes": [ { "key": "YWN0aW9u", "value": "c2VuZA==", "index": false } ] } ], "codespace": "bank" } } ``` ## ABCI Routes ### ABCIInfo Get some info about the application. #### Parameters None #### Request **HTTP** ``` curl http://127.0.0.1:26657/abci_info ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"abci_info\"}" ``` #### Response ```json { "jsonrpc": "2.0", "id": 0, "result": { "response": { "data": "{\"size\":0}", "version": "0.16.1", "app_version": "1314126" } } } ``` ### ABCIQuery Query the application for some information. > [About ABCI Query More](https://github.com/pundix/docs/blob/main/developers/json-rcp-abci-query.md) #### Parameters * `path (string)`: Path to the data. This is defined by the application. * `data (string)`: The data requested * `height (integer)`: Height at which the data is being requested for. * `prove (bool)`: Include proofs of the transactions inclusion in the block #### Request **HTTP** ``` curl http://127.0.0.1:26657/abci_query?path="a/b/c"=IHAVENOIDEA&height=1&prove=true ``` **JSONRPC** ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"abci_query\",\"params\":{\"path\":\"a/b/c\", \"height\":\"1\", \"bool\":\"true\"}}" ``` #### Response ```json { "error": "", "result": { "response": { "log": "exists", "height": "0", "proof": "010114FED0DAD959F36091AD761C922ABA3CBF1D8349990101020103011406AA2262E2F448242DF2C2607C3CDC705313EE3B0001149D16177BC71E445476174622EA559715C293740C", "value": "61626364", "key": "61626364", "index": "-1", "code": "0" } }, "id": 0, "jsonrpc": "2.0" } ``` ## Evidence Routes ### BroadcastEvidence Broadcast evidence of the misbehavior. #### Parameters * `evidence (string)`: #### Request **HTTP** ``` curl http://localhost:26657/broadcast_evidence?evidence=JSON_EVIDENCE_encoded ``` #### JSONRPC ``` curl -X POST https://localhost:26657 -d "{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"broadcast_evidence\",\"params\":{\"evidence\":\"JSON_EVIDENCE_encoded\"}}" ``` #### Response ```json { "error": "", "result": "", "id": 0, "jsonrpc": "2.0" } ``` ## Error code schedule | Error code | Illustration | Remarks | | ---------- | -------------------------------------------------- | ------- | | 0 | success | | | 1 | internal | | | 2 | tx parse error | | | 3 | invalid sequence | | | 4 | unauthorized | | | 5 | insufficient funds | | | 6 | unknown request | | | 7 | invalid address | | | 8 | invalid pubkey | | | 9 | unknown address | | | 10 | invalid coins | | | 11 | out of gas | | | 12 | memo too large | | | 13 | insufficient fee | | | 14 | maximum numer of signatures exceeded | | | 15 | no signatures supplied | | | 16 | tx in mempool | | | 17 | failed to unmarshal JSON bytes | | | 18 | invalid request | | | 19 | tx already in mempool | | | 20 | mempool is full | | | 21 | tx too large | | | 22 | key not found | | | 23 | invalid account password | | | 24 | tx intended signer does not match the given signer | | | 25 | invalid gas adjustment | | | 26 | invalid height | | | 27 | invalid version | | | 28 | invalid chain-id | | | 29 | invalid type | | | 30 | tx timeout height | | | 31 | unknown extension options | | | 32 | incorrect account sequence | | | 33 | failed packing protobuf message to Any | | | 34 | failed unpacking protobuf message from Any | | | 35 | internal logic error | | | 36 | conflict | | | 37 | feature not supported | | | 38 | not found | | | 39 | Internal IO error | | | 40 | error in app.toml | | | 111222 | panic | | # PundiX Cross Chain ## CrossChain cross chain include: * [ibc](/developers/cross-chain/ibc) # ibc In IBC, blockchains do not directly pass messages to each other over the network. This is where relayer comes in. A relayer process monitors for updates on opens paths between sets of [IBC](https://ibcprotocol.org/) enabled chains. The relayer submits these updates in the form of specific message types to the counterparty chain. Clients are then used to track and verify the consensus state. In addition to relaying packets, this relayer can open paths across chains, thus creating clients, connections and channels. Additional information on how IBC works can be found [here](https://ibc.cosmos.network/). ## IBC Channels {% tabs %} {% tab title="Mainnet" %} | source chain-id | destination | destination chain-id | source to destination channel | destination to source channel | | --------------- | ----------- | -------------------- | ----------------------------- | ----------------------------- | | PUNDXI | f(x)Core | fxcore | channel-0 | channel-0 | | PUNDXI | Osmosis | osmosis-1 | channel-1 | channel-12618 | | {% endtab %} | | | | | {% tab title="Testnet" %} | source chain-id | destination | destination chain-id | source to destination channel | destination to source channel | | --------------- | ----------- | -------------------- | ----------------------------- | ----------------------------- | | payalebar | f(x)Core | dhobyghaut | channel-0 | channel-0 | | payalebar | Osmosis | osmo-test-5 | channel-3 | channel-7744 | | {% endtab %} | | | | | | {% endtabs %} | | | | |