Introducing Zero Knowledge Credentials (ZKCreds), the latest addition to cheqd

cheqd - Introducing ZKCreds

cheqd becomes one of the first Decentralised Identity networks to enable Zero Knowledge Credentials, ‘ZKCreds’, also known as AnonCreds. Leveraging the renowned and widely used AnonCreds Verifiable Credential format, cheqd, alongside Animo, has built ZKCreds into our tech stack, opening the door to a more privacy-preserving online experience for users.


Zero Knowledge has fast become one of the hottest topics in Web3, with projects across protocols boasting bold and powerful new tooling to enable more private and autonomous online experiences for users.

Zero Knowledge or a zero-knowledge-proof (ZKP) is “a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true” (ExpressVPNP).

Put simply, a user is able to share only information that is necessary to the outcome required, and not all information they could reveal, but don’t need to. Combined with Verifiable Credentials (VCs), ZKPs offer a unique blend of privacy, flexibility and trust.

At cheqd, we’ve been determined to build ZKPs into the stack we offer to our partners, and fortunately, we haven’t had to do this alone. Thanks to the excellent leadership from the Hyperledger Indy and Hyperledger Aries communities, alongside our partner Animo, we’re thrilled to announce the support for Zero Knowledge Credentials (ZKCreds) on cheqd, using the widely known ‘AnonCreds’ Verifiable Credentials format.

Summary of AnonCreds & Zero Knowledge Creds

Across the SSI landscape, there is, of course, a broad range of use cases, which necessitate varying levels of privacy. For some, revealing more data than necessarily required is not of massive concern, for example, when less personal data is contained within the credential. However, for others, being able to prove the validity of a credential without revealing the claims, attributes or data within the credential itself is vital. For example, “ I don’t need to give up my full name or home address to prove I’m over 18”. Within a Web 3 context, “ I don’t need to reveal my wallet address to prove I hold a certain amount of a token”.

AnonCreds, short for ‘Anonymous Credentials’ — are a flavour of Verifiable Credentials that do this and more. Initially part of Hyperledger Indy, now in the Hyperledger AnonCreds project, Anoncreds have been used since 2017 and are one of the most commonly used Verifiable Credential (VC) formats in the world. Crucially, they are regarded as the standard for ZKP-based verifiable credentials, offering varying levels of privacy to the holder, dependent on the data being embedded.

However, as a Hyperledger native format, they have, for the most part, been tightly wedded to the Hyperledger Indy blockchain and an associated Hyperledger Aries Software Development Kit. This made it difficult for developers that want to reap the ZKP benefits of AnonCreds to leverage other networks’ unique value propositions — for example, the payment rails being built by cheqd.

Now, thanks to the work of the Anoncreds community, and the outstanding leadership from Timo Glastra and the Animo team, developers can issue AnonCreds on other chains. What makes this particularly poignant is that cheqd is one of the very first to offer Anoncreds on a non-Indy chain in a standard-compliant, highly performant and accessible format, which has been an industry-wide initiative, as we’ll come to.

Given the key value proposition of AnonCreds is the capability of zero-knowledge-proofs, we’ve chosen to coin the term ‘ZKCreds’ for their implementation on cheqd, given their zero-knowledge strengths and the broader level of understanding when compared to “Anon” as the key term.

ZKCreds x AFJ: opening the door to cheqd for current and future partners

Early on in our cheqd journey, we realised the Aries frameworks and AnonCreds dominance, reported in our blog post in April 2022 and have been eager to find a solution.

At cheqd, of our 42 SSI Vendors, 20+ are primarily issuing AnonCreds, or intend to, which currently requires the use of an Aries-centred Software Development Kit, such as Aries Framework Javascript — AFJ or Aries-Cloud-Agent-Python — ACA-Py.

With the release of the afj/cheqd-sdk module, cheqd’s current and prospective partners now have the ability to migrate their stack from Hyperledger Indy to cheqd, issuing AnonCreds with Aries Framework Javascript initially, with ACA-Py to follow.

Launching ZKCreds on cheqd also has a direct impact on cheqd’s tokenomics. Earlier this year, we introduced a ‘burn’ to the network as part of Tokenomics Part 4, whereby “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.”

With AnonCreds, the writing of resources (DID-Linked Resources) such as Cred Defs, Schemas and Revocation Registries to the ledger are required, each with an associated price. Currently, 50% of identity transaction fees are burnt, however, recent community discussion has meant a proposal to push this to a 99% burn rate is imminent.

Building ZKCreds into cheqd… how did we do it?

In September last 2022, we released and demoed our AnonCreds MVP, working alongside Animo. The crucial requirement for a ledger-agnostic AnonCreds was the ability to store the required AnonCreds resources on-ledger. These include, Credential Definitions (CredDefs), which create an immutable record of key credential information in one place, schemas used to list a set of attributes a credential contains, and the resources associated with revoking a credential.

Ultimately this was made possible through our pioneering implementation of an on-ledger resource module, offering the capability to store and retrieve resources, known as DID-Linked Resources, due to the way they’re stored from the cheqd ledger.

In tandem with our initial MVP, conversations started heating up around the topic of making ‘ledger-agnostic AnonCreds’, and over the past six months, a phenomenal amount of effort has been put in by organisations, including the IETF and the AnonCreds Specification Working Group amongst others, into making this possible. This culminated in the migration of AnonCreds to Hyperledger (hence why the new AnonCreds format is formally known as ‘Hyperledger AnonCreds’). More than 25 sponsors supported the adoption of AnonCreds by Hyperledger, including representatives of Indicio, Accenture, IBM Research Europe, several universities, BC Gov, and Canadian provincial governments, demonstrating the scale of their adoption and the vast pool of potential partners and end customers.

What's next?

Moving forward, we’ll now be guiding our partners through integrating with cheqd, specifically with Aries Framework Javascript. Stay tuned for tutorials on getting started with ZKCreds using AFJ, and check out the cheqd AnonCreds Method here.

For those whose applications are centred around ACA-Py, we’ll also be working with Animo and other partners to build the support for ZKCreds with ACA-Py on cheqd. If you’re involved in ACA-Py development, we’d love to hear from you — reach out to [email protected] to flag your interest.

Separately, if you’re an identity developer, not yet building on cheqd, let’s connect! Reach out to [email protected] to learn more about cheqd and how we may be able to help you.

We’ll also be hosting a series of webinars and workshops geared towards helping you to ‘Build ZKCreds on cheqd’. If you’re interested in being involved, please reach out to [email protected].

cheqd is now supported in’s SSI Kit!

Integration of cheqd into SSI Kit provides greater flexibility for adopters of cheqd, opens up a new customer-base for increased utility on the network and helps future-proof cheqd for upcoming EU regulations!


We are excited to announce that cheqd is now fully supported in’s SSI Kit. This integration expands the support for cheqd in a greater array of SDKs, and provides end-customers the flexibility to choose a wider breadth of options for credential exchange protocols.

SSI Kit leverages the cheqd/sdk, slotting neatly alongside other supported SDKs including Veramo, and the soon to be released Aries SDKs, offering a wide range of SDK choices for SSI app developers which they can select dependent on their needs and existing stack.

What is SSI Kit?

SSI Kit is a holistic and standard-compliant open source tool created and maintained by the team at It offers everything you need to use Self-Sovereign Identity (SSI) with ease, including the creation, issuance, management and verification of Verifiable Credentials across various ecosystems.

SSI Kit utility for different parties docs — SSI Kit | Basics — Learn what the SSI Kit is.

Integrating cheqd with SSI Kit provides an array of benefits for both cheqd and’s existing end-customers and users:

cheqd customers:

Supporting cheqd within the SSI Kit means that anyone that wants to use cheqd, can now do so through’s intuitive and easy to use tools — available here. Through this, SSI developers can:

  • Create DID — Create your first did:cheqd
  • Issue VC — Issue your first Verifiable Credential based on a did:cheqd
  • Verify VC — Verify your Credential based on a did:cheqd

This offers cheqd’s customers:

  • Greater flexibility for end-customers: Through expanding support for cheqd into SSI Kit, end-customers can now choose a more specific technical stack that suits their needs best — with Veramo and Aries Framework JavaScript as other enterprise options.
  • Simple APIs for credential operations: offers a selection of enterprise-ready APIs for creating, updating and revoking credentials. With this new integration, all of the operations can be carried out with cheqd DIDs which makes integrating cheqd DIDs, DID-Linked Resources and Credentials into client applications lightweight and simple!
  • Future proofed for upcoming regulations: SSI Kit uses the OpenID for Verifiable Credentials stack for establishing peer-to-peer connections and for credential exchange. This is notable because it aligns with the proposed European Digital Identity Architecture and Reference Framework, which will accompany upcoming European regulations such as eIDAS v2.
  • Streamlining the bridge from Web2 identity into Web3: Through’s IDP kit, (Identity Provider Kit) cheqd customers can use cheqd issued Verifiable Credentials with traditional identity infrastructure, such as IAM tools including KeyCloakgluu and Okta. customers:

The SSI Kit abstracts complexity for developers by following a “multi-stack approach” that enables developers to use different implementations or “flavours” of SSI. Adding cheqd as the latest “flavour” offers walt’s customers all the benefits cheqd has to offer, including:
  • Support for DID-Linked Resources: cheqd is the first identity network to build and support DID-Linked Resources (now a draft W3C standard) to support various identity data structures such as schemas, trust registries and status lists. Support for cheqd enables’s existing customer-base to utilise this innovative functionality.
  • Support for upcoming Payment Rails: cheqd’s vision is to become the de-facto payment mechanism for trusted data. By supporting cheqd within the SSI Kit,’s customers can benefit from already having existing integrations with cheqd, making it far easier and faster to leverage payment rails when released.
  • Offering a higher performance network at a lower cost: cheqd is designed as a highly performant Layer 1 with high throughput. cheqd can process an estimated 7,500 Transactions Per Second (TPS), benchmarking well beyond other leading networks such as Cardono (250 TPS), Ethereum (15–30 TPS), Avalanche (5000 TPS) and Bitcoin (10 TPS). Gas fees on cheqd are a fraction of the cost of other networks, making it far cheaper to transact on the network.

Why is’s SSI Kit important for cheqd?

When it comes to Self-Sovereign Identity, there are different technical components that need to work together to construct an end-to-end solution. The combination of different protocols together to make-up a tech stack is vital for interoperability between different ecosystems.

The Trust over IP Foundation describe these different components clearly within the ToIP Stack:

Trust over IP (ToIP) Stack

With reference to the image above, cheqd sits at the Layer 1 of the stack; cheqd is a Verifiable Data Registry with a DID method which supports the anchoring of DIDs and associated DID-Linked Resources.

