- Discover DeltaV revolutionary features and services for AI-based commerce and service activities.
+ Discover DeltaV revolutionary features and services for AI-based commerce and services activities.
Explore how to index and query blockchain data efficiently using the SubQuery indexer for the Fetch ledger.
+
diff --git a/pages/concepts/fetch-network/_meta.json b/pages/concepts/fetch-network/_meta.json
index 19660b154..8add7144b 100644
--- a/pages/concepts/fetch-network/_meta.json
+++ b/pages/concepts/fetch-network/_meta.json
@@ -1,4 +1,5 @@
{
"native-and-erc20-fet-tokens": "Native and ERC-20 FET tokens",
+ "ledger": "Ledger",
"indexer": "Indexer"
}
diff --git a/pages/concepts/fetch-network/ledger/_meta.json b/pages/concepts/fetch-network/ledger/_meta.json
new file mode 100644
index 000000000..2af2c536a
--- /dev/null
+++ b/pages/concepts/fetch-network/ledger/_meta.json
@@ -0,0 +1,4 @@
+{
+ "intro": "Introduction \uD83D\uDE80",
+ "validators": "Validators"
+}
diff --git a/pages/concepts/fetch-network/ledger/intro.mdx b/pages/concepts/fetch-network/ledger/intro.mdx
new file mode 100644
index 000000000..0823f1bca
--- /dev/null
+++ b/pages/concepts/fetch-network/ledger/intro.mdx
@@ -0,0 +1,27 @@
+import { Callout } from 'nextra/components'
+
+# Ledger
+
+## Introduction 🚀
+
+A **ledger** refers to a decentralized and distributed digital book that records all transactions across a network. This is used to ensure transparency and security of transactions and operations undertaken on that network.
+
+Within this context, the **Fetch Ledger** developed by Fetch.ai constitutes the underlying infrastructure for various decentralized applications and contracts. It employs a consensus mechanism where [validators ↗️](/concepts/fetch-network/ledger/validators) are responsible for validating transactions and creating new blocks in the [blockchain ↗️](/concepts/fetch-network/ledger/validators#overview-blockchains-consensus-and-validators). The ledger utilizes Fetch native cryptocurrency, FET, which is used for various activities within the network, including transaction fees and staking. The ledger also supports features such as [multi-signature keys ↗️](/guides/fetch-network/ledger/cli/multisig-keys), allowing users to control [keys ↗️](/guides/fetch-network/ledger/cli/keys) in different configurations.
+
+The fetchhub [mainnet ↗️](/concepts/fetch-network/ledger/validators#test-network-testnet-vs-main-network-mainnet) forms the core of the Fetch.ai ecosystem. In here, you will find all information to setup your client and connect on the network.
+
+Head over to our [guides ↗️](/guides) section and get yourself started with the ledger [installation ↗️](/guides/fetch-network/ledger/installation) and different executable operations.
+
+You can also visit the [references ↗️](/references) section for further information on ledger related topics, including [active networks ↗️](/references/fetch-network/ledger/active-networks) specifications, [ledger versions ↗️](/references/fetch-network/ledger/versions), and the [Command Line Interface (CLI) ↗️](/guides/fetch-network/ledger/cli/intro) section for guidance on how to install and configure the `fetchd` client and perform different operations within the ledger using the CLI.
+
+
+ This documentation covers the things you need to know in order to prepare yourself and start developing on the Fetch network.
+
+
+## Test networks
+
+The starting point for most users is [the test network ↗️](/references/fetch-network/ledger/active-networks#test-nets). Our test network (testnet) provides you with test tokens with no value, that you can safely experiment with through the [faucet ↗️](/guides/fetch-network/ledger/faucet).
+
+
+ This documentation is currently under construction, and the content may not be up-to-date.
+
diff --git a/pages/concepts/fetch-network/ledger/validators.mdx b/pages/concepts/fetch-network/ledger/validators.mdx
new file mode 100644
index 000000000..d3849e547
--- /dev/null
+++ b/pages/concepts/fetch-network/ledger/validators.mdx
@@ -0,0 +1,81 @@
+import { Callout } from 'nextra/components'
+
+# Validators
+
+## Overview: blockchains, consensus and validators
+
+A **blockchain** is a series of data records that functions as a distributed, replicated digital ledger of transactions across a network of computer systems. On blockchains, the records of transactions are compiled into **blocks** which are linked together to form a chain. Thus, blockchains consists of a stable chain of blocks and each one of these blocks stores a list of previously confirmed transactions.
+
+These transactions take place inside a [peer-to-peer (P2P) ↗️](https://www.investopedia.com/terms/p/peertopeer-p2p-service.asp) global network, thus, blockchains are considered borderless and immune to censorship. A blockchain network serves as a decentralized ledger since it is maintained by several computers located all over the world. This implies that each participant, namely a **node**, keeps a copy of the blockchain data and interacts with other participants to make sure that everyone is aware of the same information stored in the block.
+
+A blockchain, including the **Fetch.ai Ledger**, provides a secure and transparent way to record transactions, enabling trustless interactions between parties and removing the need for a central authority to overlook transactions.
+
+
+ This is especially crucial in decentralized systems in which multiple parties need to engage in secure and verifiable transactions. Despite the absence of a central authority to confirm and authenticate the transactions, every blockchain transaction is considered totally safe and validated.
+
+
+Only the presence of a **consensus protocol** makes this feasible. A consensus algorithm allows every node in the blockchain network to agree on the distributed ledger's current state. The consensus protocol ensures that all nodes in the network reach a common agreement on the order and validity of transactions.
+
+More specifically, a **node** is any device or computer that participates in the network by maintaining a copy of the blockchain ledger, validating transactions, and broadcasting them to other nodes. Nodes can be categorized into different types, including **full** and **validator nodes**. These latter ones are specific type of node responsible for participating in the consensus process. These validate transactions, create new blocks, and contribute to the security and operation of the blockchain network. Validator nodes typically require a significant amount of cryptocurrency to be staked and which serves as collateral and as an incentive for them to act honestly.
+
+**The most well-known consensus mechanisms** are:
+
+ - **Proof of Work (PoW)**: this is the original consensus protocol used by Bitcoin. It requires nodes (i.e. miners) to perform computationally intensive tasks to validate transactions and create new blocks. The first miner to solve the mathematical puzzle gets to add a block to the blockchain.
+
+ - **Proof of Stake (PoS)**: in this protocol, nodes (i.e. validators) are chosen based on the amount of cryptocurrency they hold and are willing to stake as collateral. Validators take turns proposing and validating blocks, and they earn rewards for their participation in the form of transaction fees and block.
+
+**Compensation and incentives for validators** can take the form of:
+
+ - **Block rewards**: in PoW and some PoS systems, validators are rewarded with newly created cryptocurrency tokens for successfully adding a new block to the blockchain.
+
+ - **Transaction fees**: validators may receive transaction fees paid by users for including their transactions in a block.
+
+ - **Delegation rewards**: in PoS networks, validators who receive delegated stakes from token holders may share a portion of the rewards with their delegators. This encourages token holders to delegate their stakes to reputable validators.
+
+ - **Slashing penalties**: while not a form of compensation, validators can be penalized (i.e. slashed) for malicious behavior or violations of network rules. The penalties are typically deducted from the validator's committed stake.
+
+In this context, the Fetch.ai Ledger 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. As previously highlighted, validator candidates can have FET delegated or staked to them by token holders. The validators are determined by who has the most stake delegated to them. The top validator candidates with the most stake become **active validators** within the network.
+
+
+ If validators double sign, are frequently offline or do not participate in governance, their staked FET (including FET of users that delegated to them) can be slashed. The penalty depends on the severity of the violation.
+
+
+### Test network (Testnet) vs Main Network (Mainnet)
+
+We can distinguish between:
+
+ - **Testnet**: it is a separate blockchain environment that developers and users can use to test new features or applications without risking real tokens. It allows for experimentation in a controlled environment.
+
+ - **Mainnet**: it is the actual production blockchain where real transactions occur with real tokens. It is the live version of the blockchain.
+
+
+ By setting up and experimenting on a testnet first, developers can ensure that everything works as intended before deploying it on the mainnet. This helps in avoiding potential issues or vulnerabilities in a live environment.
+
+
+## Set up a validator node
+
+If you are willing to set up a validator node on the Fetch network, visit our dedicated [guide ↗️](/guides/fetch-network/ledger/setup-validator-node).
+
+### Hardware requirements
+
+The hardware resources for running a validator node largely depend on the network load. As a _recommended configuration_, we suggest the following requirements:
+
+ - 2 x CPU, either Intel or AMD, with the SSE4.1, SSE4.2 and AVX flags (use lscpu to verify).
+ - 8 GB RAM.
+ - 500 GB SSD.
+ - 100 Mbit/s always-on internet connection.
+ - Linux OS (Ubuntu 18.04 or 20.04 recommended)/MacOS.
+
+Up-time is incredibly important for being a validator. It is expected that validators will have appropriate redundancies for compute, power, connectivity and so on. While the blockchain itself is highly replicated, it is also expected that validators will perform local storage backups in order to minimise validator down-time.
+
+### Set up a website for your validator
+
+Set up a dedicated validator's website and signal your intention to become a validator on our [Discord ↗️](https://discord.gg/fetchai) server. This is important since delegators will want to have information about the entity they are delegating their FET to.
+
+This is not necessary, however, it is recommended given that as a validator on the network, you will want to get other community users to delegate stake to your validator. The higher the delegated stake to a specific validator, the greater the share of the block rewards it will take.
+
+## Community
+
+We highly recommend to check out the validator community on the discord channel for more information and to check the latest announcements about becoming a validator within the Fetch.ai network:
+
+ - [Discord ↗️](https://discord.gg/fetchai).
diff --git a/pages/guides.mdx b/pages/guides.mdx
index 60c086f1d..fd313189e 100644
--- a/pages/guides.mdx
+++ b/pages/guides.mdx
@@ -15,6 +15,7 @@ import { GuideBox } from "../components/feature-guide-tabs";
+
+
+
+
+
+
+
+### Ledger
+
+
+ A list of guides related to operations executable on the Fetch Ledger.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+#### CLI - Command Line Interface
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
### Cosmpy
+
+
+
+
+
+
+
+
+
+
+
+ Once delegated, tokens can only be _re-delegated_ to another validator, or _unbond_ in order to be returned to their original account. It is important to note that those two operations take **21 days to complete**, period in which the involved tokens will be unavailable.
+
+
+### Re-delegating tokens
+
+**Re-delegating tokens allows you to transfer already delegated tokens from one validator to another**.
+
+From the above example where you delegated `1000000 atestfet` to `fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w`, you can now re-delegate parts or all of those tokens to another validator. For instance, you can re-delegate `400000 atestfet` from `fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w` to `fetchvaloper122veneudkzyalay6gusvrhhpp0560mparpanvu` by running the following command:
+
+ ```bash
+ fetchd tx staking redelegate fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w fetchvaloper122veneudkzyalay6gusvrhhpp0560mparpanvu 400000atestfet --from myKey
+ ```
+
+This will prompt for confirmation and issue a new transaction once accepted.
+
+From here, if you inspect the delegations from our account, you will be able to see that your delegated tokens are now:
+
+ - `600000atestfet` to validator `fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w` (our initial 1000000 minus the 400000 re-delegated).
+ - `400000atestfet` to validator `fetchvaloper122veneudkzyalay6gusvrhhpp0560mparpanvu`.
+
+Now, those `400000 atestfet` you re-delegated can not be re-delegated anymore for 21 days (the exact date can be found by querying the re-delegation transaction, under the `completion_time` key).
+
+
+ It is still possible to unbond those tokens if needed.
+
+
+### How to unbond tokens
+
+**Bonding** refers to the act of locking up a certain amount of cryptocurrency tokens in a wallet or smart contract to participate in the network's consensus mechanism. These tokens are often referred to as the **stake**. Conversely, **unbonding** is the process of withdrawing or releasing the previously bonded tokens. When a user initiates an unbonding transaction, they are indicating that they want to take back their tokens from the staking mechanism.
+
+You can transfer parts or all of our delegated tokens back to your account at any time by running the following command:
+
+ ```bash
+ fetchd tx staking unbond fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w 300000atestfet --from myKey
+ ```
+
+Once again, this will prompt for confirmation and issue a transaction, initiating the transfer of `300000 atestfet` from our stake on `fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w` validator address back to your account. Those tokens will then be available **after a 21 day period** (the exact date can be found by querying the re-delegation transaction, under the `completion_time` key).
+
+### How to withdraw rewards
+
+In order **to transfer rewards to the wallet**, run the following command:
+
+ ```bash
+ fetchd tx distribution withdraw-rewards validator_address --from myKey
+ ```
+
+It requires the validator address from where the reward is withdrawn, and the name of the account private key having delegated tokens to the validator. For instance:
+
+ ```bash
+ fetchd tx distribution withdraw-rewards fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w --from myKey
+ ```
+
+You can **claim all rewards when you have delegated tokens to multiple validators**, by running the following command:
+
+ ```bash
+ fetchd tx distribution withdraw-all-rewards --from myKey
+ ```
+
+The rewards will appear on the account as soon as the transaction is being processed.
diff --git a/pages/guides/fetch-network/ledger/cli/governance-proposals.mdx b/pages/guides/fetch-network/ledger/cli/governance-proposals.mdx
new file mode 100644
index 000000000..c724fcacd
--- /dev/null
+++ b/pages/guides/fetch-network/ledger/cli/governance-proposals.mdx
@@ -0,0 +1,113 @@
+# Governance proposals 📝
+
+Within any decentralised network, any significant change or adjustment should be proposed and subsequently agreed upon by the community or stakeholders involved. This process ensures that decisions are made collectively, helping to maintain transparency, fairness, and the overall integrity of the network.
+
+Hence, **a governance proposal must be submitted to change any attribute of a network**. This could be a simple poll, a software update or a governing parameter change. Whether it is a minor parameter tweak or a major software update, the proposal process is a crucial step in decentralized systems.
+
+For further information on governance within the Fetch Ledger, have a look at the following [documentation ↗️](/guides/fetch-network/ledger/governance)
+
+### Parameter change
+
+This is an example of the process in which network parameters may be changed through the use of a governance proposal.
+
+The values within this code can be changed in order to alter the minimum deposited fund threshold for a proposal to enter the voting phase, and the length of the deposit stage in which the minimum deposit threshold must be met.
+
+ ```
+ # A JSON file containing the following code should be created to instantiate the proposal.
+ # The two variables of interest are the "amount" which is set from 10000000stake to 1000stake
+ # and the "max_deposit_period" which is changed from the default value to 7200000000000
+ # equal to 2 hours, instead of the standard 2 days (in nanoseconds).
+
+ {
+ "title": "Staking Param Change",
+ "description": "Update max validators",
+ "changes": [
+ {
+ "subspace": "staking",
+ "key": "MaxValidators",
+ "value": 105
+ }
+ ],
+ "deposit": "1000000000000000000atestfet"
+ }
+ ```
+ ```
+ # Create initial proposal by uploading the JSON file
+ # this is signed by a key 'proposer' that provides a portion of the current threshold deposit
+ fetchd tx gov submit-proposal --proposal ~/json_path/proposal.json --from proposer
+
+ # In order to later refer to this proposal, the proposal_id can be determined
+ fetchd query gov proposals
+ ```
+
+### Proposal deposit phase
+
+The characteristics of the deposit phase are described by a set of network governance parameters, where the deposit period is two days from the initial proposal deposit until expiration, and a minimum threshold of 10000000 denom as default. The minimum threshold must be met during this deposit period in order to proceed to the voting phase. The proposer may provide all of this threshold, or just some. In which case, supporters of the proposal may donate additional funding towards the goal of meeting the threshold.
+
+At any point of the deposit stage, the deposit pot can be queried:
+
+ ```
+ # To get the proposal ID, use the txhash obtained when the proposal was submitted and run the following command:
+ fetchd query tx
+
+ # This command returns a text representation of the current total deposit value of a proposal
+ fetchd query gov deposits
+
+ # Other users may contribute to funding the proposal using
+ fetchd tx gov deposit --from contributer
+ ```
+
+[This documentation ↗️](https://docs.cosmos.network/master/modules/gov/01_concepts.html#proposal-submission) provides a more detailed explanation of the deposit funding period.
+
+### Proposal voting and querying
+
+After the deposit period has passed, there are two outcomes:
+
+ - The current minimum threshold is met.
+ - The value is not met and the funds are returned.
+
+In the first case this proposal is submitted and to be voted on, returning a tally at the end of the voting period.
+
+In order to submit a vote on a proposal that has passed into the voting phase, all staked users except the proposer may do so using this command.
+
+ ```
+ # Submit a vote from a key 'voter' with the desired outcome of the voter
+ fetchd tx gov vote --from voter
+ ```
+
+The current voting turnout and tally can be queried, which displays a list of all voters and their choice:
+
+ ```
+ # The current voting statistics can be printed using
+ fetchd query gov votes
+ ```
+
+#### Example output
+
+ ```
+ votes:
+ - option: VOTE_OPTION_YES
+ proposal_id: "1"
+ voter: fetch1dmehhhvul8y7slqs3zu2z3fede9kzlnyupd9rr
+ - option: VOTE_OPTION_NO
+ proposal_id: "1"
+ voter: fetch1064endj5ne5e868asnf0encctwlga4y2jf3h28
+ - option: VOTE_OPTION_YES
+ proposal_id: "1"
+ voter: fetch1k3ee923osju93jm03fkfmewnal39fjdbakje1x
+ ```
+
+### Voting outcome
+
+Once the voting period has ended, the results are used to determine the next step of the proposal.
+The potential outcomes include:
+
+ - **Majority _yes_ vote**
+ - The proposal passes through and the users act according to the proposal type - e.g. A Software update proposal passes, and users begin uptake of the new version.
+
+ - **Majority _no_ vote**
+ - The funds deposited to pass into the voting stage are returned, and there is no governance change.
+
+ - **Majority _no with veto_ vote**
+ - This outcome is indicative of a proposal which may undermine the current governance system, e.g. a proposal to set the deposit threshold or voting period to an absurd value.
+ - All funds deposited in the proposal are to be burned subject to this outcome, and there is no governance change.
diff --git a/pages/guides/fetch-network/ledger/cli/intro.mdx b/pages/guides/fetch-network/ledger/cli/intro.mdx
new file mode 100644
index 000000000..6abcc9490
--- /dev/null
+++ b/pages/guides/fetch-network/ledger/cli/intro.mdx
@@ -0,0 +1,27 @@
+# CLI - Introduction 🚀
+
+The Command Line Interface (CLI) client provides all the capabilities for interacting with the [Fetch ledger ↗️](/concepts/ledger/intro), such as creating addresses, sending transactions and the governance capabilities. Before starting with the Command Line client, you need to follow the [installation instructions ↗️](/guides/ledger/installation) for the Fetch Ledger.
+
+## Connecting to a network
+
+Users have the choice to either synchronize an entire blockchain by connecting a node to the network or directly link to existing publicly accessible nodes.
+
+### Connecting to fetchhub mainnet
+
+To connect to the **Fetch Mainnet** run the following configuration steps:
+
+ ```bash
+ fetchd config chain-id fetchhub-4
+ fetchd config node https://rpc-fetchhub.fetch.ai:443
+ ```
+
+### Connecting to Dorado Test Network
+
+To connect to the **Dorado Testnet** run the following configuration steps:
+
+ ```bash
+ fetchd config chain-id dorado-1
+ fetchd config node https://rpc-dorado.fetch.ai:443
+ ```
+
+Checkout the [network information ↗️](/references/ledger/active-networks) page for more detailed information on the available networks.
diff --git a/pages/guides/fetch-network/ledger/cli/keys.mdx b/pages/guides/fetch-network/ledger/cli/keys.mdx
new file mode 100644
index 000000000..fecb97405
--- /dev/null
+++ b/pages/guides/fetch-network/ledger/cli/keys.mdx
@@ -0,0 +1,132 @@
+import { Callout } from 'nextra/components'
+
+# CLI - Managing keys 🔑
+
+Managing keys is an essential part of working with the Ledger, since all interactions are authenticated with these keys.
+
+## How to add keys
+
+If you want to **create a new local key**, you would need to run the following command:
+
+ ```bash
+ fetchd keys add
+ ```
+
+
+ These keys are stored locally on your system. By default, these keys will be stored in the OS level keychain, however, in general these keys are considered less secure than using a hardware device
+
+
+After running the above command, `fetchd` will print out a summary of the new key being produced. An output example is shown below:
+
+ ```text
+ - name: test
+ type: local
+ address: fetch142tawq2rj397mctc3jtw9dfzf03ns0ze4swat0
+ pubkey: fetchpub1addwnpepqvtmze0ekffynnjx9n85g6sexzl49ze2vpgc2f52fteyyghjtvvqw682nkx
+ mnemonic: ""
+ threshold: 0
+ pubkeys: []
+ ```
+
+This will be followed by a 24-word mnemonic that can be used to re-generate the private key and address for the account.want
+
+
+ Keep this safe if ever use it to control Mainnet tokens!
+
+
+## How to look up for an address
+
+A common operation that you may want to carry out is to research the address related to specified key. This can be performed quickly, by running following command:
+
+ ```bash
+ fetchd keys show -a
+ ```
+
+The expected output should be as shown below:
+
+ ```bash
+ fetch142tawq2rj397mctc3jtw9dfzf03ns0ze4swat0
+ ```
+
+A less common operation, but still useful, would be to look for the public key related to a specified key.
+This can be achieved with the following command:
+
+ ```bash
+ fetchd keys show -p
+ ```
+
+The expected output should be similar to what shown below:
+
+ ```bash
+ fetchpub1addwnpepqvtmze0ekffynnjx9n85g6sexzl49ze2vpgc2f52fteyyghjtvvqw682nkx
+ ```
+
+## How to list keys
+
+If you wish to research for more detailed information for all keys within your system, simply use the following command:
+
+ ```bash
+ fetchd keys list
+ ```
+
+This will show all your keys information in a `yaml` format similar to the one generated when you first created the key:
+
+ ```bash
+ - name: test
+ type: local
+ address: fetch142tawq2rj397mctc3jtw9dfzf03ns0ze4swat0
+ pubkey: fetchpub1addwnpepqvtmze0ekffynnjx9n85g6sexzl49ze2vpgc2f52fteyyghjtvvqw682nkx
+ mnemonic: ""
+ threshold: 0
+ pubkeys: []
+ ```
+
+## How to recover a key
+
+You can import a key from a 24-word mnemonic by running the following:
+
+ ```bash
+ fetchd keys add --recover
+ > Enter your bip39 mnemonic
+
+ ```
+
+You will be prompted to enter the **mnemonic phrase**, and it will then print the matching address and key details as when creating a new key.
+
+## Hardware wallets
+
+### Set up your hardware wallet
+
+**We recommend hardware wallets as a solution for managing private keys!**
+
+The Fetch ledger is compatible with **Ledger Nano hardware wallets**. To use your Ledger Nano, you will need to go through the following steps:
+
+ 1. Set-up your wallet by creating a PIN and passphrase, which must be stored securely to enable recovery if the device is lost or damaged.
+ 2. Connect your device to your PC and update the firmware to the latest version using the Ledger Live application.
+ 3. Install the Cosmos application using the software manager (Manager > Cosmos > Install).
+
+### How to add a new key
+
+To use the hardware wallet address with the CLI, the user must first add it via `fetchd`. This process only records the public information about the key. You can **import the key** by first plugging in the device and enter the device pin. Once you have unlocked the device, navigate to the Cosmos app on the device and open it.
+
+Then, you can **add the key using the following command:
+
+ ```bash
+ fetchd keys add --ledger --index 0
+ ```
+
+
+ The `--ledger` flag tells the command line tool to talk to the ledger device and the `--index` flag selects which HD index should be used.
+
+
+When running this command, the Ledger device will prompt you to verify the generated address. Once you have done this. you will get an output in the following form:
+
+ ```bash
+ - name: hw1
+ type: ledger
+ address: fetch1xqqftqp8ranv2taxsx8h594xprfw3qxl7j3ra2
+ pubkey: fetchpub1addwnpepq2dulyd9mly3xqnvfgdsjkqlqzsxldpdhd6cnpm67sx90zhfw2ragk9my5h
+ mnemonic: ""
+ threshold: 0
+ pubkeys: []
+ ```
diff --git a/pages/guides/fetch-network/ledger/cli/multisig-keys.mdx b/pages/guides/fetch-network/ledger/cli/multisig-keys.mdx
new file mode 100644
index 000000000..15168e6f1
--- /dev/null
+++ b/pages/guides/fetch-network/ledger/cli/multisig-keys.mdx
@@ -0,0 +1,96 @@
+import { Callout } from 'nextra/components'
+
+# Multisig keys 🔐
+
+This feature of `fetchd` allows users to securely control keys in a number of configurations. This involves setting a minimum number of keys required to sign a transaction out of a maximum of N keys, known as a threshold number K.
+
+## Creating a multisig key
+
+To create a multisig key, use the following syntax:
+
+ ```
+ # Create a simple multisig key with a threshold of 1 as default
+ fetchd keys add --multisig
+
+ # Creating a multisig key with a higher threshold, K
+ fetchd keys add --multisig --multisig-threshold
+ ```
+
+### Example instantiation of a multisig key: shared business multisig key
+
+Consider a scenario in which three account holders need to collectively authorize transactions. At least two out of the three (K=2) must sign off on each transaction:
+
+ ```
+ # Create the three keys owned by the separate account holders
+ fetchd keys add fred
+ fetchd keys add ted
+ fetchd keys add ned
+
+ # Create the multisig key from keys above
+ fetchd keys add business_key --multisig fred,ted,ned --multisig-threshold 2
+ ```
+
+Importantly, remember to retrieve the address of `business_key` for future use:
+
+ ```
+ fetchd keys show -a business_key
+ ```
+
+## Signing and broadcasting multisig transactions
+
+Transactions must be signed and broadcasted before they can be executed.
+
+In order to sign a multi signature transaction, the transaction itself must not be immediately broadcast. Instead, the key holders must each sign until a minimum threshold K signatures are present.
+
+
+ For this example, we will be performing the transaction on the [Dorado ↗️](https://explore-dorado.fetch.ai/) network and therefore will be using `atestfet` as the denomination, and a gas price of 1000000000atestfet (this should be changed depending on the actual currency and network used).
+
+
+### Example: Multisig transaction
+
+ ```
+ # Create a key to represent a vendor that the business must pay
+ fetchd keys add vendor
+
+ # Generate a transaction as an output file to be signed by
+ # the keyholders, 'ted' and 'fred' in this example
+ fetchd tx bank send 1000atestfet --gas 90000 --gas-prices 1000000000atestfet --generate-only > transfer.json
+
+ # you'll get "account not found" error for missing funds
+ # add funds to using block explorer or by eg
+ curl -X POST -H 'Content-Type: application/json' -d '{"address":""}' https://faucet-dorado.fetch.ai/api/v3/claims
+
+ # This transaction file (transfer.json) is then made available for
+ # the first keyholder to sign, 'fred'
+ fetchd tx sign transfer.json --chain-id dorado-1 --from fred --multisig > transfer_fredsigned.json
+
+ # This is repeated for 'ted'
+ fetchd tx sign transfer.json --chain-id dorado-1 --from ted --multisig > transfer_tedsigned.json
+
+ # These two files are then collated together and used as inputs to the
+ # multisign command to create a fully signed transaction
+ fetchd tx multisign transfer.json business_key transfer_fredsigned.json transfer_tedsigned.json > signed_transfer.json
+
+ # Now that the transaction is fully signed, it may be broadcast
+ fetchd tx broadcast signed_transfer.json
+
+ # Now display the result of the transaction and confirm that the vendor has
+ # received payment
+ fetchd query bank balances
+ ```
+
+It is important to note that this method of signing transactions can apply to all types of transaction, including staking and withdrawal transactions as shown below.
+
+### Other multisig transaction examples
+
+Other examples are provided below:
+
+ ```
+ # In order to create a staking transaction using a multisig key
+ # the same process as above can be used with the output file of this command
+ fetchd tx staking delegate 10000atestfet --from --gas 200000 --gas-prices 1000000000atestfet --generate-only > stake.json
+
+ # The following command can also be used to create a withdrawal transaction for the
+ # rewards from staking when using a multisig key - this too must be signed as before
+ fetchd tx distribution withdraw-all-rewards --from --gas 150000 --gas-prices 1000000000atestfet --generate-only > withdrawal.json
+ ```
diff --git a/pages/guides/fetch-network/ledger/cli/tokens.mdx b/pages/guides/fetch-network/ledger/cli/tokens.mdx
new file mode 100644
index 000000000..87b759343
--- /dev/null
+++ b/pages/guides/fetch-network/ledger/cli/tokens.mdx
@@ -0,0 +1,80 @@
+# CLI - Managing tokens
+
+## How to query your balance
+
+Once `fetchd` is configured for the desired [network ↗️](/guides/fetch-network/ledger/cli/intro). The user can query their balance using the following command:
+
+ ```bash
+ fetchd query bank balances fetch1akvyhle79nts4rwn075t85xrwmp5ysuqynxcn4
+ ```
+
+If the address exists on the network, then the user will expect to see an output in the following form:
+
+ ```text
+ balances:
+ - amount: "8000000000000000000"
+ denom: atestfet
+ pagination:
+ next_key: null
+ total: "0"
+ ```
+
+## How to send funds
+
+Before sending funds, make sure the sender address has tokens available by querying your balance as shown above. Checkout the [token faucet](/guides/fetch-network/ledger/faucet) page for more information on how to add test tokens to your address.
+
+If you wish to send funds from one address to another, then you would use the `tx send` subcommand as shown below:
+
+ ```bash
+ fetchd tx bank send
+ ```
+
+In a more concrete example, if the user wanted to send `100atestfet` from `main` key/address to `fetch106vm9q6ezu9va7v7e0cvq0nedc54egjm692fcp`, then the following command would be needed:
+
+ ```bash
+ fetchd tx bank send main fetch106vm9q6ezu9va7v7e0cvq0nedc54egjm692fcp 100atestfet
+ ```
+
+When you run the command, you will get a similar output and prompt. The user can check the details of the transfer and then press `y` to confirm the transfer.
+
+ ```text
+ {"body":{"messages":[{"@type":"/cosmos.bank.v1beta1.MsgSend","from_address":"fetch12cjntwl32dry7fxck8qlgxq6na3fk5juwjdyy3","to_address":"fetch1hph8kd54gl6qk0hy5rl08qw9gcr4vltmk3w02v","amount":[{"denom":"atestfet","amount":"100"}]}],"memo":"","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""}},"signatures":[]}
+
+ confirm transaction before signing and broadcasting [y/N]: y
+ ```
+
+Once the transfer has been made, a summary is presented to the user.
+An example is shown below:
+
+ ```text
+ code: 0
+ codespace: ""
+ data: ""
+ gas_used: "0"
+ gas_wanted: "0"
+ height: "0"
+ info: ""
+ logs: []
+ raw_log: '[]'
+ timestamp: ""
+ tx: null
+ txhash: 77C7382A0B1B9FE39257A6C16C7E3169A875CB3A87F2CE9D947D7C1335B53E76
+ ```
+
+On failure, the response will have a non-zero code, as well as some logs under the `raw_log` key:
+
+ ```text
+ code: 4
+ codespace: sdk
+ data: ""
+ gas_used: "0"
+ gas_wanted: "0"
+ height: "0"
+ info: ""
+ logs: []
+ raw_log: 'signature verification failed; please verify account number (5815) and chain-id
+ (dorado-1): unauthorized'
+ timestamp: ""
+ tx: null
+ txhash: 23701B052B423D63EB4AC94773B5B8227B03A576692A57999E92F2554F2372D4
+ ```
diff --git a/pages/guides/fetch-network/ledger/faucet.mdx b/pages/guides/fetch-network/ledger/faucet.mdx
new file mode 100644
index 000000000..48f1a4c7d
--- /dev/null
+++ b/pages/guides/fetch-network/ledger/faucet.mdx
@@ -0,0 +1,67 @@
+import { Callout } from 'nextra/components'
+
+# How to get testnet tokens via the token faucet 💰
+
+A **token faucet** is a service that provides free tokens to users for testing or development purposes on a blockchain network. It helps developers and users access a blockchain's test network with a small amount of cryptocurrency without having to purchase it. This allows them to interact with the blockchain, test applications, and simulate real-world scenarios without using actual funds. It is a valuable resource for developers who want to experiment with blockchain applications in a risk-free environment.
+
+For our [test networks ↗️](/references/fetch-network/ledger/active-networks#test-nets), we have a simple token faucet implemented to allow users to get started quickly. You can send the faucet an account address, and it will transfer some test tokens back to such address. Token faucets are network specific, depending on the network type they may or may not be deployed. Please check the [networks ↗️](/references/ledger/active-networks) page for specific details.
+
+The testnet token faucet itself is available from the network block explorer available within the [active networks ↗️](/references/ledger/active-networks) page. You will be asked to enter your **Fetch Account address** (`fetch...`) and you will have to wait a few blocks for the transaction to be processed, and you should see it appearing alongside with some funds on your account.
+
+Overall, you can obtain test tokens for your account in the following way:
+
+ 1. Copy your account's address and paste it into the **token faucet** available within each [network ↗️](/references/fetch-network/ledger/active-networks) configuration. For the **Dorado testnet**, the faucet is available within the [block explorer ↗️](https://explore-dorado.fetch.ai/) homepage.
+ 2. Within the block explorer homepage, press the **Get Funds** button.
+ 3. Paste the address you wish to top-up in the pop-up window and then press **Add Funds**.
+ 4. Then, you can return to your address page, via the person icon, and should be able to see that you have been allocated **1 TESTFET** token.
+
+
+ The tokens provided by a faucet do not have any real-world market value. These tokens are specifically created for testing and development purposes within the blockchain's ecosystem. They are not intended for trading on cryptocurrency exchanges or for any commercial transactions. Therefore, while they have utility within the test network, they do not hold any value on the broader cryptocurrency market.
+
+
+## How to add funds to your wallet using faucet APIs
+
+You can also request and get testnet tokens in your wallet using the APIs, by running the following commands:
+
+### Get atestfet tokens
+
+ ```bash
+ curl -X POST -H 'Content-Type: application/json' -d '{"address":""}' https://faucet-dorado.fetch.ai/api/v3/claims
+ ```
+
+### Get nanomobx tokens
+
+ ```bash
+ curl -X POST -H 'Content-Type: application/json' -d '{"address":""}' https://faucet-mobx-dorado.fetch.ai/api/v3/claims
+ ```
+
+### Get ulrn tokens
+
+ ```bash
+ curl -X POST -H 'Content-Type: application/json' -d '{"address":""}' https://faucet-lrn-dorado.fetch.ai/api/v3/claims
+ ```
+
+### Sample response for fund request to faucet
+
+ ```text
+ {"status":"ok","uuid":"","target":""}
+ ```
+
+### Check the wallet balance
+
+If you want to check your wallet balance, you need to run the following command:
+
+ ```bash
+ fetchd query bank balances
+ ```
+
+The output would be:
+
+ ```text
+ balances:
+ - amount: ""
+ denom: atestfet
+ pagination:
+ next_key: null
+ total: "0"
+ ```
diff --git a/pages/guides/fetch-network/ledger/governance.mdx b/pages/guides/fetch-network/ledger/governance.mdx
new file mode 100644
index 000000000..ab1359fe7
--- /dev/null
+++ b/pages/guides/fetch-network/ledger/governance.mdx
@@ -0,0 +1,119 @@
+import { Callout } from 'nextra/components'
+
+# Governance
+
+## Introduction
+
+**Governance** is the mechanisms through which participants collectively make decisions about the rules, parameters, and policies that govern a given network. This can include things like protocol upgrades, parameter adjustments, and even more fundamental decisions about the network's direction and purpose. Changes are requested through **governance proposals* which represent formal suggestions or requests put forth by a member or participant of a network or community to make changes to that network. These proposals are typically submitted to a decentralized governance system, where participants in the network have the opportunity to review, discuss, and ultimately vote on the proposed changes.
+
+The approval process and the required majority for a proposal to pass can vary depending on the specific governance model of the network. Once a proposal is approved, the changes outlined in the proposal are typically implemented according to the network's governance mechanisms. This could involve deploying new smart contracts, updating software, or making adjustments to on-chain parameters.
+
+## How to take part in the governance mechanism
+
+If you wish to take part in governance, you will either need to be running a **full validator node** or you need to **have delegated stake to an existing validator**.
+
+For additional information, visit the [validators ↗️](/concepts/fetch-network/ledger/validators) section of our documentation, or the [delegation ↗️](/guides/fetch-network/ledger/cli/delegator#how-to-delegate-tokens) guide.
+
+## Stake delegation
+
+If you want to delegate your stake to a validator, the following CLI command should be used:
+
+ ```bash
+ fetchd tx staking delegate --from
+ ```
+
+ where the `` begins with the prefix `fetchvaloper1...` and the `` field contains the currency denomination.
+
+For instance:
+
+ ```bash
+ fetchd tx staking delegate fetchvaloper1cct4fhhksplu9m9wjljuthjqhjj93z0s97p3g7 1000atestfet --from agent
+ ```
+
+Check out our [delegation ↗️](/guides/fetch-network/ledger/cli/delegator#how-to-delegate-tokens) guide for further information on how to delegate your tokens to a validator using the CLI.
+
+## Proposals overview
+
+There are **three types** of governance proposal:
+
+ 1. **Text proposals**: these are the most basic type of proposal. They can be used to get the opinion from participants of the network on a given topic.
+
+ 2. **Parameter proposals**: these proposals are used to update the value of an existing software parameter of the network.
+
+ 3. **Software upgrade proposals**: these are used to propose an upgrade of the `fetchd` software, particularly in cases where the software changes might not necessary be backwards compatible or in some way present a major update to the network.
+
+## The proposal process
+
+**Any FET holder can submit a proposal**.
+
+In order for the proposal to be open for voting, it needs to come with a deposit that is greater than a parameter called _minDeposit_. The deposit need not be provided in its entirety by the submitter. If the initial proposer's deposit is not sufficient, the proposal enters the **deposit period** status. Then, any FET holder can increase the deposit by sending a _depositTx_ transaction to the network.
+
+Once the deposit reaches _minDeposit_, the proposal enters the **voting period**, which lasts 2 weeks. Any bonded FET holder can then cast a vote on this proposal, by choosing one of the following options for voting:
+
+ * Yes.
+ * No.
+ * NoWithVeto.
+ * Abstain.
+
+At the end of the voting period, the proposal is accepted if there are **more than 50% Yes votes** (excluding Abstain votes) and **less than 33.33% of NoWithVeto votes** (excluding Abstain votes).
+
+## Generating proposals
+
+When creating a proposal, you will create a proposal **JSON file** with all the relevant information.
+
+An example of a **text proposal** is shown below:
+
+ ```json
+ {
+ "title": "Switch to semantic commit messages for fetchd",
+ "description": "This proposal is advocating a switch to sematic commit messages. You can find the full discussion at: https://github.com/fetchai/fetchd/issues/231",
+ "type": "Text",
+ "deposit": "10000000000000000000atestfet"
+ }
+ ```
+
+
+ It is always recommended that the description of a text proposal has a link to a Github issue with the full proposal text along with the discussions about it.
+
+
+After having created the JSON file, you can **generate the text proposal on chain** by running the following command:
+
+ `fetchd tx gov submit-proposal --proposal proposal.json --from `
+
+## Increasing the deposit for a proposal
+
+If you want to **increase the deposit of a proposal**, you could do this by running the following command:
+
+ `fetchd tx gov deposit 100atestfet --from `
+
+For instance:
+
+ `fetchd tx gov deposit 2 100atestfet --from validator`
+
+If you want to get the **proposalID**, you will need to use the **txhash** obtained when the proposal was submitted and run the following command:
+
+ `fetchd query tx `
+
+For additional information on how to create a governance proposal using CLI, have a look at our [dedicated guide ↗️](/guides/fetch-network/ledger/cli/governance-proposals).
+
+## Listing current proposals
+
+Current proposals can be retrieved by using the **CLI** or from the **block explorer**.
+
+If you wish to **get the list of current proposals** and their corresponding **proposal-ids**, then you need to run the following command:
+
+ `fetchd query gov proposals`
+
+## Voting on a proposal
+
+If you want to **vote for a proposal**, run the following command:
+
+ `fetchd tx gov vote