cheqd’s 2022 Highlights

cheqd 2022 highlights

What a year it’s been! We thought 2021 was smashing, but hey, we should have seen what’s in store for 2022. Incredibly proud of the cheqd team and our amazing community for all we achieved this year 😍 Without further ado, here are our 2022 highlights.

2022 achievements & highlights

Brand awareness

From North to South America and across Europe, we’ve presented at 14 conferences, including Web Summit, Money 20/20, Cosmoverse, European Identity and Cloud Conference, and Internet Identity Workshop and attended over 20! We’ve also held over 40 AMAs!

Over 70 publications worldwide have mentioned cheqd or interviewed us directly, including The Sunday Times, Bloomberg, Cointelegraph (three times!), Bitcoinist, Benzinga, Currency.com and many others. We certainly got a chunk of our well-deserved publicity this year!

pasted image 0

Reflecting on a year of product development

At the start of the year, we laid out an ambitious Product Vision focused on building the foundations for our vision of an interoperable network to enable portable, verifiable and private digital credentials, with the payments rails to follow.

On the network side, we have come on a long way since the launch of the network in November 2021, introducing the core feature of identity infrastructure, DIDs, at the start of the year, followed by our innovative Resource module enabling DID-Linked-Resources which is creating waves in the SSI / #IDTech space. We’re also wrapping up the year with the introduction of identity transaction pricing to our testnet, detailed in our tokenomics v4. This will come into effect on mainnet in January of next year.

In terms of apps & SDKs which enable partners to interact with the network, what we call the ‘cheqd Toolbox’, we’ve achieved our goals and some. We successfully built out a working Javascript-based SDK, the Veramo SDK for cheqd, which offers end-to-end functionality for developers to build their identity applications. We have also made significant progress with integration into Walt ID’s SSI Kit, and our partners Animo Solutions are building cheqd support into Aries Framework JavaScript. We have already successfully demoed cheqd using AnonCreds through Aries Framework JavaScript alongside our partners Animo Solutions, and full SDK support is due to be completed following some updates to the Hyperledger AnonCreds spec to decouple dependencies on Hyperledger Indy.

If you’re looking to deep-dive into our product development, cheq out our 2022 Product Reflections blog, which offers an in-depth analysis of our progress, transparently measuring our success against vision and providing useful reflections for other projects in identity & Cosmos.

Partnerships

  • Secured 42 SSI partners representing >65% of known SSI vendor market out benchmarking competitors.
  • Secured 22 Web3 validators and over 55 mainnet validators.
  • Secured multiple partnerships in Web3: Metavisa, Leap wallet, and others.
  • In multiple late-stage talks with major corporations in the consumer credit vertical for a flagship use case to launch trusted data markets.

Bringing cheqd Network to life through product demos

Bringing infrastructure to life is not an easy feat; however, this year, we’ve found innovative ways, both within cheqd and in collaboration with our identity partners, to make cheqd real. Our wallet.cheqd demo has continuously evolved over 2022, bringing our novel features such as DID-LinkedResources to life, plus bridging the gap between DeFi and SSI, garnering excellent feedback at conferences and events.

We’re also incredibly proud of our partnership with Animo, which enabled an industry first, with the demo of AnonCreds on cheqd using the Aries Framework Javascript SDK – cheqd out a demo here. The support from the cheqd community for this is also a massive highlight, which offered the opportunity to see how the cheqd Community Pool can be used.

In 2023 you can expect demo’s coming to a whole new level, with an opportunity for YOU to really get stuck in with cheqd and HODL in an entirely new way…watch this space!

Cementing the cheqd name in key SSI / IDTech communities

DID-Linked-Resources has been proposed as a formal specification in the World Wide Web Consortium (W3C) Credentials Community Group.

Having successfully decoupled AnonCreds from Hyperledger Indy, cheqd is now helping to rework the Hyperledger AnonCreds specification into something fully ledger-agnostic.

This year Ankur attended a number of the leading Identity conferences, including 2 x Internet Identity Workshops and Rebooting Web of Trust, presenting his paper on what we can learn from the world of sports, Tinder, and Netflix. In each, he’s been noticed as a powerful voice in the space, offering leadership around interoperability, scalability and how to collaborate for the success of the space. He’s also been consistent with great tweetstorms (which we all love), which have received a lot of traction.

Alex, as ever, has been contributing to ToIP phenomenally:

Ross, Product Manager & Operations Lead, has also recently been named Co-Chair of DIF #Product-Managers. He’ll be publishing a blog about his plans for the community in the New Year, plus inviting Product Managers from across the identity space to a series of workshops, so watch this space and contact Ross if you’d like to get involved!

Community growth

Updated tokenomics

Our tokenomics updates include a community pool parameter increase, and we are proposing to introduce two new mechanisms to the cheqd tokenomics; identity transaction pricing and burns. These measures will improve the tokenomic sustainability of the cheqd network.

Social time!

Had some great fun both virtually and in-person over the year, with numerous escape rooms, in-person meetups and quarterly retrospectives, which give us the opportunity to come together and reflect.

The wider Web3 (Web5) & identity landscape