SSI Kit works at Layers 2 and 3 of the stack, supporting a suite of protocols for credential exchange and peer-to-peer connections which hit a different market compared to those cheqd supports in its other SDKs. These include: OAuthOpenID for Verifiable Credential Issuance (OpenID4VCI)OpenID for Verifiable Presentations (OpenID4VP) and Self-Issued OpenID Provider v2 (SIOP V2).

The image below offers a cheqd specific overview which helps to further illustrate SSI Kit’s place in the stack.

cheqd capability model

By supporting these protocols, it gives end-customers more flexibility in choosing a tech stack that fits on top of their use case, jurisdiction and existing identity management systems. This is especially important as:

  1. The OpenID for Verifiable Credential stack is closely related to OpenID Connect in terms of how the authentication flows work between different parties. This makes it less daunting for companies to transition from something more traditional or federated, such as OpenID Connect, to decentralised identity.
  2. The OpenID for Verifiable Credential protocols are also supported by a range of prominent SSI vendors, such as Microsoft (Entra), MattrYesPing and Workday within the VC-JWT Presentation Profile, meaning that cheqd can now support and interoperate with a wider array of large vendors and their clients.
  3. These protocols form part of the European Digital Identity Architecture and Reference Framework, which is a new interoperability profile for companies to exchange trusted data in the European Union. Conforming with the technical stack described here will help future-proof cheqd’s tech stack for the upcoming European regulatory changes, which will give legal effect for credentials as a means of data exchange.

If you are interested in learning more about these regulatory changes, we would recommend that you read Avast’s takeaways from the regulatory changes, or watch Nacho Alamillo’s presentation on the proposed eIDAS 2 Regulation.

A bright future ahead

Interoperability, flexibility, simplicity and cost-efficiency are the key ingredients for adoption of Self-Sovereign Identity. With an eye on all of these, cheqd is positioning itself strategically for any vendor or organisation looking to implement an SSI solution. SSI Kit was the perfect storm for providing another enterprise software product, while also covering a new set of connection credential and exchange protocols.

Oh, and if you made it this far — we also have a lot of exciting developments to come, using this tech stack and the cheqd <> partnership 🔜👢👢

As always, if this blog resonates with you and you want to learn more about building on cheqd, please get in touch with our product team here and cheq-out our identity documentation here.

Universal Registrar: DID utility off-the-shelf


cheqd’s new Universal Registrar driver enables easy and efficient integration with cheqd’s DID and DID-Linked Resource utility.


We are excited to announce that we have successfully built a cheqd driver into Decentralized Identity Foundation’s (DIF) Universal Registrar to enable out-of-the-box and highly efficient DID and DID-Linked Resource transactions on cheqd. This is a big step in simplifying the developer journey for client applications to use cheqd’s DID and DID-Linked Resource utility in a more light way than integrating with our Software Development Kits (SDKs).

Understanding the value of the Registrar

The Universal Registrar is an open source application created by the Decentralized Identity Foundation (DIF) which aims to make it far easier to create, update and deactivate Decentralized Identifiers (DIDs) across a range of DID Methods without full integration.


The aim of the Universal Registrar is similar to the Universal Resolver; to transform method-specific APIs for DID transactions into a common format for client applications to easily call. In more simple terms, remember the kids’ toys with different shapes and different shaped holes? Yep this one!

Imagine each different DID Method driver is a different shape. If you run an application and have to consume all different shapes and sizes, that is a hugeeeee uplift to maintain. What the Universal Registrar does is converts all of these shapes into one common shape which makes it far easier for any application to consume any of the listed DIDs (in technical terms it wraps an API around a number of co-located Docker containers).

DID Operations with minimal integration

Not only does it make it easier for client applications to support DIDs from multiple DID methods, but it also makes it far quicker and easier to create, update and deactivate DIDs — as it calls the method-specific driver with a common API.

If you imagine our SDK as a flatpack #IKEA product for DIDs, where it’s simple to put together, but you have to have instructions & the right tools (and a bit of patience).

Then imagine the Universal Registrar is like buying cheqd DID functionality straight off-the-shelf — it’s simple, efficient and quick! And it allows our partners or customers to use cheqd’s utility within minutes.

Therefore, the barrier for integrating cheqd DIDs into existing client applications has been greatly reduced by the Registrar. Instead of having to integrate with the cheqd SDK, applications can now create a simple workflow to call the relevant APIs for issuing, updating or deactivating cheqd DIDs and creating DID-Linked Resources.

Going beyond other DID Registrar Drivers

cheqd’s DID Registrar driver also supports the creation of DID-Linked Resources which goes beyond any other existing DID Method on the market. This provides the functionality for any developer to easily create the likes of schemas, trust registries and status lists on cheqd.

This week, the W3C has also formally approved the DID-Linked Resource work item which will be developed as a formal standard over the next few months here! 🥳

Getting started with the Registrar

We have created a simple setup guide for using the Registrar with Docker or locally. You can also find us on the Universal Registrar frontend.

Once you have setup the registrar, you can use the cheqd Registrar driver APIs here coupled with the Universal Registrar to build into your workflows!

For more information, we have created an Architecture Decision Record which describes the workflow for building cheqd DIDs and DID-Linked Resources into existing client applications using the Registrar.


We were clear in our Product Vision blog for 2023 that the path to adoption for cheqd goes hand in hand with the simplicity of integrating with its identity functionality. Using a DID Registrar abstracts away a lot of the complexity of fully integrating with cheqd’s SDK, but provides all the same benefits for DIDs and DID-Linked Resources. This is therefore a huge step in gaining wider adoption in a broad array of applications and SDKs, as the uplift for supporting cheqd DIDs is now much simpler. As always, if this blog resonates with you and you want to learn more about building on cheqd, please get in touch with our partnerships team here or you can try out our SDK for issuing and verifying credentials here, and you can setup the DID Registrar here! We set out at the beginning of 2022 to integrate cheqd into the DIF Universal Resolver. The Universal Resolver utilises REST APIs and other interfaces to enable the resolution of any DIDs which have a supported driver. We have successfully made this integration and you can now find did:cheqd on the list of supported drivers. Over 2023, we will improve and refactor our DID Resolver and our integration to make it fully enterprise-ready. The graph below shows our work on the cheqd DID Resolver and how the bulk of the work was carried out towards within the second and third quarter.

Our Product Vision for 2023 at cheqd

Setting the vision for the year ahead for delivering on cheqd network’s unique differentiators in decentralised identity

Co-authored by Ankur Banerjee (CTO/co-founder), Ross Power (Product Manager), and Alex Tweeddale (Product Manager & Governance).

The cheqd team is thrilled to begin 2023 with our first major version released for the cheqd mainnet/testnet to v1.x, which was successfully carried out on 30th January 2023. Throughout this blog post, we want to revisit our product reflections at the end of last year, and lay out a vision for the future.

🚀 Our product roadmap at cheqd for 2023

Our product vision last year (published just two months after the launch) described our objectives using fundamental building blocks that we wanted to deliver. We’re excited to say that our v1.x release delivered on a lot of those fundamentals (more on that later).

product roadmap at cheqd for 2023, at a glance

Therefore, for this year, we’ve outlined five product development goals the cheqd team is working on, in terms of objectives we want to achieve by the end of 2023:

  1. Double-down on building payment rails for digital identity: This is the unique selling point for which most of our partners signed up to the cheqd network — and why many people in the cheqd community are backing us. For reasons we’ll go into more detail in the blog post, we had to spend more time than we anticipated in 2022 laying down the groundwork for this — but now that those foundations have been delivered in our v1.x release, we’ll be laser-focussed on delivering the payment rails everyone has been waiting for.
  2. Continue simplifying developer experience to make building on top of cheqd network faster and cheaper: We’ve spent a lot of time in 2022 simplifying the developer experience for partners and app developers building products on cheqd. We plan to continue on our mission to make building products on cheqd simple in comparison to Web2 as well as Web3 digital identity competitors. We also want to drive more organic adoption of network usage by existing and future partners.
  3. Support compelling products addressing decentralised reputation for Web3 ecosystems: 2023 seems to be a turning point where the wider crypto ecosystem has acknowledged that Web3 requires compelling solutions to decentralised reputation, but so far this effort has been focussed on using NFTs for identity (hello, soul-bound tokens), proof-of-attendance protocols (“POAPs”), and so on. As we laid out in our trends report on decentralised identity, we think there’s a large and unaddressed gap in the market for a more privacy-focussed vision of how online reputation can be solved in decentralised communities. We’ve been working on skunkworks project for the past few months, codenamed “Project Boots”, which is aimed at this space.
  4. Integrate deeper with the Cosmoverse and beyond: We focussed a lot of last year on building out strong partnerships in the self-sovereign identity (SSI) ecosystem. This year, we want to leverage the multichain vision of the Cosmos SDK ecosystem to become one of the go-to solutions for digital identity within the Cosmoverse. We also believe that our network can be of utility for Web3 projects not built on Cosmos SDK, without them needing to switch blockchains. At the same time, we will work on improving the availability of $CHEQ tokens, and first-class support in crypto apps (such as wallets and explorers), all with the aim of making it easier to use and build upon the network.
  5. Drive adoption via industry standards for product innovations made at cheqd: We’ve been working on differentiated product innovations last year at cheqd, such as our approach to DID-Linked Resources. While we’ve written and designed this to be ledger-agnostic, widespread adoption of this idea (and therefore, normalising its usage on the cheqd network) requires us to do the legwork to get them codified as industry standards at W3CDIF, and ToIP. We think the time is ripe for this, given the Decentralized Identifiers Core (“DID Core”) became an official W3C Recommendation standard last year.

We’ll deep-dive into each of the five product development goals below. Alongside this, we are very excited to share an interactive product roadmap for cheqd which we will continue to update and iterate over the course of the year and beyond.

1️⃣ Double-down on building payment rails for digital identity

The core vision of cheqd is that while the idea of decentralised identity that is in control of the user is a noble ideal, the lack of business models on why the issuers of this data should give this data back to users is hampering adoption of self-sovereign identity.
Overview of payment rails for digital identity

Payment rails for verifiable credentials will enable each party in a digital identity ecosystem to be rewarded for their participation in the network. Credential issuers may be rewarded for issuing Verifiable CredentialsHolders may be rewarded for sharing their own data in the form of Verifiable Credentials or PresentationsCredential recipients (“Verifiers”) may be rewarded with compliance benefits and lower costs for identity verifications.

