Creds are verifiable credentials, a portable, reusable, private, and secure way to build reputation and prove that you’re real (and not AI). Unlike NFTs and SBTs, Creds are private, revocable, and can be taken between different platforms and ecosystems.

Learning journeys

Get started by learning about what cheqd and Creds are and how the technological building blocks underpin the products.

Core concepts

Familiarise yourself with the core concepts around decentralised identity and how the $CHEQ token works within this technological ecosystem.

Get started with our Products

cheqd has a series of Products, ranging from Credential Service to Creds.xyz. Get started with tutorials and guides on how to use them.

Contribute to the Network

Understand cheqd's Governance Framework, including how to delegate your tokens, vote and participate in cheqd Network governance.

Explore the cheqd ecosystem

Use our different block explorers to view network transactions, delegations, governance proposals and community pool spends.

Setup your wallet

When using the cheqd network, both testnet and mainnet, you will need to hold tokens to pay for the transaction. In this guide we offer options for setting up a wallet and adding cheqd's mainnet and testnet.

More on CHEQ

A Verifiable Data Registry ("VDR"), in the context of decentralised identity, is a place where Decentralised Identifiers (DIDs) can be anchored to.

Types of Verifiable Data Registries

Blockchain

Commonly, VDRs are blockchains, like cheqd. This is because they are great places to store data immutably.

Web domain

However, a VDR could also be a web domain, like . We could store a public DID on this website, because only the admins of cheqd have the ability to edit this.

This is largely secure, but is not as resilient as a blockchain, because, for example, the hosting provider for the website could take it down.

Sidetree

New innovations in decentralised identity have tried to create a more flexible storage layer for DIDs. Sidetree is a technology which stores DIDs and DID Documents in a temporary Layer 2 storage layer called Sidetree. This data is stored in IPFS, batched and anchored to blockchains in rollups. This minimises the amount of transactions necessary to be made to the Layer 1 blockchain.

Hypothetically, by storing DIDs in a temporary storage Layer 2, with backups in IPFS, the DID could also be updated from being stored on one VDR to another VDR. This is currently the exploratory work of did methods such as did:orb.

KERI

KERI, meaning Key Event Rotation Infrastructure, is another emerging innovation in decentralised identity. Rather than anchoring a DID to a specific location or block within a chain, KERI relies on nodes witnessing Key Event Logs (KELs). A KEL may hold an authoritative source of truth about what the latest keys related to a DID are, and who holds them.

In simple terms, KERI's logs are not immutable like a blockchain, but rely on the law of large numbers, and trust that KERI witnesses will act in a trustworthy fashion - providing the most up to date KELs with the correct Key events.

Further reading

A DID method is defined by a DID method specification, which specifies the precise operations by which and are created, resolved, updated, and deactivated.

There are currently over 100 DID methods, but only a few which should have working DID Resolvers and DID Registrars.

Further reading

What is Decentralised Identity?

Decentralised Identity, otherwise known as Self-Sovereign Identity ("SSI") is an emerging technology that enables individuals and/or organizations to maintain direct control of data relating to them, with the ability to explicitly consent to where it is shared, used and processed.

Decentralised identity aims to create a trusted data economy, where it is possible to verify, check and trust exactly who you are interacting with, in both physical and digital domains.

Through this data model, it is possible to:

• Reduce fraud, scams and phishing attempts online through digital identity proofs;

• Increase efficiency of signing up for new services, accessing events or proving attributes about yourself;

• Eliminate the need for hundreds of passwords;

• Empower individual privacy and GDPR data subject rights by design;

• Increase accountability in digital environments, minimising trolls and hate speech.

Get started

Learn about the core building blocks of decentralised identity:

What is the Trust Triangle?

Any distinct model of decentralised identity revolves around three specific actors: the issuer, the holder and the verifier. Together, these three actors constitute what is known as the Trust Triangle.

Let’s discuss these three in turn:

Who are Issuers?

However, an issuer could also quite easily be a friend, family member or even a local café. In fact, in the DeFi world, issuers could be those who you have interacted with online who attest to something about you.

Who are Holders?

Who are Verifiers?

Understanding the basics of the trust triangle

The following image shows the basic flow of how SSI works, without getting into the technical details.

Let's run through this flow in turn.

1. Trust anchor: Issuer registers a digital signature to the blockchain

One of the most important components of SSI, is understanding what goes on the blockchain and what does not.

In this first step, the issuer anchors a public signature to the blockchain in the form of a Decentralised Identifier (DID) and DID Document. In non-technical terms, the information contained in this signature is a statement from the issuer saying:

"Hey, this is my digital signature and signing keys that I am openly publishing to the world. This will help verifiers trust that if they see a digital signature within data they are presented, they can check whether it is mine or not."

The issuer may also publish what is known as a Schema, which is a list of the types of attributes there will be listed in a Credential that it issues. Schemas are useful for Credential interoperability.

2. Peer-to-peer connection: Issuer sends signed, verifiable data to the holder

To do this, the issuer needs to establish a secure off-chain, peer-to-peer connection channel with the holder. This is to preserve privacy and ensure that no personally identifiable information goes onto the blockchain.

A holder may use a digital identity wallet app to scan a QR code from the issuer to create a pairwise relationship.

Through this secure channel, an issuer will send a Verifiable Credential. This Credential is a packet of data which is tamper-proof and verifiable. Within the Credential will be the public signing keys and signature of the issuer, present in the DID Document (written to the ledger in step 1).

The Credential may also reference a particular schema, which the structure of its contents mirrors.

3. Self-Sovereignty: Holder can hold, control and consent to where their data is used

Once the Credential is sent to the holder, they now have a signed, verifiable and trustworthy instance of their data in a digital wallet that they control.

Digital identity wallet apps will have user interface which helps arrange different data by type and by substance, making it easy for the holder to have a holistic view of all their Credentials.

The holder is now empowered with full control and management capabilities over their personal data. The holder can consent and directly choose when their data is shared.

4. Peer-to-peer connection: Holder can share trustworthy data with a third party verifier

Once again, if the holder wants to share their data with a third party, another peer-to-peer channel needs to be created with a verifier. In a similar process, the holder might use their wallet app to scan a QR code from the verifier to create a secure, off-chain communications channel.

Once this channel is established, the verifier may request a selection of data from the holder.

The holder will be able to choose whether it wants to accept the request and will be able to explicitly consent to what data is shared with the verifier.

5. Decentralised trust: Verifier trust the issuer's signature in the data received

As mentioned in Step 2, the Credential that the holder presented to the verifier contained the signing keys and digital signature of the issuer.

Using the blockchain, and a process called DID Resolution, the verifier is able to check whether the signature and signing keys in the data received, correlates with what is published in the issuer's DID Document.

The verifier may also check the schema referenced in the credential, to check that all the correct attributes are present, and to also make it easier for the verifier to receive similar Credentials in the future, given there may be a common format.

The process of DID Resolution builds a chain of decentralised trust between the issuer, holder and verifier - without the issuer and verifier needing to have a direct relationship with each other.

Why is the Trust Triangle important?

The Trust Triangle enables a verifier to be able to trust data it receives from a holder without having to have any direct interaction or relationship with the issuer.

It also empowers the holder to maintain total control of their data and where it is used, through decentralised trust, utilising Decentralised Identifiers ("DIDs") and Verifiable Credentials ("VCs").

This is incredibly powerful for establishing trusted interactions at a large scale.

cheqd is a blockchain network, built in the , designed to do three core things:

1. To enable people and organisations to have digital, trustworthy interactions directly with each other, whilst maintaining privacy and without any centralised registry or organisation needed;

2. To facilitate new business models for and Verifiable Credentials, through the use of our token, $CHEQ;

3. To bridge the DeFi ecosystem with the ecosystem, for better user experiences, democratic governance, regulatory compliance and operational efficiency.

Can you explain the value here using an example?

This is you.

Digital identity is something that we rarely think about in our day-to-day lives, but it is something that we all have subscribed to.

Yet, currently, the average person, and likely you reading this, has over 150 accounts online, each with a separate username, password and security process.

Think of the likes of Facebook, X (Twitter), Instagram, Signal, Amazon, Telegram, Deliveroo, Uber... the list goes on.

Every time we open an account online, to use a service, buy something online, use social media, or even just browse the internet, we are creating a digital footprint for ourselves, which feeds into a digital profile.

And each of these different accounts holds personal data about you, such as your name, age, photographs, sex, gender etc., and also various preference data, such as what you browse, like, share or click on.

What is the problem with this?

These digital profiles are generally secured behind a password, meaning that you feel a level of confidence that you have control over them.

However, in reality this is not the case.

Our data is stored across multiple gated siloes, and every time we want to access this data, we need to prove to the gatekeeper that we are who we claim to be through an authentication process.

In other words, every time you want to get access to your own digital identity data, you need to get through a locked door using a key.

We play out this sequence multiple times a day:

Person: "Hello there, can I please get into my account to view my own data please".

Company: "Ahhh maybe, if you have the password and key you can get in, otherwise nah, you can't have your data today".

Company: "HAVE YOU SEEN THIS NEW VIDEO OF A BABY MONKEY RIDING A PIG?"

Person: "That is some GREAT content, have some more of my preference data, I don't really care - I love it, thanks"

Company: *sweats advertisement money*

This is the digital sphere we have all become accustomed to, without really being aware of, or presented an alternative. Companies do monetise your data and do use your data to create specific digital profiles for you. But we are somewhat comfortable with this because we get to use a seemingly free digital service. For this reason, we feel a level of content sacrificing a little bit of privacy for a whole lot of convenience.

However recently, this model has led to two further issues:

1. Convenience becomes inconvenient:

As we get more and more accounts, remembering and managing passwords becomes increasingly difficult. Too many times we are faced with a popup, saying something along the lines of “Hold up, before you access this service we need to ask you some questions to verify that you are who you claim to be.”

And because it's getting more difficult to manage, we end up using the same password to access multiple accounts, which leaves the door open for scammers, hackers and fraudsters to easily phish the password away and obtain our digital assets.

This constant battle to access one’s own accounts and data is frustrating, and only becoming increasingly so. And we at cheqd believe that it’s outdated.

2. Lack of trust online has become normalised:

If you are asked to prove who you are to someone online, there is no existing way of doing this. Whilst in the physical world we have verifiable documents such as passports and driving licenses which contain trusted, safety features such as watermarks and common semantics, in the digital world we have nothing of the sort.

If I meet someone on social media, an eCommerce platform or a dating website, I have no simple way to verify that the person is who they claim to be. Why is this the case? Even though I have hundreds of accounts online, and many of them even require a Know Your Customer (KYC) procedure, I never hold that verified data. Companies hold that verified data... and they monetise it.

cheqd and decentralised identity

Over the last few years, there has been a big push for individuals to have greater control, autonomy and sovereignty over their own data.

Instead of companies managing data indirectly, on your behalf, it is now possible to hold your own data securely in a digital wallet.

This type of technology has been labelled by the industry as decentralised, or Self-Sovereign Identity (SSI).

Importantly, this data is cryptographically signed by a person or company that issues it to you. The data itself is secured with a digital trustworthy signature.

And you can share this with third parties to prove trust in your own data, identity and attributes.

This does a few things.

1. It re-centres control of data around an individual (or company, thing: real or virtual);

2. It enables far greater trust in digital interactions;

3. It becomes far easier to access new services with bi-directional trust and confidence.

And the use cases and projects of this technology are growing rapidly...

How does it work in practice?

Learn more about the core building blocks for decentralised identity ecosystems:

JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale.

Linked Data empowers people that publish and use information on the Web. It is a way to create a network of standards-based, machine-readable data across Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web.

Using JSON-LD Credentials

The main difference between JSON-LD credentials and JSON credentials is the inclusion of a @context field within the credential payload.

In JSON-LD, the @context property can also be used to communicate other details, such as datatype information, language information, transformation rules, and so on, which are beyond the needs of this specification, but might be useful in the future or to related work.