From a wider market perspective, despite the crypto winter, this year has seen a number of decentralised initiatives going live. With Jack Dorsey’s announcement of Web5 right after Vitalik Buterin’s introduction of the soulbound tokens (SBTs), the decentralised web has been buzzing and making waves in the mainstream media. Although these are two separate announcements, both have driven considerable attention to the decentralised digital identity technology. No wonder why search for self-sovereign identity has seen a massive growth of over +1433%. Finally, with a growing number of identity thefts and cyber attacks, i.e. Revolut, a need for safe and privacy-preserving decentralised identity solutions hasn’t been more timely. We remain strong with our funds safely secured, taking our solutions far and wide and marking 2023 as a year of adoption.

Looking to the year ahead

To make decentralised identity adoption a reality, we have a solid plan. Starting with the payment rails architecture, we are working with our fantastic partners to make them live soon. This is the final piece of the cheqd solution to help both cheqd and SSI see adoption grow!

We’re already looking at key use cases which we think will generate the first adoption of payments and commercial models for SSI, creating entirely new business models and opportunities for companies and individuals.

Speaking of the adoption, there is going to be a groundbreaking project, bridging the Web2 paradigm into Web3! This will create entirely new business models for companies and consumers.

Finally, there is an exciting and novel project that will help bring cheqd infrastructure to life for our partners and communities alike. Expect the opportunity to get something in your own hands sometime in the new year (we’ll say no more 😁).

Happy holidays from the cheqd team! Thank you for being with us and sharing our mission of building a marketplace for trusted data. ♥️

cheqd’s tokenomics for SSI explained: part 4

cheqd-Tokenomics-4

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

TLDR CHEQ Tokenomics update

We believe this is a big improvement to our original tokenomics.

What do you think? Join the discussion on commonwealth or in our community groups.

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.
cheqd benchmarked against Sovrin pricing

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.

Current versus future staking rewards

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.

Identity transaction volume examples

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.
Inflationary to 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.
Current versus future $CHEQ 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.
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:

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

What we learned from the $CHEQ community

cheqd-The_Good_The_Bad_and_The_Ugly-3

Co-authored by Fraser Edwards and Eduardo Hotta.

We always planned on recapping how the cheqd airdrops went but in addition to that, we need to eat some humble pie and share the lessons we’ve learned in case they are of any use to projects executing future airdrops. Some of these are airdrop mechanics, some technical, and some communications and community building.

We’ve split this out into The Good, The Bad and The Ugly since that seems to bucket things nicely. For once, we’re not space-themed. Unfortunately (or fortunately) no one has made a TGTBATU in space.

  • The Good: We blew way past our original expectations and really had to HODL (Hold On for Dear Life — the meaning being from the fictional origin story of HODL)
  • The Bad: We tried some new technical approaches for the airdrop and these didn’t go exactly to plan. We also attempted to prevent and call out gaming of the airdrop but since our execution was off, we were throwing stones in glass houses.
  • The Ugly: During Mission One we found significant gaming which could have exposed the network to a similar issue to the one which has split the Juno community. We’d like to mention that we respect and like Juno very much, so this is not in any way a criticism of their airdrop. Some of this we got right, some we got wrong.

Source

Scene setting

Before we get into the action, we need to set the scene. Like most projects planning airdrops, we were aiming to widen our participation, awareness and people’s ability to build, especially as we were pretty unknown in the Cosmos ecosystem, having only founded the company in April 2021, launched in November 2021 and mainly focusing our marketing efforts on the Self-Sovereign Identity (SSI) world. We’re aiming to give people worldwide their data privacy, control and ownership back so improving participation and ownership fits well with our mission.

Before the airdrop, our community metrics were:

  1. Telegram: 12k
  2. Twitter: 25k
  3. Discord: 30 (not ks, 30!)
  4. Accounts: ~4.5k

Our original barometer for success was to increase at least our Telegram and Twitter communities by 5,000, which would have been a ~38% increase on Telegram, and 25% on Twitter.

We blew past these substantially. So let’s introduce the good.

The good

As we’ve hinted above, we shot past the internal targets we had set ourselves. Where we ended up was:

  1. Telegram: ~23k (~27k at peak) — 91.7% increase
  2. Twitter: ~48k (~50k at peak) — 94.4% increase
  3. Discord: ~11k (~15k at peak) — 36,566.7% increase (albeit from a very low level)
  4. Accounts: ~74k — 1,544.4% increase

This was almost entirely driven by Mission One where the aim was improving awareness through rewards for following us on Twitter and joining our communities on Telegram and Discord amongst others. We also wanted Mission One to allow more people to participate in Mission Two which was focused around staking and liquidity pooling (LPing).

As well as pure numbers, we’ve had many messages from members of communities we didn’t know existed (e.g. the Bangalore Web3 Cosmos community) to say we’re on their radar. Given some of our best contributors come from these communities this is exactly what we were hoping for and we hope to return their support!

Another fantastic thing that happened was the support and the encouraging words we received from our community. This airdrop experience created a strong bond between community members and also with cheqd.

The scale and pick-up caught us by surprise and led to the introduction of The Bad.

rewards.cheqd.io website traffic by country

The bad

Comms

We always aim to provide clear instructions and communicate in the simplest way possible so our messages could be understood by a wide group of people.

Unfortunately, we failed to provide a clear message in at least three instances

The first being that we stated in our first blog post that people entering the airdrop had to provide a cheqd wallet. However, more than 700 entries provided non-cheqd wallet addresses (cosmos, osmo, juno, regen, umee, etc.), which we decided to convert into cheqd wallets, so more people could participate in the airdrop.