At the same time, we acknowledge that one of the fundamental principles of SSI / decentralised identity is giving power to the user. We believe there’s a happy middle-ground that can enable these payment rails and have privacy-preserving characteristics that the SSI ecosystem (and users) value.


  1. You might hold a drivers licence, issued by a trusted authority (e.g., the government driving licence authority)
  2. When you go to buy an age-restricted product, such as alcohol or tobacco, the store might check your age by asking you for your drivers licence. (Note that the “credential” is being used here outside its original intended purpose to prove the right to drive.) This interaction is “free” for the store’s clerk, since they are only interested in checking whether the age in an official-looking document is above a certain number,
  3. However, if you wanted to rent a car, the car rental agency might run a live check against a government database or other 3rd party API to determine whether the licence is currently valid, or whether it has been revoked ahead of its original expiry date. This interaction typically costs the car rental agency something, i.e., a per-check fee paid to the API they do the lookup on.


The holder is you (the driving licence holder), the issuer is the driving licence agency, and there are two (separate, unrelated) credential recipients (“verifiers”): the alcohol store and the car rental agency. We believe there’s a large sector of the SSI market where credential recipients will be willing to pay a small fee to check the status of credentials, and it will motivate potential credential issuers to hand out data in portable and secure data credentials.

Responses captured within cheqd blog Understanding the SSI stack through 5 trends and challenges


In order to build such a solution, it is relatively easy to build a centralised, gated API where payment must be made before the API returns a response. Centralised, gated APIs are extremely common in the Web2 world. Such a centralised API would also be privacy-leaking, since the act of looking up details on such APIs itself reveals information about the client application/user accessing the information, the contents of the information being accessed, etc. Both Google and Facebook backdoor tracking data for their ad networks using their “Login with…” buttons, regardless of whether you personally use the Google/Facebook login option or not. Therefore, we’re interested in building a decentralised mechanism or API that is privacy-preserving and minimises leakage of which credential’s revocation status was checked. Logical components include:
  1. A decentralised credential status & trust registry: This answers the question “Is this credential I’ve been shown revoked or not?” and “Is the issuer of the credential trustworthy?”. We’ve already delivered a mechanism to answer these two questions in a decentralised fashion, using DID-Linked Resources (and made it more robust in our v1.x mainnet release).
  2. A token-based payment-gating mechanism: The status & trust registry above should only reveal the answer once the pre-defined payment set by the issuer of the credential has been paid. In other words, this would be a mechanism to charge for read actions on DID-Linked Resources.
  3. A payment-privacy system: The value of a transaction or the sender/recipient itself can leak private information about the parties involved. An ideal payment mechanism for the above would try to minimise information leakage.
Without giving too much of the secret sauce away, our product & engineering team already has a viable approach for a token-based payment-gating mechanism we plan on building out over Q1/Q2 of this year, layer on top of the code we’ve already shipped for credential status & trust registries. We plan on making this functionality available first using a decentralised approach as the first layer of privacy-preservation, and then layer on multiple approaches to increasing payment functionality till the end of the year.

2️⃣ Continue simplifying developer experience to make building on top of cheqd network faster and cheaper

When we started 2022, cheqd had just launched its mainnet in November 2021. While our first mainnet release certainly offered enhanced support for more complex Decentralized Identifier Documents (“DID Documents”), we knew that we were going up against incumbent networks in self-sovereign identity which had been building for much longer than us.

So we set out in address one north star question within the product team last year: “Can an app developer, starting from scratch, build a digital identity use case on cheqd in less than 30 minutes?” Critically, we didn’t distinguish this with any qualifiers such as “…compared to other SSI networks” or “…compared to Web 2.0 identity solutions”. Both Web2 as well as Web3 identity solutions are our competition since they represent the status quo in how our digital identities are handled online.

What the cheqd team has delivered in 2022

Much of what we’ve shipped in terms of products on-ledger and off-ledger was building towards answering this question. Some of this work was driven by the cheqd Product & Engineering team directly to jump-start network usage, such as building a plugin for the widely-used Veramo SDK for W3C-compliant DIDs and Verifiable Credentials.

Other efforts, such as the work done on Hyperledger Aries by Animo to make AnonCreds independent of Hyperledger Indy happened more organically through app developers building on top of the cheqd network. Ultimately, we want more app developers organically building products, so that our team can focus on unique differentiators that no other decentralised identity network offers.

cheqd Product Reflections 2022


Product partnerships are crucial to cheqd as a network, whether they are mature SSI vendors, or startups that have heard of SSI but haven’t dipped too far into building it into their products so far.

Instead of just looking at integrating cheqd at a technical level, we’re collaborating on more than a dozen specific product use cases with our partners, such as:

  1. Single Sign-On (opening up the opportunity for “Sign-in with cheqd”);
  2. Integrations in enterprise uses cases in Web2;
  3. Integrations into Web3 use cases including community & reputation managements;
  4. Integrations in private network consorta clients
  5. Integrations for Consumer Credit scores to Web3 lending environments
  6. Integrations for recycling and sustainability payments
  7. Payment rails for financial institutions
  8. Opportunities for better management of storage


At the start of 2022 we surveyed our partners to inform our product strategy for the year. The responses emphasised the importance and potential impact of assigning part of our time to adding cheqd network support in Hyperledger Aries, which is the most widely-used SSI SDK kit.

(N.B, Respondents could select that they are using multiple SDKs hence the reason for graph illustrating a percentage greater than 100).

Therefore, this year we’re continuing to build on the progress we made to support Aries frameworks on cheqd, working closely with our partners and the wider SSI community to advance standards and interoperability. This includes contributing to and integrating with Hyperledger AnonCreds, a ledger-agnostic and client-agnostic version of the widely used AnonCreds credential format. Working with Animo, we’re enabling our partners to issue Hyperledger AnonCreds using the Aries Framework Javascript SDK, followed by ACA-Py.

However, we also know that not every SSI vendor uses Aries SDK. Having a diverse and vibrant ecosystem of SDKs is important for creating a truly decentralised developer ecosystem, and as such we’re continuing to work closely with the Veramo SDK, supporting both JSON-JWT and JSON-LD credentials.

We also believe that outside of the SSI vendors we’re already partnering with, there’s a larger market of app developers who want to build privacy-enhanced digital identity experiences, but aren’t currently using SSI in their products. This has been evidenced by a large volume of inbound requests we’ve had from such startups and app developers, asking us how they could incorporate a new model for digital identity into their products. Asking these app developers to wholesale switch SDKs is hard.

Therefore, we’re focussed on building cheqd network support into DIF Universal Registrar, making it quick and easy for app developers to integrate cheqd using simple REST APIs. (REST APIs are the most commonly-used API pattern, used in Web 2.0 apps as well as within Cosmos SDK itself, e.g., for Keplr Wallet interacting with Cosmos dApps.) This will increase cheqd’s wider adoption and user / developer experience for SSI vendors, developers and Web3 partners.


With a huge amount of work on ledger-agnostic AnonCreds in-flight, we plan to continue funding and accelerating efforts to unlock first-class support for cheqd network in the most widely adopted SSI SDK.

We’re also excited to announce that we will soon be fully supported in’s SSI Kit, which natively supports JSON and JSON-LD credential types, while using a different credential exchange protocol to our existing Veramo SDK’s SSI Kit uses the Open ID Connect Stack for credential and presentation exchange, affording cheqd even more coverage across the Verifiable Credentials landscape.

3️⃣ Launch compelling products addressing decentralised reputation for Web3 ecosystems

A large gap in the current SSI space is functional governance for SSI ecosystems. There are a few approaches to Trust Registries and Trust Establishment which are currently unstandardised and generally rely on centralised infrastructure. We presented a research paper at the Rebooting Web of Trust conference last year, titled Dynamic & Decentralized Reputation for the Web of Trust: What We Can Learn from the World of Sports, Tinder, and Netflix which laid out some of extremely long-term thinking on where the digital ID industry is heading.

In the more immediate term, with cheqd’s DID-Linked Resources we’ve built a perfect foundation for creating Trusted Issuer ListsTrust Establishment files, Credential Manifests or Presentation Definitions on-ledger, identifiable with a fully resolvable DID URL. This may even improve the standard paradigm for working with interoperability profiles such as WACI-DIDComm.

Further to this, one of the needs we’ve identified from SSI clients is a web application that is able to manage trusted issuers in a given ecosystem, as well as what levels of governance are required for different purposes.

Using cheqd DID-Linked Resources, we foresee this being far easier to achieve than by building from scratch. This year, we plan to demonstrate these benefits and streamline their existing client facing application and demonstrate DIF Trust Establishment and Trust Registry capabilities on cheqd, alongside one of our partners.

Lastly on this point, we plan on launching our skunkworks project, codenamed “Project Boots”, within Q1/Q2 of this year. While the SSI space often uses the usual suspect use cases, e.g., Know Your Customer (KYC), education degrees, etc, in examples quite often, we fundamentally think these are infrequent use cases, and therefore not something truly painful that real-world users face on a daily basis. What they struggle with is proving their reputation online. Stay tuned for more on how we plan to re-use everything we’ve already launched in a compelling and fun experience for tackling reputation in Web3.

4️⃣ Integrate deeper with the Cosmoverse and beyond

One of the things we understand, in hindsight, is that while we focussed last year a lot on SSI vendor partnerships, we didn’t focus perhaps as much on building equally deep ties within the Cosmoverse. While some of the most notable players in the Cosmos ecosystem validate on our network and we collaborate in terms of contributing back open source code, we could do even better at this.

It’s worth noting that as part of our v1.x release, cheqd is one of the first Cosmos SDK chains to adopt Cosmos SDK v0.46, which brings capabilities such as Interchain Accounts. Besides, Cosmos SDK v0.46 introduces long-term and stable fixes for the “Dragonberry” security vulnerability which could theoretically compromise IBC payments. Incorporating the deep nuts-and-bolts changes needed to make cheqd ledger compatible with changes in upstream Cosmos SDK was one of the reasons why our v1.x release took longer than we expected. While being one of the first chains to adopt this Cosmos SDK release was technically challenging, we take security very seriously at cheqd — especially as we want to build the payment rails for digital identity.

Moreover, the next version of Cosmos SDK (v0.47) has an even bigger growth spurt to make the interchain software foundations more robust and secure. While we won’t need to incorporate these right away, the work we’ve done to transition v1.x will make the process of moving to Cosmos SDK v0.47 smoother when the time comes.

We’ve heard you loud and clear, though, on the need to increase our presence in the Cosmoverse. Some of our aspirational goals in this space are:

  1. First-class support for cheqd network in more Cosmos SDK wallets and apps: We’ve got first-party integrations into Leap Wallet for our network’s token functionality. We want to work on expanding support for Verifiable Credentials natively in crypto wallets by extending the WalletConnect protocol in 2023. Ideally, we want to extend this to Keplr Wallet and Mintscan, which are the two biggest product requests we get. We’re in continued discussions with both and are looking forward to these product integrations as soon as reasonably possible.
  2. Position cheqd as one of the go-to solutions for digital identity within the Cosmoverse: We’ll leverage the good work we’ve done last year, and continue to do this year, in terms of making utility usage of our network easier to specifically guide Cosmos SDK projects on how to use cheqd for privacy-enhanced digital ID. Our goals defined under simplify developer experience and decentralised reputation (aka “Project Boots”) both feed into this goal.

