Payment models
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. With the advent of the payment rails, we will be wrapping them up into a whitepaper to provide a central document, incorporating any feedback we receive against this document.
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.
Introduction
Our core vision
As we shared in our first blog in March 2021, cheqd was started to make self-sovereign identity globally adopted, specifically solving the challenge of making SSI commercially viable through customisable payment and commercial models. Our core hypothesis is that by introducing cost savings/revenue generation to SSI, we will turbocharge adoption through the virtuous flywheel effect (figure below) as we explained in our business models of identity blog.
Business models of identity. Note: trusted data could be anything from a purchase receipt to a passport (for an individual) or export license (for a company).
Our initial tokenomics focused on establishing a network at least on par with the incumbent SSI such as Sovrin, i.e. supporting DIDs, etc, which we’re happy to say we have achieved, with plenty more to come.
We are excited to announce the tokenomics for the payment models we will be building onto the network. We are looking forward to sharing how these will become the customisable commercial models in the future.
To our knowledge, this is a first in establishing public-permissionless payment models for SSI without compromising privacy.
Caveat
Despite the document below detailing out the payment models we are building, we are not trying to impose a single business model on everyone, we believe all ecosystems need to have their own choice in what works best for them. The tooling and patterns will be made available to the SSI community to use as they see fit, allowing for a mix of free and paid credentials.
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 the Travel Rule whilst maintaining individual’s privacy as far as possible.
User journey steps:
- Institution 1 shares documents to KYC provider
- KYC provider issues certified docs to Institution 1
- User creates DeFi pool (e.g. liquidity) with defined KYC criteria / process
- Institution 1 provides appropriate KYC information
- Pool processes certified docs and stores encrypted references
- Institution 1 supplies / trades assets as desired.
- Institution 2 does not provide appropriate KYC info
- 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:
- Privacy: It should not be possible to follow payments to either identify an individual or track their interactions (even pseudonymously).
- 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. 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.
- Low-cost: Transfers should not incur significant costs
- Arbitrage resistant: Recipients of data should not be able to avoid paying for that data if a tariff has been set
- Commercially sustainable: Any commercial model(s) should enable the network to be self-sufficient without penalising ecosystems on top.
- 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.
Table 1: Identity transaction volumes
* 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
Payment model diagrams
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.
Table 2: Payment model examples
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:
- Revocation registries
- Stablecoins
- Escrows
- Line of credit
- 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.
Receiver pays issuer: credential exchange flow
- Issuer publishes credential price and recipient wallet address (either on ledger or not)
- Receiver stakes $CHEQ to Escrow contract to collateralise line of credit
- Issuer issues credential to holder
- Issuer updates revocation registry for the credential
- Holder presents / shares credentials and commits to pay
- Receiver presents which credential they want to verify to Escrow contract and commits to pay
- Escrow checks CHEQ <> Stablecoin exchange rate for use to evaluate credit limit
- Escrow increments debt amount with credential price
- Escrow retrieves revocation result from the Revocation registry
- Escrow returns revocation result to Receiver
- Receiver pays Issuer in stablecoin
- Receiver presents proof of payment to the Escrow
- Escrow checks proof of payment
- Escrow clears down the debt
- Cycle repeats
Receiver pays issuer: settlement flow — happy path
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 ISSUER
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.
Receiver pays holder: credential exchange flow
RECEIVER 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.
Holder pays issuer: credential exchange flow
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 earlier blog here. 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.
# CHEQs / % supply required to establish a given Line of Credit
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.
cheqd’s expectation of SSI ecosystem formation
CHEQ supply & demand
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.
If you are interested in helping us achieve our vision, please get in touch with us at [email protected]! The more we work together, the quicker we can realise this.
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 February 2021. 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 © 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). 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.
The Use Case as a Risk Factor
The $CHEQ token is worthless in itself and gains potential value only through the protocol, its use and through continual use of Verifiable Credentials utilising cheqd payment functionality. Therefore, the success of the coin 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 trade the tokens between wallets, 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.
