Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The world of Decentralised Finance (DeFi) can be daunting for newcomers. Documentation is littered with words, which mean very little, creating a seemingly large knowledge gap and journey to embark on in order to make informed decisions.
Begin familiarising yourself with some of the language and concepts used in this space, below:
Familiarise yourself with the core network parameters for how governance operates.
Learn ahow to use the cheqd tooling to participate in governance.
In blockchain ecosystems, the Node Operator runs what is called a node. A node can be thought of as a power pylon in the physical world, which helps to distribute electricity around a wide network of users.
Without these pylons, electricity would be largely centralised in one location; the pylons help to distribute power to entire wide-scale populations. And if one pylon fails, the grid is set up to circumvent this pylon and re-route the electricity to a different route.
Similarly, in blockchain infrastructure, each node runs an instance of the consensus protocol and helps to create a broad, robust network, with no single point of failure. A node failing will have little impact on the Network as a whole; however, if multiple nodes fail, or disagree with information entered into the transaction, then the block may not be signed, and there are fail-safe measures to notify the rest of the Node Operators of this.
A cryptographic signature is a mathematical scheme for verifying the authenticity of digital messages or documents. A private key is like a password — a string of letters and numbers — that allows you to access and manage your crypto funds (your mnemonic is a version of this). So, the above is saying validators can broadcast that they agree with transactions in a block, using their password to sign their agreement in a mathematical way which ensures security and privacy.
Set up your node on cheqd and configure it to become a validator node.
Users with bonded tokens, Participants, are able to vote on Governance Proposals. The weight of a vote is directly tied to the amount of bonded tokens delegated to Node Operators.
The specifics of how a participant can vote on Proposals, or create Proposals, is detailed further in our .
If the User does not want to vote on a Governance Proposal or misses it for any particular reason, the Node Operator will inherit the delegated tokens and can use them to vote with.
Node Operator voting power = initial stake + inherited delegated tokens (if participants do not vote)
Participant voting power = delegated tokens (if a participant chooses to vote)
If you are particularly interested or passionate about a specific governance proposal or do not agree with your bonded Node Operator, it is absolutely possible to vote unilaterally. However, you must still have delegated tokens, bonded with a Node Operator to do so. To do this, follow the instructions in the section .
In short, yes. Participants may be eligible for a percentage of the rewards that Node Operators earn during the course of running a node. Node Operators may offer a certain commission for bonding to them. These rewards may come in two forms:
Writes to the cheqd Network incur what is known as a transaction fee, which is calculated based on gas. Gas may be higher when there are high transaction volumes on the Network, and vice versa. Node Operators may also set their own gas prices, above which they are considered in the pool of who creates that transaction block. However, we will not get into the nuances of gas here.
Block rewards depend on inflation. Inflation is the gradual increase in the number of blocks on the Network. A Node Operator may earn block rewards during a period of inflation, which can be disseminated to the Users delegated to the Node Operator. For this reason, it is suggested that token holders bond and delegate their tokens, to create a healthy Network and earn passive income.
Use the below links to get up to speed with some of the core concepts and terminology in the cheqd network ecosytem.
Photo credit:
The terms Validator and Node Operator are somewhat synonymous. Validator is the term used more commonly in the when referring to a Node Operator that is validating transactions on a blockchain. The only point worth mentioning is you can have a Node Operator that is NOT a Validator. These are known as Observer nodes, which play a more passive role on the network, as they don’t stake on the network or validate transactions, but can observe them.
The is based on , which relies on a set of validators to secure the network. By ‘secure the network’, this refers to the way in which validators “participate in consensus by broadcasting votes which contain ”. In English pls…
These rewards are distributed continuously and instantly. You are able to see your accumulated rewards on our dashboard: and can always claim them back into your account.
Core concepts
Learn about the core concepts regarding how the $CHEQ token is utilised in governance.
Terminology
Learn about the terminology that is applied to this governance framework.
Glossary
Discover sector-specific words and language to guide your learning journey,
Network Parameters
Understand the technical parameters the comprise the network network and governance framework.
How to Participate
Learn how to stake, vote and conduct other operations on the cheqd network as an active participant.
A stake is the amount of tokens a Node Operator puts aside and dedicates to a network’s active pool to contribute to governance and earn rewards. Staking is the verb used to describe this contribution. As cheqd is a Proof of Stake (PoS) Network, rewards can be earned in direct correlation with the amount of stake a Node Operator contributes.
Token holders, ‘users’, can delegate their tokens to Node Operators in order to earn rewards and participate in governance. Once a user has delegated tokens to a Node Operator and has tokens added to the active pool, they are known as Participants.
Users can delegate to multiple Node Operators at the same time to essentially diversify their bonded token portfolio.
Bonded tokens are those present in the active pool.
Bonded tokens = staked tokens by Node Operator + delegated tokens by a user.
Users are persons who hold $CHEQ. Users are able to delegate tokens to Node Operators in order to have those tokens bonded and added to the active pool.
Once a User has delegated tokens to a Node Operator and has tokens added to the active pool, they are known as "Participants".
Participants may be eligible for a percentage of the rewards that Node Operators earn during the course of running a node. Node Operators may offer a certain commission for delegating to them. Participants earn rewards on the delegated tokens which are bonded to the Validator.
Therefore, you may want to delegate and stake your tokens for two reasons:
To participate in Network Governance;
To earn rewards proportionate to your stake in the Network.
Choosing your Node Operator or multiple Node Operators is an important decision. There are a few things you can take into consideration:
The incentive for delegating tokens to a Node Operator is that you, as a participant, can earn rewards based on the stake of the Node Operator. Each Node Operator will have a commission rate. This is the percentage of tokens that the Node Operator will take as commission for running the infrastructure — the remaining percentage is distributed to the Participants.
You should be mindful about what reputation the Node Operator has. This is because the Node Operator may use your votes against the best interest of yourself and the community. As cheqd evolves, it is likely that there will become a political spectrum of Node Operators, who will cast their vote in different directions. Some may want to create chaos on the network and vote to disrupt the established paradigms, for example. A chaotic actor may lure users to delegate to them with a favourable commission rate and use the accumulated bonded tokens against the network’s best interests. For this reason, the choice of Node Operator you delegate to is very important.
As the name would suggest, staking is not risk-free. As the word stake literally means “having something to gain or lose by having a form of ownership of something”, individuals should be wary of the risk, as we’ll come on to.
Think of it like this, if someone says to you “what’s at stake?” they are essentially asking: “what am I risking in return for the potential rewards?”
Node Operators might exhibit bad behaviour on the Network and, as a result, have their stake slashed. Slashing means taking the stake away from the Node Operator and adding it to the Community Pool.
Bad behaviour in this context usually means that the Node Operator has not signed a sufficient number of blocks as ‘pre commits’ over a certain period of time. This could be due to inactivity or potential malicious intent.
For example in June 2019, CosmosPool a former Cosmos validator experienced a server outage on their main node; downtime that resulted in its validator being temporarily jailed and its stake being slashed by 0.01%, including that of its delegators. This was what’s call a downtime slashing incident (soft slashing) whereby the validator and delegators were punished for downtime proportionally to their stake on the network. On top of this, further slashing later occurred as evidence was found of double block signing. Both CosmosPool AND the delegators’ stakes were slashed an additional 5% and the validator was permanently removed (‘tombstoned’).
Slashing can therefore certainly affect your delegated and bonded tokens, so it is important to consider your choice.
We currently have the slashing values to:
5% slashed for double signing
1% slashed for downtime (getting jailed)
These values may change over time through proposals that are voted on the network. You can read more about slashing here.
Yes, it is possible to instantly redelegate to a new Node Operator; however, you cannot ‘hop’ between Node Operators quickly. You must complete your redelegation to a Node Operator before moving again. If you want to completely withdraw and unbond your tokens, you need to be mindful that this process takes two weeks for the tokens to become available for use again. This unbonding period is an example of a parameter, which can be adjusted by the Governance Framework process.
It is important to use consistent and plain language, to ensure that there is a clear understanding of this Governance Framework.
For this reason, this Governance Framework will utilise the key words:
"MUST",
"MUST NOT",
"REQUIRED",
"SHALL",
"SHALL NOT",
"SHOULD",
"SHOULD NOT",
"RECOMMENDED",
"MAY", and
"OPTIONAL"
These terms are to be interpreted as described in RFC 2119
Generally, this Governance Framework will use non-prescriptive language, and will focus more on MAY and SHOULD, rather than SHALL and MUST.
The Governance Framework MAY also make use of the terms, conventions and patterns in the ToIP Metamodel. It is desirable to become a ToIP compliant Network.
cheqd-specific Terms SHALL be defined in the Glossary of terms, a Controlled Document of the Governance Framework.
Reference MAY also be made to:
This glossary lays out all of the key terms you may come across while using cheqd.
Term
Definition
Agency
A service provider that hosts Cloud Agents and may provision Edge Agents on behalf of Entities. Agencies may be Unaccredited, Self-Certified, or Accredited.
Agent
A software program or process used by or acting on behalf of an Entity to interact with other Agents or with the cheqd Network or other distributed ledgers. Agents are of two types: Edge Agents run at the edge of the network on a local device; Cloud Agents run remotely on a server or cloud hosting service. Agents require access to a Wallet in order to perform cryptographic operations on behalf of the Entity they represent.
Agent-to-Agent (A2A) Protocol
A protocol for communicating between Agents to form Connections, exchange Credentials, and have other secure private Interactions. A less technical synonym is DID Communication (DIDComm).
Agent-to-Agent (A2A) Protocol Layer
The technical stack 'Layer' for peer-to-peer Connections and Interactions over the Agent-to-Agent Protocol.
Anonym
A DID used exactly once, so it cannot be contextualized or correlated beyond that single usage. See also Pseudonym and Verinym.
Anywise
A non-reciprocal relationship rooted in the Identity of one party, where the other party is the public (a faceless “other” that can be instantiated without bound). For an Organization to issue publicly Verifiable Credentials, its Issuer DID must be on a public ledger such as cheqd. It is thus an Anywise DID—a DID to which any other Entity may refer without coordination. The term “public DID” is sometimes used as a casual synonym for “Anywise DID”. However, “public DID” is deprecated because it is ambiguous, i.e., it may refer to a DID that is world-visible but usable only in pairwise mode, or to a DID that is not published in a central location but nonetheless used in many contexts, or to a DID that is both publicly visible and used in Anywise mode. Compare N-wise and Pairwise.
ATOM
The exchange token that runs and transacts natively on the Cosmos ledger.
Attribute
An Identity trait, property, or quality of an Entity.
Authentic data
Bitcoin
A type of cryptocurrency, famously created by pseudonymous Satoshi Nakamoto, using a Proof-of-Work (PoW) consensus model to mine blocks.
Blocks
A set of transaction data, forming part of a Blockchain.
Blockchain
A system in which a record of transactions are maintained across several computers that are linked in a distributed, peer-to-peer network.
Bonding
Attaching tokens to a specific Node Operator, to participate in cheqd Network Governance and delegate unused votes to that specific Node Operator.
CHEQ
The native medium of exchange, governance and transaction fees on the cheqd Network.
cheqd Network
The blockchain, built on the Cosmos SDK, that cheqd uses for transactions, governance and identity interactions.
Claim
An assertion about an Attribute of a Subject. Examples of a Claim include date of birth, height, government ID number, or postal address—all of which are possible Attributes of an Individual. A Credential is comprised of a set of Claims. (Note: Early in the development of Self-Sovereign Identity technology, this term was used the same way it was used in the early W3C Verifiable Claims Working Group specifications—as a synonym for what is now a Credential. That usage is now deprecated.)
Cloud Agent
An Agent that is hosted in the cloud. It typically operates on a computing device over which the Identity Owner does not have direct physical control or access. Mutually exclusive with Edge Agent. A Cloud Agent requires a Wallet and typically has a Service Endpoint. Cloud agents may be hosted by an Agency.
Coin
A coin operates on its own independent blockchain and acts like a native currency within a specific financial system.
Connection
A cryptographically verifiable communications channel established using an Agent-to-Agent Protocol between two DIDs representing two Entities and their associated Agents. Connections may be Edge-to-Edge Connections or Cloud-to-Cloud Connections. Connections may be used to exchange Verifiable Credentials or for any other communications purpose. Connections may be encrypted and decrypted using the Public Keys and Private Keys for each DID. A Connection may be temporary or it may last as long as the two Entities desire to keep it. Two Entities may have multiple Connections between them, however each Connection must be between a unique pair of DIDs. A relationship between more than two Entities may be modeled either as Pairwise connections between all of the Entities (Peering) or each Entity can form a Connection with an Entity representing a Group.
Connection Invitation
An Agent-to-Agent Protocol message type sent from one Entity to a second Entity to invite the second Entity to send a Connection Request.
Controlled Document
A subdocument of a Governance Framework as a normative component of the framework. These are often referred to in the Trust over IP metamodel, which cheqd intends to comply with.
Controller
An Entity that has the Private Keys and responsibility to take actions on behalf of another Entity.
Cosmos
The distributed ledger, with the coin ATOM, which cheqd is building its infrastructure on top of.
Cosmos SDK
The development kit that cheqd is using to build its infrastructure.
Core Principles
The Principles published in this Governance Framework that seek to govern the behaviour of participants in the cheqd Network.
Credential
A digital assertion containing a set of Claims made by an Entity about itself or another Entity. Credentials are a subset of Identity Data. A Credential is based on a Credential Definition.
The Entity described by the Claims is called the Subject of the Credential.
The Entity creating the Credential is called the Issuer.
The Entity holding the issued Credential is called the Holder.
The Entity to whom a Credential is presented is generally called the Relying Party, and specifically called the Verifier if the Credential is a Verifiable Credential.
Once issued, a Credential is typically stored by an Agent. (In cheqd's infrastructure, Credentials are never stored on the Ledger.) Credentials are very broad in their potential use: Examples of Credentials include college transcripts, driver licenses, health insurance cards, and building permits. See also Verifiable Credential.
Credential Definition (CredDef)
A machine-readable definition of the semantic structure of a Credential based on one or more Schemas. Credential Definitions are stored on the cheqd Network. Credential Definitions must include an Issuer Public Key. Credential Definitions facilitate interoperability of Credentials and Proofs across multiple Issuers, Holders, and Verifiers.
Credential Exchange
A set of Interaction Patterns within an Agent-to-Agent Protocol for exchange of Credentials between Entities acting in Credential Exchange Roles.
Credential Exchange Layer
The technical infrastructure Layer for Credential Exchange.
Credential Offer
An Agent-to-Agent Protocol message type sent from an Issuer to a Holder to invite the Holder to send a Credential Request to the Issuer.
Credential Registry
An Entity that serves as a Holder of Credentials issued by Trust Community Members in order to provide a cryptographically verifiable directory service to the Trust Community or to the public. The term also refers to the actual repository of Credentials maintained by this Entity. An informal Credential Registry may accept Credentials from participants whose purpose is to cross-certify each other’s roles in the Trust Community. A formal Credential Registry may be authorized directly by a Governance Authority or Accredited by an authorized Auditor for the relevant Governance Framework.
Credential Request
An Agent-to-Agent Protocol message type sent from a Holder to an Issuer to request the issuance of a Credential to that Holder.
Cryptocurrency
A digital currency in which transactions are verified and records maintained by a decentralized system using cryptography, rather than by a centralized authority.
Cryptographic Trust
Trust bestowed in a set of machines (Man-Made Things) that are operating a set of cryptographic algorithms will behave as expected. This form of trust is based in mathematics and computer hardware/software engineering. Compare with Human Trust.
Data Controller
Data Processor
Data Protection by Design
Data Subject
Decentralised identity
Synonymous with Self-Sovereign Identity, decentralised identity refers to the control and management of identity Credentials, Claims and Attributes by an Entity which the data contained in the Credentials, Claims and Attributes is about.
Decentralised Identifier (DID)
Delegate
This term has two meanings in different contexts. Firstly, it can mean an Identity Controller that acts on behalf of another Identity Controller to assist or manage Credentials, Claims or Attributes on behalf of that secondary Identity Controller.
Delegate
Secondly, it can mean delegating tokens for the purpose of participating in cheqd on-chain Governance. Delegating tokens means bonding tokens to a specific Node Operator.
DID
Acronym for Decentralized Identifier.
DID Communication
Synonym for Agent-to-Agent Protocol.
DID Document
DID Method
DID Resolver
DID Subject
The Entity identified by a DID.
DKMS
DKMS Protocol
A subset of the Agent-to-Agent Protocol that enables Agents to perform DKMS functions for interoperable digital Wallet management, e.g., key exchange, automated backup, offline recovery, social recovery, etc.
Edge Agent
An Agent that operates at the edge of the network on a local device, such as a smartphone, tablet, laptop, automotive computer, etc. The device owner usually has local access to the device and can exert control over its use and authorization. Mutually exclusive with Cloud Agent. An Edge Agent may be an app used directly by an Identity Owner, or it may be an operating system module or background process called by other apps. Edge Agents typically do not have a publicly exposed Service Endpoint in a DID Document, but do have access to a Wallet. Note that the local device may itself be an Active Thing with its own Agent, and for which the Identity Owner is the Thing Controller.
Edge-to-Edge Connection
A Connection that forms and/or communicates directly between two Edge Agents.
Entity
Entropy
The determinate and irreversible transition of the cheqd Network’s application of Governance from centralisation to decentralisation.
Fee
A proportion of Network transaction costs that is taken used to remunerate Network participants or the Community Pool.
Gas
Gas refers to the fee, or pricing value, required to successfully conduct a transaction or execute a contract on a blockchain.
Genesis Parameters
The initial Network parameters governing how cheqd works at an architectural level.
Governance
Governance is a way of regulating behaviour and ensuring order in a given system. We think of it as a melting pot with Principles, Laws, Economics and System Design as the ingredients.
Governance Authority (GA)
The Entity (typically an Organization) governing and making decisions related to a particular Governance Framework. cheqd does not have a Governance Authority in its traditional sense, its governance is conducted by the distributed consensus of the Network itself.
Guardian
An Identity Controller who administers Identity Data, Wallets, and/or Agents on behalf of a Dependent. A Guardian is different than a Delegate—in Delegation, the Identity Controller still retains control of one or more Wallets. With Guardianship, an Identity Controller is wholly dependent on the Guardian to manage the Identity Controllers' Wallet.
Holder
A role played by an Entity when it is issued a Credential by an Issuer. The Holder may or may not be the Subject of the Credential. (There are many use cases in which the Holder is not the Subject, e.g., a birth certificate where the Subject is a baby and both the mother and father may be Holders.) Holders are also those who own and hold CHEQ.
Hyperledger
Hyperledger Aries
Provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. It is infrastructure for blockchain-rooted, peer-to-peer interactions.
Hyperledger Indy
An open source project under the Hyperledger umbrella for decentralized Self-Sovereign Identity. The source code for Hyperledger Indy was originally contributed to the Linux Foundation by the Sovrin Foundation. cheqd does not use Hyperledger Indy for its Network, instead it uses Cosmos.
Hyperledger Ursa
A shared cryptographic library that would enable people (and projects) to avoid duplicating other cryptographic work and hopefully increase security in the process.
Identifier
A text string or other atomic data structure used to provide a base level of Identity for an Entity in a specific context. In Self-Sovereign Identity systems, Decentralized Identifiers (DIDs) are the standard Identifier.
Identity Data
The set of data associated with an Identity that permits identification of the underlying Entity.
Identity Controller
The person, organisation, group or thing that retains control over the Private Key(s) relating to specific identity data.
Interaction
A set of messages exchanged over a Connection using an Agent-to-Agent Protocol.
Issuer
JSON
Open standard data format used for some Verifiable Credentials
JSON-LD
Open standard data format used for some Verifiable Credentials, specifically for linking data to other datasets.
Key Recovery
The process of recovering access to and control of a set of Private Keys—or an entire Wallet—after loss or compromise. Key Recovery is a major focus of the emerging DKMS standard for cryptographic key management.
Layer 1
The core, foundational infrastructure that an SSI ecosystem is built upon. In cheqd's case, the cheqd Network is Layer 1.
Layer 2
Within blockchains a Layer 2 is a separate ledger running adjacent to the Layer 1. Layer 2 Networks are used for efficiency and scaling. The outcome of Layer 2 transactions and interactions are recorded periodically back into Layer 1.
Level of Assurance (LOA)
A measure, usually numeric, of the Trust Assurance that one Entity has in another Entity based on a defined set of criteria that establish the amount of reliance the first Entity may accept from the second Entity in the performance of the criteria. LOAs are often defined in or referenced by Governance Frameworks.
Liquidity pool
Pools of tokens locked in smart contracts that provide liquidity in decentralized exchanges in an attempt to attenuate the problems caused by the illiquidity typical of such systems.
Main net
cheqd's Network has both a test net and a main net. The main net is the Network where live and public transactions will take place after launch.
Minumum deposit
The minimum amount of tokens needed for a governance proposal to reach the stage where it is voted upon.
Mint
Minting a token simply means creating a token on-ledger
Node
A computer network server running an instance of the code necessary to operate a distributed ledger or blockchain. In cheqd Infrastructure, a Node is operated by a Node Operator running an instance of the cheqd Open Source Code.
Node Operator
The Entity responsible for running a node.
Open Governance
A governance model in which the Governance Authority is open to public participation, operates with full transparency, and does not favor any particular contributor or constituency.
Open Source License
Open Standards
Technical standards that are developed under an Open Governance process; are publicly available for anyone to use; and which do not lock in users of the standard to a specific vendor or implementation. Open Standards facilitate interoperability and data exchange among different products or services and are intended for widespread adoption. Many Open Standards have implementations that are available under an Open Source License.
Organization
A legal Entity that is not a natural person (i.e., not an Individual). Examples of Organizations include a Group, sole proprietorship, partnership, corporation, LLC, association, NGO, cooperative, government, etc. Mutually exclusive with Individual.
Overlay
A data structure that provides an extra layer of contextual and/or conditional information to a Schema. This extra context can be used by an Agent to transform how information is displayed to a viewer or to guide the Agent in how to apply a custom process to Schema data.
Pairwise
A direct relationship between exactly two Entities. Most relationships in the cheqd ecosystem will be likely Pairwise, even when one or both Entities are not Individuals. For example, business-to-business relationships are pairwise by default. A DID or a Public Key or a Service Endpoint is Pairwise if it is used exclusively in a Pairwise relationship. Pairwise relationships can exist entirely off-ledger.
Payment
A transfer of CHEQ or other cryptographically verifiable units of value from one Entity to another Entity.
Payment Address
The address of a Payment Transaction on the cheqd Network.
Permissionless
Permissionless blockchains are blockchains that require no permission to join and interact with.
Personal Data
Privacy by Design
Private Key
The half of a cryptographic key pair designed to be kept as the Private Data of an Entity. In elliptic curve cryptography, a Private Key is called a signing key.
Proof
Proof request
The data structure sent by a Verifier to a Holder that describes the Proof required by the Verifier.
Pseudonym
A DID used to prevent correlation outside of a specific context. A Pseudonym may be Pairwise, N-wise, or Anywise.
Public Key
The half of a cryptographic key pair designed to be shared with other parties in order to decrypt or verify encrypted communications from an Entity. In digital signature schemes, a Public Key is also called a verification key. A Public Key may be either Public Data or Private Data depending on the policies of the Entity.
Quorum
The minimum number of participants in the Network who need to vote on a governance proposal for the vote to be valid.
Recovery Key
Recovery Key Trustee
A Trustee trusted by another Identity Controller to authorise sharing back a Recovery Key for purposes of restoring a Wallet after loss or compromise.
Relying Party
An Entity that consumes Identity Data and accepts some Level of Assurance from another Entity for some purpose. Verifiers are one type of Relying Party.
Resolver
Revocation
The act of an Issuer revoking the validity of a Claim or a Credential.
Revocation Registry
An online repository of data needed for Revocation. In cheqd's Network Infrastructure, a Revocation Registry is a privacy-respecting cryptographic data structure maintained on the Ledger by an Issuer in order to support Revocation of a Credential.
Schema
A machine-readable definition of the semantics of a data structure. Schemas are used to define the Attributes used in one or more Credential Definitions.
Security by Design
Selective Disclosure
A Privacy by Design principle of revealing only the subset of the data described in a Claim, Credential, or other set of Private Data that is required by a Verifier.
Self-Sovereign Identity (SSI)
An identity system architecture based on the core principle that individual Identity Controllers have the right to permanently control one or more Identifiers together with the usage of the associated Identity Data.
Service Endpoint
Slashing
The potential deduction of tokens for bad behaviour on the Network.
SSI Stack
Staking
In order to participate in cheqd Network governance, participants must allocate a proportion of their tokens to float on the Network. Staking is required to validate transactions and earn Staking rewards.
Sufficient decentralisation
The point at which the cheqd Network is spread amongst enough nodes that no one node is directly accountable for decisions on the Network. This is reached through the increasing of Entropy.
Token
A medium of interaction, either for pure utility or for payment transactions.
Tokenomics
The fundamental code and parameters that determines how the Network architecture runs.
Tombstone
A mark associated with a Transaction to suggest that the Transaction should no longer be returned in response to requests for read access.
Transaction
A record of any type written to the cheqd Network.
Verifiable Credential
A Credential that includes a Proof from the Issuer. Typically this proof is in the form of a digital signature.
Verifier
An Entity who requests a Credential or Proof from a Holder and verifies it in order to make a trust decision about an Entity.
Verinym
A DID that it is directly or indirectly associated with the Legal Identity of the Identity Controller.
Wallet
A software module, and optionally an associated hardware module, for securely storing and accessing Private Keys other sensitive cryptographic key material, and other Private Data used by an Entity. A Wallet is accessed by an Agent.
Zero Knowledge Proof
A Proof that uses cryptography to support Selective Disclosure of information about a set of Claims from a set of Credentials. A Zero Knowledge Proof provides cryptographic proof about some or all of the data in a set of Credentials without revealing the actual data or any additional information, including the Identity of the Holder.
A relatively new term, intended to replace 'Self-sovereign identity'. It relates to signed, verifiable and cryptographically resolvable data using the .
As defined by the (GDPR), the natural or legal person, public authority, agency, or other body which, alone or jointly with others, determines the purposes and means of the processing of Personal Data.
As defined by the (GDPR), a natural or legal person, public authority, agency, or other body which processes Personal Data on behalf of a Data Controller.
A widely recognized for protecting Personal Data. Specific cheqd Data Protection by Design principles are a subset of the General Principles in the cheqd Governance Framework.
As defined by the (GDPR), any person whose Personal Data is being collected, held, or processed. In the cheqd Governance Framework, a Data Subject is referred to as an Individual.
A globally unique identifier developed specifically for decentralized systems as defined by the . DIDs enable interoperable decentralized Self-Sovereign Identity management. A DID is associated with exactly one DID Document.
The machine-readable document to which a DID points as defined by the . A DID document describes the Public Keys, Service Endpoints, and other metadata associated with a DID. A DID Document is associated with exactly one DID.
A specification that defines a particular type of DID conforming to the . A DID Method specifies both the format of the particular type of DID as well as the set of operations for creating, reading, updating, and deleting (revoking) it.
A software module that takes a DID as input and returns a DID document by invoking the DID Method used by that particular DID. Analogous to the function of a .
, an emerging standard for interoperable cryptographic key management based on DIDs.
As used in , a resource of any kind that can be uniquely and independently identified.
An initiative of the to develop open source distributed ledger and blockchain technology. The Hyperledger home page is .
The Entity that issues a Credential to a Holder. Based on the definition provided by the .
Any form of intellectual property license approved and published by the .
As defined by the , any information relating to an identified or identifiable natural person. In the GDPR, this natural person is called the Data Subject. Personal data SHOULD never be written to the cheqd Network.
A set of for taking privacy into account throughout the entire design and engineering of a system, product, or service. Originally defined by the .
Cryptographic verification of a Claim or a Credential. A is a simple form of Proof. A is also a form of Proof. Zero Knowledge Proofs enable of the information in a Credential.
A special Private Key used for purposes of recovering a Wallet after loss or compromise. In the DKMS key management protocol, a Recovery Key may be cryptographically sharded for .
A software module that accepts an Identifier as input, looks up the Identifier in a database or ledger, and returns metadata describing the identified Entity. The Domain Name System (DNS) uses a . Self-Sovereign Identity uses a DID Resolver.
A widely recognized for building security into systems, products, and services from the very start.
An addressable network location offering a service operated on behalf of an Entity. As defined in the , a Service Endpoint is expressed as a .
A general representation of different technological functions and protocols that provide different functions on top of each other. The most common SSI stack is the .
cheqd will launch with community-spend capabilities, allowing CHEQ Participants to approve spending from the Community Pool. This documentation is in active development, so please seek feedback and take care when using this information.
The community pool value is accumulated over time.
10% of all staking rewards generated (via block rewards & transaction fees) are continually transferred to and accrue within the Community Pool.
You can always see the balance of the cheqd Community Pools on one of our Block Explorers. Our main block explorer is here:
Funds from the cheqd Community Pool may be spent via successful governance proposal.
The prevailing assumption is that funds should be spent in a way that brings value to the cheqd Network. Or alternatively, something which benefits the wider world, such as spending the Pool on Carbon offset and sustainability.
If a community-spend proposal passes successfully, the number of $CHEQ encoded in the proposal will be transferred from the community pool to the address encoded in the proposal, and this will happen immediately after the voting period ends.
Drafting and submitting a proposal is a process that takes time, attention, and involves risk. The objective of this documentation is to make this process easier by preparing participants for what to pay attention to, the information that should be considered in a proposal, and how to reduce the risk of losing deposits. Ideally, a proposal should only fail to pass because the voters:
are aware and engaged
are able to make an informed decision to vote down the proposal.
If you are considering drafting a proposal, you should review the general background on drafting and submitting a proposal:
There are five (5) components:
Title - the distinguishing name of the proposal, typically the way the that explorers list proposals
Description - the body of the proposal that further describes what is being proposed and details surrounding the proposal
Recipient - the cheqd address that will receive funding from the Community Pool
Amount - the amount of funding that the recipient will receive in nanoCHEQ ("nCHEQ")
Deposit - the amount that will be contributed to the deposit in nanoCHEQ ("nCHEQ") from the account submitting the proposal
You should use our forum for Community Spend Proposals to discuss the Proposal with the cheqd community:
In this simple example (below), a network explorer will list the governance proposal as "Community Pool Spend." When an observer selects the proposal, they'll see the description. Not all explorers will show the recipient and amount, so ensure that you verify that the description aligns with the what the governance proposal is programmed to enact. If the description says that a certain address will receive a certain number of CHEQ, it should also be programmed to do that, but it's possible that that's not the case (accidentally or otherwise).
The amount is 1000000000ncheq. 1 billion nano-cheq is equal to 1 CHEQ, so recipient address cheqd1qgfdn8h6fkh0ekt4n4d2c93c5gz3cv5gce783m will receive 1 CHEQ if this proposal is passed.
The deposit 8000000000000 ncheqresults in 8000 CHEQ being used from the proposal submitter's account. There is a minimum deposit required for a proposal to enter the voting period, and anyone may contribute to this deposit within a 7-day period. If the minimum deposit isn't reach before this time, the deposit amounts will be burned. Deposit amounts will also be burned if quorum isn't met in the vote or if the proposal is vetoed.