The second time is the following:

A lot of people did not understand the phrase ‘week commencing’ and thought the claim website would be live on Monday 14th March 2022.

Why are we sharing this?

We took longer than we anticipated to start distribution due to the time needed to convert non-cheqd to cheqd wallets.

The second one created a situation where people started complaining that the claim page wasn’t live on Monday. This snowballed into people spreading the misinformation that we ‘delayed or cancelled’ the distribution as early as it was morning in Asia (and our team mostly follows UK hours).

Finally, the third instance happened when we closed the claim webpage as we went through a network upgrade. We had created a ‘maintenance’ page based on the design of the ‘Your Geography / IP address range is blocked’ page that was being displayed in affected regions.

Unfortunately, the ‘maintenance’ page took too long to propagate on the network, therefore people visiting the claim webpage during that time saw a ‘Your Geography / IP address range is blocked’, which created a bit of confusion that eventually led to a heavy flow of messages in our groups.

Oh, and one last thing… we were also already on high alert…

Our sensitivity to anything worrying was heightened after a project started using our ticker ($CHEQ) and had all the signs that it would be a rugpull during Mission One. This project copied and used a lot of the same things we do in our community (e.g. saying ‘cheq this out’ and their community members being called ‘cheqmates’) and also ran their own airdrop.

Without spending too much time on this, the project was indeed a rugpull and used our brand and airdrop to confuse people in the Cosmos and Juno community. Luckily, they rebranded and changed a lot of things before their rugpull, which meant they didn’t harm our brand that much. We thank our community for making them rebrand in a very short space of time!

Now going back to the gaming of the airdrop…

We’ll cover it properly in The Ugly but we saw a substantial amount of gaming of the airdrop. Enough to threaten the entire integrity of it.

This meant we had to review our original reward tiers and the amount of the rewards itself. In a nutshell, we decided to reduce the staking and increase the liquidity pool rewards.

Whilst we knew we hadn’t protected ourselves fully for Mission Two (you never can with gaming, it’s always a game of cat and mouse), we did want to call this out to other projects that were about to execute airdrops so they could avoid what we were going through.

Where we got it terribly wrong was not having our own house in order. We do wonder if we would have received the same reaction if claims had been working perfectly for those who were eligible, but alas, we’ll never know, and we have to own it. Thank you to those who did fight our corner, we really appreciated it, and it made a big difference to us.

Another thing is that we didn’t have enough manpower to reply to every tweet, support ticket, and message on Telegram and Discord. Most of the complaints, feedback, and messages came on a Saturday. Our team was so exhausted that we had to rest during that day. In hindsight, we should have bought a lot of energy drinks and answered some of the questions being brought up.

We hope this detailed breakdown goes some way towards an act of repentance.

execution

For those who are interested, strap in because this is where it gets technical.

Our Head of Marketing reviewing this section of the blog

Originally, the criteria for Mission Two were intended to be CHEQ “AND” others rather than CHEQ “OR” others as it became, to use logic gate terms. The first would have meant only people holding CHEQs would be eligible, whereas the second meant anyone who fit any of the criteria was eligible regardless of prior interaction with CHEQs.

However, during Mission One, we thought that it would be a good idea to give more people the opportunity to join Mission Two. The idea was simple: allow ATOM, OSMO, and JUNO stakers to claim an initial CHEQ reward that they could then stake or participate in a Liquidity Pool.

Thus, we split the claim in two stages, the first one for ATOM, OSMO and JUNO stakers, and the second for CHEQ stakers and LPs.

But…

We started getting feedback from the community saying that they preferred to have just one claim, as two would be too complicated. We listened and went back to having just one claim, but since we had already announced that it was “OR” instead of “AND”, we didn’t change that back.

This meant the universe of eligible addresses increased from ~30k (4.5 existing, max of 25k new due to limit) to 204k. However, our approach and processes had been designed around ~30k addresses, which we quickly found issues with.

snapshots

One of the major issues that resulted from this was that our snapshot execution was off at this new scale. The typical way to take snapshots for an airdrop is by running a full archive node for the target chains. For large chains (e.g. OSMO), this requires running what can be quite heavy infra, waiting to catch-up then being able to work with this so it can be time consuming. It also means that all of the logic for the airdrop is in code and is effectively a black-box to non-devs, putting the burden for execution and support resolution with the dev team.

We attempted to circumvent this by making API calls using Google App Scripts (similar to those used by block explorers) to pull results then use either Excel or Sheets to process these ready for distribution. This would have provided a lightweight execution and allowed the development team to focus on executing the core roadmap as well as allowing non-dev members of the team to test and support.

The first snag introduced by 204k accounts was that App Scripts was limited to 100k requests per day. Since we were checking across ATOM, OSMO and JUNO chains, we were well beyond that. After hitting rate limit alerts, we split the requests, so they were made from multiple accounts, however, we still hit the limits but without sufficient alerts in place with hindsight. This is the root cause of the majority of the genuine support tickets we have received.

The second was stitching together the results, ensuring they were unique and calculating rewards. Excel and Sheets were adequate tools for 25k accounts but were beyond their limits when tasked with 204k records requiring blends of computationally intense formulas (at least on this scale) such as vlookups, indexes and matches to combine them into a cohesive list. This meant every time we identified an issue, investigated, resolved and rolled it out, the processing took a colossal amount of time. Again, this would have been no problem at all at 30k, but hugely time consuming at 204k.

