From ccecfb618a44bc41c702ea2c2f2ddc13e998166a Mon Sep 17 00:00:00 2001 From: Felix Nicolae Bucsa Date: Fri, 22 Sep 2023 15:01:18 +0100 Subject: [PATCH] edits: reviewed content and made edits --- components/products.tsx | 2 +- pages/concepts.mdx | 11 -- .../concepts/fetch-network/ledger/_meta.json | 1 - .../fetch-network/ledger/block-explorer.mdx | 27 ----- pages/concepts/fetch-network/ledger/intro.mdx | 10 +- .../fetch-network/ledger/validators.mdx | 4 +- pages/guides.mdx | 16 ++- pages/guides/fetch-network/ledger/_meta.json | 5 +- .../fetch-network/ledger/block-explorer.mdx | 42 ++++++++ .../fetch-network/ledger/cli/_meta.json | 2 +- .../fetch-network/ledger/cli/delegator.mdx | 102 +++++++++++++----- .../ledger/cli/governance-proposals.mdx | 8 +- .../guides/fetch-network/ledger/cli/intro.mdx | 2 +- .../fetch-network/ledger/cli/tokens.mdx | 4 +- pages/guides/fetch-network/ledger/faucet.mdx | 20 ++-- .../fetch-network/ledger/governance.mdx | 28 +++-- .../fetch-network/ledger/installation.mdx | 2 +- .../fetch-network/ledger/joining-testnet.mdx | 6 +- .../ledger/setup-validator-node.mdx | 4 +- .../ledger/single-node-testnet.mdx | 15 ++- .../guides/fetch-network/ledger/snapshots.mdx | 4 +- .../fetch-network/ledger/state-sync.mdx | 2 +- pages/references.mdx | 16 +-- .../references/fetch-network/ledger/index.mdx | 42 ++++---- 24 files changed, 226 insertions(+), 149 deletions(-) delete mode 100644 pages/concepts/fetch-network/ledger/block-explorer.mdx create mode 100644 pages/guides/fetch-network/ledger/block-explorer.mdx diff --git a/components/products.tsx b/components/products.tsx index 5f346fa29..2b6abb424 100644 --- a/components/products.tsx +++ b/components/products.tsx @@ -220,7 +220,7 @@ const items: { [key: string]: Item[] } = { title: "Ledger", description: <>Get started with the Fetch Ledger., icon: ledgerIcon, - path: "/concepts/ledger/intro", + path: "/concepts/fetch-network/ledger/intro", }, ], }; diff --git a/pages/concepts.mdx b/pages/concepts.mdx index ac2accbd6..8341da99e 100644 --- a/pages/concepts.mdx +++ b/pages/concepts.mdx @@ -140,17 +140,6 @@ import { GuideBox } from "../components/feature-guide-tabs"; }} /> - - - - - - The transaction format includes a memo field that can be used to check the transaction information on the ledger nano display. - - -## Delegating stake to a validator - -You can delegate your test-net tokens to a validator who is operating the network by clicking on the **Validators** tab, and selecting one of the validators that you wish to delegate stake towards. In the **Voting Power** panel there is an option to **DELEGATE** tokens. Pressing this button will trigger a pop-up that prompts you to select a delegation amount and then sign the transaction with your Ledger Nano device. - -Upon delegating tokens, buttons labeled **REDELEGATE** and **UNDELEGATE** will appear. Delegating tokens to a validator rewards you for helping to secure the network. If you wish to delegate to a different validator, you can do so through a **REDELEGATE** transaction. You can retrieve any bonded tokens to your address by submitting an **UNDELEGATE** request, which will return the tokens after a 21-day waiting period. The rewards you receive from delegating tokens to a validator are displayed on your account page and can be sent to your address through a **WITHDRAW** transaction. diff --git a/pages/concepts/fetch-network/ledger/intro.mdx b/pages/concepts/fetch-network/ledger/intro.mdx index 05572e01e..ca0083099 100644 --- a/pages/concepts/fetch-network/ledger/intro.mdx +++ b/pages/concepts/fetch-network/ledger/intro.mdx @@ -4,15 +4,17 @@ import { Callout } from 'nextra/components' ## Introduction 🚀 -The fetchhub mainnet forms the core of the Fetch.ai ecosystem. In these pages, you will find all information to setup your client and connect on the [network ↗ī¸](/concepts/ledger/active-networks) and [CLI introduction ↗ī¸](/guides/ledger/cli/intro) pages. +The Fetch Ledger is the blockchain network developed by Fetch.ai and which 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. 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 like [multi-signature keys ↗ī¸](/guides/fetch-network/ledger/cli/multisig-keys), allowing users to control [keys ↗ī¸](/guides/fetch-network/ledger/cli/keys) in different configurations. -This documentation covers some of the things you need to know in order to prepare for and develop on this network. +The fetchhub mainnet forms the core of the Fetch.ai ecosystem. In these pages, you will find all information to setup your client and connect on the [network ↗ī¸](/references/fetch-network/ledger/active-networks). + +This documentation covers some of the things you need to know in order to prepare for and develop on the Fetch network. ## Test networks -The starting point for most will be [our test network ↗ī¸](/concepts/ledger/active-networks#test-nets), since it can provide you with test tokens with no value, that you can safely experiment with. +The starting point for most is [our test network ↗ī¸](/references/fetch-network/ledger/active-networks#test-nets), since it can provide you with test tokens with no value, that you can safely experiment with through the [faucet ↗ī¸](/guides/fetch-network/ledger/faucet). -Head over the [Command Line client ↗ī¸](/guides/ledger/cli/intro) section for guidance on how to install and configure the `fetchd` client. +Head over to the [Command Line Interface (CLI) client ↗ī¸](/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. 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 index 9a6b77070..5d1f32748 100644 --- a/pages/concepts/fetch-network/ledger/validators.mdx +++ b/pages/concepts/fetch-network/ledger/validators.mdx @@ -28,13 +28,13 @@ In this context, the Fetch.ai Ledger relies on a set of validators that are resp 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. -### Testnet vs Mainnet +### 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's the live version of the blockchain. + - **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. diff --git a/pages/guides.mdx b/pages/guides.mdx index d86471c75..bb83359d1 100644 --- a/pages/guides.mdx +++ b/pages/guides.mdx @@ -395,6 +395,14 @@ import { GuideBox } from "../components/feature-guide-tabs"; + + + + + - - - + The transaction format includes a memo field that can be used to check the transaction information on the ledger nano display. + + +## Delegating stake to a validator + +Within the block explorer landing page, you can delegate your tokens to a validator which is operating on the network by clicking on the **Validators** tab, and selecting one of the validators that you wish to delegate stake towards. By clicking on a validator name, you will be redirected towards that validator's details. + +For more information on how to delegate tokens to validators, visit our [guide ↗ī¸](/guides/fetch-network/ledger/cli/delegator). diff --git a/pages/guides/fetch-network/ledger/cli/_meta.json b/pages/guides/fetch-network/ledger/cli/_meta.json index c34b97bf4..85a173af8 100644 --- a/pages/guides/fetch-network/ledger/cli/_meta.json +++ b/pages/guides/fetch-network/ledger/cli/_meta.json @@ -3,6 +3,6 @@ "keys": "CLI - Managing keys \uD83D\uDD11", "tokens": "CLI - Managing tokens", "multisig-keys": "CLI - Multisig keys", - "delegator": "CLI - Delegator guide", + "delegator": "CLI - Delegation", "governance-proposals": "Governance proposals \uD83D\uDCDD" } diff --git a/pages/guides/fetch-network/ledger/cli/delegator.mdx b/pages/guides/fetch-network/ledger/cli/delegator.mdx index bda08a6ea..2d8f4537b 100644 --- a/pages/guides/fetch-network/ledger/cli/delegator.mdx +++ b/pages/guides/fetch-network/ledger/cli/delegator.mdx @@ -1,18 +1,22 @@ import { Callout } from 'nextra/components' -# CLI - Delegator guide +# CLI - Delegation -## Querying the state +Delegations refers to the act of assigning the responsibility of validating transactions and creating new blocks to a specific validator node. Below you can find different operations executable through the [CLI ↗ī¸](/guides/fetch-network/ledger/cli/intro). -### How to query the current staking holdings of validators +## How to query the current staking holdings of validators -The following command can be used to retrieve the current staking holdings of all validators: +You can query the current staking holdings of validators using the `fetchd`command-line interface, and run the following command: ```bash fetchd query staking validators ``` -On `dorado` test network, this will produce an output similar to the following, describing the status of all the existing validators: +This command will provide information about all the existing validators in the network, including details such as their operator address, consensus public key, status, tokens staked, commission rates, and more. + +The output will be a list of validators, each represented in a block of information, similar to the example you provided earlier. This information gives an overview of each validator's status and staked tokens. + +On `dorado` test network, this command will produce an output similar to the following: ```text - | @@ -64,12 +68,20 @@ On `dorado` test network, this will produce an output similar to the following, ... ``` -If you want to obtain the same information for a **single validator**, use the following command, by providing the `operatoraddress` of the validator: +Similarly, if you wish to retrieve the same information but now for a **single validator**, use the following command, by providing the `operator_address` of the specific validator: + + ```bash + fetchd query staking validator operator_address + ``` + +For instance: ```bash fetchd query staking validator fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w ``` +This command will provide detailed information about the specific validator, including their commission rates, minimum self-delegation, and other relevant details. + A delegator will be particularly interested in the following keys: - `commission/commission_rates/rate`: the commission rate on revenue charged to any delegator by the validator. @@ -79,13 +91,21 @@ A delegator will be particularly interested in the following keys: ### How to query the delegations made to a validator -From a validator address, we can **retrieve the list of delegations** it received: +You can **query the list of delegations made to a specific validator** using the `fetchd` command-line interface, and run the following command: ```bash fetchd query staking delegations-to fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w ``` -Below is a sample of delegations `validator2` received on `dorado`: +Here, replace `VALIDATOR_OPERATOR_ADDRESS` with the actual operator address of the validator you are interested in. For instance: + + ```bash + fetchd query staking delegations-to VALIDATOR_OPERATOR_ADDRESS + ``` + +This command will provide information about the delegations made to the specified validator, including details such as the delegator's address, the validator's address, and the amount of shares and tokens delegated. + +Below, you can find an example of delegations to `validator2` received on `dorado` testnet: ```text - delegation: @@ -104,17 +124,27 @@ Below is a sample of delegations `validator2` received on `dorado`: amount: "100000" ``` -### How to query the re-delegations +This output shows two delegations made to the validator, along with the delegator's address, the validator's address, the number of shares, and the amount of tokens delegated. + +### How to query re-delegations + +Re-delegation is the process of transferring already delegated tokens from one validator to another. This allows participants to change their delegation strategy without having to unbond and wait for the unbonding period to complete. + +Delegators can choose to re-delegate the tokens they already delegated from one validator to another at any time. Re-delegation takes effect immediately, without any waiting period. However, the tokens can not be re-delegated until the initial re-delegation transaction has completed its 21 day completion time. The unlocking time is indicated by the `redelegationentry/completion_time` field in the outputs below. -Delegators can choose to re-delegate the tokens they already delegated from one validator to another. Re-delegation takes effect immediately, without any waiting period. However, the tokens ca not be re-delegated until the initial re-delegation transaction has completed its 21 day completion time (the unlocking time is indicated by the `redelegationentry/completion_time` field in the outputs below). +You can **query the list of re-delegations made from a validator** by using the `fetchd` command-line interface and run the following command: -To obtain the list of re-delegations made from a validator, use the following command: + ```bash + fetchd query staking redelegations-from VALIDATOR_OPERATOR_ADDRESS + ``` + +Replace `VALIDATOR_OPERATOR_ADDRESS` with the actual operator address of the validator you are interested in. For instance: ```bash fetchd query staking redelegations-from fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w ``` -This produces an output similar to the following, where delegator `fetch15fn3meky8ktfry3qm73xkpjckzw4dazxpfx34m` issued 2 re-delegations from `fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w` to `fetchvaloper122veneudkzyalay6gusvrhhpp0560mparpanvu`: +This command will provide information about the re-delegations made from the specified validator, including details such as the delegator's address, the source validator's address, the destination validator's address, and information about the re-delegation entries. The output will be a list of re-delegations, each represented in a block of information. Below you can find an example output: ```text fetchd query staking redelegations-from fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w @@ -138,23 +168,31 @@ This produces an output similar to the following, where delegator `fetch15fn3mek balance: "10000" ``` -Similarly, the list of re-delegations issued by a delegator can be obtained with the following command: +Here, delegator `fetch15fn3meky8ktfry3qm73xkpjckzw4dazxpfx34m` issued 2 re-delegations from `fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w` to `fetchvaloper122veneudkzyalay6gusvrhhpp0560mparpanvu`: + +Similarly, you can obtain the list of re-delegations issued by a delegator by running the following command: ```bash fetchd query staking redelegations fetch15fn3meky8ktfry3qm73xkpjckzw4dazxpfx34m ``` -### How to query the user rewards +### How to query rewards -After having delegated some tokens to a validator, the user is eligible to a share of the rewards the validator collects. +Once you have delegated tokens to a validator, you will be eligible to a share of the rewards the validator collects. + +If you wish to **retrieve all the outstanding rewards for a specific address**, run the following command using the `fetchd` command-line interface, : + + ```bash + fetchd query distribution rewards DELEGATOR_ADDRESS + ``` -If you wish to **retrieve all the outstanding rewards for an address**, run the following command: +You will need to replace `DELEGATOR_ADDRESS` with the actual address of the delegator whose rewards you want to query. For instance: ```bash fetchd query distribution rewards fetch15fn3meky8ktfry3qm73xkpjckzw4dazxpfx34m ``` -This will produce the following output, in which the address has delegated tokens to 2 validators on `dorado` test network: +This command will provide information about the rewards earned by the specified delegator, including details such as the validator addresses and the amount of rewards in different denominations. The output will be a list of rewards, each represented in a block of information. Below you can find an example output: ```text rewards: @@ -171,13 +209,15 @@ This will produce the following output, in which the address has delegated token amount: "0.000000000001200000" ``` -You can also **filter rewards for a given validator**. For instance, you can filter rewards for `validator5` as shown below: +In this example, the delegator at `DELEGATOR_ADDRESS` has earned rewards from two different validators on `dorado` test network. The rewards are listed in different denominations, such as `atestfet`. + +You can also **filter rewards for a given validator**. For instance, you can filter rewards for `validator5` (`fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w`) as shown below: ```bash fetchd query distribution rewards fetch15fn3meky8ktfry3qm73xkpjckzw4dazxpfx34m fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w ``` -We now get the reward from this specific validator: +In the output, we get the rewards from this specific validator: ```text - denom: atestfet @@ -204,7 +244,7 @@ This will require a confirmation before issuing a transaction. After the transac **Re-delegating tokens allows you to transfer already delegated tokens from one validator to another**. -From the above example where we delegated `1000000 atestfet` to `fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w`, we can now re-delegate parts or all of those tokens to another validator. For instance, we re-delegate `400000 atestfet` from `fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w` to `fetchvaloper122veneudkzyalay6gusvrhhpp0560mparpanvu` by running the following command: +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 @@ -212,12 +252,12 @@ From the above example where we delegated `1000000 atestfet` to `fetchvaloper1z7 This will prompt for confirmation and issue a new transaction once accepted. -From here, inspecting the delegations from our account, we will see that our delegated tokens are now: +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` we redelegated 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). +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. @@ -225,25 +265,31 @@ Now, those `400000 atestfet` we redelegated can not be re-delegated anymore for ### How to unbond tokens -You can transfer parts or all of our delegated tokens back to our account at any time by running the following command: +**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 back to our account. Those tokens will then be available **after a 21 day period** (the exact date can be found by querying the redelegation transaction, under the `completion_time` key). +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, the following command can be used: +In order **to transfer rewards to the wallet**, run the following command: ```bash - fetchd tx distribution withdraw-rewards fetchvaloper1z72rph6l5j6ex83n4urputykawcqg6t98xul2w --from myKey + 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. +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: +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 diff --git a/pages/guides/fetch-network/ledger/cli/governance-proposals.mdx b/pages/guides/fetch-network/ledger/cli/governance-proposals.mdx index 20e41a20f..c724fcacd 100644 --- a/pages/guides/fetch-network/ledger/cli/governance-proposals.mdx +++ b/pages/guides/fetch-network/ledger/cli/governance-proposals.mdx @@ -1,6 +1,10 @@ # Governance proposals 📝 -**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. +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 @@ -40,7 +44,7 @@ The values within this code can be changed in order to alter the minimum deposit 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. +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: diff --git a/pages/guides/fetch-network/ledger/cli/intro.mdx b/pages/guides/fetch-network/ledger/cli/intro.mdx index 10df96d5c..6666c6349 100644 --- a/pages/guides/fetch-network/ledger/cli/intro.mdx +++ b/pages/guides/fetch-network/ledger/cli/intro.mdx @@ -1,6 +1,6 @@ # CLI - Introduction 🚀 -The Command Line 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. +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 diff --git a/pages/guides/fetch-network/ledger/cli/tokens.mdx b/pages/guides/fetch-network/ledger/cli/tokens.mdx index 6491b7196..82afbf450 100644 --- a/pages/guides/fetch-network/ledger/cli/tokens.mdx +++ b/pages/guides/fetch-network/ledger/cli/tokens.mdx @@ -2,7 +2,7 @@ ## How to query your balance -Once `fetchd` is configured for the desired [network ↗ī¸](/guides/ledger/cli/intro). The user can query their balance using the following command: +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 @@ -21,7 +21,7 @@ If the address exists on the network, then the user will expect to see an output ## 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/ledger/faucet) page for more information on how to add test tokens to your address. +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: diff --git a/pages/guides/fetch-network/ledger/faucet.mdx b/pages/guides/fetch-network/ledger/faucet.mdx index 970dc6bee..97310e9a3 100644 --- a/pages/guides/fetch-network/ledger/faucet.mdx +++ b/pages/guides/fetch-network/ledger/faucet.mdx @@ -1,32 +1,32 @@ -# How to use the token faucet +# How to use the token faucet 💰 ## Introduction -For our test networks, we have a simple token faucet implemented to allow users of the network to get started quickly. You can send it an account address, and it will transfer some test token on it. +A token faucet is a service or tool that provides free tokens or cryptocurrency 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. -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. +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 it an account address, and it will transfer some test tokens back to it. -The token faucet itself is available from the network block explorer (`GET FUNDS` button on the homepage). +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. -Enter your `fetch...` address in the popup and click **Add funds** button. Wait a few blocks for the transaction to be processed, and you should see it appear along with some funds on your account. +The token faucet itself is available from the network [block explorer](/guides/fetch-network/ledger/block-explorer) page by clicking on the **GET FUNDS** button available on the in the explorer homepage. By clicking on this button, you will be asked to enter your Fetch Account address (`fetch...`) in the pop-up window and click the **Add Funds** button afterwards. 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. -## Add funds to Wallet using faucet APIs +## How to add funds to wallet using faucet APIs -You can also request and get testnet tokens in your wallet using the APIs. +You can also request and get testnet tokens in your wallet using the APIs, by running the following commands: -### Get some atestfet +### Get atestfet ```bash curl -X POST -H 'Content-Type: application/json' -d '{"address":"
"}' https://faucet-dorado.fetch.ai/api/v3/claims ``` -### Get some nanomobx +### Get nanomobx ```bash curl -X POST -H 'Content-Type: application/json' -d '{"address":"
"}' https://faucet-mobx-dorado.fetch.ai/api/v3/claims ``` -### Get some ulrn +### Get ulrn ```bash curl -X POST -H 'Content-Type: application/json' -d '{"address":"
"}' https://faucet-lrn-dorado.fetch.ai/api/v3/claims diff --git a/pages/guides/fetch-network/ledger/governance.mdx b/pages/guides/fetch-network/ledger/governance.mdx index c7f01539a..0c6b45687 100644 --- a/pages/guides/fetch-network/ledger/governance.mdx +++ b/pages/guides/fetch-network/ledger/governance.mdx @@ -2,11 +2,21 @@ import { Callout } from 'nextra/components' # Governance -If you wish to take part in governance, you either need to be running a full validator node or you need to have have delegated stake to an existing validator. +## 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 the rules, parameters, or policies that govern 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 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 section ↗ī¸](/concepts/fetch-network/ledger/validators) of our documentation, or the [delegation ↗ī¸](/guides/fetch-network/ledger/cli/delegator#how-to-delegate-tokens) guide. ## Stake delegation -If you want to delegate stake to a validator the following command should be used: +If you want to delegate stake to a validator, the following command should be used: ```bash fetchd tx staking delegate --from @@ -20,9 +30,11 @@ For instance: fetchd tx staking delegate fetchvaloper1cct4fhhksplu9m9wjljuthjqhjj93z0s97p3g7 1000atestfet --from agent ``` +Have a look at 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 proposal: +There are **three types** of 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. @@ -72,17 +84,19 @@ If a user wants to **increase the deposit of a proposal**, they would run the fo `fetchd tx gov deposit 100atestfet --from ` -For example: +For instance: `fetchd tx gov deposit 2 100atestfet --from validator` -To get the **proposalID**, use the **txhash** obtained when the proposal was submitted and run the following command: +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 [guide ↗ī¸](/guides/fetch-network/ledger/cli/governance-proposals). + ## Listing current proposals -Current proposals are visible from the block explorer and using the CLI. +Current proposals can be retrieved by using the CLI or from the [block explorer ↗ī¸](/guides/fetch-network/ledger/block-explorer). If you wish to **get the list of current proposals** and their corresponding _proposal-ids_, then run the following command: @@ -99,5 +113,5 @@ For instance: `fetchd tx gov vote 5 yes --from validator` - When using CLI commands make sure that your CLI is pointing at the correct network. See the [CLI introduction ↗ī¸](/guides/ledger/cli/intro) in our documentation for more details. + When using CLI commands make sure that your CLI is pointing at the correct network. See the [CLI introduction ↗ī¸](/guides/fetch-network/ledger/cli/intro) in our documentation for more details. diff --git a/pages/guides/fetch-network/ledger/installation.mdx b/pages/guides/fetch-network/ledger/installation.mdx index 30611dac5..bcec8f72a 100644 --- a/pages/guides/fetch-network/ledger/installation.mdx +++ b/pages/guides/fetch-network/ledger/installation.mdx @@ -59,7 +59,7 @@ You can also **verify that you are running the correct version** by running the fetchd version ``` -This should print a version number that must be compatible with the network you're connecting to. See the [network page ↗ī¸](/references/ledger/active-networks) for the list of supported versions per network. +This should print a version number that must be compatible with the network you're connecting to. See the [network page ↗ī¸](/references/fetch-network/ledger/active-networks) for the list of supported versions per network. ### FAQ diff --git a/pages/guides/fetch-network/ledger/joining-testnet.mdx b/pages/guides/fetch-network/ledger/joining-testnet.mdx index e48847fe4..748b17e2c 100644 --- a/pages/guides/fetch-network/ledger/joining-testnet.mdx +++ b/pages/guides/fetch-network/ledger/joining-testnet.mdx @@ -6,7 +6,7 @@ In order to join the test network, you will need to have the **correct version o ## Using a local version -if you have correctly followed the [installation guide ↗ī¸](/guides/ledger/installation), then you should now have `fetchd` successfully installed in your path. +if you have correctly followed the [installation guide ↗ī¸](/guides/fetch-network/ledger/installation), then you should now have `fetchd` successfully installed in your path. You can check this with the following command: @@ -16,7 +16,7 @@ You can check this with the following command: **This should print a version number that must be compatible with the network you are connecting to**. -Check the [network page ↗ī¸](/references/ledger/active-networks) for the list of supported versions per network. +Check the [network page ↗ī¸](/references/fetch-network/ledger/active-networks) for the list of supported versions per network. ### Configuring the client fetchd @@ -90,7 +90,7 @@ If you wish to connect to the **Dorado testnet** for example, you would need to fetchd start --p2p.seeds=eb9b9717975b49a57e62ea93aa4480e091ae0660@connect-dorado.fetch.ai:36556,46d2f86a255ece3daf244e2ca11d5be0f16cb633@connect-dorado.fetch.ai:36557,066fc564979b1f3173615f101b62448ac7e00eb1@connect-dorado.fetch.ai:36558 ``` -4. Your local node will now synchronize with the network, replaying all blocks and transactions. This process may take some time depending on factors like the network's age and your disk speed. Consider using [chain snapshots ↗ī¸](../snapshots/) to speed up this process. +4. Your local node will now synchronize with the network, replaying all blocks and transactions. This process may take some time depending on factors like the network's age and your disk speed. Consider using [chain snapshots ↗ī¸](/guides/fetch-network/ledger/snapshots) to speed up this process. 5. You can query your node's status from its RPC API to know when it has finished syncing by running: diff --git a/pages/guides/fetch-network/ledger/setup-validator-node.mdx b/pages/guides/fetch-network/ledger/setup-validator-node.mdx index 097e6cd3c..ab736db7f 100644 --- a/pages/guides/fetch-network/ledger/setup-validator-node.mdx +++ b/pages/guides/fetch-network/ledger/setup-validator-node.mdx @@ -4,8 +4,8 @@ You need to have: - - [installed ↗ī¸](/guides/ledger/installation) fetchd. - - Configured and [connected ↗ī¸](/guides/ledger/joining-testnet) your validator to the desired network. + - [installed ↗ī¸](/guides/fetch-network/ledger/installation) fetchd. + - Configured and [connected ↗ī¸](/guides/fetch-network/ledger/joining-testnet) your validator to the desired network. ## Creating a validator diff --git a/pages/guides/fetch-network/ledger/single-node-testnet.mdx b/pages/guides/fetch-network/ledger/single-node-testnet.mdx index cde30ff44..b4a833be4 100644 --- a/pages/guides/fetch-network/ledger/single-node-testnet.mdx +++ b/pages/guides/fetch-network/ledger/single-node-testnet.mdx @@ -11,9 +11,9 @@ testing. This document will outline the steps required in order to configure a ` These steps only need to be done once in order to setup the local network. -1. Build the ledger from source. Follow the [installation instructions ↗ī¸](/guides/ledger/installation) in order to compile the latest version of the ledger. +1. Build the ledger from source. Follow the [installation ↗ī¸](/guides/fetch-network/ledger/installation) instructions in order to compile the latest version of the Ledger. -2. Remove any existing networks. Since we are starting a new network, we need to remove any local files that we have in our system from a previous network +2. Remove any existing networks. Since we are starting a new network, we need to remove any local files that we have in our system from a previous network: `rm -Rf ~/.fetchd` @@ -22,8 +22,8 @@ testing. This document will outline the steps required in order to configure a ` `fetchd init --chain-id localnet-1 my-local-node-name` - * `localnet-1` is the chain id - * `my-local-node-name` is the moniker for the node + - `localnet-1` is the chain id + - `my-local-node-name` is the moniker for the node If you want to make any updates to the genesis, it is a good opportunity to make these updates now. @@ -33,10 +33,10 @@ testing. This document will outline the steps required in order to configure a ` `fetchd keys add validator` - * `validator` is the name of the key in the keyring + - `validator` is the name of the key in the keyring - For more informationm checkout the complete [documentation on keys ↗ī¸](/guides/ledger/cli/keys). + For more informationm checkout the complete documentation on [keys ↗ī¸](/guides/fetch-network/ledger/cli/keys). 5. Adding the validator to the network. To set the initial state for the network, use the following command which allocates `100000000000000000000` `stake` tokens to the validator which can be bonded: @@ -56,8 +56,7 @@ testing. This document will outline the steps required in order to configure a ` `fetchd collect-gentxs` - After running this command, the network will be successfully configured and you have computed the final genesis configuration - for the network. + After running this command, the network will be successfully configured and you have computed the final genesis configuration for the network. ## Running the local node diff --git a/pages/guides/fetch-network/ledger/snapshots.mdx b/pages/guides/fetch-network/ledger/snapshots.mdx index bbf18724f..99b667a7c 100644 --- a/pages/guides/fetch-network/ledger/snapshots.mdx +++ b/pages/guides/fetch-network/ledger/snapshots.mdx @@ -6,7 +6,7 @@ As blockchains get longer, the process of syncing from the genesis block begins In circumstances where a faster sync is required, various snapshots of the fetchd chain state data are available for download, to more quickly bootstrap a node. -Snapshots are available for both mainnet and the most recent testnet. The URLs can be obtained from the [active network page ↗ī¸](/references/ledger/active-networks). +Snapshots are available for both mainnet and the most recent testnet. The URLs can be obtained from the [active network page ↗ī¸](/references/fetch-network/ledger/active-networks). **We aim to update snapshots on a daily basis**. @@ -20,7 +20,7 @@ If you are already running fetchd, it is important that you stop it before proce Instructions for this are highly installation dependent and beyond the scope of this document, but could be as simple as a Ctrl-C. -If you have not already initialised your node, follow the instructions for [joining a testnet ↗ī¸](/guides/ledger/joining-testnet) then return to this page before starting fetchd. **Remember to modify the information for the mainnet as appropriate**. +If you have not already initialised your node, follow the instructions for [joining a testnet ↗ī¸](/guides/fetch-network/ledger/joining-testnet) then return to this page before starting fetchd. **Remember to modify the information for the mainnet as appropriate**. ### Reset your node diff --git a/pages/guides/fetch-network/ledger/state-sync.mdx b/pages/guides/fetch-network/ledger/state-sync.mdx index cb829bd2c..9d257c73e 100644 --- a/pages/guides/fetch-network/ledger/state-sync.mdx +++ b/pages/guides/fetch-network/ledger/state-sync.mdx @@ -5,7 +5,7 @@ import { Callout } from 'nextra/components' **State sync** is a feature which allows you to quickly bootstrap a new node by allowing it to pull a _state snapshot_ taken by other nodes. - The state sync feature is only available from `fetchd v0.10.6` and later. Prior versions needed to either sync from scratch or restore a [chain snapshot ↗ī¸](/guides/ledger/snapshots), which both could take hours before having the node fully synced. + The state sync feature is only available from `fetchd v0.10.6` and later. Prior versions needed to either sync from scratch or restore a [chain snapshot ↗ī¸](/guides/fetch-network/ledger/snapshots), which both could take hours before having the node fully synced. With state sync, it now takes only a few minutes before having an operational node. diff --git a/pages/references.mdx b/pages/references.mdx index 29d81c773..69ef2ed9a 100644 --- a/pages/references.mdx +++ b/pages/references.mdx @@ -79,7 +79,7 @@ import { GuideBox } from "../components/feature-guide-tabs"; content={{ title: "Versions", description: "Explore the Ledger versions released over time.", - path: "/references/ledger/versions" + path: "/references/fetch-network/ledger/versions" }} /> @@ -87,7 +87,7 @@ import { GuideBox } from "../components/feature-guide-tabs"; content={{ title: "Active networks", description: "Explore the list of active networks and their specifications.", - path: "/references/ledger/active-networks" + path: "/references/fetch-network/ledger/active-networks" }} /> @@ -98,7 +98,7 @@ import { GuideBox } from "../components/feature-guide-tabs"; content={{ title: "Mainnet archives 🗄", description: "Explore the list of Mainnet network versions", - path: "/references/ledger/mainnet-archive" + path: "/references/fetch-network/ledger/mainnet-archive" }} /> @@ -106,7 +106,7 @@ import { GuideBox } from "../components/feature-guide-tabs"; content={{ title: "Validator security", description: "Discover the concept of security involving validators and their objectives.", - path: "/references/ledger/security" + path: "/references/fetch-network/ledger/security" }} /> @@ -124,7 +124,7 @@ Explore how to index and query blockchain data efficiently using the SubQuery in content={{ title: "Endpoints / Playground UIs", description: "The graphql API endpoints serve a playground UI to browsers for convenience.", - path: "/references/indexer/endpoints" + path: "/references/fetch-network/indexer/endpoints" }} /> @@ -132,7 +132,7 @@ Explore how to index and query blockchain data efficiently using the SubQuery in content={{ title: "Querying", description: "Understand how the GraphQL API works in conjunction with Postgraphile and its plugins for resolving different GraphQL requests.", - path: "/references/indexer/querying" + path: "/references/fetch-network/indexer/querying" }} /> @@ -143,7 +143,7 @@ Explore how to index and query blockchain data efficiently using the SubQuery in content={{ title: "Versioning", description: "Discover how to retrieve the versions of both the GraphQL API and the Indexer.", - path: "/references/indexer/versioning" + path: "/references/fetch-network/indexer/versioning" }} /> @@ -152,7 +152,7 @@ Explore how to index and query blockchain data efficiently using the SubQuery in content={{ title: "Entities", description: "Entities are fundamental units of information that represent distinct objects or concepts, each with its own set of attributes.", - path: "/references/indexer/entities" + path: "/references/fetch-network/indexer/entities" }} /> diff --git a/pages/references/fetch-network/ledger/index.mdx b/pages/references/fetch-network/ledger/index.mdx index b9820de93..5d5d4b4e3 100644 --- a/pages/references/fetch-network/ledger/index.mdx +++ b/pages/references/fetch-network/ledger/index.mdx @@ -2,34 +2,34 @@ **Introduction**: -- [Introduction 🚀 ↗ī¸](/concepts/ledger/intro) -- [Block explorers 🔎 ↗ī¸](/concepts/ledger/block-explorer) -- [Validators ↗ī¸](/concepts/ledger/validators) +- [Introduction 🚀 ↗ī¸](/concepts/fetch-network/ledger/intro) +- [Validators ↗ī¸](/concepts/fetch-network/ledger/validators) **Resources**: -- [Versions ↗ī¸](/references/ledger/versions) -- [Active networks ↗ī¸](/references/ledger/active-networks) -- [Mainnet archives 🗄 ↗ī¸](/references/ledger/mainnet-archive) -- [Validator security ↗ī¸](/references/ledger/security) +- [Versions ↗ī¸](/references/fetch-network/ledger/versions) +- [Active networks ↗ī¸](/references/fetch-network/ledger/active-networks) +- [Mainnet archives 🗄 ↗ī¸](/references/fetch-network/ledger/mainnet-archive) +- [Validator security ↗ī¸](/references/fetch-network/ledger/security) **Guides**: -- [Installation 🛠 ↗ī¸](/guides/ledger/installation) -- [How to use chain state snapshots 📸 ↗ī¸](/guides/ledger/snapshots) -- [State-sync ↗ī¸](/guides/ledger/state-sync) -- [How to set up a validator node 🌐 ↗ī¸](/guides/ledger/setup-validator-node) -- [How to join a testnet ↗ī¸](/guides/ledger/joining-testnet) -- [How to run a single node network ↗ī¸](/guides/ledger/single-node-testnet) -- [Governance ↗ī¸](/guides/ledger/governance) -- [How to use the token faucet ↗ī¸](/guides/ledger/faucet) +- [Installation 🛠 ↗ī¸](/guides/fetch-network/ledger/installation) +- [How to use chain state snapshots 📸 ↗ī¸](/guides/fetch-network/ledger/snapshots) +- [State-sync ↗ī¸](/guides/fetch-network/ledger/state-sync) +- [How to use the block explorer 🔎 ↗ī¸](/GUIDES/fetch-network/ledger/block-explorer) +- [How to set up a validator node 🌐 ↗ī¸](/guides/fetch-network/ledger/setup-validator-node) +- [How to join a testnet ↗ī¸](/guides/fetch-network/ledger/joining-testnet) +- [How to run a single node network ↗ī¸](/guides/fetch-network/ledger/single-node-testnet) +- [Governance ↗ī¸](/guides/fetch-network/ledger/governance) +- [How to use the token faucet 💰 ↗ī¸](/guides/fetch-network/ledger/faucet) ** Command Line client**: -- [CLI - Introduction 🚀 ↗ī¸](/guides/ledger/cli/intro) -- [CLI - Managing keys 🔑 ↗ī¸](/guides/ledger/cli/keys) -- [CLI - Managing tokens ↗ī¸](/guides/ledger/cli/tokens) -- [CLI - Multisig keys ↗ī¸](/guides/ledger/cli/multisig-keys) -- [CLI - Delegator guide ↗ī¸](/guides/ledger/cli/delegator) -- [Governance proposals 📝 ↗ī¸](/guides/ledger/cli/tokens) +- [CLI - Introduction 🚀 ↗ī¸](/guides/fetch-network/ledger/cli/intro) +- [CLI - Managing keys 🔑 ↗ī¸](/guides/fetch-network/ledger/cli/keys) +- [CLI - Managing tokens ↗ī¸](/guides/fetch-network/ledger/cli/tokens) +- [CLI - Multisig keys ↗ī¸](/guides/fetch-network/ledger/cli/multisig-keys) +- [CLI - Delegation ↗ī¸](/guides/fetch-network/ledger/cli/delegator) +- [Governance proposals 📝 ↗ī¸](/guides/fetch-network/ledger/cli/tokens)