As always, we’ll continue to support $CHEQ in more CEXs/DEXs as an ongoing goal to make the tokenomics of our network more viable.

5️⃣ Drive adoption via industry standards for product innovations made at cheqd

Technical standards are crucial in ensuring interoperability between different SSI ecosystems. As such, we are currently in the process of getting two different standards created: ledger-agnostic Hyperledger AnonCreds and W3C DID-Linked Resources. This is based on feedback from our SSI vendor-partners that efforts we put into getting these product innovations at cheqd incorporated into standards has a tangible impact on their prioritisation for these features into being used in their products.

Later in the year, we will kick off a technical standard looking at how Verifiable Credentials can be incorporated within WalletConnect at the Chain Agnostic Standards Alliance (CASA). The basic idea here is that there are far more crypto wallets in active use, as opposed to SSI wallets, and native support for Verifiable Credentials in crypto wallets will significantly increase the reach and distribution of SSI. We want to focus on WalletConnect since some of the most widely-adopted crypto wallets support this protocol, and our proposal would be to specify a technical method through which dApps and wallets can signal which kind of Verifiable Credential features they support. Similarly, we’re also exploring collaboration with the Open Wallet foundation, a Linux foundation project with the goal of developing an open-source engine for secure and interoperable multi-purpose wallets.

Finally, we are eager to participate and explore live interoperability testing amongst projects, such as Silicon Valley Innovation Program Plugfest and other large SSI networks such as European Blockchain Services Infrastructure (EBSI) and LACChain. This is important because cheqd does not want to build in a vacuum and aligning with other chains, programmes and identity initiatives will ensure that cheqd’s progress in payments and resources is market-ready and interoperable cross-ecosystem.

⏪ How our v1.x release enables our 2023 product goals

Hopefully, we’ve given a flavour above on our product vision for this year. We’ve been humbled by the response over 2022 from our partners and app developers building on top of the cheqd network. There is clear excitement about the product vision we’ve laid out in terms of economically-sustainable business models for digital identity. But to truly be able to build towards that vision, our strategy was to first offer a decentralised network that was incrementally better than the current state-of-the-art in self-sovereign identity.

Making AnonCreds ledger-independent and the opportunities unlocked by DID-Linked Resources are two tangible examples where we exceeded the capabilities of current SSI networks. But, we also knew that achieving our north star goal of “up-and-running in 30 minutes or less” required additional effort.

To wrap up our product vision, we wanted to recap the key areas that our v1.x release delivers on, and forms the fundamentals of our product roadmap we’ve outlined above for 2023…

Read: cheqd Network Changelog – release 1.x


The feedback on DID-Linked Resources that we received from the decentralised identity community has been, overall, positive. One of the features that developers appreciated was the robust versioning (and being able to query historical versions) for these digital Resources. While it was technically possible to query historical versions of DID Documents as well, we’ve released the same robust versioning method we built for DID-Linked Resources for actual DID Documents themselves. (It’s worth noting that not all DID methods support versioning.)

We also spent the latter half of 2022 building SDKs and integration software such as support in the DIF Universal Resolver, which we know are important for developer adoption. Using the lessons learnt along the way, we refactored parts of our on-ledger code to make building integrations with SDKs and 3rd party apps easier. This enables our goals for simplifying developer experienceintegrating deeper with Cosmoverse, and aligning for industry-standardisation (based on feedback we received for DID-Linked Resources).


Prior to the v1.x update, writing a DID to cheqd mainnet only costs gas, approximately 0.004 $CHEQ. In comparison to other networks, this is a far lower price (you’ll find a pricing comparison here, also below).


Prior to the v1.x update, writing a DID to cheqd mainnet only costs gas, approximately 0.004 $CHEQ. In comparison to other networks, this is a far lower price (you’ll find a pricing comparison here, also below).

Additionally, $CHEQ was previously inflationary, meaning the staking rewards are generated from inflation only, and only slashing, tombstoning or no-with-veto slashing provide an inflationary pressure. Therefore, we chose to introduce two key mechanisms to counteract these. The first, identity transaction pricing, means that any transaction on-ledger related to identity has a specific, fixed fee. For example, creating a DID or any form of resource, like an image or schema, has a set fee. The current prices for these can be seen here, and below.

The second, a burn mechanism helps establish equilibrium with the inflation on the network by burning a proportion of the identity transaction charges above. Over time we see this a viable route to return the total supply to the total initial supply of one billion $CHEQ. The current burn % has been set at 50%, however we have tested the right up to 99% and will take the communities lead to decide where this % will remain for a longer term.

In addition to making identity transactions more economically-sustainable, we also see this an important method of providing more stability to app developers building with cheqd, as a means to more accurately forecast and price the build of products for customers.


Preparing for and implementing the v1.x release did however have its fair share of challenges, which transparently slowed down our release cycle.

To accommodate for the ledger enhancements, fundamental changes were required to the underlying code base which the ledger uses. For example identity transaction pricing and the ability to provide an alternative URI for a DID did not exist in the previous version, meaning this feature would not be possible to implement. The effort and time required to implement the changes and test these expanded far greater than we’d anticipated, however ultimately doing so has put us in a far better position which will mean we take back the time in future implementation and releases.

We’ll be providing a deeper-dive into these challenges, plus others, and crucially our lessons learnt which we hope will be useful for other Cosmos SDK-based projects and the general developer community alike.

Tell us what you think!

It’s going to be a very busy and ambitious year here at cheqd and we would love your feedback on our product vision for 2023. We welcome engagement and feedback across a range of different forums, such as our Community Slack and Commonwealth Governance Forum (best for extended, in-depth discussions).

We, at cheqd, help companies leverage SSI. cheqd’s network is built on a blockchain with a dedicated token for payment, which enables new business models for verifiers, holders and issuers. In these business models, verifiable credentials are exchanged in a trusted, reusable, safer, and cheaper way — alongside a customisable fee. Find out more about cheqd’s solutions for self-sovereign identity

cheqd Product Reflections 2022

A retrospective on a year building a Decentralized Identity network on Cosmos. Co-authored by Ankur BanerjeeRoss Power and Alex Tweeddale.


2022 has been a huge year for the cheqd Product & Engineering team. We’ve made three major software upgrade releases to the cheqd network and several minor upgrades, including:

Each upgrade comes at the end of a development cycle (shown by the spikes on the graph below), contributing towards our mission to build a stable, trusted and secure decentralised identity network, known within SSI as a Verifiable Data Registry.

Cadence of our commits on cheqd node over 2022

From these releases, here’s a quick overview of what our overall journey looks like so far:

cheqd Journey to Payment Rails

You can think of everything we have been working on to date as:

  1. Feature parity with all other SSI networks;
  2. Identity functionality that goes beyond existing SSI networks; and
  3. The tooling and scaffolding to lay the foundations for payment rails for Verifiable Credentials.

Bringing this all together into a visual representation, using the Trust Over IP stack as we have done in the past, helps to make sense of what cheqd’s capabilities look like both now and what’s to come…

cheqd Capability Stack

Our top product takeaways

Before diving into how we measured up against our 2022 roadmap, we wanted to lay out five key product takeaways from this year.

1. SDKs are a crucial product driver to adoption

To get cheqd integrated into our partners’ software applications, we must focus on supporting the broadest range of SDKs, across Hyperledger Aries and non-Aries spheres. Until functionality is supported fully in an SDK, the fact that it is supported on the cheqd network is less relevant.

This year, 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 in the process of building cheqd support into Aries Framework JavaScript.

That said, we also want to be honest with ourselves and you in some areas. We had hoped to make more progress and have a larger suite of SDK support this year. However, the complexity of SDKs and the effort we put into building other first-of-a-kind aspects of our ledger, such as a Resource module has slowed this progress down. Aries SDKs are largely a community challenge. With each SDK so tightly bedded to Hyperledger Indy, it’s taking a mammoth effort from the whole AnonCreds community to rework this into a Ledger-agnostic AnonCredss specification.

2. Payment rails are worth the cost / benefit analysis

Mass adoption for cheqd is predicated on the success of the payment rails. Earlier in the year, we conducted a survey and gathered that payment rails would swing partners to invest the time and resources to fully integrate with cheqd because they would offer a new angle and incentive for clients and customers to bite on SSI technology.

Data showing how payment rails will help cheqd’s partners gain adoption

While admittedly, we didn’t make the progress into payment rails that we set out at the beginning of the year, we have laid the groundwork in terms of identity functionality, partnerships and interoperability for payments to feature centre stage in 2023.

3. Interoperability is a USP

In terms of identity on-ledger, we generally feel a great sense of accomplishment with our progress. Being able to bridge the AnonCreds crowd with the VC-JWT and VC-DI (JSON-LD) proponents using innovative and highly requested standards will help cheqd establish itself as a respected alternative to other leading identity networks such as Sovrin and ION.

We are also leading the charge to broaden Hyperledger Aries SDKs’ dependencies and innate ties to Hyperledger Indy. We joked about the interoperability pitfalls of Aries at the start of the year in our presentation on the Seven Deadly Sins of Commercialising SSI, and now meaningful interop changes are finally coming to fruition.

Meme about Hyperledge Aries interop

4. Never underestimate the difficulty of refactoring to support upstream changes

The Cosmos-wide Dragonberry vulnerability and patch (see 0.6.9) was a big shakeup in the Cosmos SDK ecosystem. As a result of the vulnerability, there have since been widely coordinated sets of changes for securitys reasons across the Cosmos ecosystem.

In just two months there have been six Cosmos SDK bumps addressing security issues. In two of these releases (0.46.5 and 0.46.7) prior versions of Cosmos SDK were retracted for security reasons, meaning that expedited shifts to the latest SDK versions was a priority.

Additionally, software for decentralised identity gets developed very rapidly and requires fast catchup to upstream projects/codebases. For example, our Veramo SDK for cheqd requires changes to be made when there are upstream changes in the Veramo SDK versions.

What that means for us is a lot of developer resources need to be dedicated to keeping up with the quick succession of upstream releases upstream which has inevitably taken away focussed time on cheqd specific product features.

5. Demos speak louder than words (and code…)

Getting a general audience and Web3 audiences to understand the value of decentralized identity can be challenging. Blogs, docs and written information are often difficult to consume for newcomers unfamiliar with our terminology. For this reason it is important that we focus on demonstrating the value of cheqd’s identity technology, rather than simply explaining it.