snapshots

After seeing issues in the speed of distribution for Mission One, for Mission Two, we used a CosmJS-based Cloudflare Worker, which is a highly scalable/fast way of doing distributions, using six distribution wallets to include multiple distribution transactions per block.

rewards.cheqd.io website traffic spike

However, one of the assumptions we built into this model was being able to use Cloudflare Works Unbound (up to 30 seconds CPU time) versus Cloudfare Workers Bundled. Unfortunately, Unbound is only possible with a custom enterprise contract which isn’t highlighted in the documentation. Although we had six distribution wallets, when we had a flood of transactions, each worker was only able to run for 100ms max before being throttled, forcing us to drop down to one distribution account whilst we refactored.

CloudFlare Workers comparison

Over the weekend, we refactored to use three Workers (with two accounts each) that could fit comfortably within the execution time for a Bundled Cloudflare Worker, which comfortably cleared the queue down extremely quickly. During this refactoring, we spotted an issue where it was possible to claim multiple times. As we had assumed at worst, a small distribution queue, we were checking whether there had already been a distribution to an address when anyone attempted to claim. This meant if you submitted multiple claims before the first distribution was made, there would be multiple distributions. We, therefore, shifted the check to the point of distribution to prevent multiple claims.

The other issue was that we stored the list in a key-value pair called Cloudflare Workers KV (key, value; example below), which sorts the keys (in our case, wallet addresses) alphabetically. Originally, this would not be a problem since the speed of distribution using the Unbound usage model would prevent any backlog of addresses.

Key: cheqd1…xxx Value: {“amount”:50,”timestamp”:1649853749658}

Unfortunately, until this was resolved, it meant that anyone low down the list of addresses alphabetically was constantly being pushed to the end by new requests. We fixed this by appending a randomly-assigned “queue-X” prefix in front of the key.

New functionality required

One major downside of not getting things right the first time is that it often introduces the need for new features which weren’t originally required.

As a result of the issues in the snapshots, we had a blend of:

  1. People who had not claimed
  2. People who had successfully claimed against a correct allocation
  3. People who had successfully claimed against a partially correct allocation

Since our distribution was built around a single claim/distribution, we had to amend this to allow those in category three to claim any missing rewards, moving from a single claim/distribution to multiple with more complex logic. Eventually, this accounted for:

  • Eligible for
  • Claimed
  • Claimed but not yet distributed
  • Eligible for but not claimed

Circling back, this cascade all started from the decision to increase eligibility from 30k to 204k wallets. Whilst we thought our approach would support this increase in volume, we were quickly disillusioned.

However, this baptism of fire did have some major upsides.

The good (again)

The result of some extremely late nights and colossal team efforts (special shout out to Ankur, Ross, Tasos and Javed here) was our infrastructure distribution and support processes had not only been volume tested but also drastically improved.

Whilst we would advocate that teams follow the typical snapshot processes, the distribution process we now have is much more feature complete, quicker and flexible than originally as well as having been thoroughly volume tested. We will be open-sourcing this part of the code-base for use in any future projects.

The ugly

The first inkling that something was off was when we downloaded the completed entries from Mission One, and spotted a suspicious series of emails, e.g. [email protected], [email protected], etc, when scanning through.

Since we had a lot of data points from Mission 1 (Telegram handle, Twitter handle, email addresses, who referred whom, etc.) we started investigating to understand the scale of the problem and the potential exposure from Mission Two since the rewards were much larger.

The most egregious of these were:

  • Multiple cheqd accounts per Twitter account:
  • 1 twitter account which had submitted 49 different addresses
  • Overall we had 915 accounts where 1 Twitter account owned multiple addresses
  • The same cheqd address submitted by multiple email addresses or Twitter accounts:
  • 1 account submitted by 160 different email addresses
  • Overall we had 781 addresses that were submitted by different email or Twitter accounts

We also had 116 instances in support tickets where the airdrop was transferred out of the account and then a ticket raised claiming it was never received.

Whilst investigating, we identified that the bulk of these were coming from the same country. This behaviour was confirmed as widespread when we saw it openly discussed on our Discord server with syndicates and dumping both openly talked about.

Since we identified 12k wallets from this country with a high proportion of gaming, we took the difficult decision to add these to a denylist and geoblock then work through valid claims via our support processes.

And, believe us… it wasn’t easy.

Currently, out of all the addresses we blocked and the tickets raised, we had less than 90 valid claims for this country. Further, the majority of these had already been dumped. In the spirit of fair play, since they followed the airdrop rules, we have rewarded them.

As we covered in The Bad, we attempted to highlight this to other projects about to execute airdrops but we didn’t get this right in a number of areas. However, now that we are through the majority of the tickets, we are comfortable that we took the right approach, although we should definitely have made sure all our processes were working before we highlighted the issues we were seeing.

If there are any projects about to do an airdrop, we would be more than happy to share in detail what we learned, the investigations we did, and what we would change for the future, including addresses which would be worth checking for exposure when shaping an airdrop to check.

The really ugly

Now, to the really ugly stuff…

After we communicated our decision about the geoblock, a group of people spread disturbing lies (which we won’t repeat here) and tried to ban us from social media by reporting our cheqd profiles. This same group also incentivised people to downvote us on CoinMarketCap and CoinGecko. Although we can’t prove it, we believe this group has done these activities before, as it was well coordinated and done at an impressive speed.

