cheqd has launched v2 of its testnet for a token-incentivised SSI network built on the Cosmos blockchain framework. This new testnet follows on from our open-source announcement and incorporates tokenomics for mainnet as well as the cheqd Governance Framework.
Over the past week, we have been testing out a new version of the cheqd-node software. Transparently, we wanted to message and release this last week but held off to investigate why some node operators were reporting errors during the installation process.
This turns out to have been an issue due to a few outdated links in the documentation, which have all been comprehensively updated and cross-checked.
The most important thing about the new release is that it’s a breaking change: the existing testnet (“v1”) will be deprecated. In its place, we’ve set up a new testnet network (“v2”) which is officially the new cheqd testnet going forward.
Since we open-sourced our code in August 2021, we’ve had partners from the self-sovereign identity space as well as community members come onboard our initial network. We’d love to explain what’s happening next in our product roadmap and what brought about this breaking change.
What are the major changes in cheqd testnet v2?
When we initially launched cheqd’s testnet v1 in July 2021, we were still in the process of finalising the tokenomics that would be deployed on the network. This meant that our cheqd node software used the default parameters from a Cosmos SDK network along with identity transactions implemented on the Hyperledger Indy transaction model.
We have since then published our tokenomics model for the cheqd SSI network and a series of blog posts walking through the cheqd Governance Framework.
Our tokenomics blog post is the best starting point to understand those changes but to summarise on the impact for node operators (on cheqd mainnet):
- We will have an overall supply of 1 billion $CHEQ tokens. Our original testnet had this as a fixed amount with no inflation. The consequence of this is that node operators would have received rewards only from transaction fees on the network, and there would have been no block rewards consistently for new block creation. Based on conversation and feedback from the community, we have now changed this to incorporate a level of inflation (1–4%) using Cosmos’s built-in mechanism, which dynamically sets the inflation rate within a range based on how many tokens are bonded via staking.
- The goal for the percentage of bonded tokens is currently set to 60% of the overall supply. This was benchmarked against a number of projects, and we feel this strikes a balance between securing the network and paying for identity transactions.
- We’ve also set parameters for the governance module based on the cheqd governance framework.
How do I join cheqd testnet v2?
We have updated all of the documentation related to node setup and management, so if you want to set up a node on the v0.2.3 release, check out the Github repo for cheqd-node.
If you are an existing node operator: we recommend using a new virtual machine/host (ideally). This will ensure you don’t run into any issues due to old configuration files. If you can’t spin up a new virtual machine, you can uninstall the old version of the node using:
apt remove cheqd-nodePlease also make sure that you’ve removed old app directories and configuration files. More details are available on our Debian package overview.
Getting started as a node operator on cheqd testnet v2
- Install the
cheqd-nodesoftware on a hosting platform of your choice. - When you have a node successfully installed, please fill out our node operator onboarding form so that you can acquire CHEQ testnet tokens required for staking on the network.
- Once you have received your tokens, promote your node to a validator.
- If successfully configured, your node would become the latest validator on the cheqd Testnet! Say hi to the other node operators on the #testnet-node-operators channel.
Any time you have questions or need support, join our cheqd Community Slack and ask for help.
What’s new in the cheqd-node release v0.2.3?
cheqd-node v0.2.3 is our last major milestone release planned for cheqd-node before we launch the cheqd mainnet. It incorporates the following breaking/major changes:
ACCOUNT NAMES NOW START WITH THE “CHEQD” PREFIX RATHER THAN “COSMOS”
Impact: The new account name format is one of the reasons why this node release version is incompatible with cheqd testnet v1.
THE LOWEST DENOMINATION OF $CHEQ TOKENS
Another major change is that the lowest denomination of a token has been changed to 1 nano $CHEQ (“ncheq”), which is 10^-9 CHEQ. The previous testnet had 1 CHEQ as the smallest denomination, which would not have allowed for very precise pricing for transactions. We always wanted to make this change, as we foresee this being a potential issue in the future. This is similar to how Cosmos ATOM uses 10^-6 ATOM as the smallest unit.
Impact: All transactions (transfers, balances, etc.) are now calculated in ncheq. Please make sure you double-check your calculations for transactions so that the transaction amount in ncheq works out to the right value in whole CHEQ terms.
For more details, please see ADR 004: Token fractions.
GENESIS PARAMETERS AND COSMOS SDK UPDATE
All genesis parameters have been updated to reflect what they would be on the mainnet. (More details are outlined in ADR 005: Genesis parameters.)
We also upgraded from Cosmos SDK v0.42 to v0.44 since it’s a security release that contains breaking changes in the underlying SDK. Cosmos v0.43 was discontinued and superseded. We wanted to ensure that this important security update was accounted for before the mainnet launch.
BUILDING A CHEQD DID METHOD COMPLIANT WITH W3C SPECIFICATIONS
We’ve removed the NYM transaction type from this release. We thought long and hard about whether we wanted to keep the same transaction types as Hyperledger Indy, especially since Hyperledger Indy was designed before the W3C specifications in SSI were finalised. Indy, therefore, makes certain assumptions and choices that result in it being incompatible with the W3C DID Core specifications.
Impact: We have work-in-progress to make the cheqd DID method compliant with W3C specifications. We believe this is the right choice to make to limit future tech debt.
Our communication layer is still planned to work with Hyperledger Aries. Integrating a W3C specification compliant DID method would make it easier in the future to extend Aries to support other W3C-compliant DID methods and Verifiable Data Registries, which we see as an exciting leap forward for the SSI community.
For SDKs/client libraries, we still plan to have at least one implementation of a client library that supports Indycreds and cheqd DID method credentials.
What’s next for cheqd’s product roadmap?
We hope the summary above explains the changes that we have made and the rationale for them. As always, we welcome feedback on our product releases and keen to take any feedback onboard.
October / November 2021 is an exciting time for the cheqd team, as we have major milestones planned. Our product and engineering team strongly believes in releasing early and often to ship iterations of the product regularly and provide updates.
LAUNCH THE CHEQD MAINNET
Based on current projections, we aim to launch v1 of the cheqd mainnet by the end of October 2021 or latest, by November 2021. Our main objective is to implement relatively stable and finalised ledger APIs/functions, giving app developers confidence to build against the network.
It will have minimum viable functionality for a stable, production-grade network that offers a new range of functionality for SSI application vendors, digital identity companies, enterprises that need to issue/receive digital credentials, and node operators from a DeFi background.
This would include:
- Finalised tokenomics implemented (this is already present on cheqd testnet v2)
- A W3C compliant DID method
- Final stability changes and bugfixes
OPEN-SOURCE OUR INFRASTRUCTURE TOOLING REPOSITORY
Many of our node operators run standalone virtual machines, but we have also received interest in more sophisticated setups. Our engineering team has been working on DevOps tooling using Terraform for deploying multi-node, multi-region deployments on AWS using Elastic Container Service (ECS) on Fargate.
We want to open-source and provide this to the community as another available node operator who might want to run more than one node or to have a more robust infrastructure setup. While we currently only work with AWS, we hope to support other cloud platforms in the future and welcome contributions from the open source-community from anyone who wants to contribute automation assets.
PUBLIC PRODUCT ROADMAP WEBSITE
We recognise that our community is excited to find out more about what we do next, discuss and provide feedback on our product roadmap in more detail.
As a sneak peek, these would include:
- More robust support for the W3C-compliant cheqd DID method in client libraries
- Support for revocation registries and BBS+ signatures
- Holder-pays-issuer, verifier-pays-issuers, and other charging mechanisms
- Block explorer and/or monitoring tools for node operators and general public
Join us on testnet and say hi 👋
We highly appreciate all the interest from the community in participating in the cheqd testnet and building a vision together for an authentic data network. To all of our existing testnet node operators, thank you. 
If you would like to learn about our partner programme for self-sovereign identity vendors, please reach out to us at [email protected].
Please feel free to ask us any questions on the cheqd Community Slack. We also hugely believe in the value of the community supporting and engaging with each other, so whenever you see someone in need of support, feel free to jump in.
Onwards and upwards,
The cheqd product team 
