Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ Once installed, `cheqd-node` can be controlled using the [cheqd Cosmos CLI guide

## 🛠 Developing & contributing to cheqd

`cheqd-node` is written in Go and built using Cosmos SDK. The [Cosmos SDK Developer Guide](https://docs.cosmos.network/main) explains a lot of the [basic concepts](https://docs.cosmos.network/main/basics/app-anatomy) of how the cheqd network functions.
`cheqd-node` is written in Go and built using Cosmos SDK. The [Cosmos SDK Developer Guide](https://docs.cosmos.network/sdk/v0.50/learn) explains a lot of the [basic concepts](https://docs.cosmos.network/sdk/v0.50/learn/beginner/app-anatomy) of how the cheqd network functions.

If you want to build a node from source or contribute to the code, please read our guide to [building and testing](docs/build-and-networks/README.md).

Expand Down
4 changes: 2 additions & 2 deletions architecture/adr-list/adr-002-mnemonic-keys-cosmos.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ For example, an identity wallet application or backend application would need to

### Assumptions / Considerations

Cosmos SDK uses [known algorithms for deriving private keys from mnemonics](https://docs.cosmos.network/main/learn/beginner/accounts#keyring). This can be replicated using standard crypto libraries to carry out the same steps as in Cosmos SDK:
Cosmos SDK uses [known algorithms for deriving private keys from mnemonics](https://docs.cosmos.network/sdk/v0.50/learn/beginner/accounts#keyring). This can be replicated using standard crypto libraries to carry out the same steps as in Cosmos SDK:

```text
rounds of iteration : 2048
Expand Down Expand Up @@ -64,4 +64,4 @@ N/A

## References

* [Cosmos SDK account generation and keyrings](https://docs.cosmos.network/main/learn/beginner/accounts)
* [Cosmos SDK account generation and keyrings](https://docs.cosmos.network/sdk/v0.50/learn/beginner/accounts)
2 changes: 1 addition & 1 deletion architecture/adr-list/adr-004-token-fractions.md
Original file line number Diff line number Diff line change
Expand Up @@ -58,4 +58,4 @@ It was decided to go with **10^-9** as the smallest fraction, with the whole num

## References

* [Cosmos ADR proposal to add coin metadata](https://docs.cosmos.network/main/build/architecture/adr-024-coin-metadata)
* [Cosmos ADR proposal to add coin metadata](https://docs.cosmos.network/sdk/v0.50/build/architecture/adr-024-coin-metadata)
6 changes: 3 additions & 3 deletions architecture/adr-list/adr-005-genesis-parameters.md
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ Tendermint requires [genesis parameters](https://docs.cometbft.com/v0.38/core/us

## Cosmos SDK module parameters

Cosmos application is divided [into a list of modules](https://docs.cosmos.network/main/modules). Each module has parameters that help to adjust the module's behaviour.
Cosmos application is divided [into a list of modules](https://docs.cosmos.network/sdk/latest/modules/modules). Each module has parameters that help to adjust the module's behaviour.

### `auth` module

Expand Down Expand Up @@ -80,7 +80,7 @@ Cosmos application is divided [into a list of modules](https://docs.cosmos.netwo

| Parameter | Description | Mainnet | Testnet |
| - | - | - | - |
| `constant_fee` | The fee is used to verify the [invariant(s)](https://docs.cosmos.network/main/build/building-modules/invariants) | 10,000,000,000,000 ncheq (10,000 CHEQ) | 10,000,000,000,000 ncheq (10,000 CHEQ) |
| `constant_fee` | The fee is used to verify the invariant(s) | 10,000,000,000,000 ncheq (10,000 CHEQ) | 10,000,000,000,000 ncheq (10,000 CHEQ) |

### `distribution` module

Expand Down Expand Up @@ -184,5 +184,5 @@ The parameters above were agreed separate the cheqd mainnet and testnet paramete

## References

* [List of Cosmos modules](https://docs.cosmos.network/main/modules)
* [List of Cosmos modules](https://docs.cosmos.network/sdk/latest/modules/modules)
* [Tendermint genesis parameters](https://docs.cometbft.com/v0.38/core/using-cometbft#genesis)
12 changes: 6 additions & 6 deletions architecture/adr-list/adr-006-community-tax.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,19 +15,19 @@ description: This is the suggested template to be used for ADRs on the cheqd-nod

## Summary

The aim of this ADR is to define how ["community tax" as described in the Cosmos blockchain framework](https://docs.cosmos.network/main/modules/distribution#the-distribution-scheme) will work on cheqd network.
The aim of this ADR is to define how ["community tax" as described in the Cosmos blockchain framework](https://docs.cosmos.network/sdk/latest/modules/distribution/README#the-distribution-scheme) will work on cheqd network.

## Context

### What is "community tax"?

`communityTax` is a value set in genesis for each Cosmos network and defined as a percentage that is applied to the fees collected in each block.

Tokens collected through this process accumulate in the **community pool**. The percentage charged as `communityTax` can be changed by [making proposals on the network and voting for acceptance](https://docs.cosmos.network/main/modules/gov) by the network.
Tokens collected through this process accumulate in the **community pool**. The percentage charged as `communityTax` can be changed by [making proposals on the network and voting for acceptance](https://docs.cosmos.network/sdk/latest/modules/gov/README#x-gov) by the network.

### Community tax collection

From [Cosmos SDK documentation, `distribution` module](https://docs.cosmos.network/main/modules/distribution#reward-to-the-community-pool):
From [Cosmos SDK documentation, `distribution` module](https://docs.cosmos.network/sdk/latest/modules/distribution/README#reward-to-the-community-pool):

> The community pool gets `community_tax * fees`, plus any remaining dust after validators get their rewards that are always rounded down to the nearest integer value.

Expand All @@ -46,7 +46,7 @@ To spend tokens from the **community pool**:
2. If proposal is approved using the voting process, the recipient address specified will receive the requested tokens.
3. The expectation on the recipient is that they spend the tokens for the purpose specified in their proposal.

More information about fee distribution is available in the [**End Block** section of Cosmos's `distribution` module](https://docs.cosmos.network/main/modules/distribution#the-distribution-scheme) documentation.
More information about fee distribution is available in the [**End Block** section of Cosmos's `distribution` module](https://docs.cosmos.network/sdk/latest/modules/distribution/README#the-distribution-scheme) documentation.

## Decision

Expand All @@ -73,5 +73,5 @@ More information about fee distribution is available in the [**End Block** secti

## References

* [Cosmos SDK `distribution` module parameters](https://docs.cosmos.network/main/modules/distribution#the-distribution-scheme)
* [Cosmos SDK `governance` module](https://docs.cosmos.network/main/modules/gov)
* [Cosmos SDK `distribution` module parameters](https://docs.cosmos.network/sdk/latest/modules/distribution/README#the-distribution-scheme)
* [Cosmos SDK `governance` module](https://docs.cosmos.network/sdk/latest/modules/gov/README#x-gov)
2 changes: 1 addition & 1 deletion docs/cheqd-cli/cheqd-cli-fee-abstraction.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ The equivalent IBC denomination amount is required to pay for transactions. **En
You can find out if you've got sufficient balance in supported IBC denominations using the following methods:

1. **Through Leap Wallet**
1. Ensure you have added the cheqd wallet you want to use for transactions to a supported desktop/mobile wallet. The recommended wallet app is [Leap Wallet](https://www.leapwallet.io/download). If you previously used Keplr Wallet, we recommend [migrating from Keplr Wallet to Leap Wallet](https://docs.cheqd.io/product/network/wallets/migrate) as it has better support for [looking up real-time gas prices](./cheqd-cli-token-transactions.md).
1. Ensure you have added the cheqd wallet you want to use for transactions to a supported desktop/mobile wallet. The recommended wallet app is [Leap Wallet](https://www.leapwallet.io). If you previously used Keplr Wallet, we recommend [migrating from Keplr Wallet to Leap Wallet](https://docs.cheqd.io/product/network/wallets/migrate) as it has better support for [looking up real-time gas prices](./cheqd-cli-token-transactions.md).
2. Once you've added the cheqd wallet account to Leap Wallet, use the network switcher to switch to **Osmosis**. This will allow you to see the balances you have on Osmosis chain, including native OSMO as well as any IBC denominations such as USDC.
2. **Sending tokens over IBC**
1. If you have an existing Osmosis account, you can send tokens over IBC to your cheqd account. This is done by sending the tokens from your Osmosis account to the address of your cheqd account. Use the `Swap` flow to send tokens over IBC. The tokens will be sent to the cheqd account and will be available for use in transactions. Otherwise, you can use the `cheqd-noded tx ibc-transfer transfer` command to send tokens over IBC from your Osmosis account to your cheqd account. The command will look like this:
Expand Down
2 changes: 1 addition & 1 deletion docs/cheqd-cli/cheqd-cli-key-management.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ Account addresses are on a cheqd node are an encoded version of a public key. Ea

To submit a transaction on behalf of an account, it must be signed with an account's private key.

Cosmos supports [multiple keyring backends](https://docs.cosmos.network/main/user/run-node/keyring) for the storage and management of keys. Each node operator is free to use the key management method they prefer.
Cosmos supports [multiple keyring backends](https://docs.cosmos.network/sdk/latest/node/keyring#setting-up-the-keyring) for the storage and management of keys. Each node operator is free to use the key management method they prefer.

By default, the `cheqd-noded` binary is configured to use the `os` keyring backend, as it is a safe default compared to file-based key management methods.

Expand Down
4 changes: 2 additions & 2 deletions docs/setup-and-configure/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ The interactive installer is written in **Python 3** and is designed to work on

### Software installed by installer

1. **Cosmovisor** (default, but can be skipped): The installer [configures Cosmovisor](https://docs.cosmos.network/main/tooling/cosmovisor) by default, which is a standard Cosmos SDK tool that makes network upgrades happen in an automated fashion. This makes the process of upgrading to new releases for network-wide upgrades easier.
1. **Cosmovisor** (default, but can be skipped): The installer [configures Cosmovisor](https://docs.cosmos.network/sdk/latest/guides/upgrades/cosmovisor#cosmovisor) by default, which is a standard Cosmos SDK tool that makes network upgrades happen in an automated fashion. This makes the process of upgrading to new releases for network-wide upgrades easier.
2. **`cheqd-noded` binary** (mandatory): This is the main piece of ledger-side code each node runs.
3. **Dependencies**: In case you request the installer to restore from a snapshot, dependencies such as `pv` will be installed so that a progress bar can be shown for snapshot extraction. Otherwise, no additional software is installed by the installer.

Expand Down Expand Up @@ -107,7 +107,7 @@ Select cheqd network to join:

#### 4. Choose Cosmovisor configuration options

The next few questions are used to configure Cosmovisor-related options. Read [an explanation of Cosmovisor configuration options in Cosmos SDK documentation](https://docs.cosmos.network/main/tooling/cosmovisor), or choose to install with the default settings.
The next few questions are used to configure Cosmovisor-related options. Read [an explanation of Cosmovisor configuration options in Cosmos SDK documentation](https://docs.cosmos.network/sdk/latest/guides/upgrades/cosmovisor#cosmovisor), or choose to install with the default settings.

1. `Install cheqd-noded using Cosmovisor? (yes/no) [default: yes]`: Use Cosmovisor to run node
2. `Do you want Cosmovisor to automatically download binaries for scheduled upgrades? (yes/no) [default: yes]`: By default, Cosmovisor will attempt to automatically download new binaries that have passed [software upgrade proposals voted on the network](../upgrades/README.md). You can choose to do this manually if you want more control.
Expand Down
1 change: 0 additions & 1 deletion docs/setup-and-configure/configure-cheqd-node.md
Original file line number Diff line number Diff line change
Expand Up @@ -291,7 +291,6 @@ Here are some of the most important parameters set in the config file above:
* Keep the state sync off, unless you want to serve statesync snapshots from your node.
* Set the mempool limit to 5000 txs. This should be sufficient to most use-cases.

See more details about cosmos-SDK configuration [here](https://docs.cosmos.network/v0.50/learn/advanced/config).

## `config.toml` Configuration file

Expand Down
2 changes: 1 addition & 1 deletion docs/setup-and-configure/cosmovisor-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -107,4 +107,4 @@ cosmovisor_disable_recase = false

> **⚠️ Reminder**: Like the service file, custom config.toml changes can be overwritten by the installer. **Decline updates** if you’ve made manual modifications.

For further details, refer to the official [Cosmovisor documentation](https://docs.cosmos.network/main/tooling/cosmovisor).
For further details, refer to the official [Cosmovisor documentation](https://docs.cosmos.network/sdk/latest/guides/upgrades/cosmovisor#cosmovisor).
8 changes: 4 additions & 4 deletions docs/setup-and-configure/requirements.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,9 +23,9 @@ Extended information on [recommended hardware requirements is available in Tende

Storage requirements may vary, depending on your specific needs:

* If you need more historic data and you plan to initialize your node by using state DB snapshot, you will need at least 625 GB of SSD storage.
* If you don't need specific historic data, you can use state sync to initialize your node. In this case, your node will start with less than 1GB of disk space consume, but it will keep to grow with time. It's recommended to provide at least 10GB of SSD.
* In case you need full chain history and you want to run an archive node, you will need 2.7 TB of disk storage. For obtaining full chain history snapshot, reach out to our team on Discord.
* If you need more historic data and you plan to initialize your node by using state DB snapshot, you will need at least 50GB of storage.
* If you don't need specific historic data, you can use **state sync** to initialize your node. In this case, your node will start with less than 1GB of disk space consume, but it will keep to grow with time. It's recommended to provide at least 10GB of SSD. You can always reset your node and reinitialize it with state sync if you run out of space.
* In case you need full chain history and you want to run an archive node, you will need 3 TB of disk storage. For obtaining full chain history snapshot, reach out to our team on Discord.

> ⚠️ **Storage requirements for the blockchain grows with time**. Therefore, these minimum storage figures are expected to increase over time. Read our validator guide for "pruning" settings to optimise storage consumed.

Expand Down Expand Up @@ -95,4 +95,4 @@ If you're not running a validator node, or if you want more advanced control on
## Further information

* Tendermint documentation has [best practices for running a Cosmos node in production](https://docs.cometbft.com/v0.38/core/running-in-production).
* [Сosmovisor could be used for automatic upgrades](https://docs.cosmos.network/main/tooling/cosmovisor); however in our testing so far this method has not been reliable and is therefore currently not recommended.
* [Сosmovisor could be used for automatic upgrades](https://docs.cosmos.network/sdk/latest/guides/upgrades/cosmovisor#cosmovisor); however in our testing so far this method has not been reliable and is therefore currently not recommended.
2 changes: 1 addition & 1 deletion docs/upgrades/upgrade-guides/v0.6-upgrade.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ For this upgrade from `0.5.0` to `0.6.0` there are 2 possible scenario:
- upgrade by installing Cosmovisor
- upgrade only `cheqd-noded` binary.

[Cosmovisor](https://docs.cosmos.network/main/tooling/cosmovisor) is a tool from the `cosmos-sdk` team which is able to make an upgrade in a full-auto mode. It can download and exchange binary without any actions from a node operator. Beginning with version `0.6.0`, and with all subsequent versions, we will leverage Cosmosvisor as a tool to handling our upgrade process.
[Cosmovisor](https://docs.cosmos.network/sdk/latest/guides/upgrades/cosmovisor#cosmovisor) is a tool from the `cosmos-sdk` team which is able to make an upgrade in a full-auto mode. It can download and exchange binary without any actions from a node operator. Beginning with version `0.6.0`, and with all subsequent versions, we will leverage Cosmosvisor as a tool to handling our upgrade process.

For [more information about interactive installer please see this documentation](../../setup-and-configure/README.md).
You will find answers to common questions within this document, however of course feel free to reach out to the team on Slack or Discord.
Expand Down
4 changes: 2 additions & 2 deletions docs/validator-guide/unjail.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Unjailing a validator

Validator nodes can get "jailed" along with a penalty imposed (through its stake getting slashed). Unlike a proof-of-work (PoW) network (such as Ethereum or Bitcoin), proof-of-stake (PoS) networks (such as the cheqd network, built using [Cosmos SDK](https://github.com/cosmos/cosmos-sdk)) use [stake slashing as a mechanism of enforcing good on-chain behaviour](https://docs.cosmos.network/main/modules/slashing) from validators.
Validator nodes can get "jailed" along with a penalty imposed (through its stake getting slashed). Unlike a proof-of-work (PoW) network (such as Ethereum or Bitcoin), proof-of-stake (PoS) networks (such as the cheqd network, built using [Cosmos SDK](https://github.com/cosmos/cosmos-sdk)) use [stake slashing as a mechanism of enforcing good on-chain behaviour](https://docs.cosmos.network/sdk/latest/modules/slashing/README#x-slashing) from validators.

## Conditions that cause a validator to be jailed

Expand All @@ -10,7 +10,7 @@ There are two scenarios in which a validator could be jailed, one of which has m

When a validator "misses" blocks or doesn't participate in consensus, it can get temporarily jailed. By enforcing this check, PoS networks like ours ensure that validators are actively participating in the operation of the network, ensuring that their nodes remain secure and up-to-date with the latest software releases, etc.

The duration on how this is calculated is defined in the [genesis parameters of cheqd network](../../architecture/adr-list/adr-005-genesis-parameters.md). Jailing occurs based on a sliding time window (called the [*infraction window*](https://docs.cosmos.network/main/modules/slashing)) calculated as follows.
The duration on how this is calculated is defined in the [genesis parameters of cheqd network](../../architecture/adr-list/adr-005-genesis-parameters.md). Jailing occurs based on a sliding time window (called the [*infraction window*](https://docs.cosmos.network/sdk/latest/modules/slashing/README#x-slashing)) calculated as follows.

1. The `signed_blocks_window` (set to 25,920 blocks on mainnet) defines the time window that is used to calculate downtime.
2. Within this window of 25,920 blocks, **at least 50% of the blocks must be signed** by a validator. This is defined in the genesis parameter `min_signed_per_window` (set to `0.5` for mainnet).
Expand Down