And…

You can tell a lot about someone by the way they react when challenged and regardless of whether we were right or wrong in our actions, the abuse that followed wasn’t and isn’t acceptable anywhere for any reason.

Rather than engaging constructively, our Community Managers (CMs), Ambassadors and team were subjected to disgusting racism, sexism, sharing of pornography, and threats of violence, including death threats. The correlation between polite genuine claims and vitriol from those trying to game the airdrop was pretty much perfect.

We have to say a massive thank you to our CMs, Ambassadors and the wider community for their patience and grit in responding to this!

The plot timeline

The plot points above are all intertwined, so we’ve created a timeline view below to show them in chronological order.

Lessons Learned

It’s not as easy as it seems to run an airdrop campaign. As you have seen with our airdrop, and many others, people will try to make the most out of it. It’s normal, a natural human behaviour. We knew this would happen and we tried our best to reward our real community (old and new).

We’re sharing this blog post to help other projects out there that are facing similar issues and to answer some questions that people outside our community might have.

If you have any questions feel free to drop a message on Telegram or Discord.

And, to close this chapter and move on to the next, we ask people that are participating in other airdrops, to be patient, have empathy, and try to understand that behind a project there is a team of people.

People need to eat, sleep, and are working their a** off to get things done right. Like anything in life, sometimes things go as planned, sometimes there are bumps in the way.

We would like to end this blog post by thanking our community members, Community Managers, and Ambassadors for backing us and giving us the strength to keep fighting the Data Wars.

Happy birthday, cheqd! Year in review

happy bday cheqd blog

Co-authored by Fraser Edwards and Ankur Banerjee

It’s now just over a year since we started work on cheqd (or verim as we were first called), which feels like both the shortest and longest year of our lives, certainly the most exciting! Since it’s our first anniversary, we decided to give you a rundown of our first year and share a glimpse into our plans – as always a huge thanks to our community that has been part of this incredible journey!

Pre-genesis (< November 2022)

Post-genesis (> November 2022)

Obviously, the first two items here have to be the following:

Since then, we have been on board a rocket ship! There are so many things to cover, we’ve had to break them out into sections, or the next bit would just be a wall of hyped bullet points:

  • Partnerships (inc. exchanges)
  • Tech / Product (inc. decentralisation)
  • Marketing and Community

Partnerships (incl. exchanges)

EXCHANGES

Just four months on from mainnet launch we are now listed on two centralised exchanges  (Gate.io and Bitmart), two decentralised exchanges (Osmosis and Uniswap) and a fiat on-ramp (Indacoin), so averaging an exchange a month.

  • The key part is providing easy access to the token to allow anyone to begin building as we extend the network utility.
  • Indacoin are especially relevant as they allow anyone with a credit or debit card to access the network without complex service agreements or contracts.
Screenshot 2022-04-21 at 16.26.30

OTHER PARTNERSHIPS

  • SSI: Now working with over 32 market-leading SSI vendors, including esatus, Spherity, Danube Tech, Northern Block, Serto, DIDx, Tykn, Randa Solutions, truu, Anonyome Labs, Domi Labs, Evernym in our first cohort; and, Mavennet, ID Lynx, Umazi, Gravity, Animo Solutions, AyanWorks, Verio, Soverio, Monokee, SecureKey, Gayadeed in our second SSI cohort.
  • Validators: Partnered with top Cosmos validators, including Everstake, Citadel.One, Forbole, Notional, Informal Systems, WhisperNode, Lavender.Five, Enigma, Smartnodes and many more.
  • Consultancies: Signed multiple partnership agreements with consultancies, including 51Nodes, Chainstep and more to be announced with large global consultancies.
  • Global Expansion and Consortia: Signed partnerships with experts and large consortia across the globe, including Data Sharing Coalition in the Netherlands and Australian Data Exchange in Australia.
  • Cross-chain partnerships: MetaVisa, Kado, Avarta & Nethermind in preparation to expand with our SSI partners with new web3 SSI applications.
Screenshot 2022-04-28 at 09.12.07

Tech/ Product (incl. decentralisation)

pasted image 0

A recap of cheqd’s product roadmap priorities for Q1 2022

  • cheqd demo wallet: Inside the next few weeks, we will have a basic wallet for holding W3C Verifiable Credentials as well as tokens, specifically for demo purposes, which can then be expanded upon by ourselves and our partners in bringing end-customers to the network.
