Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This page lists the ADRs for cheqd-node that have been Accepted, Proposed, or in Draft stage.
The following ADRs have been moved to the cheqd identity documentation site
| Category | Status |
|---|---|
Due to the nature of the cheqd project merging concepts from the Cosmos blockchain framework and self-sovereign identity (SSI), there are two potential options for creating Command Line Interface (CLI) tools for developers to use:
Cosmos-based CLI: Most likely route for Cosmos projects for their node application. Most existing Cosmos node validators will be familiar with this method of managing their node.
VDR CLI: Traditionally, a lot of SSI networks have used Hyperledger Indy and therefore the Indy CLI tool for managing and interacting with the ledger. This has now been renamed to Verifiable Data Registry (VDR) Tools CLI and is the tool that most existing SSI node operators ("stewards") would be familiar with.
Ideally, the cheqd-node project would provide a consistent set of CLI tools rather than two separate tools with varying feature sets between them.
This ADR will focus on the CLI tool architecture choice for cheqd-node.
Any CLI tool architecture chosen should not increase the likelihood of introducing bugs, security vulnerabilities, or design pattern deviations from upstream Cosmos SDK.
Actions that are carried out on ledger through a CLI tool in cheqd-node now include token functionality as well as identity functionality. E.g., if a DID gets compromised, there could be mechanisms to recover or signal that fact to issuers/verifiers. If tokens or the staking balance of node operators get compromised, this may potentially have more severe consequences for them.
Would node operators want a single CLI to manage everything?
This might be the case with node operators from an SSI / digital identity background, or node operators familiar with Hyperledger Indy CLI / VDR Tools CLI.
A “single CLI” could be a single tool as far as the user sees, but actually consist of multiple modules beneath it in how it’s implemented.
Would node operators be okay with having two separate CLIs?
One for Cosmos-ledger functions, and one for identity-specific functions.
Unlike existing Hyperledger Indy networks, it is anticipated that some of the node operators on the cheqd network will have experience running Cosmos validator nodes. For this group, having to learn a new “single” CLI tool could cause a steeper learning curve and a worse user experience than what they have now.
Node operators may want one/separate CLIs for security and operational reasons, i.e., for a separation of concerns in terms of functionality.
Pros:
Simple to do, no changes needed in code developed.
Differences in functionality between the two CLIs can be explained in documentation.
Node operators with good technical skills will understand the difference.
Cosmos CLI design patterns would be consistent the wider Cosmos open source ecosystem.
No steep learning curve for potential node operators who only want to run a node, without implementing SSI functionality in apps.
Cons:
Key storage for Cosmos accounts may need to be done in two different keystores.
Potentially confusing for node operators who use both CLIs to know which one to use for what purpose.
Potentially a steeper learning curve for existing SSI node operators.
Pros:
Both Cosmos CLI and VDR Tools CLI would have native support for identity as well as token transactions.
Node operators/developers could pick their preferred CLI tool.
Cons:
Significant development effort required to implement very similar functionality two separate times, with little difference to the end user in actions that can be executed.
VDR Tools CLI has DID / VC modules that would take significant effort to recreate in Cosmos CLI
Cosmos CLI has token related functionality that would take significant development effort to replicate in VDR Tools CLI, and opens up the possibility that errors in implementation could introduce security vulnerabilities.
Commands in the Cosmos CLI could be made available as aliases in the VDR Tools CLI, or vice versa.
Pros:
Single CLI tool to learn and understand for node operators.
Development effort is simplified, as overlapping functionality is not implemented in two separate tools.
Cons:
Less development effort required than Option 2, but greater than Option 1.
Opens up the possibility that there's deviation in feature coverage between the two CLIs if aliases are not created to make 1:1 feature parity in both tools.
Based on the options considerations above and an analysis of development required, the decision was taken to maintain two separate CLI tools:
cheqd-node Cosmos CLI: Any Cosmos-specific features, such as network & node management, token functionality required by node operators, etc.
VDR Tools CLI: Any identity-specific features required by issuers, verifiers, holders on SSI networks.
Editable versions of the diagrams (in Excalidraw format)
Faster time-to-market on the CLI tools, while freeing up time to build out user-facing functionality.
Cosmos account keys may need to be replicated in two separate key storages. A potential resolution for this in the future is to integrate the ability to use a single keyring for both CLI tools.
Seek feedback from cheqd's open source community and node operators during testnet phase on whether the documentation and user experience is easy to understand and appropriate tools are available.
| Category | Status |
|---|---|
The aim of this document is to define the genesis parameters that will be used in cheqd network testnet and mainnet.
Cosmos v0.44.3 parameters are described.
Genesis consists of Tendermint consensus engine parameters and Cosmos app-specific parameters.
Tendermint requires genesis parameters to be defined for basic consensus conditions on any Cosmos network.
Cosmos application is divided into a list of modules. Each module has parameters that help to adjust the module's behaviour.
auth modulebank modulecheqd module (DID module)crisis moduledistribution modulegov modulemint moduleresource moduleslashing modulestaking moduleibc moduleibc-transfer moduleThe parameters above were agreed separate the cheqd mainnet and testnet parameters. We have bolded the testnet parameters that differ from mainnet.
The token denomination has been changed to make the smallest denomination 10^-9 CHEQ (= 1 ncheq) instead of 1 CHEQ. This is a breaking change from the earliest versions of the cheqd testnet that which required issuing new tokens to be transferred and issued to testnet node operators.
Inflation allows fees to be collected from block rewards in addition to transaction fees.
In production/mainnet, parameters can only be changed via a majority vote without veto defeat according to the cheqd network governance principles. This allows for more democratic governance frameworks to be created for a self-sovereign identity network.
Existing node operators will need to re-establish staking with new staking denomination and staking parameters.
Unbonding period, and deposit period have all been reduced to 2 weeks to balance the speed at which decisions can be reached vs giving enough time to validators to participate.
This is the suggested template to be used for ADRs on the cheqd-node project.
| Category | Status |
|---|---|
The aim of this ADR is to define the smallest fraction for CHEQ tokens.
Cosmos SDK doesn't provide native support for token fractions. The lowest denomination out-of-the-box that can be used in transactions is 1token.
To address this issue, similar Cosmos networks assume that they use N digits after the decimal point and multiply all values by 10^(-N) in UI.
Popular Cosmos networks were compared to check how many digits after the decimal point are used by them:
Cosmos: 6
IRIS: 6
Fetch.ai: 18
Binance: 8
Fractions of CHEQ tokens will be referred by their SI/metric prefix, based on the power of 10 of CHEQ tokens being referred to in context. This notation system is common across other Cosmos networks as well.
It was decided to go with 10^-9 as the smallest fraction, with the whole number token being 1 CHEQ. Based on the SI prefix system, the lowest denomination would therefore be called "nanocheq".
There is no backward compatibility. To adjust the number of digits after the decimal point (lowest token denomination), the network should be restarted.
The power of 10 chosen for the lowest denomination of CHEQ tokens is more precise than for Cosmos ATOMs, which allows transactions to be defined in smaller units.
This decision is hard to change in the future, as changes to denominations require significant disruption when a network is already up and running.
N/A
This is the suggested template to be used for ADRs on the cheqd-node project.
| Category | Status |
|---|---|
What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
A short (~100 word) description of the issue being addressed. "If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the ADR.
This section describes the forces at play, such as business, technological, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral. It is simply describing facts. It should clearly explain the problem and motivation that the proposal aims to resolve.
This section describes the implementation and/or architecture approach for the proposed changes in detail.
This section describes the resulting context, after applying the decision. All consequences should be listed here, not just the "positive" ones. A particular decision may have positive, negative, and neutral consequences, but all of them affect the team and project in the future.
All ADRs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The ADR must explain how the author proposes to deal with these incompatibilities. ADR submissions without a sufficient backwards compatibility treatise may be rejected outright.
{positive consequences}
{negative consequences}
{neutral consequences}
{reference link}
{list of questions or action items}
| Category | Status |
|---|---|
This ADR describes how cheqd/Cosmos account keys can be imported/exported into identity wallet applications built on Evernym VDR Tools SDK.
Client SDK applications such as Evernym VDR Tools need to work with cheqd accounts in identity wallets to be able to interact with the cheqd network ledger.
For example, an identity wallet application or backend application would need to pay network transaction fees for writing cheqd DIDs to the ledger. This may also need to be extended in the future to support peer-to-peer payments for credential exchange.
Cosmos SDK uses known algorithms for deriving private keys from mnemonics. This can be replicated using standard crypto libraries to carry out the same steps as in Cosmos SDK:
The mnemonic above is assumed to be a pre-existing one cheqd/Cosmos CLI. The "passphrase" above is user-defined, and defaults to blank if not defined.
Mnemonic import/export can be achieved using pre-existing BIP39 packages and Cosmos SDK's Rust library cosmrs.
Using these pre-existing libraries, cheqd accounts can be recovered using the standard BIP44 HDPath for Cosmos SDK chains described below:
Functionality will be added to VDR Tools SDK to import/export cheqd accounts using mnemonics paired with the --recover flag as done with Cosmos wallets.
Not applicable, since this is an entirely new feature in VDR Tools SDK for integration with the new blockchain framework.
Adding/recovering cheqd accounts in VDR Tools SDK will follow a similar, familiar process that users have for Cosmos wallets.
N/A
N/A
This is the suggested template to be used for ADRs on the cheqd-node project.
| Category | Status |
|---|---|
The aim of this ADR is to define how "community tax" as described in the Cosmos blockchain framework will work on cheqd network.
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 by the network.
From Cosmos SDK documentation, distribution module:
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.
To spend tokens from the community pool:
community-pool-spend proposal can be submitted on the network.
Recipient address and amount of tokens should be specified.
The purpose for which the requested community pools tokens will be spent should be described.
If proposal is approved using the voting process, the recipient address specified will receive the requested tokens.
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 documentation.
cheqd's network will keep the communityTax parameter enabled, i.e., non-zero.
The value of communityTax, based on a review of similar Cosmos networks will be set to 2%.
The behavior of communityTax is the across Cosmos SDK v0.42 and v0.43.
The cheqd network will have a pool of tokens that can be used to spend on initiatives valued by the community.
N/A
cheqd's Governance Framework should provide guidance on how to submit proposals and recommended areas of investment in community efforts.
| Category | Status |
|---|---|
Issued credentials need to be revocable by their issuers. Revocation needs to be straightforward and fast. Testing of revocation needs to preserve privacy (be non-correlating), and it should be possible to do without contacting the issuer.
This has obvious use cases for professional credentials being revoked for fraud or misconduct, e.g., a driver’s license could be revoked for criminal activity. However, it’s also important if a credential gets issued in error (e.g., has a typo in it that misidentifies the subject). The latter case is important even for immutable and permanent credentials such as a birth certificate.
In addition, it seems likely that the data inside credentials will change over time (e.g., a person’s mailing address or phone number updates). This is likely to be quite common, revocation can be used to guarantee currency of credential data when it happens. In other words, revocation may be used to force updated data, not just to revoke authorization.
Adds a Revocation Registry Definition, that Issuer creates and publishes for a particular Credential Definition. It contains public keys, maximum number of credentials the registry may contain, reference to the Credential Definition, plus some revocation registry specific data.
value (dict):
Dictionary with Revocation Registry Definition's data:
max_cred_num (integer): The maximum number of credentials the Revocation Registry can handle
tails_hash (string): Tails file digest
tails_location (string): Tails file location (URL)
issuance_type (string enum): Defines credential revocation strategy. Can have the following values:
ISSUANCE_BY_DEFAULT: All credentials are assumed to be issued and active initially, so that Revocation Registry needs to be updated (REVOC_REG_ENTRY transaction sent) only when revoking. Revocation Registry stores only revoked credentials indices in this case. Recommended to use if expected number of revocation actions is less than expected number of issuance actions.
ISSUANCE_ON_DEMAND: No credentials are issued initially, so that Revocation Registry needs to be updated (REVOC_REG_ENTRY transaction sent) on every issuance and revocation. Revocation Registry stores only issued credentials indices in this case. Recommended to use if expected number of issuance actions is less than expected number of revocation actions.
public_keys (dict): Revocation Registry's public key
id (string): Revocation Registry Definition's unique identifier (a key from state trie is currently used) owner:cred_def_id:revoc_def_type:tag
cred_def_id (string): The corresponding Credential Definition's unique identifier (a key from state tree is currently used)
revoc_def_type (string enum): Revocation Type. CL_ACCUM (Camenisch-Lysyanskaya Accumulator) is the only supported type now.
tag (string): A unique tag to have multiple Revocation Registry Definitions for the same Credential Definition and type issued by the same DID.
Note: REVOC_REG_DEF can be updated.
(owner, cred_def_id, revoc_def_type, tag) -> {data, tx_hash, tx_timestamp }
Request Example:
Reply Example:
The Revocation Registry Entry contains the new accumulator value and issued/revoked indices. This is just a delta of indices, not the whole list. It can be sent each time a new credential is issued/revoked.
value (dict):
Dictionary with revocation registry's data:
accum (string): The current accumulator value
prev_accum (string): The previous accumulator value. It is compared with the current value, and transaction is rejected if they don't match. This is necessary to avoid dirty writes and updates of accumulator.
issued (list of integers): An array of issued indices (may be absent/empty if the type is ISSUANCE_BY_DEFAULT). This is delta, and will be accumulated in state.
revoked (list of integers): An array of revoked indices. This is delta; will be accumulated in state)
revoc_reg_def_id (string): The corresponding Revocation Registry Definition's unique identifier (a key from state trie is currently used)
revoc_def_type (string enum): Revocation Type. CL_ACCUM (Camenisch-Lysyanskaya Accumulator) is the only supported type now.
Note: REVOC_REG_ENTRY can be updated.
MARKER_REVOC_REG_ENTRY_ACCUM:revoc_reg_def_id -> {data, tx_hash, tx_timestamp }
MARKER_REVOC_REG_ENTRY:revoc_reg_def_id -> {data, tx_hash, tx_timestamp }
Request Example:
Reply Example:
| Category | Status |
|---|---|
The Hyperledger Aries protocol describes a payment mechanism that can used to pay for the issuance of credentials.
It is necessary to establish which public APIs from Hyperledger Aries can be implemented in cheqd-node to provide an implementation of payments using CHEQ tokens using a well-understood SSI protocol.
Hyperledger Aries protocol has the concept of payment "decorators" ~payment_request and ~payment_receipt in requests, that can be used to pay using tokens for credential issuance.
A message is sent by the Issuer to the potential Holder, describing the credential they intend to offer and optionally, the price the issuer would be expected to be paid for said credential. This is based on the Hyperledger Aries credential offer RFC.
A payment request can then be defined using the Hyperledger Aries Payment Decorator to add information about an issuing price and address where payment should be sent.
details.id field contains an invoice number that unambiguously identifies a credential for which payment is requested. When paying, this value should be placed in memo field for the cheqd payment transaction.
payeeId field contains a cheqd account address in the correct format for cheqd network.
The payment flow can be broken down into five steps:
Build a request for transferring tokens. Example: cheqd_ledger::bank::build_msg_send(from_account, to_account, amount_for_transfer, denom)
from_account: The prospective credential holder's cheqd account address
to_account: Same as payeeId from the Payment Request
amount_for_transfer: Price of credential issuance defined as details.total.amount.value from the Payment Request
denom: Defined in details.total.amount.currency from the Payment Request
Build a transaction with the request from the previous step Example: cheqd_ledger::auth::build_tx(pool_alias, pub_key, builded_request, account_number, account_sequence, max_gas, max_coin_amount, denom, timeout_height, memo)
memo: This should be the same as details.id from the Payment Request
Sign the transaction Example:cheqd_keys::sign(wallet_handle, key_alias, tx).
Broadcast the signed transaction Example: cheqd_pool::broadcast_tx_commit(pool_alias, signed).
Key fields in the response above are:
hash: Transaction hash
height: Ledger height
This is a message sent by the potential Holder to the Issuer, to request the issuance of a credential after tokens are transferred to the nominated account using a Payment Transaction.
request_id should be the same as details.id from Payment Request and memo from Payment Transaction.
Issuer receives Credential Request + payment_receipt with payment transaction_id. It allows the Issuer to:
Get the payment transaction by hash from cheqd network ledger using get_tx_by_hash(hash) method, where hash is transaction_id from previous steps.
Check that memo field from received transaction contains the correct request_id.
If steps 1-4 are successful, the Issuer is able to confirm that the requested payment has been made using CHEQ tokens. The credential issuing process can then proceed using standard Hyperledger Aries protocol procedures.
REPLACE WITH PNG
Editable version available on swimlanes.io or as text for compatible UML diagram generators below:
Credential issuance outside of the payment flow is compatible with and carried out using existing Hyperledger Aries protocol procedures. This should provide a level of compatibility with existing apps/SDKs that implement Aries protocol.
Defining the transaction in CHEQ tokens is specific to the cheqd network.
By defining the payment mechanism using Hyperledger Aries protocols, this allows the possibility in the future to support payments on multiple networks.
Existing SSI app developers should already be familiar with Hyperledger Aries (if building on Hyperledger Indy) and provides a transition path to add new functionality.
Hyperledger Aries may not be a familiar protocol for other Cosmos projects.
Using the Payment Decorator in practice means there could be interoperability challenges at in implementations that impact credential issuance and exchange.
N/A
| Category | Status |
|---|
This ADR will define how Verifiable Credential schemas can be represented through the use of a DID URL, which when dereferenced, fetches the credential schemas a resource. The identity entities and transactions for the cheqd network are designed to support usage scenarios and functionality currently supported by .
Hyperledger Indy is a verifiable data registry (VDR) built for DIDs with a strong focus on privacy-preserving techniques. It is one of the most widely-adopted SSI blockchain ledgers. Most notably, Indy is used by the .
Our aim is to support the functionality enabled by into cheqd-node. This will partly enable the goal of allowing use cases of existing SSI networks on Hyperledger Indy to be supported by the cheqd network.
The following identity-domain transactions from Indy were considered:
NYM: Equivalent to "DIDs" on other networks
ATTRIB: Payload for DID Document generation
SCHEMA: Schema used by a credential
CRED_DEF: Credential definition by an issuer for a particular schema
REVOC_REG_DEF: Credential revocation registry definition
REVOC_REG_ENTRY: Credential revocation registry entry
CL-Schema resource can be created via CreateResource transaction with the follow list of parameters:
MsgCreateResource:
Collection ID: UUID ➝ (did:cheqd:...:) ➝ Parent DID identifier without a prefix
ID: UUID ➝ specific to resource, also effectively a version number (supplied client-side)
Name: String (e.g., CL-Schema1 ) ➝ Schema name
ResourceType ➝ CL-Schema
MimeType ➝ application/json
Data: Byte[] ➝ JSON string with the follow structure:
attrNames: Array of attribute name strings (125 attributes maximum)
CLI Example:
[TODO: explain that a Cred Def is simply an additional property inside of the Issuer's DID Doc]
Adds a Credential Definition (in particular, public key), which is created by an Issuer and published for a particular Credential Schema.
It is not possible to update Credential Definitions. If a Credential Definition needs to be evolved (for example, a key needs to be rotated), then a new Credential Definition needs to be created for a new Issuer DIDdoc. Credential Definitions is added to the ledger in as verification method for Issuer DIDDoc
id: DID as base58-encoded string for 16 or 32 byte DID value with Cheqd DID Method prefix did:cheqd:<namespace>: and a resource type at the end.
value (dict): Dictionary with Credential Definition's data if signature_type is CL:
primary (dict): Primary credential public key
revocation (dict, optional): Revocation credential public key
schemaId (string): id of a Schema the credential definition is created for.
signatureType (string): Type of the credential definition (that is credential signature). CL-Sig-Cred_def (Camenisch-Lysyanskaya) is the only supported type now. Other signature types are being explored for future releases.
tag (string, optional): A unique tag to have multiple public keys for the same Schema and type issued by the same DID. A default tag tag will be used if not specified.
controller: DIDs list of strings or only one string of a credential definition controller(s). All DIDs must exist.
CRED_DEF entity transaction format:
Don't store Schema DIDDoc in the State.
CredDef URL: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue
CredDef Entity URL: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue?service=CL-CredDef
CRED_DEF DID Document transaction format:
CRED_DEF state format:
"credDef:<id>" -> {CredDefEntity, txHash, txTimestamp}
Note: CRED_DEF cannot be updated.
Schema. Option 2
Schema URL: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue#<schema_entity_id>
SCHEMA DID Document transaction format:
Schema. Option 3
Schema URL: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue
SCHEMA DID Document transaction format:
Schema. Option 4
Schema URL: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue#<schema_entity_id>
SCHEMA DID Document transaction format:
SCHEMA State format:
"schema:<id>" -> {SchemaEntity, txHash, txTimestamp}
id example: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue
Cred Def. Option 2
Store inside Issuer DID Document
CredDef URL: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue#<cred_def_entity_id>
CRED_DEF DID Document transaction format:
CRED_DEF state format:
Positive
Credential Definition is a set of Issuer keys. So storing them in Issuer's DIDDoc reasonable.
Negative
Credential Definition name means that it contains more than just a key and value field provides this flexibility.
Adding all Cred Defs to Issuer's DIDDoc makes it too large. For every DIDDoc or Cred Def request a client will receive the whole list of Issuer's Cred Defs.
Impossible to put a few controllers for Cred Def.
In theory, we need to make Credential Definitions mutable.
| Only available in Cosmos CLI | In both Cosmos CLI and VDR CLI | Only available in VDR CLI |
|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
| Parameter | Description | Mainnet | Testnet |
|---|---|---|---|
Revocation registries for credentials are not covered under the scope of this ADR. This topic is discussed separately in as there is ongoing research by the cheqd project on how to improve the privacy and scalability of credential revocations.
official project background on Hyperledger Foundation wiki
GitHub repository: Server-side blockchain node for Indy ()
GitHub repository: Plenum Byzantine Fault Tolerant consensus protocol; used by indy-node ()
(did:indy)
official project background on Hyperledger Foundation wiki
GitHub repository: Provides links to implementations in various programming languages
GitHub repository: Contains Requests for Comment (RFCs) that define the Aries protocol behaviour
specification
official project website
GitHub repository ()
: Sovrin Network token library
Authors
Alexandr Kolesov
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2021-09-10
Cosmos transactions + Queries
Signing service + Key storage
Identity transactions + Queries
MultiSig
(Transaction + Query) sending + Proof validation
DIDs + VCs (+ DID storage)
Network bootstrapping commands
Authors
Alexandr Kolesov, Ankur Banerjee, Alex Tweeddale
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2021-09-15
Last Updated
2022-12-08
max_bytes
This sets the maximum size of total bytes that can be committed in a single block. This should be larger than max_bytes for evidence.
200,000 (~200 KB)
200,000 (~200 KB)
max_gas
This sets the maximum gas that can be used in any single block.
200,000 (~200 KB)
200,000 (~200 KB)
time_iota_ms
Unused. This has been deprecated and will be removed in a future version of Cosmos SDK.
1,000 (1 second)
1,000 (1 second)
max_age_num_blocks
Maximum age of evidence, in blocks. The basic formula for calculating this is: MaxAgeDuration / {average block time}.
12,100
25,920
max_age_duration
Maximum age of evidence, in time. It should correspond with an app's "unbonding period".
1,209,600,000,000,000 (expressed in nanoseconds, ~2 weeks)
59,200,000,000,000 (expressed in nanoseconds, ~72 hours)
max_bytes
This sets the maximum size of total evidence in bytes that can be committed in a single block and should fall comfortably under max_bytes for a block.
50,000 (~ 50 KB)
5,000 (~ 5 KB)
pub_key_types
Types of public keys supported for validators on the network.
Ed25519
Ed25519
max_memo_characters
Maximum number of characters in the memo field
512
512
tx_sig_limit
Max number of signatures
7
7
tx_size_cost_per_byte
Gas cost of transaction byte
10
10
sig_verify_cost_ed25519
Cost of ed25519 signature verification
590
590
sig_verify_cost_secp256k1
Cost of secp256k1 signature verification
1,000
1,000
default_send_enabled
The default send enabled value allows send transfers for all coin denominations
True
True
create_did
The specified transaction fee for creating a Decentralized Identifier (DID) on the cheqd network
50,000,000,000 ncheq (50 CHEQ)
50,000,000,000 ncheq (50 CHEQ)
update_did
The specified transaction fee for updating an existing Decentralized Identifier (DID) on the cheqd network
25,000,000,000 ncheq (25 CHEQ)
25,000,000,000 ncheq (25 CHEQ)
deactivate_did
The specified transaction fee for deactivating an existing Decentralized Identifier (DID) on the cheqd network
10,000,000,000 ncheq (10 CHEQ)
10,000,000,000 ncheq (10 CHEQ)
burn_factor
The percentage of the transaction fee for create_did, update_did or deactivate_did that is burnt, i.e., destroyed from the cheqd network
50%
50%
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)
community_tax
The percent of rewards that goes to the community fund pool
0.02 (2%)
0.02 (2%)
base_proposer_reward
Base reward that proposer of a block receives
0.01 (1%)
0.01 (1%)
bonus_proposer_reward
Bonus reward that proposer gets for proposing block. This depends on the number of pre-commits included to the block
0.04 (4%)
0.04 (4%)
withdraw_addr_enabled
Whether withdrawal address can be changed or not. By default, it's the delegator's address.
True
True
deposit_params
min_deposit
The minimum deposit for a proposal to enter the voting period.
[{ "denom": "ncheq", "amount": "8,000,000,000,000" }] (8,000 cheq)
[{ "denom": "ncheq", "amount": "8,000,000,000,000" }] (8,000 cheq)
max_deposit_period
The maximum period for Atom holders to deposit on a proposal. Initial value: 2 months.
604,800s (1 week)
172,800s (48 hours)
voting_params
voting_period
The defined period for an on-ledger vote from start to finish.
259,200s (3 days)
86.40s (1.2 minutes)
tally_params
quorum
Minimum percentage of total stake needed to vote for a result to be considered valid.
0.334 (33.4%)
0.334 (33.4%)
threshold
Minimum proportion of Yes votes for proposal to pass.
0.5 (50%)
0.5 (50%)
veto_threshold
The minimum value of veto votes to total votes ratio for proposal to be vetoed. Default value: 1/3.
0.334 (33.4%)
0.334 (33.4%)
mint_denom
Name of the cheq smallest denomination
ncheq
ncheq
inflation_rate_change
Maximum inflation rate change per year. In Cosmos Hub they use 1.0. Formula: inflationRateChangePerYear = (1 - BondedRatio / GoalBonded) * MaxInflationRateChange
0.045 (4.5%)
0.045 (4.5%)
inflation_max
Inflation aims to this value if bonded_ratio < bonded_goal
0.04 (4%)
0.04 (4%)
inflation_min
Inflation aims to this value if bonded_ratio > bonded_goal
0.01 (1%)
0.01 (1%)
goal_bonded
Percentage of bonded tokens at which inflation rate will neither increase nor decrease
0.60 (60%)
0.60 (60%)
blocks_per_year
Number of blocks generated per year
3,155,760 (1 block every ~10 seconds)
3,155,760 (1 block every ~10 seconds)
image
The specified transaction fee for creating an image as a DID-Linked Resource on the cheqd network
10,000,000,000 ncheq (10 CHEQ)
10,000,000,000 ncheq (10 CHEQ)
json
The specified transaction fee for creating a JSON file as a DID-Linked Resource on the cheqd network
2,500,000,000 ncheq (2.5 CHEQ)
2,500,000,000 ncheq (2.5 CHEQ)
default
The specified transaction fee for creating any other type of DID-Linked Resource on the cheqd network, other than images or JSON files
5,000,000,000 ncheq (5 CHEQ)
5,000,000,000 ncheq (5 CHEQ)
burn_factor
The percentage of the transaction fee for image, json or default DID-Linked Resources that are burnt, i.e., destroyed from the cheqd network
50%
50%
signed_blocks_window
Number of blocks a validator can miss signing before it is slashed.
25,920 (expressed in blocks, equates to 259,200 seconds or ~3 days)
17,280 (expressed in blocks, equates to 172,800 seconds or ~2 days)
min_signed_per_window
This percentage of blocks must be signed within the window.
0.50 (50%)
0.50 (50%)
downtime_jail_duration
The minimal time validator have to stay in jail
600s (~10 minutes)
600s (~10 minutes)
slash_fraction_double_sign
Slashed amount as a percentage for a double sign infraction
0.05 (5%)
0.05 (5%)
slash_fraction_downtime
Slashed amount as a percentage for downtime
0.01 (1%)
0.01 (1%)
unbonding_time
A delegator must wait this time after unbonding before tokens become available
1,210,000s (~2 weeks)
259,200s (~3 days)
max_validators
The maximum number of validators in the network
125
125
max_entries
Max amount of unbound/redelegation operations in progress per account
7
7
historical_entries
Amount of unbound/redelegate entries to store
10,000
10,000
bond_denom
Denomination used in staking
ncheq
ncheq
max_expected_time_per_block
Maximum expected time per block, used to enforce block delay. This parameter should reflect the largest amount of time that the chain might reasonably take to produce the next block under normal operating conditions. A safe choice is 3-5x the expected time per block.
30,000,000,000 (expressed in nanoseconds, ~ 30 seconds)
30,000,000,000 (expressed in nanoseconds, ~ 30 seconds)
allowed_clients
Defines the list of allowed client state types. We allow connections from other chains using the Tendermint client, and with light clients using the Solo Machine client.
[ "06-solomachine", "07-tendermint" ]
[ "06-solomachine", "07-tendermint" ]
send_enabled
Enables or disables all cross-chain token transfers from this chain
true
true
receive_enabled
Enables or disables all cross-chain token transfers to this chain
true
true
Authors
Alexandr Kolesov
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2021-09-08
Authors
{Author or list of authors}
ADR Stage
{DRAFT | PROPOSED | ACCEPTED | REJECTED | SUPERSEDED by ADR-xxx | ABANDONED}
Implementation Status
{Implemented | In Progress | Not Implemented}
Start Date
{yyyy-mm-dd}
Last Updated
{yyyy-mm-dd}
Authors
Andrew Nikitn, Ankur Banerjee
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2021-09-23
Authors
Alexandr Kolesov
ADR Stage
ACCEPTED
Implementation Status
Implemented
Start Date
2021-09-08
Authors
Renata Toktar
ADR Stage
DRAFT
Implementation Status
Not Implemented
Start Date
2021-09-10
Authors
Ankur Banerjee
ADR Stage
PROPOSED
Implementation Status
Not Implemented
Start Date
2021-09-01
Authors | Renata Toktar, Alexander Kolesov, Ankur Banerjee |
ADR Stage | DRAFT |
Implementation Status | Draft |
Start Date | 2022-06-23 |