This list contains all stable releases in the cheqd-node v1.x.x family, and skips pre-release versions.

v1.4.0: Fix interactive installer [March 2023]

This version primarily fixes the interactive installer, an off-ledger helper software for carrying out cheqd-node installations and upgrades. The installer now:

  1. Attempts to create a backup of the user's configuration folder and private validator state files, when carrying out upgrades or downloading snapshots.

  2. Frees up spaces by deleting the data folder when requesting a snapshot restore (only if the backup has been made).

  3. Bumps Cosmovisor if necessary.

  4. Separates out warning, error, info etc level messages based on success status of the action.

To enable debug level logs in case the installer fails, set an environment variable called PYTHONDEVMODE to the value 1 on your system. This will provide additional diagnostic logging that can help pinpoint errors if the installer fails.

Read Full changelog on GitHub: cheqd-node v1.4.0 release notes

v1.3.0: Fix pruning settings [February 2023]

This version creates a standalone Golang package called github.com/cheqd/cheqd-node/api which is generated using the Pulsar generation file. This allows non-ledger applications such as the did:cheqd Resolver to consume a standalone package with just the API interaction elements, without needing to import the entire cheqd-node Golang package.

This version also bumps Cosmos SDK to v0.46.10.

Read Full changelog on GitHub: cheqd-node v1.3.0 release notes

v1.2.5: Fix pruning settings [February 2023]

The previous version of our node software had to be run in pruning="nothing" setting due to an upstream issue with the Cosmos SDK iavl package. This release fixes and restores support for setting pruning settings.

Read Full changelog on GitHub: cheqd-node v1.2.5 release notes

v1.2.2: Custom identity transaction pricing, improvements to DIDs and DID-Linked Resources, Cosmos SDK v0.46.x [January 2022]

This release is a state-breaking update that brings fundamental changes to the cheqd-node testnet and mainnet. The release notes below pertain to the cheqd-node changes only. Changes to identity applications and tooling is summarised in a separate change log.


The release can be broken down into 6 primary areas of development:

  1. Identity transaction pricing and burn

  2. Enhancements to DIDs and DID-Linked Resource functionality

  3. Changes to protobuf definitions required for enhancements to DID and DID-Linked Resource functionality

  4. CosmosSDK version bumps

  5. Miscellaneous fixes

  6. Introduction of Behavioural Driven Development

1. Identity transaction pricing

In this release we’ve introduced new mechanisms to the cheqd’s tokenomics. Currently (prior to this release), writing a DID to cheqd mainnet only cost the gas fee, which was 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.

Going forward, any changes required to periodically maintain these, especially before we implement pricing oracles to programmatically maintain stable dollar pricing for our partners, will require further votes.

Architectural decisions, diagrams and in-depth explanations of the scope and relationships will be shared shortly in a follow-up blog-post and document.

Mechanism 1: Identity transaction pricing

Identity transactions such as DIDs and DID-Linked Resources (e.g. visual representations of Verifiable Credentials; trust & revocation registries; schemas; documents; logos) writes will have a cost greater than gas which will increase rewards from the network as identity utility increases. 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. See detailed pricing and comparison to Sovrin here.

Mechanism 2: Burns

As mentioned above, the network is currently inflationary only aside from slashing, tombstoning and no-with-veto having deflationary effects. Implementing a burn mechanism will bring the system into equilibrium. The volume of tokens burnt will increase in the same way as distributions will, with the aim of bringing total supply back to one billion.

As can be seen in the image available here 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.

2. Enhancements to DIDs and DID-Linked Resource functionality

A number of core changes have been implemented to enable continued interoperability with products and applications across the decentralised identity ecosystem. These include:

Introduction of a DID deactivation transaction

Previously it was not possible to mark DIDs as deactivated on the cheqd network. This is now possible. This enables cheqd to support each of the required transactions for integrating with the Universal Registrar.

Historical version of DIDDocs can be stored and retrieved

Fetching historical versions of DIDDocs easily and without friction is an incredibly important feature for DIDDoc indexing in decentralised identity applications.

We have used the same versioning techniques for DIDDocs as was implemented for DID-Linked Resource versioning. This required an on-ledger change as previously we were using the ‘transaction hash’ of the on-ledger block as the DIDDoc ‘version’, which presents a problem as in the event a user has multiple DID operations in the same transaction, it becomes impossible to distinguish between the various versions of the DIDDocs. This has now been replaced with a UUID.

A number of other networks lack this feature and don’t provide the functionality to fetch historical DIDDocs, which can be a limiting factor for those building decentralised identity applications.

Enforce UUIDs to be in lower case by default for DIDs & DID-Linked Resources

UUIDs are not case sensitive. This means that UUIDs with both upper and lower case characters are semantically identical

Previously when users created a UUID for a DID-Linked Resource they could use both lower and upper case in the UUID. The cheqd network, however, is only able to handle lower case characters. As such, we introduced a converter that would convert all UUID DIDs to lower case UUIDs.

As a result of this change, existing DIDs and Resources that were created prior to this upgrade, will be altered to lowercase if they previously contained uppercase characters.

Bringing Indy-style DID identifiers in line with specification

The style for the unique identifier of a DID was initially based on the legacy Hyperledger Indy algorithm. We’ve brought it in line with the updated DID Indy specification requirements instead.