image-png
  • Payment Rails: Published the tokenomics for the payment rails, which we’ll be building out over the coming months.
  • ERC-20 token: Partnered with Gravity Bridge to create an ERC20 representation of the Cosmos-based CHEQ token
  • Commits: Been featured on the most number of commits (top five Crypto wide) for the development team across the entire web3 ecosystem!
  • Upgrades: We have upgraded the network twice already. This has included some major improvements to the identity functionality of the network, now hardened and ready for the team to further expand the utility of the network at pace.
  • Documentation: we’re making it as easy as possible to learn more about SSI, decentralised identity and our place in this at cheqd through our new learning site on learn.cheqd.io for validators and the community.
  • Research: Completed an extensive survey of our partners and the entire community, following which we published two detailed pieces of analysis. Firstly, the ​​Top 5 trends in Decentralised Self-Sovereign Identity and Privacy-preserving Technology in Web 3.0, based on a survey of general audiences and experts in the field of self-sovereign identity. Secondly, a more technical piece Understanding the SSI Stack through 5 Trends and Challenges, based on an expert audience of self-sovereign identity vendors and enthusiasts.
  • Infrastructure: We’ve also continued to make choices critical to the long-term sustainability of the network and ease of use, building out DevOps automations to streamline setting up a node, managing a node, and migrating from AWS to a blend of Hetzner, DigitalOcean, and Cloudflare.
  • DIDs: Successfully published the first DID on cheqd mainnet using the cheqd DID method (announcement coming soon!). Refactored the Indy DID method into a W3C compliant format, with DID Docs, options for multiple DID Controllers and more complex Verification Relationships. Built two DID resolvers (main and proxy) for resolving DIDs on cheqd easily.
  • Verifiable Credentials: Utilised an existing SDK to issue our first Verifiable Credential, signed by a cheqd DID. Working on the implementation of Credential schemas with their own DID and DID Document to enable compatibility with AnonCreds. Expanding Hyperledger Aries based SDKs to expand their scope beyond Hyperledger Indy. Packaging all of this into a digestible unified SDK for all our partners to work with.
  • Carbon Neutral: Joined the Cosmos ZERO Carbon Commitment, led by Regen Network – an open-source working framework for carbon footprint calculations for Cosmos Blockchains – to offset our carbon footprint.
Here’s a peek at what’s next – find out more in our full blog here.

cheqd featured in top crypto project daily codebase commits

DECENTRALISATION

The concept of Entropy was created by the team at cheqd to model how the control of the network changes over time, from the initial launch where the core team had greater control (Low Entropy), to a state where the community and users of the network have full control over the network (High Entropy).

We also created a scorecard and model for measuring Entropy.

So, where are we now?

Entropy change

Comparing this to where we started at cheqd mainnet launch, we have decentralised in almost all categories, improving from a score of 9 to a score of 20, out of a possible total of 35. This is a dramatic shift but there is still plenty of improvement remaining, specifically on the number of governance proposals and codebase commits successfully submitted from outside the core team.

Marketing & Community

Our marketing team mainly focused on two areas, content and community building. We’re happy to see that our content got us published in fantastic media outlets, allowed us to get our website pages ranking high on internet searches, and educated many people who haven’t heard about SSI before.

We’re honoured to have loyal and engaged members who have been part of our journey and have seen this amazing growth! Here are some of our highlights:

  • Built an incredible community of over 50 thousand members, including developers and node operators
  • Published 52 blog posts and one whitepaper ‘Self-Sovereign Identity – How big is the market opportunity?‘
  • Got >150 media coverage including Bloomberg, Yahoo! Finance, Benzinga, Market Watch, Bitcoinist and more!
cheqd press collage
  • Uploaded >20 videos
  • Successfully completed our Cosmos Community Rewards, with cheqd growing the number of wallets from 6,000 to 71,000+. This also took our community engagement to new levels with 21,000+ Telegram group members, 48,000+ Twitter followers, and nearly 10,000+ Discord users!
cheqd socials
  • Participated in >five podcasts
  • Organised two memes competitions (and more to come, stay tuned)
  • Attended three conferences/events in person (more to come as events start to open up again)
  • Organised two giveaway contests

Moving forward

  • Building out the identity functionality to the latest standards as they emerge so we will always be at the forefront.
  • Building out payment functionality so the network effects of SSI can be turbocharged by revenue generation and cost-saving.
  • Establishing partnerships with Web3.0 projects to create new utilities including:
    • KYCd but anonymous liquidity pools or collateralised loans
    • p2p transfers with trust, i.e. no more test transfers
    • Proper NFT provenance and ownership
    • Decentralised reputation systems for identity proofing, i.e. legitimate influencer or exchange representative vs a scammer
    • Launching a self-serve decentralised partnership network
  • Progressing our burgeoning partnerships across custodians, exchanges and compliance providers so that we can present an end-to-end solution for enterprises where they don’t need to worry about crypto.

Keep up with our work – follow us on Twitter and Telegram!

SSI for regulatory compliant DeFi

SSI for regulatory compliant DeFi-1

CeDeFi and SSI as Continuums

By Fraser Edwards, CEO & Co-founder at cheqd and Martin Worner, Co-founder at Confio

A continuum can be defined as a model that gradually transitions from one condition to another without abrupt changes. A seamless, natural progression between states. And as we move into a world of Web 3.0, continuums are becoming increasingly important. It may even be possible to argue that the goal of Web 3.0 is one single continuum.

Rather than distinct, standalone ecosystems, Centralised Finance (CeFi) and Decentralised Finance (DeFi) exist on a spectrum, and they are becoming a continuum of one another. CeDeFi, for example, was first coined as a term by Changpeng “CZ” Zhao, CEO of Binance, on the advent of Binance Smart Chain, to describe this coalescence.

Similarly, identity can be modelled as a continuum, from centralised systems, like Identity & Access Management (I&AM) and Customer Relationship Management (CRM), through Federated systems, e.g. login with Facebook or Google, to decentralised or self-sovereign identity, e.g. cheqd, Lissi or IATA travel pass.

Cryptocurrency transfer split
Cryptocurrency transfer split for Central, Northern and Western Europe between CEXs and DEXs. Source: Chainalysis.