Example of the JSON-LD @context section

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2020-05-01T06:09:10Z",
  "credentialSubject": {
    "id": "did:cheqd:c822493c-9728-4279-bc88-a03904fff8b2",
    "alumniOf": {
      "id": "did:cheqd:66694a94-b6b3-4731-ab65-dc80bb24e58d",
      "name": [{
        "value": "cheqd University",
        "lang": "en"
      }, {
        "value": "cheqd d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": {  }
}

In order to explain the concept of Verifiable Credentials, we have put together a simple explainer using the concept of an email with attachments.

Further reading

More more of a detailed and deeper understanding, we suggest starting with these external resources.

Overview

There are multiple types of Verifiable Credentials, each with their own set of benefits and features:

cheqd has built a Resources Module to extend the functionality of our decentralised identity network, providing capabilities not found on other self-sovereign identity networks.

A DID-Linked Resource is a blob of information stored on-ledger, discoverable through the same syntax that is widely used within the SSI industry.

What issues do DID-Linked Resources solve?

Centralisation

Many SSI resources such as schemas currently reference web URLs such as . Other areas where this can be issues are:

• DID methods, such as and , where trust is based on Web 2.0 infrastructure

• Revocation lists maintained on servers, such as

If, for example, any of the infrastructure listed above was to experience downtime due to technical faults, a dDoS attack or a failure of a cloud hosting provider, this could hugely disrupt the proper use of Verifiable Credentials in a production environment.

Link Rot and Longevity

Such web URLs as described above are also single-points of failure due to .

Credential schemas, once defined, should be able to be used and referenced for many years, without being changed. For this reason, keeping an up-to-date version of the links themselves is crucial. Moreover, if the schema locations are moved and the links are broken, the Credentials issued become far less trustworthy.

Semantic Linkage

The way schemas are currently referenced from web URLs (e.g., schema.org/Person) is not immutable. Schemas may be changed and previous schema definitions may be purged from the database. This means if you had a Verifiable Credential issued in 2015 which referred to a particular schema in 2022, that schema definition may have significantly changed.

On the other hand, solutions that do currently store schemas on ledger (e.g., Hyperledger Indy) don't have semantic linkage between old and new versions. In this instance, current ledgers allow new versions to be made but don't offer an easy way for client apps to discover linkages as they evolve over time.

Use cases for DID-Linked Resources

The use of Resources is potentially very broad; they can provide many different roles, such as:

• A schema, such as Camenisch-Lysyanskaya ("CL") schema ‘CL’, JSON-LD schema, JSON schema etc.

• A document, such as a Governance Framework

• An branding elements, such as a company logo, brandmark, etc which can be pulled directly by block explorers and other Web3 applications

• A revocation registry for revoking already-issued credentials.

Through extending the use of DIDs to identify other on-ledger resources, trust can begin to be chained.

New use cases enabled by DID-linked Resources

You can think of it as a hyperlink for #Web3. But unlike a hyperlink, it is possible to specify the type of resource to be retrieved, and reject anything unexpected.

A Verifiable Presentation is a combination of , bundled together into a format to present to a third party.

Like VCs, Verifiable Presentations contain proofs (i.e. they can be signed with cryptographic keys). In this regard, a major difference between VCs and Verifiable Presentations is that Verifiable Presentations are signed with cryptographic keys of the holder to prove, for example, that the actor who is sharing the Verifiable Presentation is also the credential subject of the underlying VCs.

With some credential formats like AnonCreds, holders can freely choose which information (from underlying VCs) they include in a Verifiable Presentation and thus, share with a relying party. It is even possible for holders to prove to a relying party that they possess a certain attribute or fulfil certain conditions without disclosing details (e.g. the proof that one is older than 18 without revealing the real age) via so-called 'Zero Knowledge Proofs'.

There are multiple standards used for Verifiable Presentations, that will be listed below:

Aries Present Proof

Presentation Exchange 2.0.0

A "", in an everyday sense, is an attestation, evidence or proof of qualification, competence or authority issued to an entity, either individual or person, by a third party with relevant authority or assumed competence to do so. This may be evidence of authority, status, rights, entitlement to privileges, or the like, usually in a written form.

Historically, we have relied on public issuing bodies to verify our identities — i.e. passports, driving licence, birth certificates, etc. These credentials go on throughout our lives, being issued to us or requested by us at times we need them. We provide them to others regularly, without ever wondering what happens to them, where they now sit, and how long they’ll be retained.

Essentially credentials are a means to verify identity.

What is a Verifiable Credential?

A Verifiable Credential ("VC") is a tamper-evident data file with a set of claims about a person, organisation, or thing that can be cryptographically verified. These verifiable credentials can be used to build , which can also be cryptographically verified.

Okay, stop there, let's simplify what this technical language means.

A familiar concept: Email

Let's imagine something we're all familiar with.

Here's a classic email with some attachments.

This is how most people are familiar with sending information about themselves digitally.

I am sure everyone reading this has had to attach a photocopy of their passport to an email, in order to prove that they are who they claim to be. Or alternatively, has attached their CV to an email to prove their work and education records, either as a word document or PDF.

The problem with this system, is that it is not currently possible to check the validity of an attachment sent via email. Word Documents, PDFs, JPEGs etc have no security features that allows a third party to check if they were legitimate or not.

Let's take the example of the CV. You receive it as an attachment, you read it, and to check the validity you need to contact the references which are generally at the bottom of the CV to check whether this person really did all the things they claim to have done.

This is time consuming, and frequently, owing to the lack of trust in these data formats, can be susceptible to fraud.

How do Verifiable Credentials change this?

A Verifiable Credential is a digital file that stores data. However, importantly it is designed to hold two core types of data:

• Claims

A claim is an attestation about something. It could say that "I went to Oxford University".

• Proofs

The verification key material and the Decentralised Identifier ("DID") enable the issuer to essentially sign the claims in the credential, to vouch for their autheneticity.

Why is this useful and important?

Verifiable Credentials change the way that data can be trusted when presented. This is because when you receive a Verifiable Credential, you are able to check, without contacting another party:

1. Whether that data was issued by a specific issuer;

2. That the data hasn't been tampered.

Unlike attachments in an email, which are data files that need to be independently verified, to trust their contents; Verifiable Credentials enable that verification innately, through the use of Decentralised Identifiers. This is a powerful component for building trust in a decentralised Web 3.0.

Therefore, you can reach the definition:

A Verifiable Credential ("VC") is a tamper-evident data file with a set of claims about a person, organisation, or thing that can be cryptographically verified. These verifiable credentials can be used to build Verifiable Presentations, which can also be cryptographically verified.

For more information, please see the Verifiable Credential Data Model Specification below:

It is easy to think of DIDs as identifying something in the same way as how a registration plate identifies a car, and a car's owner.

To take an example, this is James Bond's Aston Martin DB5.

James Bond's Aston Martin has a unique identifier, the license plate, identifying the owner of the car and also the features of the car:

Similarly, a DID is a unique identifier, identifying the DID subject (a person, company or thing), and providing information about the DID subject.

Both identifiers can be checked against a registry in order to provide verifiable information about the thing that the identifier is identifying.

The process for withdrawing the information from the DID is very similar to the license plate number: through resolving a DID to get information about the DID Document.

Why are these identifiers important?

License plates and DIDs both give third parties a high degree of trust and confidence in who/what they are interacting with.

To understand what we mean here, let's look at the following scenario:

If James Bond rocked up to a swanky spy party in his DB5, and someone were to accuse him of stealing the car, how could he prove ownership and control of it?

Well, James Bond can likely prove control and ownership of that car in 3 main ways:

1. The license plate is on James Bond's car. And the unique registration plate BMT 216A will be linked to Mr Bond's identity through a registry, such as the DVLA. Anyone is able to check that the registration details of the car match it's visual features, and authorised persons are able to check whether James Bond's identity matches the license plate.

2. James Bond holds the physical keys to unlock and use the car.

3. James Bond holds a physical document called a VC5 Logbook, which is a required document, alongside other identity documents, to update any of the information in the DVLA database.

This model uses the DVLA registry and the physical access/documentation about the car, as two separate layers of trust and assurance, meaning:

1. The BMT 216Alicense plate could be removed and placed on another car

2. James Bond's keys could be stolen

3. James Bond's VC5 Logbook could be stolen or forged

However, doing any of the above would not result in an ownership change on the DVLA registry.

Trust in Self-Sovereign Identity models works in a very similar way, where:

• A Decentralised Identifier (DID) is like the license plate

• A DID Document on a blockchain is like the DVLA registry

• A private cryptographic key is like the VC5 Logbook

• Authenticating using the keys in the DID Document is like proving that you can open the car with your set of keys

Of course, there is a lot of complexity here, so we will walk through each part in this learning documentation in simple terms.

Analogy: Resolving a License plate number

The equivalent to searching a registration plate number on a DVLA indexing site, is resolving a DID through a DID resolution method.

When you want to search for a License Plate registration, you generally search the Registration number into an indexing service, such as the DVLA website below:

Through this search function, you are able to retrieve information about what the license plate refers to.

For example, with James Bond's license plate, the following information is fetched:

This creates a level of confidence in the fact that the registration plate belongs to the specific car, as a person could cross reference the listed features against the visual features of the car. Further, any competent authority would have the power to go one level deeper and tie the legal owner of the car to the license plate.

Resolving a DID

A DID at face value is a URL, which has the following composition:

Below, you can see the method for resolving a registration plate number, as well as the similar method for resolving a DID.

What does a DID Document contain?

An example of a DID Document is below, which explains various information about the DID subject. We will walk through this sequentially as it is quite technical and complex.

id

The id field at the top identifies the DID subject. Using the above analogy, the DID subject would be James Bond's Aston Martin DB5, because it is the entity that is identified by the identifier. In more general identity use cases, the DID subject could be an entity such as a car, but is usually a company or organisation.

verificationMethod

The verificationMethod, in this example, describes a cryptographic key or list of keys and the controller(s) of the key(s). Each Verification Key itself lists:

• an ID for the specific key;

• the controller, i.e., the identifier of the person or company with control over that key; and,

• the type of cryptographic key.

• the verification key material such as publicKeyMultibase

Going back to the above analogy, holding a private key for a certain cryptographic key pair is like holding the V5C logbook, as it enables DID Controllers to update/change/amend information about the ownership of the DID.

Without access to the verification keys, the ownership or control of the DID would not be able to change.

In reality, James Bond himself could have a specific verification key, his colleague "Q" could have a second specific key and the Secret Intelligence Service MI6, could have a third specific key. Each party would be known as a DID Controller, and would be able to update/change/amend the DID Document accordingly.

authentication

The authentication property is very important. This property enables only the DID subject to prove and authenticate who they are.

In our specific example, James Bond may be the only party that holds a Verification key, listed under the authentication property. This is almost analogous to holding the keys to the car. Using this property, if challenged about being the owner of the car, James Bond would have all the tools necessary to prove and authenticate the car, under this verification key for authentication.

service

The service field provides further information about where to contact the DID subject. In our analogy, this could point to a specific email address for help@MI6.com. This property is quite flexible, but importantly, it should not disclose any personally identifiable information.

There are also other useful fields which may be included in a DID Document, such as assertionMethod, keyAgreement, capacityInvocation and capacityDelegation. These are outside of the scope of this introductory information, and should be the topics of further reading.

The key difference between the use of something like the license plate registry and the use of DIDs, is the former relies on a centralised database, whereas, the latter relies wholly on decentralised trust and cryptographic key management.

This makes DIDs far more extensible, scalable and workable beyond jurisdictional borders.

Coming back to the important question

Earlier, I asked the rhetorical question: how can James Bond prove ownership and control of this car if someone was to challenge that it was his?

The next question is, how can James Bond prove control of his car, with the use of DIDs, DID resolution and verification keys?

James Bond still can likely prove control and ownership of that car:

1. The unique DID related to his Aston Martin DB5 will be registered on a Verifiable Data Registry, such as a blockchain.

2. Through using a DID Resolver to resolve the DID, a third party would receive a DID Document, containing verification keys.

3. The third party creates a challenge request to authenticate the DID, and James is able to use his private key to prove control of the public key listed in the DID document. This proves James has legal control of the car without reliance on a centralised party.

4. James Bond still holds the physical keys to unlock and use the car. He now also holds cryptographic keys to authenticate and prove ownership.

Through this method of DID resolution and authentication, people, organisations or objects can have a level of cryptographic trust in the identifiers relating to them, without reliance on traditional centralised models.

This is, and will continue to be, a core building block for Web 3.0 going forward.

JSON Web Token (JWT) is an open standard () that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

This information can be verified and trusted because it is digitally signed.

JWTs are widely used in legacy identity infrastructure, underlying the frameworks used by and . As such, there is a plethora of software libraries and toolkits for developers to build upon using JWT, making their adoption far more seamless than other Verifiable Credential formats.

AnonCreds are a type or flavour of Verifiable Credentials that were originally developed by the company , and were subsequently adopted by the as part of the 'Indy' codebase that was contributed to , a project. This codebase was forked into the project for ledger code, for cryptographic libraries, and the ledger-agnostic Hyperledger Aries codebase for agent, wallet, and credentialing code.

AnonCreds are now far more widely adopted, through organisations such as the , and the .

How are AnonCreds different to other Credential types?

AnonCreds were designed to provide additional privacy benefits, compared with JSON and JSON-LD based Verifiable Credentials. There are a series of differences that can be summarised as follows:

• Camenisch-Lysyanskaya (ZKP CL-Signatures): a Credential format which is not defined in the W3C Verifiable Credential Data Model. Rather it is a bespoke data expression format coupled with a particular digital signature algorithm.

• Link Secrets: A mechanism to link ZKP-CL credentials to DIDs, by including a DID for the holder in the credential’s schema. Holders can prove that Credentials are not tampered with and that they are authentic, since holders are the only party that knows the Link Secrets made at the point of issuance.

• Schemas: The schemas are defined in a document and they are written to an Indy ledger where they can’t be changed. To update a schema, a new version must be created and written to the ledger for future use. This schema is fetched from the ledger by verifiers when calculating the verification.

• Credential definitions: Each issuer of a Verifiable Credential must post a credential definition that says to the world, "I intend to publish credentials from schema X, signed using keys Y[0]...Y[N], and with revocation strategy Z". This helps verifiers prove that the Credential has not been tampered with.

• Predicate proofs: Through the use of link secrets and Indy schemas, it is possible to present an assertion, such as "date_of_birth is more than 18 years ago)", without revealing any additional information.

• Privacy preserving revocation: Using cryptographic accumulators and 'tails files', revocation statuses can be queried without creating a chain of correlation through which a user's privacy can be compromised.

The ZKP-CL processing model requires that the credential’s schema is defined and posted to an Indy ledger. The credential issuer follows the pre-defined schema. They leverage the CL Signature suite to sign each statement in the credential. The credential is anchored to a link secret that is known only to the holder (stored in the holder’s software), and when the holder is issued a credential, it packages up a cryptographic commitment to the link secret within another long number that the issuer uses for the credential ID.

A metaphor for this is that of a digital watermark; the link secret is like a stamp that is used to create a watermark. The stamp used to create the watermark is NOT packaged up or put in the credential in any form; all that is in the credential is very-hard-to-fake evidence that the holder possesses the stamp and is capable of generating such watermarks. Unlike non-ZKP methods, zero-knowledge methods generally do not share a correlatable identifier (such as a persistent or public DID) and also do not reveal actual signatures. Instead, they only reveal a cryptographic proof of a valid signature. This means the holder of the credential cannot be correlated just by presenting a proof of the credential (this is the primary privacy problem with public/private key cryptography that ZKP-CL Signatures were invented to solve over a decade ago).

All other non-ZKP Signature formats require a resolvable DID—which is a correlatable globally unique identifier—and also produce the same signature on all equivalent presentations, which is a second fully correlatable globally unique identifier

Why are AnonCreds a contentious issue?

AnonCreds have been the subject of heavy debate within the decentralized identity community for the following reasons:

• Interoperability: AnonCreds are intrinsically tied to Hyperledger Indy, and largely to Hyperledger Aries. Historically, they cannot be written to other Layer 1 Utilities, nor are they compliant with the W3C Verifiable Credential data model, given their core architectural differences. As such, this shoehorns adopters into a particular tech stack, which although open source, is largely reliant on the Indy/Aries community for updates, since there is no formal Standard.

• Scalability: The use of ZKP-CL signatures, whilst certainly containing benefits from a privacy perspective, are very large files which can lead to inefficiencies when used at scale in production environments.

• Hyperledger Indy has performance and scalability issues when it comes to running more than 25 nodes in terms of its throughput. Its method of revocation also generates very large files, which is very slow to compute in a low-latency environment.

What is Selective Disclosure?

Selective disclosure empowers an individual to decide which specific pieces of information, contained within a Verifiable Credential, will be disclosed to a verifier. This stands in contrast to the conventional practice of revealing all the data present in a Verifiable Credential.

For instance, Alice could selectively share only her age to confirm eligibility for purchasing products on an e-commerce platform, without divulging other personal details found in her Verifiable ID document used for verification. This approach enhances privacy and provides individuals with greater control over their personal data.

The Significance of Selective Disclosure

Selective disclosure is a crucial element of Self-Sovereign Identity (SSI) because it allows individuals to share only the essential personal information required for a transaction or interaction. This minimizes the risk of identity theft and various forms of fraud.

SD-JWTs: A Mechanism for Selective Disclosure

A Selective Disclosure JSON Web Token (SD-JWT) is a subtype of JSON Web Token wherein the claims within the body are hashed, rendering them unreadable without proper disclosure. The original values of the claims can be unveiled by providing the necessary disclosures.

How it Operates

When presenting a conventional credential via JWT, the claims are plainly visible to the verifier. In contrast, with an SD-JWT credential, claims are encrypted in a hashed format, ensuring their unreadability. The holder can then choose which claims to reveal to the verifier by providing plain text key-value pairs (referred to as disclosures) alongside the SD-JWT. The verifier can hash these disclosures and compare them to the values in the SD-JWT, thereby verifying the inclusion of the claim in the SD-JWT. Additionally, SD-JWTs allow for the inclusion of decoy hashes in the credential, serving as dummy values to obfuscate the actual number of claims in the credential.

Identity network transaction pricing

Tokenomics are typically documented and distributed via a dedicated whitepaper. However, since our tokenomics will be a constant iteration, we have been using blogs to explain these in an easier-to-digest format, with a summary available in the Governance Framework.

• Part 1 of cheqd’s tokenomics covered the context/background, utility through parameters such as initial supply and inflation, and governance tokenomics. It’s now time to complete the picture with distribution/allocations.

• Part 2 of cheqd’s tokenomics covered the initial distribution of the token.

• Part 3 of cheqd’s tokenomics covered the planned architecture of the payment rails.

TL;DR

Tokenomics part four outlines measures to improve the tokenomic sustainability of the cheqd network. This is achieved through an increase in the network’s identity transaction pricing for DIDs and Resources (from gas price to more concrete dollar values) and the introduction of deflationary mechanisms in the form of burns. Essentially, the fee used for identity transactions will be split: a portion will go back to Validators and Delegators as block rewards, a portion will be burnt (destroyed) to reduce supply, and a portion will be designated to the Community Pool. The exact weighing of this split is for you, the community, to decide.

We are proposing to introduce two new mechanisms to the cheqd tokenomics:

1. Identity transaction pricing

• Identity transactions such as DIDs, credential schema, etc. writes will have a cost greater than gas which will increase rewards from the network as identity utility increases.

• This is similar to Osmosis’ external incentive charges funding the community pooland rewards on Kujira stakers scaling with network utility use.

• This has been achieved using genesis parameters which will be updated periodically to maintain stable pricing for users until we migrate to using oracles such as those provided by Umee.

2. Burns

• A proportion of the identity transaction charges will be burnt to establish equilibrium with the inflation on the network and target total supply returning to a total initial supply of one billion $CHEQ.

• A Commonwealth discussion has been created to open up discussion on the proportion of any charges which should be burnt.

3. Community pool parameter increase

• The $CHEQ community pool recently funded work by Animo to reward them for their work on their Anoncreds demo on cheqd and continue their work on Anoncreds ledger independence. We believe the percentage of network rewards should be increased to encourage work such as this.

• A Commonwealth discussion has been created to open up discussion on the proportion of network rewards which should be allocated to the community pool.

Identity transaction pricing and burns will augment the work we are doing on payments for self-sovereign identity/decentralised identity.

Introduction

It’s almost a year to the day since we successfully launched the cheqd mainnet. In that time, we have learnt a huge amount, especially regarding tokenomics which we are now proposing to update.

Currently (prior to the proposed update), writing a DID to cheqd mainnet only costs gas, which is approximately 0.004 $CHEQ. This is extremely cheap when compared to networks such as Sovrin, where writing a DID costs $10, especially taking into account the value we are bringing as a network, protocol and team.

Alongside this, $CHEQ is currently inflationary (where staking rewards come from), with only slashing, tombstoning or no-with-veto slashing providing any deflationary pressure.

We are proposing to update and improve both of these.

The best and easiest place to start is pricing.

Network Pricing

Per the introduction, current identity transactions on cheqd are too cheap for the value they create. We intend to move to the following pricing structure, which is still extremely competitive whilst matching the value created much closer.

Note: Currently, schemas, credential definitions and revocation registry transactions are all priced the same since on-ledger they are all categorised as “resources”. Over time, these will likely become opinionated and differentiated according to the value they create and the burden they place on the ledger.

The keen-eyed of you will notice that the pricing above is in dollars, and obviously, cheqd mainnet runs in $CHEQ. In short, we are setting parameters to convert from US dollars to $CHEQ using baselined $CHEQ pricing at network update. For more details, please see the Implementation: Dollar to $CHEQ section below.

At current price levels ($0.03-$0.04), writing a DID will equate to 66.6 - 50 $CHEQ, which leads us to where these tokens will be distributed upon writes. This mechanism is similar to the mechanism Osmosis uses to fund the community pool through network charges for anyone creating external pool incentives. It also brings us towards the mechanisms built by the Kujira team for rewards to increase as the use of the network utility increases.

Distribution, rewards & burn

The tokens being charged by the network can either be distributed across stakers or burnt (or both according to a defined split):

• Burn: Provides a deflationary mechanism to counter inflation on the network.

• Distribution: Augments inflation-based rewards so APY will rise as network use does.

Distribution and rewards

If we assume that 50% of the tokens spent will be burnt, we have 50% being distributed to delegators, validators and the community pool.

Using the example in the diagram below, any block with a DID written within it is worth approximately ~four times a standard block where the block reward is ~12 $CHEQ. This means rewards on the network will begin to rise with adoption.

It is also worth noting that whilst resource transactions (which include revocation writes and updates) are substantially cheaper than DID transactions, we are expecting them to be orders of magnitude more frequent. Sovrin mainnet has a ratio of approximately fifty revocation registry updates to every DID, which we believe will be on the extreme low-side as adoption scales.

Repeating a table we included in Tokenomics part 3 below, issuing credentials and hence interacting with revocation registries is significantly higher than DID transactions.

Tokens which have been charged by the network for identity transactions but not burnt will be distributed according to stake on the network so, distributed across delegators, validators and the community pool.

Burn

As mentioned above, the network is currently inflationary only aside from slashing, tombstoning and no-with-veto having deflationary effects. Implementing a burn mechanism will bring the system into equilibrium.

The volume of tokens burnt will increase in the same way as distributions will, with the aim of bringing total supply back to one billion.

All together

Bringing distribution, rewards and burn all together means the system will be dynamic and as the network use increases, both rewards and burns will increase, increasing APY whilst also bringing the total supply back towards one billion. As rewards increase, the $CHEQ community can prioritise APY or accelerating burns to drive total supply down to the original initial supply.

Implementation

Dollar to $CHEQ

In the first version of identity transaction pricing, we are achieving dollar pricing through periodically adjusting on-ledger parameters , using baselined $CHEQ prices, via governance votes. Over time, we intend to migrate to oracles such as those provided by Umee to maintain constant dollar pricing for our partners. Until we have implemented oracles, we propose to update the parameters quarterly to keep pricing stable. Please see the Community and Governance section for more details.

Read more on our ADR on Genesis Parameters

Burn percentage

As can be seen in the image above showing the genesis parameters which define the costs in $CHEQ, there is also a “burn factor” variable which sets the percentage of the tokens charged for identity transactions which will be directly burnt. This can be adjusted through on-ledger governance votes according to the cheqd community preferences.

Community and Governance

Implementation of these mechanisms (pricing, distribution, and burn) will require on-ledger votes both to implement but also to periodically maintain these, especially before we implement pricing oracles to programmatically maintain stable dollar pricing for our partners.

We would welcome the community's feedback on the burn_factor, specifically on whether they would prioritise burning more or increasing rewards on the network.

Our view is that a high burn_factor in the immediate term would be preferable since this minimises the amount of burning required in the future to return to the total initial supply (one billion) whilst maintaining rewards where they currently are but would welcome the community’s views and opinions. We’re looking forward to engaging here. To that end, we have begun a Commonwealth discussion here.

Frequency

Until we build support for oracles so that dollar pricing can be maintained programmatically, we will need to periodically update the genesis parameters covered in Implementation: Dollar to $CHEQ. _Currently, we believe this should be quarterly so that we do not need to hold governance votes every month which would put too much burden on both delegators and validators. However we would welcome feedback from the community.

Community pool

This also feels an opportune time to open a discussion on the percentage of network rewards allocated to the community pool, specifically to increase the percentage allocated and hence empower and reward more work like Animo’s work on demonstrating AnonCreds on the cheqd network via the community pool. We have therefore opened up another Commonwealth discussion here.

Next steps

We believe all of these changes will improve the sustainability and success of the cheqd ecosystem but, as always, want to hear the community’s feedback. As per the introduction, we are constantly learning here at cheqd and want to make sure we build on those learnings to achieve maximum success.

We want to open these changes up for discussion, specifically, the burn_factor which will define the proportion of network charges which will be burnt and how much will be distributed to delegators, validators and the community pool. We also want to open up a discussion to increase the proportion of rewards allocated to the community pool to further incentivise work like that being delivered by Animo.

As we launch these implementations onto the network, we are able to focus on building support for cheqd into more SDKs to allow our partners to access the network utility more easily as well as focusing on our USP: payments, which is what we’re most excited about.

Please head to the following Commonwealth discussions for each debate or our Telegram and Discord for more informal conversations:

• Burn percentage discussion

• Community pool percentage discussion

We look forward to hearing from you.

Thanks, The cheqd team

Disclaimers

The values and statements made above are indicative only and should not be construed as an offer or guarantee.

About this Document

This document sets out the aims and intentions of the core cheqd team for the payment models, based on the current state of its ecosystem in November 2022. These evaluations are subject to change for technical, legal, business and other reasons. We will make our best efforts to keep the entire cheqd community informed and updated with changes to this distribution strategy.

cheqd Governance

Integral to cheqd is the concept of decentralised Governance, explained in full detail in our Governance Framework. This is important because the content of the cheqd tokenomics and this distribution document are subject to change if the governance mechanism opts to make Major Network Changes. Such governance decisions are outside of the direct control of the core team. As such, changes may affect (among other things) the token ($CHEQ) price , the specifics of token distribution and the network parameters.

Legal Uncertainty as a Risk Factor

There is underlying legal uncertainty in the nature of blockchain projects due to how quickly the industry is evolving and how legal regulations and frameworks need to adapt to keep up. For this reason, it is reasonably foreseeable that there will be further guidance and regulations on digital assets, cryptocurrency, Decentralised Autonomous Organisations (DAOs) and digital identity going forward. cheqd’s core team has made the best efforts to build cheqd in a generative way to develop alongside updates in the law. This notwithstanding, there is still a surface area of risk, where future or existing legal regulations could have a negative effect on the proper functioning of the project and on the value of $CHEQ.

No regulatory authority in Singapore, including the Monetary Authority of Singapore, has reviewed or approved the $CHEQ tokens or any of cheqd’s documentation, including blog posts, website material, webinars, events, videos or other graphics (the “Information Material”). The acquisition of tokens is subject to a potential acquirer’s compliance with the laws and regulations in the jurisdiction they reside in.

Acquisition as a Risk Factor

The acquisition of $CHEQ tokens carries with it significant risks. Prospective acquirers should carefully assess and take into account such risks prior to acquiring $CHEQ tokens. cheqd's initial core team and all of their collective past, present or future officers, directors, managers, employees, agents, advisors or consultants, or any other person (collectively, “cheqd”), expressly disclaims any and all responsibility for any direct or consequential loss or damage of any kind whatsoever arising directly or indirectly from: (a) reliance on any information contained in the Information Material; (b) any error, omission or inaccuracy in any such information; and (c) any action resulting therefrom. cheqd does not guarantee the accuracy of the statements made or conclusions reached in the Information Material and does not make, and expressly disclaims, all representations and warranties (whether express or implied by statute or otherwise). Past is not a reliable indicator of the future. The Information Material does not constitute advice, nor any recommendations or an offer, by cheqd or any of its affiliates and all of their collective past, present or future officers, directors, managers, employees, agents, advisors or consultants, or any other person, to any recipient of the Information Material. cheqd strongly encourages you to seek appropriate advice in respect of $CHEQ tokens and taking into account your personal circumstances, including but not limited to financial, legal, tax advice.

The Use Case as a Risk Factor

The $CHEQ token is worthless in itself and gains potential value within the cheqd ecosystem only through the protocol, its use and through continual use of Verifiable Credentials utilising cheqd payment functionality. Therefore, the success of the coin’s utility depends on multiple factors, including but not limited to, the health of the overall cryptocurrency market, the resilience of the cheqd protocol, and the success of Self-Sovereign Identity vendors in implementing real-world use cases.

$CHEQ must also be held within a wallet that can, ideally, consume Verifiable Credentials as well as $CHEQ tokens. This relies on the work of third parties to facilitate a functioning and healthy ecosystem.

In order to offer access to acquiring the $CHEQ tokens, it is essential that cheqd engages centralised or decentralised exchanges to list and facilitate the trade of tokens. The dependence on exchanges to recognise and list $CHEQ is a large risk vector. The likelihood of (specifically centralised) exchanges listing cheqd is directly correlatable to the size and activity of the cheqd community and the functional capabilities of the protocol and its governance model.

Security of Technology as a Risk Factor

Blockchains are not infallible to risk; nor is the storage of private keys for the purposes of owning $CHEQ and Verifiable Credentials. The wallet and the tokens it contains can only be accessed using the corresponding private keys. The owner of the tokens is solely responsible for keeping their private keys safe and protecting the safekeeping and protection of the private keys for the wallet against unauthorised access. While there will be safeguards put in place to help prevent such loss, the issue cannot be ruled out.

51% Proof of Stake attacks as well as rogue, malicious Governance proposals could be damaging to the proper functioning of cheqd as a protocol and as a community. It can also not be ruled out that blockchains generally, the cheqd Network, or other decentralised protocols become the target of attacks by hackers - alongside the further development of new technologies such as quantum computing.

Tokenomics are typically documented and distributed via a dedicated whitepaper. However, since a large proportion of the tokenomics for cheqd directly relate to governance, our tokenomics will be a constant iteration, we incorporated them into the cheqd network’s documentation here, which will also be continuously updated.

We can then continue using blogs to explain the initial and updated tokenomics in an easier to digest format.

Distribution explained

Tokenomics are typically documented and distributed via a dedicated whitepaper. However, since a large proportion of the tokenomics for cheqd directly relate to governance and our tokenomics will be a constant iteration, we incorporated them into the cheqd network’s Governance Framework, which will also be continuously updated. We can then continue using blogs to explain the initial and updated tokenomics in an easier to digest format.

Summary

Firstly, let’s start with a brief summary for those with little time to spare. The main groups are broken into:

• Community and grants: Token rewards for our incredible community, especially those who have been with us since the start and who are key to the adoption of self-sovereign identity (SSI). This also includes grants for the SSI community so they can immediately use and vote on the network.

• Foundation: The treasury will be used to support cheqd’s mission as well as vote on the direction of the protocol.

• Contributors: The core team and those who have supported us in executing, including our exceptional advisors.

• Shareholders: Our investors, as mentioned in our announcement here, who supported us when our mission was simply to establish the payment rails and commercial models for self-sovereign identity without us knowing where this would take us. Again, a huge thank you!

Notes

Vesting: Based on our analysis, it is possible to both stake unvested tokens and receive staking rewards for those unvested tokens, helping secure the network. Circulating supply at Token Generation Event: Our distributions and calculations put the maximum circulating supply at 5.42% including treasury provided liquidity.

Community and grants

The token and identity communities are both absolutely critical for us and the adoption of SSI and trusted data. We have the opportunity to not just achieve success for cheqd but the paradigm as a whole — data control back to individuals.

Community

cheqd is committed to launching the network in a regulatory compliant fashion, so any offerings will target to fit within the laws set out within each geography. The current paradigm of identity is a problem globally, and we can only work at that scale if we are not excluded from certain countries or geographies. That being said, we fully intend to reward our community for their support, both until now and in the future, as we wouldn’t be where we are without our earliest members. We hope the cheqd community will spread the paradigm far and wide, demanding companies to adopt the technology, educating friends and family, introducing the concept into their workplaces so that everyone can get back their privacy. We would remind everyone to join our Telegram and Twitter to keep an eye out for our news and surprises.

SSI & validator grants

To make adoption as easy as possible for the SSI community, we provide token grants to the companies developing in this space. These grants will smooth the transition to using a token-based network and provide them with stakes, which can generate token rewards, helping to offset the cost of using the network. We are already seeing the impact of these grants on the SSI community’s ability and willingness to adopt the network, which I look forward to Tobias Halloran (Head of Partnerships) sharing in the coming weeks and months. It will also provide us with a window to establish the necessary partnerships with custodians, exchanges and OTC desks such that their end clients do not need to worry about handling tokens at all.

Foundation

As with most other projects, the focus of the foundation, managing the cheqd treasury, is to maintain and accelerate the adoption of the network primarily through: further feature development, business & partnership development, and marketing. In addition to this, we will likely establish further grants and further advisor agreements where necessary. As per our governance framework, we will only be one vote of many on the network but want to be a major contributor guided by the community. Beyond the initial distribution, we expect proportionate staking rewards to flow back to the treasury to maintain a constant supply to maintain the team. Our priority here is ensuring we have sufficient treasury to support the project’s development and its team for an extended period.

Circulating supply

As you have spotted, we have a variety of vesting periods over the groups, which naturally impact the circulating supply of tokens. In addition to vesting, block rewards will also increase that circulating supply. Naturally, it’s up to each token holder how much comes into circulation but the graph below outlines the maximum circulating supply at each stage.

Now and next

As always, we would love to know your thoughts or feedback on our decisions and direction as comments on the article or via any of our other channels, take your pick! Have we missed something? If so, let us know!

The $CHEQ token at a basic level is used for three core functions:

1. Network decisions: cheqd is a Delegated Proof of Stake network, where individuals can vote on network decisions via a decentralised governance framework.

2. Identity writes: $CHEQ can be used to write Decentralised Identifiers (DIDs) and DID-Linked Resources to the network. This write also includes a percentage of tokens burnt from the network.

3. Credential Payments: $CHEQ can be used to pay for decrypting on-ledger resources for the purpose of a Verifier paying a Credential Issuer.

Getting started

Learn about the different mechanisms of the $CHEQ token below:

Summary

Over the past months, the team has been analysing the desired behaviour of the network stakeholders as well as the available functionality provided by Cosmos to identify the levers to achieve the right incentives. Whilst there are many parameters, we will focus the analysis on the key parameters which affect the incentives on the network.

Our Network parameters are listed here:

It should be noted that these parameters can, at any point, be modified via the governance procedures.

General

The main function of the general parameters is to set supply, inflation and targets for bonded targets.

Initial supply and goal_bonded

• The Initial supply of tokens, i.e. to be minted at the Token Generation Event, is set to 1b (1 x 10^9) which we deemed adequate for the initial size of the network. Please see inflation for how this is likely to increase.

• The goal for the percentage of bonded tokens (goal_bonded) is currently set to 60%. This was benchmarked against a number of projects and we feel this strikes the balance between securing the network and paying for identity transactions.

The inflationary parameters were much more impactful to network incentives based on our analysis. Implementing zero inflation would eliminate block rewards and therefore incentivise the push for maximum adoption of the network utility since rewards would entirely depend on transaction fees. Rewards would scale with transaction volume but consequently rewards would be low at low transaction volumes and also unpredictable. As a benchmark, Sovrin’s self-sovereign identity network has variable volumes month-by-month for various transaction types, and thus rewards for node operators / validators that only relied on transaction fees would make it difficult for node operators to predict fees collected from the network.

Inflation: inflation_min and inflation_max

Inflation (inflation_min & inflation_max) somewhat solves this problem by introducing block rewards which are independent of transaction and hence gas fees. Assuming there is little to no downward pressure on price at low inflation, block rewards provide a largely predictable reward over sufficient time, ensuring support and securing of the network is rewarded. However, inflation dilutes the incentive for network use, i.e. scaling rewards according to transaction volume.

Consequently, inflation can be seen as a double-edged sword. It rewards maintaining the network even at low volumes, but dilutes the incentive to drive maximum adoption.

By modelling rewards against transaction volume and using a number of reference points (CIVIC, EVEREST, LUNA & UST all-time high transaction volumes) we established that inflation_max should be <4% to achieve any meaningful incentives through transaction volumes. We similarly used all-time low transaction volumes to identify inflation_min as 1% to maintain sufficient rewards at low volumes.

Distribution

Communitytax, baseproposerreward & bonusproposerreward

As with the general parameters above, we analysed existing projects (e.g. Fetch.ai, Terra & Akash) and modelled various scenarios to understand the impact of the parameters on the network.

Across these projects, the values for communitytax, baseproposerreward and bonusproposerreward appear to be set to their defaults. Our modelling suggests the reason for this is that aside from communitytax, rewards across the network are largely dictated by stake regardless of the baseproposerreward and bonusproposerreward values**.**

As a result, we similarly didn’t see a reason to change the default values.

However, as the network progresses and becomes increasingly decentralised, it may become beneficial to reduce these values. For example, looking at Osmosis, another token on Cosmos, the communityrecently lowered these values to 0. The logic behind this decision was to reduce the Node Operators with the largest stake on the network from getting richer, and to incentivise a wider breadth of stake distribution.

Governance

Tokenomics is a subset of overall network governance. It is a way of incentivising or decentivising different actions on the network through economic forces, which in turn, regulates user behaviour.

For tokenomics to have an effect on the progression of the network, there must also be ways that a User can interact with its governance. In cheqd’s Network, we use a system of collective voting, based on liquid democracy. This voting architecture has a symbiotic relationship with the tokenomics to regulate the network.

Let’s explain this simply. I want to make a materially significant change on the Network, let’s say a Parameter Change, adjusting the default parameters explained in this post. The steps necessary to reach an accepted Proposal are as follows:

1. I need to draft a Proposal;

2. I need to make a deposit alongside my Proposal to publish it on-ledger;

3. I need that deposit to reach a parameter known as MinDeposit;

4. This needs to happen before the max-deposit-period expires.

The Proposal will then reach what is known as voting stage, where:

1. Enough people need to vote on the proposal for it to be valid (quorum);

2. A minimum threshold need to vote ‘Yes’ on the Proposal;

3. Below a certain number of votes must veto the Proposal;

4. The ‘Yes’ threshold must be met before the voting period expires,

If all the stars align above, then the Proposal will be accepted and the changes will be rolled out across the Node Operators in a process known as signal and switch. The specifics of this process will be articulated and explained in greater depth and detail in our Governance Framework.

So where do tokenomics come in? Well, someone needs to set the default parameters for:

1. MinDeposit

2. MinDeposit period time limit

3. Quorum

4. Threshold

5. Veto

6. Voting period time limit

The value of these parameters has a knock-on effect on other aspects of the network. For this reason, choosing these parameters is therefore not a simple game of ‘numberwang’. We selected each value for a reason.

MinDeposit

We did a detailed analysis of each token on Cosmos, taking the MinDeposit as a factor of the amount of tokens staked on the respective Network.

We found that the range was very large and calculated that our minimum deposit could sit proportionately as low as 360 (Cosmos’ lowest value) or as high as 36,000 (Osmosis’ highest value), given our total tokens at 1 billion and a bonded goal of 60%.

Another common theme we noticed was that projects tended to begin with a higher MinDeposit and then lower this value through a Proposal as the Network matured (Cosmos and Osmosis). This is something that we thought would be valuable to replicate as well, in line with the Principle of Entropy.

We settled on a value of 8,000 as MinDeposit. This was not only a sensible middleground given our calculations, but gives us the option to Propose to scale down the value as the network progresses and becomes more decentralised.

Max_deposit_period and voting period

For the MinDeposit time period (max_deposit_period) and voting period (voting_period) we settled on the value of 1 week. This is because this figure seems unproblematic and functional for healthy Cosmos communities. 2 weeks, which was the parameter on our testnet, was too long to wait in order to push through new updates.

Quorum and threshold

For the quorum and threshold, there is a very strong relationship between the two values. Once again we have decided to stick with Cosmos’ default parameters because they work well in healthy governance communities.

These are:

• 33.34% quorum; and

• 50% threshold.

One model of Governance that we think would be a valuable addition further along our roadmap, however, is Polkadot’s system of Adaptive Quorum Biasing. In this model, the lower the quorum tends, the higher the threshold tends, and vice versa. If this feature was implemented into Cosmos SDK’s governance module, Proposals to move to this would certainly be welcomed.

Veto

Veto is possibly the most extreme example of where governance and tokenomics overlap, as a veto vote ‘burns’ the tokens invested in the Proposal which sit in an escrow called a ModuleAccount.

We believe that the 33.34% default setting for veto is both high and low enough. Veto votes should be used sparingly, only when Users think that a Proposal is contradicting a core cheqd Principle (to be released in our Governance Framework).

Changes

A starting point

As we’ve mentioned briefly above, these values are very much the start and we fully expect these to be updated by the community through the processes set out in the governance framework. Our hope though is that these values set a strong foundation for a successful, self-governing ecosystem.

Improvements

As we covered in the context section, these values are the Minimum Viable Tokenomics to establish the network. As the base values are updated by the community, the team will begin delivering more complex tokenomic functionality including a variety of commercial models such as transactional payments, subscriptions or volume-based discounting.

Our primary focus will be on enabling these commercial models along with stable settlement, achieved through support for stablecoins and potentially central bank digital currencies.

Our tokenomics webinar

If you rather watch a video about our tokenomics, cheq out our webinar below.

cheqd Tokenomics Webinar

You can also download the cheqd Tokenomics slides here.

cheqd Circulating Supply Explained

There are plenty of terms and metrics used to measure a project’s tokenomics, often with their own methodology for measuring certain aspects of them, which can cause plenty of confusion. This is further complicated by the fact that certain terms are accidentally used interchangeably or can have a different definition or interpretation depending on the user or reader of it.

“Circulating Supply” is a great example of this.

Circulating Supply (CS) is defined by CoinGecko as: "The amount of coins that are circulating in the market and are tradeable by the public."

Below we have outlined a few different potential interpretations of Circulating Supply using different calculation methodologies:

Simplified view

Cosmos Auth Module

Token distribution is done programmatically based on Cosmos' Vesting Accounts. Every vesting wallet receives their tokens at the outset but they are locked natively and automatically vest and unlock.

This explains why vested tokens are not automatically shown as Circulating Supply, since tokens are distributed in advance, they are automatically vested and unlocked, and are not moved between accounts. Here's an example to illustrate how it works.

Token holder

1. Receives 1 million tokens with a vesting period of 2 years into a Cosmos SDK genesis account

2. Can see their wallet with 1 million tokens but can't move tokens (no transfer/sell)

3. Tokens start vesting on a block-by-block basis (in the case of continuous vesting accounts)

4. Can stake or vote with their entire balance

5. Can only transact tokens once they are vested

The reason we opted for this approach

We decided to distribute the tokens and automate its release as it is far more efficient, secure, and precise than the alternatives, e.g. there is no need for smart contracts which can be vulnerable, or manual distribution which is effort intensive and inefficient. We save our team precious time that can be better spent elsewhere, i.e. not spending days unlocking and transferring tokens.

To use an example, we see it as unlikely that the National Health Service in the UK would charge for credentials moving between their own hospitals. However, they may seek to monetise those which are used in private health.

We believe both models should be possible and will be providing the tooling on that basis.

What are we solving for?

Example

The requirements explained below are best understood following an SSI example. We’ll briefly consider peer-to-peer verification before payments or transfers of digital assets, inc. NFTs.

Either through self-attested data or third-party attested data one user can prove their identity to another, avoiding the service support imposters which have plagued OpenSea recently or remove the need for test transfers, i.e. sending 1 token to confirm the recipient then sending the balance. This could be especially powerful in allowing DeFi protocols to meet theTravel Rule whilst maintaining individual’s privacy as far as possible.

User journey steps:

1. Institution 1 shares documents to KYC provider

2. KYC provider issues certified docs to Institution 1

3. User creates DeFi pool (e.g. liquidity) with defined KYC criteria / process

4. Institution 1 provides appropriate KYC information

5. Pool processes certified docs and stores encrypted references

6. Institution 1 supplies / trades assets as desired.

7. Institution 2 does not provide appropriate KYC info

8. Institution 2 attempts to supply / trade assets as desired but is blocked by pool

Principles

Before diving into the payment models, it is worth grounding on the principles which informed these. Whilst there are many detailed requirements they can be summarised into:

1. Privacy: It should not be possible to follow payments to either identify an individual or track their interactions (even pseudonymously).

2. Privacy: Resulting from 1, but also to ensure the network remains General Data Protection Regulation (GDPR)and other privacy regulation compliant, no personal data (even encrypted) should be written to the ledger.

3. Stability: Any price for a credential should be stable (against fiat) across time to avoid misaligned incentives, i.e. a verification is delayed hoping for a price increase or decrease.

4. Low-cost: Transfers should not incur significant costs

5. Arbitrage resistant: Recipients of data should not be able to avoid paying for that data if a tariff has been set

6. Commercially sustainable: Any commercial model(s) should enable the network to be self-sufficient without penalising ecosystems on top.

7. Flexible: Proprietary credential formats should not be required. Commercial models should not be dictated by the network. They should be available for those who wish to use them but not dictated by the protocol.

Read vs write volumes

One model we have seen frequently is monetising any “identity” writes to the ledger, with some focusing on public DIDs and others allowing personally identifiable information onto the ledger to make charging easier, albeit by sacrificing privacy.

We see this as an unnecessary sacrifice. From our analysis, it is much better to focus on credential presentations / reads rather than writes to the ledger which the table articulates using passport issuance in the UK as an example.

The average UK household takes ~3.9 holidays per year.

Multiplying for both outbound and inbound flights (x2) and the touchpoints whilst travelling (x4: check-in, exit border, departures, entry border) equals 31.2 checks per year. This ignores non-travel uses of passports, i.e. opening bank, insurance or telecomms accounts._

Since credentials should not be written to the ledger, using passports as an example there is approximately a 1.5m factor between the DIDs written and the number of the credentials read / received. Monetising these fits the needs of the market most but also works best with the volumes.

Now to the payment model themselves.

Payment models

Whilst there are numerous commercial models to come, we will focus on the two payment models which will help form the building blocks of these. These are:

• Holder pays issuer; Receiver pays holder

• Receiver pays issuer

Note: Whilst the diagram shows one organisation as an issuer and one as a receiver, these roles are interchangeable depending on the data being transacted and the surrounding interaction.

As can be seen from the table below, each of these models has its place facilitating business models for identity already and we expect SSI ecosystems will combine these to suit their needs.

Receiver pays issuer

Firstly, we will tackle “receiver pays issuer” since it is both the model which is requested most by our partners and the model which will have the greatest impact on cheqd tokenomics.

We will be stepping through the building blocks before arriving at the solution we will be building, explaining our logic as we go, covering:

1. Revocation registries

2. Stablecoins

3. Escrows

4. Line of credit

5. Collateral

Revocation registries

Revocation registries, as their name suggests, are used to define whether a credential has been revoked or not once it has been issued. As usual this is best explained using an example:

As we all know, driving licences are used for much more than proving the ability of an individual to drive. They are frequently used in bars or grocery shops for buying cigarettes or alcohol, or specific to the latter, picking up packages which have been delivered there. In this scenario, there is little benefit to knowing if the driving licence has been revoked or rescinded. Your legality to drive (or not) does not have any bearing on whether you are old enough to buy cigarettes or are the right individual to pick up a package.

In contrast, your ability to rent a car is directly tied to that legality to drive, hence why rental agencies verify your licence as well as checking for any points.

Crucially, whilst revocation registries exist on-ledger, they do not identify individuals, preventing privacy leakage. This provides an ideal component for monetising credential verifications where desired.

For anyone interested in more detail, our partners at Tykn have written an excellent explanation on the requirements and workings of current revocation registries on Hyperledger Indy.

Stablecoins

Since one of the requirements was for the price of and payments for credentials to be stable over time, this enforced the need to use a stablecoin for denomination and payment. Using any volatile token could lead to arbitrage opportunities for both verifying or paying for credentials leading to dysfunctional ecosystems. However, since the tooling will be built to be agnostic, counterparties who wish to transact in non-stables will be able to do so.

Whilst we will initially build out around a single stablecoin for speed, we expect this to be flexible in the future so any ecosystem can decide to use any stablecoin. This would also allow settlement in Central Bank Digital Currencies / GovCoins which could bring broad adoption to cheqd.

Rather than build our own stablecoin, we will leverage pre-existing solutions in the market, partly for our own speed but also, if it’s not broken, it doesn’t need fixing.

Escrows

Since maintaining anonymity for individuals, minimising transaction costs and establishing an extensible pattern were key requirements, our team and advisors coalesced around an escrow pattern.

An escrow is a contractual arrangement in which a third party (the stakeholder or escrow agent) receives and disburses money or property for the primary transacting parties, with the disbursement dependent on conditions agreed to by the transacting parties. (Wikipedia)

Escrows have been used for centuries to ensure payment is only made if certain conditions are met whilst preventing either the sender or the recipient from gaming the payment. Most people experience these when buying houses with funds put into escrow with solicitors until the transfer of ownership of the house can be confirmed, at which point the funds are unlocked.

Uncoincidentally, our CEO holds patents for using escrows for Hashed Timelock Contracts for cross-blockchain payments as part of his work on Central Bank Digital Currencies on the Jasper-Ubin project with the Monetary Authority of Singapore and Bank of Canada.

This function maps extremely well to executing a payment only if a credential has been verified. Escrows also present additional benefits:

• Aggregating payments reduces the number of privacy attack vectors since payments are not made individually

• Aggregating payments reduces the transaction costs overall since payments are made in bulk

• Extensibility, see section further on.

Line of credit

A line of credit (LOC) is a preset borrowing limit that can be tapped into at any time. The borrower can take money out as needed until the limit is reached, and as money is repaid, it can be borrowed again in the case of an open line of credit. (Investopedia)

Since organisations prefer to maintain their capital / cash as far as possible rather than pay transactional fees, it does not make sense for any receivers to make payments to the escrow each time a verification is performed.

Instead, we expect organisations to prefer either a fortnightly or monthly payment cycle. Since payments are incurred per verification but only settled fortnightly, monthly or on-demand, this creates the need for credit with the receiver building up debt on the escrow before settling periodically. This is analogous to liquidity provisioning in pools in that liquidity can be bonded for a given timeframe, then claimed based on that committed timeframe.

The question then becomes, where does this line of credit come from. Since we are operating in a public-permissionless system, it makes little sense for issuers to extend lines of credit to receivers. Especially since these roles are interchangeable. Which leads us to collateral.

Collateral

This line of credit can be leased from the network through collateral locked to the escrows. This allows a receiver / receiver of data to maintain a line of credit up to the value of the CHEQ they hold multiplied by a factor to avoid margin calls, creating the two following scenarios:

• Receiver settles debt on time: credit limit remains

• Receiver does not settle on time: collateral slashed / penalised on pre-agreed terms

Over time, it is likely that the collateral will become blended to reduce volatility and hence reduce the factor required to avoid the margin calls mentioned above. MakerDAO has plenty of excellent work on this which we will be leveraging so we don’t reinvent the wheel! Initially, we are likely to use a 200% liquidation ratio to protect against volatility with the aim of reducing this as the solution matures. Similarly, we will be looking at existing implementations such as Aave to bootstrap development.

Please see more details in the Supply & Demand section below.

We are closely watching Osmosis’ superfluid staking and Persistence’s liquid staking work respectively for their ability to provide returns whilst assets are locked as collateral.

Combined Combining the components mentioned above results in the payment diagrams below. The arrows in white are the typical credential flow with those in gold showing the payment flows we will be laying on.

User journey steps:

1. Issuer publishes credential price and recipient wallet address (either on ledger or not)

2. Receiver stakes $CHEQ to Escrow contract to collateralise line of credit

3. Issuer issues credential to holder

4. Issuer updates revocation registry for the credential

5. Holder presents / shares credentials and commits to pay

6. Receiver presents which credential they want to verify to Escrow contract and commits to pay

7. Escrow checks CHEQ <> Stablecoin exchange rate for use to evaluate credit limit

8. Escrow increments debt amount with credential price

9. Escrow retrieves revocation result from the Revocation registry

10. Escrow returns revocation result to Receiver

11. Receiver pays Issuer in stablecoin

12. Receiver presents proof of payment to the Escrow

13. Escrow checks proof of payment

14. Escrow clears down the debt

15. Cycle repeats

Extensibility As mentioned when explaining escrows, one of their benefits is extensibility, specifically for commercial models. The payment flow above represents a building block for these with the escrow the key piece of the puzzle to move from “receiver pays issuer” to much more complex commercial models such as subscriptions, volume-based discounting or cost mutualisation.

To achieve these, the escrow moves from facilitating payments between two organisations in a relatively dumb manner, e.g. debt is built up by receiver to an issuer and periodically settled, to adjusting the debt increment depending on a pre-agreed schedule, e.g. an issuer provides discounts to any receiver who verifies more than 10k credentials in a given month, or a consortium nets off their debts to each other before settlement to reduce the amounts being transferred unnecessarily.

We see this as one of the major benefits to using escrows for this purpose.

Receiver pays holder; holder pays issuer

Receiver pays holder

One of the greatest opportunities with these payment rails is rewarding the individual (holder) for the data they share, whether that data has come from an issuing organisation or is direct from themselves. Specifically flipping around the following quote:

If you are not paying for it, you’re not the customer; you’re the product being sold.

Since there are already models for this interaction in the current world (brave browser and the Basic Attention Token), it is easy to model this into an SSI payment flow. Furthermore, the transaction fees and price stability requirements are less restrictive since the interaction is expected to be transactional and payment will be relatively instant whether issuing or presenting / sharing credentials.

That being said, the individual or organisation may wish to pay or be paid in either stablecoin or stable & privacy token to maintain price stability but more importantly their privacy.

Holder pays issuer

As per Table 2, there are frequent interactions where an individual will purchase a credential from an organisation and then be able to share it elsewhere without restriction, potentially being paid / rewarded in the previous section. Passports are an easy example, but so is classpass (subscription / voucher which allows access to multiple gyms / salons), showing the range of value these credentials can represent.

The pervasiveness of this model already will guarantee this model will see frequent use.

CHEQ supply & demand

As CHEQ will be used as collateral for the lines of credit mentioned above, we expect this will have a significant impact across supply & demand.

Supply

The tokenomics at distribution / genesis were covered in our Tokenomics Part 2. At the time of writing this blog (28th February 2022), the total supply of CHEQs in the market is ~1.008B with an inflation rate of ~2%, with a maximum of 4% currently set.

We are currently working on APIs to feed Total Current Supply and Current Circulating Supply directly into CoinMarketCap and CoinGecko since these are not readily available in Cosmos SDK.

Demand

Since CHEQs will be used as collateral for lines of credit, across the entire network CHEQs will be locked up in proportion to the number of organisations maintaining these lines of credit and the size of the line of credit they wish to maintain.

The table below articulates the proportion of tokens which would be locked up dependent on the token price, assuming a 200% liquidation rate which would be likely when the payment models are first released.

Related to this, it is worth us re-sharing how many of these ecosystems /use-cases and hence companies (since each consortium will involve multiple companies) we are expecting to leverage the network.

Building

Still to come

Throughout this blog we have talked about the payment models being building blocks for the commercial models. Whilst the payment rails will keep the cheqd team busy enough for a while, we will then build out those customisable commercial models for DAOs, consortia and individual organisations.

Beyond this, we have ideas on how to solve reputation in a public-permissionless SSI ecosystem, i.e. ensuring incentives prevent bad actors from issuing fraudulent credentials, and counter-party risk, i.e. where poor quality or fraudulent credentials are issued, any party harmed by these can claim, potentially via insurance mechanisms.

Expect more blogs as we flesh out our ideas for tackling these.

Next steps

This approach and architecture has been gestating since we founded cheqd with the last 6 months dedicated to establishing a standards-based viable network for anyone who wants to use the network regardless of payments.

We have now turned our focus to building the payment and commercial models for SSI as we originally set out to do. There is much more work to be done but we wanted to share our approach so that anyone who is interested in our mission and interested in collaborating can begin doing so.

Overview

One of the most repeated bits of feedback that we've had, throughout our survey results and community engagement, is that: more easy explanation and examples on how cheqd can be used in practice would better help people understand the project.

These subpages will try and lay out simple use cases where cheqd will be able to create new commercial models.

Payment models explained

There has been a consistent cold start problem for digital credential ecosystems where organisations do not see a clear commercial model or revenue opportunity to justify the switch up costs to credential-based technologies. This is because the perceived value in Verifiable Credentials is the costs saved when there is a significant amount in circulation (the chicken🐔), but this cannot occur without organisations issuing credentials in the first place (the egg🥚).

Unfortunately, the benefits of credentials, prior to the point of mass adoption, provide no compelling reason for businesses to change their current data collection and retention practices until this is the case.

Since launching cheqd, our hypothesis has been that Credential Payments will be the catalyst for credential adoption, by incentivising issuers to release data back to the holder, and allowing them to set a price for trusted data checks. This thinking has since been validated by data collected by cheqd’s partners and potential customers, where 70% of respondents believed that payment rails would help drive adoption with their customers.

We now believe that credential ecosystems are technically mature enough to scale, especially with new regulations like eIDAS 2.0 accelerating their adoption and providing a template for interoperability. Yet, there is a barrier between the theoretical and philosophical benefits of Verifiable Credentials, and the commercial and business benefits of Verifiable Credentials. A payments or incentive layer is still required to provide a compelling reason for enterprise organisations to make the switch.

To achieve this shift, we’ve built Credential Payments into our cheqd Studio product to allow organisations to build trusted data markets easily, with simple REST APIs. This abstracts the complexity and responsibility of handling interactions with the ledger and provides a clear integration pathway for developers that are not familiar with decentralised identity standards or blockchain.

At a basic level, the CHEQ token is used to pay identity writes on the cheqd network. This functionality is made available through custom modules built by cheqd for DIDs and DID-Linked Resources.

Identity writes to cheqd

As cheqd is integrated into more Software Development Kits, it will become easier for cheqd's partners to write identity transactions to the network.

Identity write pricing

The below link is the canonical place for the updated identity write pricing.

Example of holder paying for Verifiable Credentials

What cheqd fixes now

This is Jane Doe

Jane Doe has recently completed her university degree at Bright University. She wants to receive a digital, verifiable and certifiable copy of her diploma to apply for a prospective job.

In order for this to happen, first Bright University needs to register their Decentralised Identifier (DID) to a Verifiable Data Registry or ledger. In this case, Bright University anchor their DID to cheqd, using the cheqd DID method.

The specific Public DID is registered as did:cheqd:mainnet:923u592u5ghgu3r8

Bright University also anchors an adjacent DID Document which contains information about Bright University such as:

• This is the DID of Bright University

• This is the endpoint for Bright University's help/contact address

• These are the list of public keys that Bright University might sign with for Verifiable Credentials for University Degrees.

Jane has completed her degree and she has successfully achieved a First Class Honours. Now, she wants to receive a digital copy of the diploma to be able to hold it in her digital identity wallet.

On the physical certificate there is a QR code which Jane scans. This creates a peer-to-peer encrypted channel between the University and Jane's phone, which has her digital identity wallet.

Bright University issues a Verifiable Credential to Jane through this peer-to-peer encrypted channel. The Verifiable Credential has the following claims:

• This is Jane Doe's diploma

• Jane Doe graduated from Bright University in the year 2022

• Jane Doe achieved a First Class Honours in her MSC degree in Computer Science.

The Verifiable Credential has a proof, meaning it is digitally signed by the Public DID of Bright University, as well as potentially cryptographic material referring to a specific public key, which may be used for a particular purpose (such as asserting claims).

To learn more about Verifiable Credentials, please see the page:

In return for a very high value University Credential, that provides Jane a verifiable record of her diploma, and is an optional addition to Jane's physical diploma, Jane is required to pay the University $10.00 USD.

Jane is required to pay this $10.00 in $CHEQ (or a stablecoin that she holds), before she is able to receive the Verifiable Credential. In the background the price of $CHEQ is equated to $10.00 USD, and is transferred to Bright University's wallet address.

Jane receives the Verifiable Credential to her digital identity wallet once the payment has been successfully completed. This entire data flow takes place off-ledger. This is important because it keeps all of Jane's personal information private, and only with her.

Jane now holds a Verifiable Credential of her University degree in her digital identity wallet and is able to use this to prove claims about herself.

Jane applies online for a new job as a Lead Engineer at a leading technology company.

The technology company asks for Jane to upload her education records. Rather than filling out the form manually; Jane scans another QR code to create a peer-to-peer encrypted channel with the technology company. Jane sends a Verifiable Presentation containing her claims and the attached proof to those claims, in a few clicks or taps.

The technology company is able to verify the validity of the claims that Jane presents, by resolving the DID embedded in the Presentation. Through resolving the DID, the technology company is able to see the DID Document and the information contained. Automatically, the technology company is able to ascertain that the proof inside Jane's Verifiable Presentation was issued by the real Bright University and is for the correct purpose.

The technology company is now satisfied and progresses Jane to the next phase of the application.

What cheqd fixes in Web 3.0

John Smith is a gamer who has built a substantial in-game profile for game developer's, Digiplay, latest metaverse game. John wants to receive a verifiable copy of his in game assets, which he can hold ownership of, unilaterally, in his digital data wallet, in order to port these assets over to a new game made by MetaZap.

In order for this to happen, first DigiPlay needs to register their Decentralised Identifier (DID) to a Verifiable Data Registry or ledger. In this case, DigiPlay anchors their DID to cheqd mainnet, using the cheqd DID method.

The specific Public DID is registered as did:cheqd:mainnet:6nhj3p3yf8f83g14

DigiPlay also anchors an adjacent DID Document which contains information about the game developer, such as:

• This is the official game developer DigiPlay

• This is the endpoint for DigiPlay's help/contact address

• These are the list of public keys that DigiPlay might sign with for Verifiable Credentials for different game accomplishments and in-game assets.

John has put a significant amount of hours into DigiPlay's title, but does not want to lose the progress he's made, as the game becomes obsolete and older. He wants to be able to port his progress into another, technically compatible title, in order to continue progressing from a relative position. He also has unlocked unique and rare skins, cosmetics and in-game assets which he wants to be able to use in future games.

Therefore, he scans a QR code provided by DigiPlay on their in-game main menu which creates a pairwise, peer-to-peer encrypted channel between John and DigiPlay. Through this channel, DigiPlay issues John a Verifiable Credential, or series of Verifiable Credentials, with various in game information such as:

• This is John Smith's gamertag: JohnSmith99

• John has reached rank 55 in our title

• John has received the following achievements on his profile:

  • Achievement A

  • Achievement B

  • Achievement C

• John has unilateral ownership of rare and unique items in this game:

  • NFT Blue Leopard skin for GG-B67

  • NFT Navy-blue 49145 player skin

  • NFT 8676 Custom stock

In this instance, the Verifiable Credential gives John a way to prove that he owns these items, easily, and he is able to showcase his profile and in-game assets in compatible wallets and third-party games.

Since without a Verifiable Credential, John will lose these in-game assets he has earnt, he is happy to pay a $15,00 one-time fee to get a verifiable digital copy of his assets in order to hold them unilaterally in a digital wallet, data vault or secure enclave on his PC, games console, or mobile phone.

Before John is able to receive the Verifiable Credential, in the background the price of $CHEQ is equated to $15.00 USD, and is transferred to DigiPlay's wallet address.

John receives the Verifiable Credential once the payment has been successfully completed.

John now holds a Verifiable Credential of his in-game profile in his digital data wallet on his desired console, mobile or computer, and is able to use this to prove attributes about himself.

John now wants to start a new game with a brand new metaverse title, made by game's company MetaZap.

John wants to port his in game assets, skins and prestige to MetaZap to build verifiable status in his player profile and allow him to use his unique items.

When John starts up MetaZap, the initial loading menu asks John whether he wants to port over any existing assets. John scans another QR code to create a peer-to-peer encrypted channel with MetaZap. John sends a Verifiable Presentation containing his relevant data and claims with the attached proof to those claims.

MetaZap is able to verify the validity of the claims that John presents, by resolving the DID embedded in the Presentation. Through resolving the DID, MetaZap is able to see the DID Document and the information contained from DigiPlay. Automatically, it is able to ascertain that the proof inside John's Verifiable Presentation was issued by the real DigiPlay and starts downloading John's assets into his MetaZap account.

Governance is not an easy concept to understand. This is because it is something which cannot be easily visualised and lacks a common definition.

If I said to you, what is an apple? You might respond by saying that it is a small round fruit which is commonly red, but can be green or even yellow. If I asked 10 people the same question, I would get a pretty similar answer. Apples are easy, they exist in the physical world and we come across them on a daily basis.

Now, if I asked the same 10 people: what is governance? Someone might say governance is about how the country is run. Someone else might say that governance is about law and order. None of them will provide a correct or incorrect answer, they will provide an answer based on what their conception of governance is.

Governance can come in many shapes and sizes. You can govern something as large as a country, or something smaller such as a school, or something intangible like a social media platform… or a blockchain.

What is Governance?

Governance is a challenging concept. It relates to setting rules and standards that people abide by and follow. Most models of governance rely on a hierarchical structure, where a sovereign authority regulates from a top-down perspective. For example, a national government is responsible for setting laws and enforcing them on the public. This makes sense because, without a level of prescribed governance to keep the public in check, order would descend into anarchy.

At cheqd, we like to think about Governance as constituting 4 parts:

Now, let’s break these down simply.

Types of governance

1. Law and guidelines

The law is something we are all familiar with. It’s a set of rules imposed on us, usually by a government or sovereign entity in a particular, defined jurisdiction. Non-compliance with law often results in a punishment of some sort.

Importantly, however, laws are rules that you have a choice whether to follow. You can choose to break the law if you want to, if for example you feel a law is morally unjust, however there will be consequences for your actions. Laws act to deter people from breaking them. In this sense, they are guidelines that are enforced by punishment.

2. Principles and social norms

Principles and social norms are a fun specimen. They play on human behavioural psychology. The crux of governing through principles and social norms is that if you get enough people to do something, or believe something, the community will innately enforce that thing.

For example, it is not illegal to sing the entire musical of Les Miserables to yourself, rather loudly on the London Underground. In fact, it might make the London Underground a much more cheery place, were carriages to normalise singing. However, there is a social stigma against loud singing on the London underground. As a matter of principle and to enforce this principle, you will not be thrown into a jail cell, but you will receive a lot of cutting stares, disgruntled faces, and maybe someone whispering and gesturing for you to keep it down. Or for particularly awful singing, a tut.

The point is here, that people impose principles that are unwritten, because they follow the general herd mentality of a normalised society, from the perspective of that society.

3. Markets and Economics

Most things humans touch or have created in the world have a fiscal element. Or at least, you could probably make a strong argument that is the case. For this reason, when it comes to governance, there is generally a financial angle.

In this way, regulating markets and the price of something has a large amount of sway on whether something will be willingly followed. Tokenomics largely implement this for decentralised networks.

4. Architecture

Like law, architecture is something that sets the boundaries of what people can and cannot do. In the physical world for example, a locked door in a University signals that students cannot enter. The difference between law and architecture is that people do not have much of a choice to circumvent the architecture regulation. In this case, a student could purchase the tools to break through the locked door, but it would require a high degree of effort and force.

In digital domains, architecture becomes a much more powerful method of governance, as rules, boundaries and punishments can be coded into protocols themselves to deter or incentivise people. These architectural boundaries can be so strong that it can make it near impossible to avoid them. For example if you find a locked door in a video game, unlike in the physical world where it might be possible to break through it, in the digital world there may be no possible method of going through, and the door acts as a permanent and unbreakable barrier.

Coming back to the question: what is Governance?

Governance is a multifaceted concept, encapsulating each of the four parts, discussed above. It is a way of regulating behaviour and ensuring order in a given system.

All four of these parts weigh into one another, and different weightings can be applied to different Governance Frameworks.

For example, Governance set by governments relies largely on Law & Guidelines, to uphold order and less on Architecture.

This can be represented via the diagram below, which shows how government uses different quantities of the modalities to govern.

Whereas, the regulation of a Social Media Network relies much more on Principles & Social Norms and less on Markets & Economy.

This is represented in the diagram below.

In this sense, Governance is something flexible, which can be adapted for different use cases, based on a combination of factors such as, among other things:

1. Whether there is a clear jurisdiction;

2. Whether the system is in the physical or digital world;

3. Whether there is a currency.

How we define Governance

What is Decentralised Governance?

This is made possible because of the architecture of the Network, which enables the Network to become self-regulating and autonomous over time.

This is how the cheqd Network governance will look to begin:

Over-time the Network may vote to raise or lower these sliders, in accordance with group consensus.

One thing that will stand out looking at this chart is the lack of Law governing the Network.

In this way, the decentralised Network acts as its own Legislature, Executive and Judiciary, as decentralised consensus checks and balances each stage in the passing of a proposal.

A decentralised Network where accountability is spread out as such is often referred to as being sufficiently decentralised.

The cheqd Governance Framework embodies the following General Governance principles. These General Principles SHOULD be used as checks and balances against new Proposals on the Network.

Updates, amendments or revisions to this Principles list can be made through the process explained in the Section .

1. Interoperability

cheqd SHOULD enable digital identity data for an entity to be represented, exchanged, secured, protected, and verified in an interoperable way, across multiple decentralised identity Networks, using open, public, and royalty-free Standards, such as the Standards for Decentralised Identifiers (DIDs) and Verifiable Credentials (VCs) defined by the World Wide Web Consortium (W3C).

2. Accessibility

cheqd SHOULD enable applications to build on top of the Network, maximising usability and accessibility, in order to create additional value and utility for other members of the industry.

cheqd can be defined as a Layer 1 component of the Trust over IP stack, and SHOULD act as a module for other Layers in the stack to plug-into, from a technical and governance perspective.

3. Transparency

cheqd Network and Community SHOULD enable Network Users to easily access and verify information necessary to understand the incentives, rules, policies, and algorithms under which Node Operators and other participants of the Network operate.

cheqd SHOULD therefore, open source its work to the entire community.

4. Integrity

cheqd Network and Treasury SHOULD uphold the highest levels of integrity in the running of the Network, ensuring decisions and proposals are made in a public domain, without coercion, in the collective best interests of the cheqd Community.

5. Control

Network Users SHOULD control their own identifiers and encryption keys, and be able to employ end-to-end encryption for all interactions.

Network Participants SHOULD always have a right to vote on the cheqd Network and have full control of their choice of vote.

6. Security

cheqd Network code and updates SHALL provide appropriate, measurable security of the data, including protection against unauthorized or unlawful processing, accidental loss, destruction, or damage, using significant technical and organizational measures.

cheqd Network SHOULD make publicly available their network health monitoring, data and analytics tooling.

7. Data Protection

cheqd Network Users SHALL NOT enable personal data, as defined in the GDPR, to be written to the Network, in either a plain text proposal, memo, DID Document or a software update.

cheqd Network SHALL ensure any data uploaded to the Network is anonymous and uncorrelateable.

A User’s right to be forgotten (i.e. the right for their personally identifiable information to be erased or put beyond use) SHALL be promptly honored wherever applicable.

8. Notification

Network Users SHOULD notify the other Users of the Network as soon as practically possible if there is a security breach, data breach or else if a Regulator has made an inquiry into the Network’s operations.

9. Decentralization

10. Sustainability

cheqd SHOULD always strive to be environmentally sustainable, given the imminent threat of climate change and the important role that technology can play in mitigating this threat.

For example, this MAY be achieved through a Carbon Tax on the Network. A Carbon Tax is a nominally small fee that is charged for the use of the Network, which can be put aside into a Community Pool, and donated for the betterment of the environment.

11. Inclusion

cheqd Users SHALL NOT exclude or discriminate against any other User within its governance scope, on the basis of age, body size, visible or invisible disability, incapacity, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, country of origin, heritage, personal appearance, race, caste, color, religion, or sexual identity and orientation.

cheqd Users SHOULD always seek to use inclusive and neutral language to best reflect the interests of a diverse, multidisciplinary and multicultural Network.

12. Privacy

The cheqd Network SHALL NOT allow any use of the Network that results in technical or regulatory privacy infraction, such as surveillance, personal tracking, and abuse.

cheqd Network SHOULD use the tools available to it, such as the veto power to ensure that the network is not used as a Layer 1 for Layer 2 and 3 applications that compromises Privacy.

Verifier pays Issuer is a Credential Payment flow that enables "issuers" to charge a premium fee to validate the legitimacy of the credential's status. This is an incredibly powerful tool for companies that want to issue Verifiable Credentials, but also want to put a sensible commercial model in place.

Example of Verifier pays Issuer flow

This is Jane Doe

Jane Doe has recently completed her university degree at Bright University. She wants to receive a digital, verifiable and certifiable copy of her diploma to apply for a prospective job.

DID and DID-Linked Resource Creation

In order for this to happen, first Bright University needs to register their to a or ledger. In this case, Bright University anchor their DID to cheqd, using the cheqd DID method.

Bright University, however, want to make sure that they also receive a payment when Jane uses her digital diploma for other purposes. As such, Bright University create a "Premium" credential with a $20.00 fee to fully validate.

Bright University anchor their DID to cheqd, and create a "chargeable" $20.00 DID-Linked Resource to allow relying parties to Pay to Trust the credential's status and also the governance framework under which the university operates.

The specific Public DID is registered as did:cheqd:mainnet:923u592u5ghgu3r8 and the DID-Linked Resouce is available via did:cheqd:mainnet:923u592u5ghgu3r8/resources/5c2529b0-656d-4244-8e55-906d124df523.

Bright University specify that $20.00 must be paid to Bright University to access the status information regarding the credential they will issue to Jane.

Credential Issuance

Jane has completed her degree and she has successfully achieved a First Class Honours. Now, she wants to receive a digital copy of the diploma to be able to hold it in her digital identity wallet.

On the physical certificate there is a QR code which Jane scans. This creates a peer-to-peer encrypted channel between the University and Jane's phone, which has her digital identity wallet.

• This is Jane Doe's diploma

• Jane Doe graduated from Bright University in the year 2022

• Jane Doe achieved a First Class Honours in her MSC degree in Computer Science.

• $20.00 ($CHEQ or stablecoin) must be paid to Bright University to validate and verify the status pof the credential.

The Verifiable Credential has a proof, meaning it is digitally signed by the Public DID of Bright University, as well as potentially cryptographic material referring to a specific public key, which may be used for a particular purpose (such as asserting claims).

Jane now holds a Verifiable Credential of her University degree in her digital identity wallet and is able to use this to prove claims about herself.

Verifiable Presentation flow

Jane applies online for a new job as a Lead Engineer at a leading technology company.

The technology company is only able to verify the validity of the claims that Jane presents by resolving the DID embedded in the Presentation and by paying $20.00 to Bright University to verify the Credential's legitimacy, status and validity.

Through paying to verify the credential, the technology company is able to see the DID Document and also the Credential status information stored as a DID-Linked Resource. Automatically, the technology company is able to ascertain that the proof inside Jane's Verifiable Presentation was issued by the real Bright University and is for the correct purpose.

The technology company is now satisfied and progresses Jane to the next phase of the application.

On the other side, Bright University make $20.00, which they can later withdraw into fiat currency. This creates a trusted relationship between the "Verifier" (technology company) and the "Issuer" (Bright University) whereby a fair payment can be made for cryptographically verifiable data that makes the technology companies recruitment process much easier.

Introduction

Governance Frameworks are generally perceived as largely inaccessible documents, for various reasons:

1. People do not understand what governance is, or why it is important;

2. The documentation is generally convoluted and difficult to find;

3. They are too formal and written in abrasive, legal language;

4. They do not educate the reader about the concepts they are governing.

At cheqd, we want our Governance Framework to be something that is easy to read, understand and use in practice. We want this document to be clearly understood by a diverse and multidisciplinary audience and collective, spanning across the world.

We are committed to writing our documentation in simple language, using easy examples to explain difficult concepts, and designing a Governance Framework which is open and easy to change.

This is the most important part of any Governance Framework...

Core to our Governance Framework, above all, is first, common understanding and common acknowledgement of how a system is run, and secondly, clear, accessible and democratic ways to influence decisions and the direction of change. This can only be achieved through clear communication, transparency and inclusivity.

Let's make this easy, accessible and inclusive

Through this Governance Framework, WE want to help YOU as a Network User, Node Operator or cheqd Community Member understand and familiarise yourselves with the following:

1. What Governance (and decentralised governance) is;

2. What cheqd’s mission is, and how our Network functions;

3. How you can impact Network Governance, either in off-chain forums, or through on-chain Proposals;

4. How the cheqd Network rewards participants through transaction fees and rewards;

5. What Principles YOU SHOULD uphold while using the cheqd Network;

6. How cheqd has built its Network to become more decentralised over time, as Low Entropy tends towards High Entropy.

In return, we kindly ask that YOU, while using the cheqd Network:

1. Demonstrate empathy and kindness toward other people;

2. Act with openness and respect to Users of differing opinions, viewpoints, and experiences;

3. Give and gracefully accept constructive feedback;

4. Accept responsibility for your mistakes, and are open to apologizing to those affected by our mistakes;

5. Focus on what is best not just for YOU and your desired outcomes on the Network, but make decisions with the entire cheqd community in mind.

We also ask that YOU follow the provisions of our Code of Conduct to ensure the best experience for others in the community.

Let’s make cheqd a success together, and payment rails for trusted digital data a global standard: improving trust and efficiency in every industry.

This section is a set of Foundational Principles which are core to the Network. They set a baseline of Principles which the General Principles sit underneath in terms of hierarchy.

The Foundational Principles SHOULD NOT need to change throughout the lifecycle of the Network. They are designed to be flexible enough to underpin the Network as it progresses.

Updates, amendments or revisions to this Principles list can be made through the process explained in the Section .

1. The Principle Principle

A Principles based Governance model is toothless unless there is a Principle explaining how to properly follow and interpret the Principles.

Given the genesis structure of the Network, a lot of power to govern the Network is vested in the architecture, and decentralised consensus from the Users of the Network.

For this reason, the Principle Principle holds that Network Users should follow these Principles.

This Principle SHOULD be upheld in the following way:

If there is a clear contradiction between a Principle listed in this Governance Framework and a Proposal made to the Network, that Proposal SHOULD be either:

1. Rejected, meaning that it will not reach voting stage, but the creator of the Proposal will be refunded its tokens;

2. Vetoed, meaning that it will not reach the voting stage and the deposited tokens for the Proposal are burnt.

Naturally, it will be at the discretion of the voter whether to reject or veto the Proposal. The User SHOULD use their reasonable judgement to make this decision, based on the degree of harm the hypothetical Proposal could do to the Network.

Throughout this Governance Framework, it will be made clear where the veto should be used, to maintain the security and safety of Network Users.

2. The Balancing Principle

With respect to the Principle Principle, it is also crucial to balance the right to freedom of expression with the other Principles set forth in this document.

We do not want Users to feel hesitant to make genuine, well-intentioned Proposals, for fear of having their Proposal vetoed. We want Users to feel that their voice can be heard without being shut down and penalised. And we want to instill a culture of inclusivity and open-discussion.

The Balancing Principle adds on to the Principle Principle. If there is a Proposal to amend, add or remove a Principle which is well-reasoned and well-intentioned, such Proposal SHOULD NOT be vetoed.

Voters SHOULD make a judgement call, based on their own morals and perceptions whether such a Proposal is genuinely well-intentioned; or whether it is created to antagonise, discriminate or cause harm to a set of persons or Users.

Of course, if there is a strong personal sense that a Proposal constitutes the latter, then a veto vote will be the best course of action.

We cannot set or regulate these boundaries, and we will not be able to intervene here, but we want the Network to govern this delicate grey area itself, minimising toxicity and maximising inclusion.

We want the Network to keep itself in-check.

What does this look like?

3. The Principle of Increasing Entropy

Entropy is the transition from a centralised Network, where very few people make decisions that change the course and direction of the Network, to a fully decentralised Network, where a large, diverse collective reach consensus on the course and direction of the Network.

At the genesis of the Network, there will be a set of default parameters and decisions made by a select few. Therefore, this state has very Low Entropy because there is purposefully curated form, structure and order.

As more node operators join the Network, as more decisions are made, and as the capability to make a decision on the Network is spread across more and more Users, Entropy increases. This is because the initial structure, form and order is gradually dissipated.

This Principle therefore holds that decisions made on the Network SHOULD be taken with a view to increase Entropy and to make the system more decentralised.

This Principle SHOULD be self-fulfilling in the sense that any Network Proposals made after genesis will most likely increase Entropy.

There will likely become a point where Entropy has reached the point of sufficient decentralisation and that its increase may plateau slightly for technological reasons. The Network SHOULD maintain this high Entropy state.

Primer on Principles-based Governance

The Principles listed in this Framework are designed to provide a functional reference point, and act as checks and balances, for cheqd community members and Network Users voting on the Network.

These Principles are specifically designed to govern and ‘on-chain’ governance activities. They should serve as the foundation and baseline for the Network to build upon as it iterates and becomes increasingly decentralised.

Regulating through Principles-based Governance, as explained in , means that these are not hard rules. There is no single entity that can impose a punishment for failure to comply with these Principles. Instead these are suggestions to nudge Users on the Network to act within the best interests of the community, to be inclusive and to keep the Network secure. The Principles can be interpreted broadly, or narrowly, this is up to the discretion of the User and the community.

If the general consensus of the Network believes a Network Proposal is contrary to a Principle, they SHOULD feel inclined to reject or veto such as Proposal. This SHOULD keep the Network in check and within a set of boundaries to keep it developing in a healthy way. A decision by Network consensus MAY also incur a financial penalty on the User acting contrary to a Principle. In this way, the Network regulates behaviour through Principles as well as Economics using the Network's Architecture.

This type of Regulation, through norms and Principles is also flexible and can change quickly, as society and the Network develops. This is Unlike Laws and Guidelines which are far more static.

Updates, amendments or revisions to this Principles list can be made through the process explained in the section .

cheqd Network Principles

Familiarise yourself with our set of principles for interacting with the network.

What is decentralised governance?

The principle concept of decentralised governance is that no single person, entity or organisation can control the direction of change in a public Network. Instead, the direction of change is agreed by the democratic votes of an ever-growing, diverse collective.

This point is desirable to reach, because it maximises Network security and resilience, creates an environment which is governed by a broad, diverse and multijurisdictional collective, and enables the Network to function purely as a utility, regulating itself through its own architecture.

However, this point is not something that can be reached overnight. There is a transition period between the genesis event of any decentralised Network and the point at which sufficient decentralisation may be claimed.

We want cheqd to achieve sufficient decentralisation, and to dissolve the initial control over the Network that few stakeholders may have. We want decisions to be made by the Network, and not by ourselves, the initial core team.

This is why we have created the concept of Entropy to transparently and effectively achieve sufficient decentralisation, through decentralised governance.

Entropy

Entropy is broadly defined as the degree of disorder or uncertainty in a system or process of degradation or a trend to disorder, according to the . In Physics, and specifically, the Second Law of Thermodynamics, its function is best explained through a metaphor succinctly delivered by .

Let’s think of a sandcastle sitting in a desert.

The sandcastle in the desert has both order and structure, and there are very few ways to arrange the sand grains to achieve the same structure.

Nearly anything done to the sandcastle will remove some of the order and structure of the sandcastle, gradually eroding the sand away from the familiar and notable structure.

For this reason, the sandcastle can be said to have Low Entropy because it relies on order, structure and design.

Conversely, a pile of sand with roughly the same amount of sand grains as the sandcastle has immeasurably more ways of ordering the sand to look like a pile of sand. This is due to the relative disorder of the sand pile.

For this reason, the pile of sand, with many more ways to arrange it, has High Entropy.

Now imagine that the sandcastle was left in the desert all day. The winds in the desert would blow the sand around, and it would slowly disintegrate and fall to bits.

However, there is nothing fundamental in the laws of physics that says that the wind could not pick up some sand from a pile and deposit it in precisely, the exact shape of a sandcastle.

It is just extremely, extremely unlikely because there are very few ways of ordering the sand so it looks like a sandcastle.

It is overwhelmingly more likely that the wind will take the Low Entropy structure, the sandcastle, and turn it into a High Entropy structure, the sand pile.

In short, physics says that Entropy always increases.

This same pattern and natural law can be seen in the development of decentralised governance. And if modelled correctly, a decentralised Network can be created so that Entropy always increases, gradually making the Network more and more decentralised.

The increasing of Entropy is one of cheqd’s foundational Principles, and we believe we can use it as a tool to achieve sufficient decentralisation efficiently and with transparency.

The genesis event

Like a perfectly formed sandcastle with Low Entropy, any decentralised ecosystem must begin with a structure, set of rules, parameters and default settings which govern the scope, boundaries and objectives of the Network — usually set by a small group of individuals.

For this reason every decentralised Network begins with a Low Entropy genesis event from which point Entropy increases.

This can be thought of like a Big Bang, starting a new system with a set of fundamental rules and boundaries.

Interestingly, the next block, known as Block 1, wasn’t mined until six days after the Genesis Block. This is considered as a very strange occurrence for the protocol, since the general time gap between blocks is intended to be ~10 minutes.

Many have questioned why Satoshi Nakamoto, the infamous pseudonymous creator of Bitcoin, caused the delay. The most likely theory is that Nakamoto spent the first 6 days testing the protocol and its stability, before backdating the timestamp.

Others believe that Nakamoto wanted to play God and recreate the story of the world being created in six days… Just like the Big Bang, Nakamoto had to create a set of default settings and parameters for Bitcoin to develop autonomously.

The point of this elaboration, however, is to highlight that for every Network that eventually reaches a point of sufficient decentralisation and High Entropy, there is a Big Bang event, and a period of tinkering and adjustment, as Low Entropy begins to increase.

And this is where we started at cheqd.

Going forward, we want to clearly lay out how the Network will enable a smooth transition from a Low Entropy genesis event to a High Entropy, sufficiently decentralised structure.

How do we model Entropy?

To model Entropy, we wanted to build more visual and accessible than an algorithm or formula; something that could be easily applied to multiple blockchains and utilised by any layperson and diverse audience .

Where we landed was: a Scorecard

The spider diagram above, the Entropy Scorecard, shows a scale scoring from 1 - 5 which we refer to as Entropy Levels, measuring tangible decentralisation from a genesis state (and Low Entropy) to beyond the point of sufficient decentralisation (and High Entropy).

At each point on the diagram sits a different metric of measurement. It is important to note that we could have selected more, fewer or different metrics to calculate Entropy against. We chose the seven metrics listed below because they provide a very sensible, digestible foundation for a rough calculation of cheqd’s Entropy. These metrics cover each angle of the Network, from security to geography to utility to governance.

We will walk through our reasoning behind each choice:

Validators (number)

This is the number of Node Operators on the Network. This is significant because the composition of Node Operators on the Network has a direct relationship with the dilution of voting power. The greater the number of Node Operators, the:

1. Greater choice the token holders have in who to bond and delegate tokens to for the purpose of Network Governance.

2. Greater the strength of security on the Network, with fewer points of failure.

Developers (commits)

This is the number of commits made on the source code after launch via cheqd’s open source repositories. Ideally, we would also be able to measure the amount of commits made by developers outside the core team of cheqd. Commits from developers outside cheqd add healthy randomness to the code and the development of the Network.

Participants (number)

This is the number of bonded token holders, meaning the Network Users who have bound a portion of their tokens to a Node Operator in order to participate in Governance.

This is important because the larger the pool of Participants, the more the voting power will become diluted across the Network, since Participants are able to vote unilaterally, regardless of the Node Operator they are bonded to.

Nakamoto coefficient (number)

Taken from previous work done on blockchain decentralisation, this is the minimum number of Entities in the Network that can pool together to reach 51% stake on the Network. The higher the number here, the more the Network is secure against malicious attacks and undesirable breaking changes.

Exchanges (volume)

Exchanges are closely correlated with the accessibility of the token. Being able to buy and sell CHEQ on an exchange will open the token up to a larger range of Users. A higher number of exchanges will lead to a healthier split of stake, with hypothetically, lower volume across each exchange.

Nodes (country)

The geographical makeup of the Network is important when discussing decentralisation. This is because geographic diversity lends itself to diversity of thought and perspective. Furthermore, a geographically diverse Network increases the security because even if an entire country was to shut its infrastructure down, a multijurisdictional Network would continue resolutely.

Proposals (number)

Like developer commits, Network Governance Proposals transition the Network away from its genesis state to a more random and disordered Entity. This again is very important in removing the initial control and order that the cheqd core team has implemented into the genesis state of the Network.

The Proposal and Voting process on cheqd is based on a liquid democracy. As a result, the more decisions are made through this process, the more control is taken away from a centralised collective and moved to the consensus of a wide-barrelled and diverse group of Participants.

Calculating Entropy

Having laid out the distinct metrics used to constitute Entropy, it is next important to lay out the values that define each Entropy Level. These values are specific to cheqd and the levels of decentralisation we would like to eventually reach.

These values have been calculated by us looking at our end-goal, taking the point at which we feel we could be maximally or sufficiently decentralised, and scaling backwards.

The values that we have chosen are as follows:

To ‘score’ Entropy, you need to add the total sum of the Entropy Level across each metric.

For example, the highest level of decentralisation a Network could reach according to this model would be Entropy Level 5 in all metrics - totalling a score of 35. Whilst the lowest level a Network could have would be Entropy Level 1 in all metrics - totalling a score of 5.

We would also love to see other Networks applying the same scorecard model of Entropy to exhibit their Network’s level of decentralisation, and whilst slight changes may need to be made to accommodate for nuances in different Networks, the core concept can remain the same.

Over time, we do expect this initial table to be iterated, extended and revised as decentralised ecosystems in general become more mature, more distinct and as opinion from Regulators, such as the Security and Exchange Commission (SEC) becomes more clear.

Entropy Progression

In this section we want to explain where we are, where we want to get to, and why we want to get there.

Where we started

Like any other blockchain Network, cheqd began its life cycle with a Low Entropy score. This is absolutely normal for the genesis of a decentralised Network, as the core team will have put in the default parameters, meaning there will be a higher locus of control, and change has not yet been made via the governance framework processes.

At launch our Entropy score was lower than 14.

A low entropy score as such, can be represented by the scorecard below:

This score quickly began to shift after launch as more participants joined from different geographies and stake began to spread more evenly. We will soon be launching a Governance Dashboard which shows where the network is on this scale.

Where we want to get to

We are aiming for high Entropy for various reasons, because it:

1. Correlates with higher Network security and resiliency across countries

2. Means broader contributions to the Network from a multidisciplinary and diverse collective

3. Enables increased integration capabilities with other technologies to improve the ecosystem as a whole

4. Increases the democratisation of wealth and dilution of rewards across a larger scope of actors

5. Dilutes the control from a select group of people, to a genuinely decentralised and diverse collective.

As a benchmark, we want to aim for an Entropy Score greater than 28; and with none of the scores below Entropy Level 3.

This combination is important because it will ensure that there is limited surface area for centralisation or control, as all metrics have progressed beyond a Low Entropy state.

A High Entropy Network would generate a scorecard illustrated by the example below:

At this point of High Entropy, we would hope that we would be considered a Network which is sufficiently decentralised, although of course this is not up for us to decide. Yet, we believe that this progression of Low to High Entropy is an important journey for every decentralised Network to embark on.

How do we plan to get there?

To increase Entropy, we have developed a governance framework that champions decentralisation as time progresses.

Achieving high Entropy involves:

1. Making it easy for Node Operators to onboard in an Open Source way

2. Having clear and transparent documentation, in multiple languages

3. Having simple governance processes to evolve the Network baked into the protocol

4. Incentivising a healthy community, with places to discuss positive and constructive ideas

5. Enabling all parties to be remunerated for their active contribution and participation

And a combination of the above will increase the Network Entropy in a healthy and natural way, bridging the middleground between Low and High Entropy, as seen below:

As the initial team, we have a responsibility to, as we like to put it, create the first domino and push it over. Or in other terms, we need to take care in setting a strong technical foundation alongside a culture of transparency, inclusivity and open communication to push Entropy in the right direction.

Where does this leave us?

We have introduced and explained the following:

1. Why decentralisation is an important goal for healthy blockchain Networks;

2. Why Increasing Entropy is crucial to achieving this goal;

3. How to model Entropy to achieve greater clarity.

And looking back now, what we want the reader to take away from this is to understand the following:

Decentralised Networks and protocols often leave a lot to be desired, especially when it comes to clearly defined lines.

Through our model of Entropy, we incentivise healthy behaviour, high resiliency, and utility which should be the building blocks for any decentralised Network.

We also want this to move decentralisation towards greater regulatory clarity, rather than towards greater dissonance.

If we want to make self-sovereign identity, rooted on a decentralised Network a reality, we can only do this through being open, creative and inclusive in the way we work. Helping frame decentralised ecosystems in a way which makes sense for laypersons will bolster the chances of SSI and token payment rails being used in regulated industries worldwide.

Entropy dashboard

Our friends at observatory.zone have built a dashboard to monitor cheqd's levels of decentralisation and entropy, below:

What does staking mean?

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.

What is delegation?

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.

What does bonded mean?

Bonded tokens are those present in the active pool.

Bonded tokens = staked tokens by Node Operator + delegated tokens by a user.

What is 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.

What is a Participant?

Once a User has delegated tokens to a Node Operator and has tokens added to the active pool, they are known as "Participants".

Why stake?

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:

1. To participate in Network Governance;

2. To earn rewards proportionate to your stake in the Network.

How do I choose which Node Operator to stake to?

Choosing your Node Operator or multiple Node Operators is an important decision. There are a few things you can take into consideration:

Commission rate

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.

Reputation

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.

Slashing and Validator Jail

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.

What if I change my mind about a Node Operator? Is it possible to redelegate or unbond from a Node Operator?

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:

• Sovrin Glossary

• eSSIF Lab Glossary

• DAO Model Law Glossary

After exploring the options available, we felt the Gravity Bridge was the most suitable and could help us achieve our results in the fastest whilst safest way possible.

One of the key things that attracted us to the Gravity Bridge is the way in which the Ethereum contract has been highly optimised, utilising batches to dramatically reduce the cost of transfers between Cosmos and Ethereum.

We also felt the decentralised running of the network was most in line with our vision at cheqd. As it’s a non-custodial solution, a stake can be slashed for any misbehaviour in accurately bridging assets or secure messages.

In addition, as a native bridge, the value of tokens on the destination chain and the absence of double spending are guaranteed by the same consensus as on the consensus chain. This means all the validators are coming to a consensus that the individual owns the tokens that are registered on both sides (the same amount of tokens has been launched on both sides of the bridge — i.e. on both chains).

Finally, we also saw the bridge as a powerful way to ensure having a token on another chain doesn’t fracture liquidity like wrapped tokens through a custodian would do.

Potential issues identified

One of the issues that was raised with the Gravity Bridge is down to the upgrade process. Given the team’s warranted focus on simplicity, it has led to the Solidity contract (gravity.sol) being non-upgradeable, whereas the other bridges can be upgraded by multi-sig wallets. This means the validators and their delegators are completely in control of the Gravity Bridge, and no one else can change the code.

Although we recognise this concern, we feel that the validators on the Gravity Bridge chain have a legitimate governance process and have acted in line with our principles to date. We also plan to set up a validator node on the Gravity chain and engage more in the governance and running of the bridge itself.

Governance and voting

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 Governance Framework.

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)

What if I want to vote unilaterally, i.e. without a Node Operator/Validator?

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 Voting on cheqd.

Can Participants earn tokens?

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:

1. Transaction fees

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.

2. Block rewards

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.

These rewards are distributed continuously and instantly. You are able to see your accumulated rewards on our dashboard: cheqd.omniflix.co and can always claim them back into your account.

How do I make changes on the Network?

Every User is encouraged to contribute to the cheqd Network. To make this easy, it is important to explain HOW a User can contribute, and what the best practices are for making changes.

For this reason, it is important to distinguish when a change can be made entirely off-ledger, and when a change is needed to be voted on, and made on-ledger. To do this we must differentiate between minor changes which are able to take place entirely off-ledger and major network changes which need to be formalised on-ledger.

Minor Network changes

These are changes that are insignificant, and do not affect the way the Network runs overall. Minor Network changes include, but are not limited to:

• Textual edits to the Governance Framework or written general documentation;

• Sensible additions to general documentation to improve clarity;

• Minor code changes;

• Finding, reporting and suggesting fixes to bugs;

• Translating the cheqd documentation into various languages.

Major Network changes

These are changes that have a materially significant effect on the Network. Such changes SHOULD be made via a Proposal, following the steps in the decision tree diagram below.

Major Network changes include, but are not limited to:

• Materially significant Architecture Decisions (ADs), such as:

  • An additional feature to cheqd;

  • Removal of a feature of cheqd;

• Parameter changes for the Network;

• Community pool decisions;

• Materially significant changes to a cheqd Principle;

• Significant connections to other infrastructure.

See more below:

cheqd's Principles

Whenever a major network change takes place on the Network, reference MUST be made to cheqd's Foundational Principles. The Principles should act as a checks and balance against major network changes.

This means, that major network changes should never oppose a Principle, unless it is acting to update or change a Principle.

Community

You do not have to own any CHEQ to participate in our community discussion. You are free to learn about cheqd and participate in our community discussions across multiple platforms and forums.

Use the below links to get up to speed with some of the core concepts and terminology in the cheqd network ecosytem.

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.

Learn About the Community Pool

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.

What is the balance of 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:

How can funds from the Community Pool be spent?

Funds from the cheqd Community Pool may be spent via successful governance proposal.

How should funds from the Community Pool be spent?

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.

How are funds disbursed after a community-spend proposal is passed?

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 a Community-spend Proposal

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:

1. are aware and engaged

2. 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:

1. How to contribute to cheqd

2. How to draft a major network proposal and engage the community

3. How voting on cheqd works

Formatting a Community Pool Spend Proposal

There are five (5) components:

1. Title - the distinguishing name of the proposal, typically the way the that explorers list proposals

2. Description - the body of the proposal that further describes what is being proposed and details surrounding the proposal

3. Recipient - the cheqd address that will receive funding from the Community Pool

4. Amount - the amount of funding that the recipient will receive in nanoCHEQ ("nCHEQ")

5. Deposit - the amount that will be contributed to the deposit in nanoCHEQ ("nCHEQ") from the account submitting the proposal

Off-ledger template

You should use our forum for Community Spend Proposals to discuss the Proposal with the cheqd community:

On-ledger example

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.

{
  "title": "Community Pool Spend",
  "description": "This is the summary of the key information about this proposal. Include the URL to a PDF version of your full proposal.",
  "recipient": "cheqd1qgfdn8h6fkh0ekt4n4d2c93c5gz3cv5gce783m",
  "amount": [
    {
      "denom": "ncheq",
      "amount": "10000000000000"
    }
  ],
  "deposit": [
    {
      "denom": "ncheq",
      "amount": "8000000000000"
    }
  ]
}