As part of our interoperability efforts and support for AnonCreds with AFJ (documented here we needed to expand the supported identifiers on-ledger. The main barrier preventing full support for AnonCreds on cheqd using Aries SDKs is that AnonCreds is still dependent on the Indy SDK. When you call any function in the Indy SDK, you need to use the legacy Indy-style identifier format to carry out a transaction. Supporting Indy-style identifiers is therefore a stepping-stone in the wider AFJ support for cheqd.

Ability to specify alternative URLs for DID-Linked Resources

By default DID-Linked resources have a DID URL auto generated. For example, a DID URL for a DID-Linked Resource looks like this:


When resolved (see here) you’ll find that this shows the IIW logo, used in our wallet demo.

However, as part of our mission to drive the wider adoption of DID-Linked Resources beyond cheqd, and create the “web of trust”, we have enabled the ability to add an alternative URI for where that same resource can be found.

This is similar to the ‘alsoKnownAs’ property in the DID Core specification.

Checksums for DID-Linked Resources now stored correctly

A checksum is a value that represents the number of bits in a transmission message, used to detect high-level errors within data transmissions. They provide a party on the receiving end information about the date to make sure that the full range of data is fully delivered. The checksum value itself is typically a long string of letters and numbers that act as a sort of fingerprint for a file or set of files to indicate the number of bits included in the transmission.

For example, if a user created a DID-Linked Resource, and 1 month later wanted to retrieve this, it would be possible to calculate the sha256 locally and then compare it with the “checksum” field from the resource in order to check whether this resource was changed or not.

Prior to this release, it was calculated in a less usable way, using “sum256 + data_bytes” where it only needed sum256 (which is what is used from v1.0.0 going forward).

3. Changes to protobuf definitions required for enhancements to DID and DID-Linked Resource functionality

To accommodate for the ledger enhancements, fundamental changes are required to the underlying code base which the ledger uses known as protobuf definitions.

Protobuf definitions can be seen as a template for variables in the ledger code-base; the existing release up to this point uses protobuf definitions v1, whilst this upgrade replaces these with v2 protobuf definitions. 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.

To inspect the source of protobuf definitions, follow the links below. These are simply contained within the overall v1.0.0 upgrade so don’t require any additional steps for developers.

Previous protobuf definitions:

  • cheqdid.cheqdnode.cheqd.v1

  • cheqdid.cheqdnode.resource.v1


  • cheqd.did.v2

  • cheqd.resource.v2

Another aspect of this change is based on best practices. When we launched the cheqd network we identified certain best-practices and designed an implementation approach which would allow us to roll out these conventions in a phased approach. This enabled us to move quickly, whilst not compromising anything on ledger in the initial stages. With this release the cheqd ledger is in line with overall style guides making it more flexible and robust for both our team and other developers to build on.

4. Cosmos SDK version bumps

As is customary with the use of the underlying CosmosSDK and associated libraries, regular version bumps are required to keep the cheqd ledger in line with the wider ecosystem's changes, for example updates to IBC. In this release we’ve bumped the Cosmos SDK version to 46.6, crucially bringing key security patches as well as a bump to IBC to ibc-go v5.1.

5. Miscellaneous fixes

cheqd-noded configure command removed

As part of the overall ledger changes, the cheqd-noded configure command has become an outdated and deprecated command. The command has been removed and documentation has been updated accordingly. This changes the manual installation of cheqd-node, and the Interactive Installer which previously relied on this.

Interactive Installer fixes

The Interactive installer was using the legacy configure cmd ‘cheqd-noded’ to do the configuration for app.toml and config.toml files. As this is no longer used, the interactive installer no longer requires the configure command.

The following changes are now made by default when installing a node:

  • RPC port by default listens to world i.e from tcp:// to tcp://

  • The default minimum gas price is set to 50ncheq, increased from 25ncheq

  • An option introduced for a user to enter persistent peers, log level and log format when doing interactive installation

Ledger Nano support fix

A bug was identified where the Ledger nano hardware wallet was not working with cheqd transactions. This has been resolved in this release.

6. Behaviour Driven Development

To date our testing approach has been focused around unit testing and more manual approaches to application testing. In this release we’ve introduced Behaviour Driven Development (BDD) at scale across the entirety of the cheqd node. BDD, is a framework which uses human-readable descriptions of product requirements as the basis for testing. Developers implement a well known vocabulary that can be understood by a regular user, to help identify the issues that arise.

We see this as an integral to building strong foundations that will enable developers to more easily build with cheqd, and streamline the overall development process for our core team as we progress further with ledger development centred on the implementation of cheqd payment rails.

Full changelog


  • feat(installer): Get installer to handle multi-platform binaries DEV-1667 by @ankurdotb in #376

  • feat: DeactivateDid transaction to mark DIDs as deactivated DEV-1774 by @khornonzon in #332

  • feat(proto): Proto API v2 DEV-1786 by @askolesov in #398

  • feat(proto): Refactor app to support proto v2 by @askolesov in #436

  • feat: DidDoc versioning DEV-1892 by @askolesov in #443

Bug fixes, patches & version bumps


  • build(buf): Change buf.build package name by @ankurdotb in #453

  • build: Buf.build config for generating proto DEV-1545 by @jay-dee7 in #339

  • build(docker): Move to Alpine images for Dockerfile by @anikitinDSR in #356

  • build: Backport workflow and other fixes to release/0.6.x branch DEV-1822 by @ankurdotb in #410

  • build: Release with v-tags by @ankurdotb in #424


  • security(tendermint): Bump github.com/tendermint/tendermint from 0.34.19 to 0.34.20 by @dependabot in #367


Last updated