What we are seeing now, is like two separate bubbles, a coalescence between DeFi and CeFi in one bubble, and Centralised identity and Decentralised Identity in another. Creating a continuum and symbiotic relationship between the transitioning finance and identity worlds. This can best be seen by the flow of European institutional funds, e.g. pension funds, into DeFi.

bubble coalesence

Combining these continuums into a grid, it is then possible to position protocols, with most of the current DeFi protocols naturally falling into pseudonymous but DeFi area and traditional finance (TradFi) into centralised identity and CeFi (duh!). 

Screenshot 2022-02-22 at 16.30.55
The Continuum Catalyst

The regulatory landscape for DeFI is, without doubt, the catalyst and root cause of this continuum. This is because of the pressure that a decentralised cryptocurrency ecosystem has put on traditional, centralised financial regulations.

The problems are threefold:

  1. Decentralised Exchanges (DEXs) and Decentralised Autonomous Organisations (DAOs) generally have no liability infrastructure or accountable persons, in the instances of fraud, theft or phishing;
  2. Anonymous or pseudonymous transactions supported by coin-mixing/tornado cash protocols can make money laundering difficult to prevent and easier to obscure than in the physical world. Similarly, their pseudo-anonymous identifiers make it difficult for users to demonstrate a sufficient level of understanding of the risks involved in different protocols and transaction types.
  3. The global, cross-border, cyberspace-located nature of transactions and interactions in the cryptocurrency world, act at odds with the distinct jurisdictional scope of national law.

The motivation for regulators pushing for identity is to establish whether the entity behind a platform falls under their jurisdiction or the investor is resident in their jurisdiction. This ensures that the regulators meet their obligations and terms of reference. They cannot ignore entities or residents in their jurisdiction who act in an unsupervised environment.

Furthermore, global regulators have acknowledged that a law on its own is not sufficient to regulate the industry and have resorted to regulating the technical architecture protocols must have in place, mandating increasingly complex identity requirements onto who uses any CeFi or DeFi protocol. Identity requirements, which largely, can only be accomplished by using a decentralised approach, to complement the privacy and pseudonymity-first approach of DeFi.

The most commonly cited identity requirement on CeFi and DeFi is the Financial Action Task Force (FATF) Virtual Assets and Virtual Asset Service Providers, Recommendation 16: the Travel Rule. This has imposed a requirement on Virtual Asset Service Providers (VASPs), such as exchanges or custodians, to store personal information of both parties to transactions greater than $1000 US.

For Exchanges, as an example, the following information is required:

Originator customer information

Owing to this requirement, the identity continuum has been viewed as a trade-off between privacy and regulatory compliance, e.g. full anonymity or pseudonymity would not meet the Travel Rule requirements. Yet, while this may seem binary at first thought, i.e. data is either provided or not, we are starting to see innovations creating different ways of achieving this data sharing without directly compromising user privacy. 

Whilst the likes of Aave ARC have used centralised solutions to achieve this, there is a movement towards decentralised or SSI solutions across both individual and corporate identity. The likes of Notabene, Centre, Bloom and Shyft are already looking into how to reuse KYC’d data, through Self-Sovereign Identity and the interplay between Verifiable Credentials (VCs) and Decentralised Identifiers (DIDs) to enable access to VASPs without compromising user privacy. Similarly, Coinbase, Circle, Anchorage and Robinhood have formed the TRUST consortium to tackle the same issue in a privacy-preserving way. 

Echoing the above, James Taylor, CBO at Unizen says, “DeFi needs to adopt Self-Sovereign Identity in order to onboard banks and TradFi institutions. Verifiable Credentials and Zero-Knowledge Proofs are novel applications that complement the existing compliance framework and retain user’s sovereignty.”

cheqd, eIDAS and the Travel Rule

Due to the continuum of decentralised identity and finance, there is an emerging overlap between the amendments to the European Identification and Trust Services (“eIDAS”) Regulation and a resolution to the Travel Rule friction, tending towards SSI standards.

eIDAS was a Regulation that came into force in 2016 to create a more seamless way of identifying, authenticating and verifying people and businesses in a cross-border setting. It enables organisations to rely on digital signatures and proofs, rather than solely on physical documentation. Recently, there has been a push within the European ecosystem to extend the scope of eIDAS to incorporate Verifiable Credentials into the remit of the eIDAS model, through initiatives such as eIDAS Bridge.

Through an updated eIDAS framework, the sharing of Verifiable Credentials and Verifiable Presentations will satisfy legal requirements for KYC checks and identity checks. This presents a very real opportunity for DeFi protocols seeking regulatory compliance to skip centralised or federated systems, keep their decentralised ethos and protect their user’s privacy. There is a further incentive for DeFi as identity is key to preventing the proceeds of crime from flowing into the financial systems. Additionally, the pseudo-anonymous nature of DeFi creates an adversarial environment where cheating others is widespread as seen for example by front-running or wash trading, and by establishing identity it becomes possible to ascertain who is indulging in the adverse behaviour and remedies can be made. Thus taming DeFi through accountability gives greater confidence to prospective investors and opens DeFi to wider adoption.

How does this work?