This year we’ve created two initial demos of how credentials may work in real world scenarios. Firstly, we partnered with Animo Solutions to demo AnonCreds on cheqd being issued and used in various scenarios. This went down very well with identity audiences, but again, newcomers and Web3 companies struggled to understand why AnonCreds were cool!

Secondly, we created a cheqd wallet demo which shows how Verifiable Credentials can be stored and used alongside your crypto. In this demo, we enable a user to get a social media credential for authenticating with Twitter or Discord, then upload a QR code of a ticket for an event, and present a combined presentation of their social media credential and the event credential.

This demonstrates how credentials can be used to prove a level of trust and reputation in someone’s identity and also their validity for entering an event, a topic we’ve since expanded on. Demos like this go a long way to showing people the power of the identity technology we’ve built, and we want to go even further with simple, gamified demonstrations of the tech in 2023.

Looking back on our 2022 Product Vision

We strongly believe that transparency in our product development is integral to the success of cheqd. As such, we want to take a candid look at how we have measured against our initial goals set at the beginning of 2022. We hope that you, our partners and community members, also continually challenge and hold us to account.

Looking back to the start of the year, our three focus areas for development laid out in our January Product Vision blog were broken down into:

  1. Identity: Core identity functionality for our partners to build compelling self-sovereign identity use-cases on top of the cheqd network.
  2. Web 3.0 Core: Core Web 3.0 functionality adds deeper integration for our network and token into the Cosmos and other blockchain ecosystems.
  3. Web 3.0 Exploratory: Emerging Web 3.0 use-cases such as decentralised exchanges (DEX) ecosystems; decentralised autonomous organisations (DAOs); identity for non-fungible tokens (NFTs), and in general, DeFi applications.

So, how did we match up against these goals and objectives? We’ll take a look at each Core section and give them a score based on how many goals we successfully achieved.

Identity Retrospective

  • TOTAL SCORE: 5/6

1. Tutorials for developers


Tutorials are critical for having actual utility built on the network, since if users don’t know how to use what we’ve built, there is little value in it. We have been hard at work on expanding our documentation for developers using cheqd’s identity and ledger functionality:

To utilise the Veramo SDK for cheqd, you can follow the setup guide here. You can then follow our tutorials to begin creating DIDs and DID-Linked Resources on cheqd, or create Verifiable Credentials and Presentations.

2. Integrations with industry-standard identity projects


We set out at the beginning of 2022 to integrate cheqd into the DIF Universal Resolver. The Universal Resolver utilises REST APIs and other interfaces to enable the resolution of any DIDs which have a supported driver. We have successfully made this integration and you can now find did:cheqd on the list of supported drivers. Over 2023, we will improve and refactor our DID Resolver and our integration to make it fully enterprise-ready.

The graph below shows our work on the cheqd DID Resolver and how the bulk of the work was carried out towards within the second and third quarter.

Cadence for DID Resolver commits

We have also made significant progress to integrate cheqd into the DIF Universal Registrar. This will enable parties to create, update and deactivate cheqd DIDs through a standard interface. The Universal Registrar can also be leveraged to support cheqd in a wider range of applications and SDKs. You can cheq out our progress in our Open Source repository here.

3. New & Improved Identity Functionality


We have gone above and beyond other identity networks on the market. Firstly, looking at the cheqd DID method, we have incorporated the ability to have multiple DID controllers and to have more complex verification method relationships not present in the did:indy method.

We have also published implementation reports for our DID method, DID resolver and DID URL dereferencer against the DID Core Specification Test Suite to transparently show our DID method capabilities.

Most notably, we have built a ‘resource’ module which supports DID-Linked Resources identifiable with unique, DID Core conformant, DID URLs. This functionality is available to begin using through the Veramo SDK for cheqd. You can learn more about DID-Linked Resources in our guide here.

Using DID-Linked Resources, we have been able to natively support AnonCreds on cheqd, a type of credential format used by Hyperledger Indy and Hyperledger Aries libraries which has increased privacy-preserving qualities compared to VC-JWT and VC-DI (JSON-LD) based credentials.

You can see how cheqd benchmarks against Hyperledger Indy in a side-by-side comparison here.

4. Payment rails for identity


Payment rails for identity has been cheqd’s flagship offering since the network was launched. In the last year we have laid the groundwork and foundations for payment rails to layer on top.

In our update 1.0.x we are introducing new tokenomics for the network which will tie the CHEQ token to the core identity utility on the network. You can see cheqd’s updated pricing and comparison against Sovrin and Indicio here.

This is the first step towards payment rails, and early in 2023 we hope to release a phased architectural plan for achieving full payment rail functionality.

5. Client SDKs in more programming languages


At the beginning of 2022 we were planning to use Verifiable Data Registry (VDR) Tools SDK, from one of our key partners Evernym (acquired by Avast, now merged into Gen) as the primary enterprise-ready SDK for cheqd. However, towards the beginning of 2022 we conducted a product survey which established that software vendors prefer to use programming languages/frameworks based on JavaScript (81.2%), Python (62.5%), and Go (28.1%), instead of Rust which VDR Tools SDK uses (16%).

Since then, we have built our own SDK (cheqd SDK) and integrated cheqd into a JavaScript based SDK, the Veramo SDK, as a plugin. You can take a look at the modular architecture for our SDK packages here.

In terms of our product development on the cheqd SDK, below you can see the commits over the year for the cheqd SDK and cheqd Veramo plugin.

Cadence for cheqd SDK commits
Cadence for cheqd Veramo plugin commits

We have also successfully demoed cheqd using AnonCreds through Aries Framework JavaScript, and full SDK support is due to be completed following some updates to the AnonCreds spec to decouple dependencies on Hyperledger Indy. Going forward into 2023, we want to continue to integrate cheqd into as wide an array of SDKs as possible, starting with Aries Cloud Agent Python (ACA-Py), followed by Aries Framework Go and Aries Framework .NET.

6. Better interoperability and support for emerging identity standards:


cheqd has made a splash in the identity world with heavy influence into two emerging technical standards. Firstly, a W3C specification for DID-Linked Resources, as an extension to the DID Resolution Specification. Secondly, an updated ledger-agnostic Hyperledger AnonCreds specification that will complement cheqd’s approach to supporting AnonCreds object using its DID-Linked Resources.

Through supporting AnonCreds on cheqd, cheqd is the first network to support all major credential types, with VC-JWT fully supported and VC-DI (JSON-LD) at the final stages of being production ready.

Web 3.0 retrospective

  • TOTAL SCORE: 3/6

1. Wider integration with Cosmos ecosystem


We have expanded the number of platforms that cheqd functionality is available on. For example, at the beginning of 2022, staking and governance functionality was only available through with our friends at OmniFlix on our web-based cheqd x OmniFlix dashboard.

Now, we natively support staking and governance in our own cheqd wallet web-app and separately support governance operations at our cheqd x Commonwealth forum.

Notably, cheqd is also fully supported by Leap Wallet on their browser extension and on their mobile app. The beta Leapboard enables you to manage your CHEQ alongside your other Cosmos-based tokens in one place.

Going forward into 2023, we still want to push for full Keplr integration, and importantly, we want to introduce the ability to manage Verifiable Credentials within existing Cosmos-based applications.

2. Bridge to Ethereum networks


In Q1 2022, we successfully set up a bridge to Ethereum for the cheqd network using the Gravity Bridge. A blockchain bridge or ‘cross-chain bridge’ enables users to transfer assets or any form of data seamlessly from one entirely separate protocol or ecosystem to another (i.e. Solana to Ethereum, or in our case Cosmos to Ethereum and vice versa). The ERC20 version of CHEQ, the CHEQ-ERC20 wrapped token can be found here!

Read more about the cheqd x Gravity bridge and our decisions around it here.

3. Improved automation and tooling


We have made significant progress in how we have architected our cheqd node tooling and infrastructure. At the beginning of 2022, for example, it was a manual process to upgrade your cheqd node from scratch. We have since introduced an interactive installer which automates the process of upgrading cheqd nodes, making it significantly easier and less time consuming to run a cheqd node.

In addition, we have introduced several new components to streamline the setup and management of nodes in the form of infrastructure-as-code. We have started using HashiCorp’s Terraform to define consistent and automated workflows. This automation gives prospective network Validators the choice of whether they want to just install a validator node (using our install instructions), or whether they want to set up a sentry-plus-validator architecture for more security.

To complement Terraform, we have also introduced Terragrunt which performs the role of a wrapper to make our infrastructure available in Hetzner and DigitalOcean, as well as making it easier to utilise with AWS or Azure.

And to make cheqd configurations reusable across other Cosmos networks, we have begun using Ansible, which again acts as a wrapper or envelope to take cheqd configurations between separate Cosmos projects for node operators.

For a condensed list of the tooling and automation improvements we have made during the year, take a look through our Open Source-a-thon blog.

4. Native, cross-chain privatives for the Cosmos ecosystem


Our demo wallet showcases how cheqd DIDs and DID-Linked Resources can sign and be wrapped into Verifiable Credentials in Cosmos-based identity wallets. Using the demo wallet, you can now obtain credentials for authenticating with a social media profile, as well as for importing event tickets which you can combine into one proof. Within these Credentials, there are schemas and images which are stored as resources on the cheqd network. You can watch a video of the full demo here.

This is a huge step for demonstrating how cheqd’s identity functionality can begin to slot into other Cosmos-based applications. A priority for 2023 will be exploring how cheqd’s identity primitives can be utilised across other Cosmos chains, perhaps through opening up cheqd’s DID and Resource module to the rest of the Cosmos ecosystem via Interchain Accounts.

5. Smart contracts using CosmWasm


Using smart contracts and CosmWasm will likely be a crucial component of creating a privacy-preserving payment flow for credentials on cheqd. We are waiting until the first iteration of payments on cheqd has gone live before looking to integrate smart contracts. This is because CosmWasm will largely increase the computation cost for running a cheqd node. Therefore, we want to make sure the addition of CosmWasm does not get introduced before it is ready to be used.

6. Establish ourselves as a leader in decentralised governance for identity


cheqd’s Governance Framework is poised to become the first fully Trust over IP conformant Layer 1 Governance Framework. This will be enabled through cheqd’s approach to DID-Linked Resources which will identify the Governance Framework with a unique DID URL.

The cheqd governance framework also tightly aligns itself with the latest Governance standards coming out of the ISO/TC 307 technical committees on Governance (ISO/TS 23635:2022) where the concept that cheqd refers to as “Entropy” was a core component of the ISO approach to blockchain governance.

cheqd’s Governance Framework has since been lauded by leaders in the decentralised identity space. Drummond Reed, Director of Trust Services at Gen and co-author of the DID Core Spec stated:

“As SSI matures we’re seeing innovation at every layer of the Trust Over IP stack. cheqd is the only ToIP Layer 1 public utility I’ve seen with a governance framework designed explicitly to evolve from permissioned to permissionless. Add to that cheqd’s commitment to interoperability across all SSI ecosystems and its unique focus on SSI-based value exchange and you have one of the most exciting projects in SSI today.”

We’ll also be continuing to engage with working groups, consortium and organisations in the SSI space, such as Decentralized Identity Foundation (DIF)Trust over IP (ToIP)World Wide Web Consortium Credentials Community Group (CCG)European Blockchain Services Infrastructure (EBSI), and LACCHAIN to align on best practices and standards for governance and identity technology.


In 2022 we have made huge amounts of progress in terms of product development across the board, completing 8/12 objectives we set at the beginning of the year. Our development cadence and quantity of work is also illustrated by the sheer volume of commits (5,365), pull requests (262) and frequency of PRs (1.3 per day) that we’ve achieved this year, shown in the overview below (this is just based off of 2 of our repositories (cheqd/cheqd-node and cheqd/sdk).

Overview of cheqd’s development metrics

Putting this into perspective, cheqd ranks at the top of all the Cosmos-based chains for total commits for the month of December (as of 22/12/2022) with 874, and this wasn’t even our month with the highest number of commits (we reached 1,175 in November).

Graphic showing monthly commits of Cosmos chains

This is a huge testament to the dev and dev ops teams who have worked around the clock to bring our product visions to life, and we’d be nowhere without them!

In summary, 2022 was the year of building solid foundations, and this can often go under the radar. 2023 will be the year of functional applications, utility and deployments on cheqd.

In fact, we intend to start the year with a bang (hint hint you may have heard of a project with the codename Boots.)

cheqing out,

Ankur, Ross and Alex

cheqd’s tokenomics for SSI explained: part 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.


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.


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.


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.


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.


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



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.


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.


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.


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.


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.

The cheqd team


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.

cheqd update 1 year since network launch — next stop: payment rails

The foundations are set for cheqd’s first-of-a-kind decentralised identity payment rails

Co-authored by Ross Power (Product Manager), Alex Tweeddale (Product Manager & Governance Lead) and Ankur Banerjee (CTO/co-founder).

Making cheqd the most flexible, usable and interoperable network is integral for achieving wider adoption, as we pave the way for the first-of-its-kind decentralised identity payment rails. Recently we wrapped up the third quarter of 2022 and nearing just 1 year since network launch, we’re thrilled to have built the foundation for our partners to truly get to work on building their decentralised identity applications on the cheqd network, and we can’t wait to see what they create. Now, as partners begin to integrate their applications with cheqd, we’re heads down on building what we’re here for… cheqd’s Payment Rails for self-sovereign identity (SSI).


Since we launched cheqd in 2021, we’ve been on a mission to build a stable, trusted and secure decentralised identity network (known within SSI as a Verifiable Data Registry). This is the cornerstone of SSI, acting as the ultimate trust machine required for the verifications of identity data.

Ultimately, it is the fundamental infrastructure needed for being able to offer our first-of-a-kind payment rails which we believe is the missing piece in the widespread adoption of Self Sovereign Identity.

Here’s a quick reminder of what the journey so far looks like…

cheqd — journey to credential payment rails

In a sense, you can think of everything we have been working on to date as:

  1. Feature parity with all other SSI networks;
  2. Identity functionality that goes beyond existing SSI networks; and
  3. The tooling and scaffolding to lay the foundations for payment rails for Verifiable Credentials.

Bringing this all together into a visual representation, using the Trust Over IP stack as we have done in the past, helps to make sense of what cheqd’s capabilities look like both now and what’s to come…

cheqd Capability Matrix

For more information on any of the above including tutorials for creating DIDs and Issuing Verifiable Credentials, head to our identity docs, or reach out to [email protected].

Going beyond the current SSI paradigm

With all the above in place, we now match many of the leading networks in the space, and go well beyond.

Not bad going for a company just over a year old — check out the image below as an example of how cheqd now stacks up against Hyperledger Indy:

cheqd vs Indy comparison — October 2022

To learn more about cheqd pricing and features comparison to Indy based networks, please email: [email protected].

Breaking this down into a quick summary, we can safely say that:

  1. Performance: We are much faster and more scalable for production environments, boasting a far greater transaction per second speed and number of transactions per block.
  2. Decentralisation: Owing to the number of nodes which can run on cheqd there is far greater decentralisation. This means that the network is more resilient to attack or malicious actors.
  3. Incentives: We include rewards for maintaining and using the network functionality using our native token: CHEQ. This is even prior to our payment rails being enabled.
  4. Extensibility: We have improved on the way Indy handles DIDs, keeping directly in line with DID Core. This enables cheqd to support the full remit of DID Core, since it does not need to convert anything like a ‘nym’ into a DIDDoc. It works using DIDs from the start.
  5. Innovation: We include far more flexible on-ledger resources, which we’ve built to be directly retrievable using standardised DID URLs. This enables a far greater range of resources to be anchored and easily referenced on cheqd
  6. Interoperability: We support a greater range of Verifiable Credentials and SDKs (JSON based JWT, AnonCreds and soon JSON-LD). Indy is closely tied to Hyperledger Aries libraries and struggles to work with other libraries owing to its specific transaction types.

From today, this means our existing partners will be able to begin using cheqd to its full potential, with feature parity with other networks and additional benefits.

Here’s a quick reminder of who are existing partners are:

cheqd partners — October 2022

Looking ahead to the future

As a network we have built fast and are now at a poignant moment for ourselves and partners as we witness products start to fully integrate with cheqd. Soon we’ll be seeing real applications using cheqd as their underlying network. Our demo with Animo shows a first in SSI with AnonCreds being issued on a non-Indy chain (check this out here).

It also means we can now move our attention to our primary objective and what we believe is the missing piece in the widespread adoption of Self Sovereign Identity — a commercial model that works for all parties.

Therefore, over the next 6 months, our roadmap is largely broken down into two streams:

  1. Integrating with SSI networks and onboarding them onto cheqd for existing clients and identity use cases
  2. Completing the research, development and implementation of payment functionality for revocation statuses and eventually for Verifiable Credentials.
cheqd partners — October 2022

Like always, we’d love to hear your thoughts on our writing and how resources on-ledger could improve your product offering. Feel free to contact the product team directly — [email protected], or alternatively start a thread in either our Slack channel or Discord.

AnonCreds Indy-Pendence: Part Two

Part 2: Bringing cheqd AnonCreds to life with Animo Solutions in Aries Framework JavaScript

Co-authored by Alex Tweeddale (Product Manager at cheqd), Ross Power (Product Manager at cheqd), Timo Glastra (CTO, co-founder at Animo), Berend Sliedrecht (Software Engineer at Animo).

Read part 1 here.


In our previous blog we explained how we’re using cheqd’s on-ledger resources module to decouple AnonCreds from Hyperledger Indy and natively support AnonCreds and AnonCreds Objects on cheqd.

This work has laid the foundation for the next piece of the puzzle, bringing cheqd AnonCreds to life with easily accessible and usable Software Development Kits (SDKs).

Over the past few months we have been collaborating with Animo Solutions to support AnonCreds on cheqd within Aries Framework JavaScript. We are thrilled to announce that we have achieved this goal. Via this integration, users will be able to issue, verify and present AnonCreds with cheqd DIDs, and with AnonCreds Objects written as cheqd Resources, identifiable via DID URLs.

Showcasing AnonCreds on cheqd

During the demo we co-hosted with Animo at their office in Utrecht as a pre-event for Rebooting the Web of Trust (RWoT) on the 19th September 2022, we were able to show a full end-to-end journey of Ankur, our CTO, using AnonCreds. You can also watch a demo of this, here.

As you’ll see in the video, using a custom version of Animo’s self-sovereign identity demo we were able to showcase:

  1. AnonCreds issuance: Ankur gets his Animo identity for his name, date of birth and address as a fully functional AnonCred on cheqd.
Accepting Animo Identity AnonCred Credential into identity wallet

2. AnonCreds presentation and verification: Ankur signs up to attend the RWoT conference using his Animo identity AnonCred which is verified against the cheqd network.

Signing up for RWoT using Credentials
Connecting to RWoT to sign up for conference
A Credential request from RWoT for Ankur’s Credentials

3. AnonCreds issuance: Ankur receives a RWoT AnonCred for his entry to the conference.

Accepting the RWoT Credential sent to Ankur

4. AnonCreds presentation and verification: Ankur presents his RWoT AnonCred to gain access to the conference.

Presenting the RWoT as an AnonCred to attend the conference

Under the hood, you can check out the schema and credential definitions used for this AnonCred, which are identifiable using a DID URL, and stored as cheqd resources, via our DID Resolver.

Animo Identity schema:

Animo Identity credDef:

RWoT schema:

RWoT Credential Definition:

Integration into Aries Framework JavaScript

Aries Framework JavaScript (AFJ) is a framework that enables users to quickly and easily issue, hold and verify Verifiable Credentials. The main goals of AFJ are:

  • Interoperability between all the Aries implementations,
  • Usability for non-SSI developers and to remain agnostic of the credential format or DID method that is used and to lead the way in terms of interop.

In the recent months AFJ has heavily been expanding into a more modular and “less specific” framework. The integration with cheqd is a prime example of this, being the first true showcase of anchoring AnonCreds on non-Indy ledgers. Supporting more credential formats, ledgers and DID methods is crucial and essential to the continual development of AFJ.

How Animo leveraged the cheqd SDK to accelerate the integration into AFJ

One of the catalysts for Animo to support AnonCreds on cheqd was the release of cheqd/SDK in August, which was integrated into the Veramo SDK for cheqd. The Veramo SDK for cheqd was built in a modular fashion, which made it a very useful frame of reference for integrating cheqd into AFJ, and making it easier to leveraging the architectural design that the cheqd team put together.

Looking ahead

To continue the work to decouple AnonCreds from Hyperledger Indy, Animo is currently raising funds to fully implement Ledger Agnostic AnonCreds in AFJ and ACA-Py with cheqd. cheqd and Animo are also working closely with Esatus to support the development of Aries Framework .NET. This means, over the coming months users will be able to interact with cheqd and build their identity applications in any of the key SDKs they already use, whether this is AFJ, ACA-Py, Veramo or .NET. The image below provides a visual aid to where things are currently at:
The cheqd “stack” and tooling at different technical layers

Animo and cheqd continue to collaborate in this effort. The cheqd team are continuing to offer support for widening the SDKs available, for example working on a Universal Registrar Driver which will speed up the ACA-Py development. cheqd are also seeing the community get behind these efforts, with an new initiative to utilise the Community Pool funds to help financially support the progress.

AnonCreds Indy-Pendence: Part One


Co-authored by Alex Tweeddale (Product Manager & Governance Lead), Ross Power (Product Manager), and Ankur Banerjee (CTO/Co-founder).

Read part 2 here.


🚀 We are very excited to announce that the on-ledger resources feature released on cheqd mainnet allows for developers to support AnonCreds natively on the cheqd network.

Supporting AnonCreds on cheqd is a landmark achievement, since they have previously been tightly coupled with Hyperledger Indy chains. We are the first network to successfully decouple this dependency.

cheqd now provides support for AnonCreds, and in doing so, it remains compliant with W3C DID Core Spec, enabling SchemasCredDefsRevocation Registry Definitions and Revocation Registry Entries to be created using on-ledger resources, identifiable via DID URLs. This work is seminal in creating a broader ecosystem-agnostic ledger-layer, which supports greater interoperability for self-sovereign identity (SSI).

What are “AnonCreds”?

AnonCreds are a type or “flavour” of Verifiable Credentials that are utilised predominantly by Hyperledger Indy for ledger code and interactions, Hyperledger Ursa for cryptographic libraries, and the Hyperledger Aries codebase for agent, wallet, and credentialing code.

AnonCreds are now widely adopted, through organisations, such as the Government of British Columbia, IDunion and the IATA Travel Pass.

We carried out a survey earlier in 2022, finding that AnonCreds constituted the highest adopted (or roadmapped) Credential type amongst our respondents in 2022:

  • 45.9% AnonCreds;
  • 40.5% JSON based JWT;
  • 40.5% JSON-lD with BBS+ signatures; and
  • 32.5% JSON-LD.

(The percentages represent the percentage of respondents who selected the Credential type to support in 2022).

The respondents here were largely partners of cheqd. Therefore, to fully support all our partners and their existing clients within our network, we needed to build a way to support AnonCreds.

Why are AnonCreds a contentious issue?

For anyone in the self-sovereign identity (SSI) community, there is no avoiding the fact that AnonCreds divide the opinion of the community.

AnonCreds were originally designed to provide additional privacy benefits, compared with JSON and JSON-LD based Verifiable Credentials. To achieve these privacy benefits, AnonCreds utilise a series of bespoke technical components, including:

  1. Camenisch-Lysyanskaya (CL-Signatures) to encode individual claims for the purpose of enabling selective disclosure.
  2. Link secrets written into Credential Definitions, used when issuing AnonCreds to: (a) bind the issued Credentials to a particular holder; and (b) enable the holder to present a Zero-Knowledge Proof to a verifier without using a correlatable identifier.
  3. Hyperledger-Indy specific transaction syntax for on-ledger schemas, credential definitions, revocation registry definitions and revocation registry entries.
  4. Cryptographic accumulator deltas on-ledger, compiled into off-ledger ‘tails files’for the purpose of asserting proofs of non-revocation, while maintaining privacy for AnonCreds holders.

These bespoke technical components afford AnonCreds a degree of ingenuity; but it comes at the cost of interoperability.

Vendor Lock-in

A bit like how Apple products only really work with other Apple products; AnonCreds only really work with Hyperledger Indy, and are largely tied to Hyperledger Aries libraries to be issued and consumed.

Image comparing AnonCreds and Apple compatibility. Source.

Historically, AnonCreds cannot be written to other Layer 1 Utilities, since Credential Definitions and CL-Schemas are custom Indy-specific transactions which are not conformant with W3C DID Core. This shoehorns adopters into a particular tech stack, which although open source, is largely reliant on the Indy/Aries community for updates, since there is no formalised Standard approved by a reputable international body like IETF or W3C. It is worth noting, however, that AnonCreds v1 is being proposed as a Standard and is in the process of being taken to the Internet Engineering Task Force (IETF).


The use of ZKP-CL signatures provides AnonCreds benefits from a privacy perspective, yet, it also requires the computation of very large files which can lead to inefficiencies when used at scale in production environments.

Kaliya Young’s recent blog on Being “Real” about Hyperledger Indy & Aries / Anoncreds highlights many of the scalability issues around CL-Signatures well.

Similarly, the “tails files” used in Indy revocation suffer from similar inefficiencies. Each “tails file” can contain up to 20,000 revocation entries; and in a highly utilised ecosystem, there may be large amounts of these tails files, of 20,000 entries archived. On making a request of non-revocation and querying a tails file of this size, it may take a much longer time than usual to return a proof, creating a slower user experience than standard centralised models.

Owing to the benefits, as well as the tradeoffs, we previously concluded that AnonCreds in their current format have led to a degree of short-termism and long-termism within the community. Vendors with clients knocking on their door and asking for a product tomorrow are swaying towards short-term solutions which work now (such as AnonCreds which contains privacy-preserving revocation and the capability for predicate proofs).

Whereas, enthusiasts and SSI visionaries are looking at a longer-term vision of harmonisation and wide-barrelled interoperability (such as JSON-LD with BBS+ signatures or even AnonCreds V2 with BBS+ signatures). This is because BBS+ signatures provide a lot of the same benefits as AnonCreds (CL signatures), but with much smaller file sizes. Nonetheless, at cheqd we have acknowledged that there is a value in supporting both types of Verifiable Credentials.

Supporting AnonCreds on cheqd

Our first port of call in supporting AnonCreds was differentiating what makes AnonCreds distinct from other types of Credentials in terms of what goes on the ledger, and looking at ways that we could accommodate for those differences using cheqd functionality.

Decoupling AnonCreds from Indy

The key features of what makes an AnonCred exist at two distinct levels:

  1. Ledger level: What must be written to a verifiable data registry for AnonCreds to be created and functional in practice?
  2. Credential and SDK level: What cryptographic techniques must be employed within an SDK to give AnonCreds their privacy-preserving features?

For the existing AnonCreds stack, on Hyperledger Indy, these two levels can be represented by Figure 1 below:

Figure 1: How Indy and Aries interact for AnonCreds support

Here, Hyperledger Indy is important for supporting AnonCreds since it has to-date been the only identity-blockchain which can natively support DIDs, Schemas, Credential Definitions (and optional Revocation Registry) transactions written to the ledger.

Our hypothesis in supporting AnonCreds was that if we were able to replicate the functionality of the Ledger layer, the SDK and credential layer would be able to fit on top, without any wholesale changes in client applications that currently use AnonCreds. This would decouple the dependency on Hyperledger Indy, creating a much broader and widely interoperable ecosystem for AnonCreds.

Figure 2: How cheqd and Aries theoretically can interact for AnonCreds support

However, we did not want to build a carbon copy of Hyperledger Indy. As previously discussed, Hyperledger Indy is contentious for multiple reasons, scalability, and interoperability.

For this reason, we wanted to explore the option of supporting Credential Definitions and Schemas on-ledger, but in a way which directly conformed with W3C DID Core and with greater scalability.

Composition of AnonCreds Object identifiers

To reach a composition of Schemas, CredDefs, RevRegDefs and RevRegEntries on-ledger which is W3C DID Core compliant, it is important to understand exactly how these bespoke transactions are composed on Hyperledger Indy, and why this did not achieve conformance with the standard.

What goes into a Legacy AnonCreds ID?

Historically, AnonCreds Identifiers for scheamas, CredDefs and Revocation writes have been composite strings, recognised only by Hyperledger Aries and Indy applications.

For example, AnonCreds on-ledger schema_id, contain the following information:

  • Publisher DID: is a string. The DID of the Schema Publisher.
  • Object type: An integer denoting the type of object. 2 is used for Schemas.
  • Name: is a string, the name of the schema
  • Version: is a string, the version of the schema in semver format. The three part, period (“.”) separated format MAY be enforced.

The schema_id therefore was formatted in the following way:


For example, a Legacy AnonCreds schema_id could be:


The problem with this approach is that it:

  1. Ties AnonCreds to Hyperledger Indy, since Indy is the only possible chain which can provide all the required content for schemas, CredDefs and Revocation writes;
  2. Limits client applications to expect a very specific identifier format for AnonCreds Objects.

Therefore, to decouple AnonCreds from Hyperledger Indy it has been important to move away from this identifier format and to create a more extensible approach to providing client applications the required information.

AnonCreds Specification expansion

Recently, the AnonCreds specification has evolved to allow different ‘AnonCreds Object Methods’ which do not necessarily need to conform to the same representation as the legacy identifiers.

This approach gives different Object Methods the flexibility to define their own AnonCreds Object Identifier formats. This is a welcome change which provides greater flexibility in how AnonCreds Objects may be represented on different chains. Using this extension of the AnonCreds specification, cheqd has been able to create its own AnonCreds Object Method.

cheqd AnonCreds Object Method

In an earlier blog, we discussed our approach to resources on cheqd at length and highlighted the benefits of using on-ledger schemas, compared to other existing solutions such as

cheqd AnonCreds Objects build directly on this approach, in that we wanted to create an identifiable path to each specific AnonCreds Object using DID URLs.

Example of cheqd DID URL for schema resource

We have now created an extensive body of documentation to explain how we can support AnonCreds on cheqd, including how we represent each of the AnonCreds Objects using DID Core conformant DID URLs. See here for: Central to this approach has been removing all dependencies on Hyperledger Indy from the core “data” contents of an AnonCreds Object, and moving anything specific to a particular network to “AnonCreds Object Metadata”. This mimics how DID Document representation is able to support multiple different approaches, where anything network specific should be represented within the “DID Document metadata” section, rather than in the core body of what is returned.

Conclusion and next steps

Through the use of the resource module, cheqd is able to support all AnonCreds specific Objects within the parameters of DID Core, by identifying each Object and future Object versions with DID URLs.

This creates an elegant platform for AnonCreds to be issued on-top, which will allow cheqd to support any SSI vendor in the marketplace at a technical level. We have started with integration into Aries Framework Javascript (AFJ) and are looking to expand into Aries Cloud Agent Python (ACA-Py) as well as Aries Framework .NET. Read more about our plans in Part 2!

We look forward to working with our partners and the broader SSI community to see how we can innovate together using this new functionality, and decouple AnonCreds dependencies further.

As always, we’d love to hear your thoughts on our work and how resources on-ledger, or AnonCreds on cheqd could improve your product offering. Feel free to contact the product team directly — [email protected], or alternatively start a thread in either our Slack channel or Discord.

AnonCreds Indy-Pendence was originally published in cheqd on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building decentralised Identity applications on cheqd with Veramo


Launching the Veramo SDK for cheqd, enabling our partners to create and manage Decentralised Identifiers, Verifiable Credentials and Verifiable Presentations on cheqd

Co-authored by Ross Power (Product Manager), Tasos Derisiotis (Senior Blockchain Engineer), Ankur Banerjee (CTO/co-founder) and Alex Tweeddale (Governance & Compliance Lead)

We’re thrilled to launch the Veramo Software Development Kit (SDK) for cheqd. A Software Development Kit is a collection of libraries containing crucial building blocks of SSI which act as a bridge between cheqd and the identity apps provided by our partners. This is a big step forward in the overall adoption of the cheqd network as it makes it possible for our partners to start building their Decentralised Identity applications using cheqd.


One of the primary objectives for Q2 at cheqd was to make it easier for our SSI partners to create and manage DIDs, schemas, CredDefs (for AnonCred users) and Verifiable Credentials. We also wanted to begin work on supporting credential presentation and verification (you can see what we set out to achieve below).

To achieve this objective, it was important to build cheqd support into software that was compatible with languages and applications that our partners already used.

As part of our Product Research earlier this year, we conducted a survey to gauge the current stack our SSI partners are currently working with and plan to leverage in the future.

Within this, we identified that most companies use JavaScript/TypeScript or related frameworks as their primary language for development, as seen in the graphic below:

However, despite this dominance, the choice of SDK’s (Software Development Kit) didn’t correlate to this, with non-Javascript based SDKs holding the largest proportion, 35.1%, of respondents using Aries Cloud Agent Python (ACA-Py); and secondly, 27.0% of the respondents using Evernym’s VDR Tools SDK (tied to Hyperledger Indy):

What do we mean by an SDK?

The widely used, yet often not well described, term ‘SDK’ refers to Software Development Kits.

To get to grips with this, it’s first important to understand one of the key building blocks that make up SDKs — ‘libraries’.

A library is a packaged, reusable chunk of code that performs a certain function or set of closely related functions. You can insert a library into your application and call it when you need to implement that function without having to write the code from scratch.

So, suppose that instead of an application, you are building a house. One of the things you will need for that house is a stove, but it will not be very practical for you to build it from scratch when you could just buy one off the shelf. A library is to an application what the stove is to that house.

Building on this, an SDK is therefore a collection of libraries, APIs, documentation, utilities, and/or sample code that help you implement certain features without having to do the work from scratch. SDKs vary in scope and function from implementing a feature or set of features, like an analytics SDK for instance, to building whole applications for a specific platform.

Going back to our house analogy, if a library is a stove, then an SDK is a whole kitchen. While you can go and buy all your kitchen appliances, cabinets, and counters separately, it will be a lot easier to buy a full kitchen set, complete with built-in appliances and instructions on how to assemble it. SDKs can be limited in scope such as in the case with one room, but they can also have a bigger scope of a collection of rooms or even the whole house.

Where do SDKs fit in the overall SSI technology stack?

Taking a look at the Trust over IP technology stack helps to illustrate where SDKs fit in. As a reminder, this Trust over IP stack demonstrates the different elements of what is required in the Self Sovereign Identity ecosystem.

At the top level, Layer 4, you’ll notice application ecosystems. These are what the regular user interacts with; a mobile app you download from the app store to hold an airline ticket or vaccine credential for example. At the opposite end of the stack, Layer 1, you have the underlying plumbing. This is the distributed ledger layer where Decentralised Identifiers (DIDs), used to sign Verifiable Credentials (VCs), live.

Between the two you have a vast array of technologies which are used for the sending and receiving of Verifiable Credentials (VCs) and Verifiable Presentations (VPs) in a secure, privacy-preserving fashion. The combination of these two layers is what are more commonly known as SDKs, which contain various libraries that are made up of the technologies required for sending and receiving VCs and VPs.

Selecting the most suitable SDK to leverage for cheqd

Based on the findings detailed above, deciding on which SDKs wasn’t immediately obvious, although we had a few key requirements:

  1. The SDK should be JavaScript based — this is both due to the overall stack out partners were using, and also the dominance of Javascript and Typescript in the Web 3.0 and Cosmos ecosystem
  2. The SDK should be written in languages that are used in web-based applications, such as Keplr, so we can demonstrate DeFi activities (e.g, governance, staking and delegating) in the same wallet as holding a credential
  3. The SDK should be highly modularised so that those not directly using it can easily leverage the cheqd plug-ins built to work with it into their own SDK
  4. The SDK should already be used across the SSI ecosystem, with a significant amount of time being invested into its continuous product development
  5. The SDK should be building in a W3C compliant way, supporting the key exchange protocols and credentials our partners and beyond require

After some research, including exploring Aries Framework JavaScriptAries Framework Go (transpiled to Wasm), Trinsic Okapi and MATTR, we settled on the Veramo SDK.

What is the Veramo SDK and why did we select it?

Available at: uport-project/veramo

Veramo is a JavaScript Framework for Verifiable Data. The Veramo SDK is an agent designed to handle multiple networks and DID methods. Current implementations of the Veramo SDK include did:ethr, did:web, did:key and more.

We chose Veramo for a few key reasons.

  1. Design Principles — The Veramo SDK was designed to be highly flexible and modular making it highly scalable and fit for a lot of complex workflows. As a result, we felt it offered a route to minimise how much needs to be built from scratch. Through its flexible plug-in system, it’s easy to pick and choose which plug-ins are most beneficial, plus it’s possible to add in our custom packages where required which we knew would be necessary from Cosmos-based transactions.
  2. Developer Experience — The Veramo SDK has been designed in a way that offers a fast end-to-end process. Ultimately, at cheqd, we want to reduce the amount of time our team spends on SDKs and so we can maintain our focus on building ledger functionality (i.e. building our implementation of the revocation registry and the credentials payment rails).
  3. Attractive & Simple CLI — The Veramo core API is exposed by its CLI which makes it easy to create DIDs and VCs directly from a terminal or local cloud agent.
  4. Platform Agnostic — The Veramo packages run on Node, Browsers and React & React Native right out of the box.

What does the Veramo SDK for cheqd allow you to do on the cheqd network?

Veramo provides an excellent foundation for clients that want to build verifiable data applications. This is because Veramo Core, the Veramo CLI and any specific plugins are available as NPM packages, enabling:

  1. Identity functionality to be carried out through a native CLI interface; or
  2. Identity functionality to be integrated directly into client applications through NPM packages.

More importantly, Veramo is useful for both DIDs as well as Verifiable Credentials and Verifiable Presentations. It’s not just for one side of the credential usage process.

When combining the existing packages provided by the Veramo SDK with some native packages that we’ve built at cheqd the following functionality is available on the cheqd network (hyperlinks go to the tutorial/information for each):

With the additional Resource module recently applied to the cheqd ledger, AnonCreds will also be possible through the cheqd/sdk which the Veramo SDK for cheqd uses. This is not yet available but is part of the immediate cheqd product roadmap.

Thank you to the Veramo team for all their support throughout. We’re thrilled to strengthen this partnership and appreciate these kind words shared with us by the Veramo team:

The cheqd team quickly and effectively understood all the effort that the Veramo team has been putting into making life easier for developers when building better layers of trust in their applications. We also thank the cheqd team for being participative and collaborative in the Veramo community by supporting the development and discussions.

– Italo Borssato

I was pleasantly surprised to hear that the folks from cheqd were able to extend and adapt Veramo to their own use-case while leveraging existing integration, which then allowed them to focus on their core business. This kind of permissionless innovation and integration is what we were hoping for when designing the Veramo framework. I’m very happy to see the cheqd team not only using Veramo but also contributing back.

– Mircea Nistor

Our implementation of the Veramo SDK for cheqd

Veramo’s modular architecture meant we were able to leverage much of the existing work which offers the core functionality required for credential and presentation issuance and verification.

Adding the ability to create and update DIDs took more work, including contributing to Veramo upstream to improve the overall ecosystem beyond our own implementation. For example, we wanted to support full DIDDoc create and update operations which were not previously available within Veramo’s codebase.

Below you’ll find the basic architecture for the Veramo SDK for cheqd. The Veramo packages offer key Layer 2 and Layer 3 functionality, as described above, including exchange protocols and proof formats.

The key cheqd package is did-provider-cheqd.

The purpose of this @cheqd/did-provider-cheqd NPM package is to enable developers to interact with the cheqd ledger using Veramo SDK.

It includes Veramo SDK Agent methods for use with the Veramo CLI NPM package. It can also be consumed as an NPM package outside Veramo CLI for building your own applications with NPM.

The package’s core functionality is borrowed from Veramo Core NPM package and extends this to include cheqd ledger functionality, such as creating and managing DIDs.

Head over to our tutorials site to find everything you need to install this package and start using cheqd for your identity products today!

Figure 1: Veramo SDK for cheqd architecture

A reference implementation of the Veramo SDK for cheqd, built for the cheqd web demo

If you’re interested in how cheqd has worked with the Veramo packages, but aren’t sure what this would look like in practice, perhaps our implementation we built for an IIW demo would be useful for you.

For a full walkthrough of our choices here check out Ankur’s Tweetstorm on this and if you’re interested in doing something similar feel free to reach out to the product team at cheqd ([email protected]).

Figure 2: A reference implementation of the Veramo SDK for cheqd, built for the cheqd demo

FAQs on Veramo & our implementation

Q: Is it possible to use cheqd libraries to build a mobile wallet? (do the cheqd libraries take React Native support into account)

A: Veramo runs on React Native right out of the box. More information on this is available here.

Q: Do the cheqd libraries introduce any new dependencies that won’t work in React Native? (e.g. the cosmjs libraries or other crypto-related libraries)

A: React Native can work with any browser-based JS library, since cosmjs works in browser environments and most other libraries we use at cheqd.

Q: Where are keys stored?

A: The Veramo SDK uses a PrivateKeyStore for hosting the key data. The @veramo/data-store package provides an implementation that uses a database for storing these keys encrypted by a SecretBox.

The modular architecture of the framework makes it possible to use multiple types of key stores and key management systems for different purposes. These include implementations using CloudHSM, mnemonic-based key derivation, or even web3 wallets.


We’re thrilled to have hit this exciting milestone at cheqd.

We knew our partners were eager for us to answer their question “when will I be able to use the cheqd ledger for identity? and now we’re happy to be able to say “go have a play now!”.

So what’s next for cheqd in terms of SDKs?

Ultimately, we know that there are more focused and dedicated teams who are building SSI SDKs, and our Veramo SDK is just the start. Over the coming months and weeks, we’re in the process of forming ’cheqd SDK Alliances’ within our partner network who can collaborate on required SDKs, leveraging this implementation.

These alliances include those looking to build for; Aries Framework Javascript, .NET, Aca-PY and further building on Veramo.

Where we believe we can add the greatest value is by building out our approach to Revocation Registry and the credential payment rails, which we believe will be a real game-changer for SSI’s adoption.

If you’re interested in joining one of the alliances, reach out to the cheqd product team ([email protected]).

As always, we’d love to hear your thoughts on our writing and what this means for your company. Feel free to contact the product team directly — [email protected], or alternatively start a thread in either our Slack channel or Discord.