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.

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.

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!

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.

• 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.

• covered the initial distribution of the token.

• 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 and .

• This has been achieved using genesis parameters which will be updated periodically to maintain stable pricing for users until we migrate to using .

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

• 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

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.

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.

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

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

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.

• Burn 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

Legal Uncertainty as a Risk Factor

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

$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.

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.

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.