Since only one of: physical address, national identity number, customer identity number or date and place of birth is required, it is possible to meet the Travel Rule with only name, account number (wallet address) and a customer identification number. Through a process we set out below, data can be verified by a DeFi protocol without creating another data silo. Importantly, this also will make it possible, albeit onerous and costly, to investigate wrongdoing such as funds routing from hacks.

We have laid out how this works in the diagram and steps below:

diagram
  1. If the DeFi protocol supports it, anyone (individual or organisation) can create a pool or contract with defined KYC requirements. These KYC requirements could range from:
    1. Blacklisting to prevent certain geographies from participating;
    2. Full checks of documents;
    3. Zero-knowledge proof checks for certain criteria.
  2. An individual or organisation will need to receive a Verifiable Credential for going through a normal KYC process once, likely with a reputable VASP, or trusted entity such as a bank, law firm, insurance company etc.
  3. The individual or organisation will be issued a secure, verified digital version of their KYC’d data, likely a passport, driver’s licence or certificate of incorporation.
  4. As part of interacting with the DeFi protocol’s pool, they are required to fulfil the KYC criteria. And, since the data in a Verifiable Credential is, by its very nature, verifiable and certified, it can be checked extremely quickly to avoid introducing more barriers.
  5. The user will provide a Verifiable Credential for their name, wallet address and customer identification number from the VASP to the DeFi pool.
  6. Assuming they fulfil the requirements, the individual or organisation can interact with the pool.
  7. Depending on the policy, the pool may make use of Zero-Knowledge Proofs (ZKPs), see below.

Zero-knowledge proofs

Using Zero-Knowledge Proofs (ZKPs), it is possible to perform checks on an organisation or individual without having to process the underlying data. As examples:

  • It would be possible to check that an individual or organisation has been successfully KYC’d by a trusted organisation for other information such as the user’s address, age or national identity number.
  • It is possible to check an individual is over a certain age without needing their date of birth.
  • It would be possible to check the risk or credit profile of the user without disclosing the underlying information;
    • E.g. Institutional or accredited investors could trade all DeFi, new retail may trade lending, swapping but not highly leveraged futures.
  • Similarly, it would be possible to exclude an organisation based on an excluded country list without needing to know exactly which company they are incorporated in.

Regulatory Authorities

Through the model above, any regulatory authority could request access to the pool of details (which would not contain any information on address, national identity number or date and place of birth). Due to the eIDAS regulatory changes, this would be sufficient for valid identity verification and reporting by the DeFi protocol. If the Regulatory needed to request the underlying data, it would have to request this from the original issuer, making it extremely time-consuming to even secure a single individual’s data as well as reducing the number of copies in circulation.

Corporate SSI

Whilst the example above focused on individuals due to the simplicity of the Travel Rule, where this is likely to come into its own is institutions/companies. Bodies like the Global Legal Entity Identifier Foundation (GLEIF) are already building out SSI implementations (e.g. their virtual legal entity identifier vLEI) to give companies digital identities. This will mean that due diligence/onboarding, mergers & acquisitions and other processes are simplified and improved compared to working through paper documents or at best, easily counterfeited PDFs.

The direction of travel (rule)

There is a clear trend to enable regulatory compliant DeFi, both to be compliant with regulations and avoid prosecution or having to move jurisdictions but also to widen access to entities/individuals with stronger counterparty risk requirements. Our expectation is that the markets could split into two, with institutions flowing into regulated markets whilst individuals remaining anonymous/pseudonymous.

We would also like to state that while this architecture is possible, it does not mean that it should be adopted since we know a large majority of the DeFi community prize their anonymity/pseudonymity and we hope there will always be protocols to support them.

However, it provides a template for any protocol to implement this approach (if they wish and see demand) without having to recreate the architecture.

The key is that as regulation is applied or regulatory compliant DeFi becomes a larger sector, we do not create more data silos and we want to maintain privacy as far as possible.

Coalescing

As we have caveated above, this model should not be imposed upon protocols. However, it does provide a route towards regulatory compliance for those who wish for one with the potential upshot of drastically widening access to DeFi whilst protecting individuals.

To contribute to enabling regulatory compliant DeFi cheqd has joined the CeDeFi Alliance. CeDeFi Alliance is a non-profit organisation kickstarted by Unizen and JUN Capital in order to bring the leading teams from CeFi and DeFi for mass adoption of Distributed Ledger Technology. We are excited to announce that cheqd is joining the CeDeFi Alliance for spearheading the growth of SSI under robust policy frameworks.

The Alliance will reach out to Government Industry Groups on Blockchains and Regulators for creating a compliant policy framework that allows every Individual and Organisation to use CeDeFi Technology with confidence in its full legitimacy.

We would love to hear the community’s thoughts on this, especially everyone’s expectation of the market direction over the coming months and years.

And for anyone building in this space, please get in touch, we would love to hear from you. Drop either [email protected] or Toby ([email protected]) a note and we’ll be straight back to you.

Otherwise, make sure to join our community on Telegram, Twitter or Discord – take your pick!

cheqd’s tokenomics for SSI explained: part 3 – Payment Models

Tokenomics 3

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:

  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. 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.
  3. Low-cost: Transfers should not incur significant costs
  4. Arbitrage resistant: Recipients of data should not be able to avoid paying for that data if a tariff has been set
  5. Commercially sustainable: Any commercial model(s) should enable the network to be self-sufficient without penalising ecosystems on top.
  6. 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:

  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.

Receiver pays issuer: credential exchange flow

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

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.