Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section lists previous software upgrade proposals and specific instructions on how to execute them.
100x increases in gas prices, with minimum gas price going up from 50ncheq to 5000ncheq (as discussed on the governance forum)
This change incorporates looser restrictions on DID Document properties such as assertionMethod, allowing developers to specify additional details for keys which might not necessarily be used for authentication/controller purposes (e.g., BBS+ keys for credential issuance.)
build(deps): Sync go workspace dependencies, bump NPM packages, bump bufbuild/buf-setup-action from 1.45.0 to 1.47.2 by @dependabot in https://github.com/cheqd/cheqd-node/pull/814
chore(deps): Bump cosmossdk.io/math from 1.3.0 to 1.4.0 by @dependabot in https://github.com/cheqd/cheqd-node/pull/815
fix: Update interactive installer to handle syslog deprecation [DEV-4630] by @filipdjokic in https://github.com/cheqd/cheqd-node/pull/820
build: Bump direct + address vulnerable dependencies by @Eengineer1 in https://github.com/cheqd/cheqd-node/pull/829
build: Bump github.com/gabriel-vasile/mimetype from 1.4.7 to 1.4.8 by @dependabot in https://github.com/cheqd/cheqd-node/pull/830
fix: fix slice init length by @davidwoood in https://github.com/cheqd/cheqd-node/pull/808
chore(deps): Bump cosmossdk.io/math from 1.4.0 to 1.5.0 by @dependabot in https://github.com/cheqd/cheqd-node/pull/832
chore(deps): Bump github.com/spf13/cast from 1.7.0 to 1.7.1 by @dependabot in https://github.com/cheqd/cheqd-node/pull/831
fix: Added key id ref bypass on strict validation by @Eengineer1 in https://github.com/cheqd/cheqd-node/pull/837
docs: Add v3.1.3 binaries.json file [DEV-4669] by @filipdjokic in https://github.com/cheqd/cheqd-node/pull/839
fix: Switch upgrade name given precedence by @Eengineer1 in https://github.com/cheqd/cheqd-node/pull/840
@davidwoood made their first contribution in https://github.com/cheqd/cheqd-node/pull/808
Full Changelog: https://github.com/cheqd/cheqd-node/compare/v3.0.1...v3.1.4
Any validators upgrading should have carried out the Ubuntu 24.04 LTS upgrade to v2.0.2 before attempting this upgrade
After this upgrade, Keplr Wallet unfortunately cannot support dynamic fee lookups for Cosmos SDK chains that are not natively integrated into their wallet. Therefore, we recommend users to migrate to Leap Wallet from Keplr Wallet.
For non-identity transactions (e.g., standard transfers, staking, rewards, etc), this upgrade introduces EIP-1559 style burns, with the introduction of a feemarket module which introduces dynamic gas pricing. This might affect how you attach/calculate fees when submitting transactions.
Use --gas auto and --gas-adjustment (with value of 1.7 to 1.8) for optimal results. Using fixed --fees is unlikely to work if you don't look up real-time gas prices on the network.
cheqd-noded query feemarket gas-price ncheq
Initiating a GET request at https://api.cheqd.net/feemarket/v1/gas_price/ncheq. The result will be an object as:
Interpret the value of price.amount as the fixed fee in price.denom units, in which case 5000000000000000ncheq using --fees OR calculate the gas prices necessary by multiplying the value of price.amount by (10^4) * (10^9) = 10^13, in which case resulting in 50ncheq. Any increase in the indicative gas price or gas limit will result in greater quantities than the suggested minimum base fee.
We're excited to announce the latest protocol upgrade to our community. This release brings cutting-edge features designed to enhance transaction efficiency, fee flexibility, and cross-chain interoperability. Here's what's coming your way:
Revolutionising the fee structure for a smoother, more efficient user experience. The advanced Additive Increase Multiplicative Decrease (AIMD) model ensures fair and efficient fee adjustments.
Base Fee: Dynamically adjusts based on network congestion. This fee is burnt, reducing token supply and enhancing the economic value of $CHEQ.
Priority Fee: Optional tip for validators to prioritise your transactions.
Block Elasticity: Dynamic block sizes to address congestion, improving transaction times while mitigating volatility in fees and maximising block utilisation.
Congestion-Responsive: Adjustments maintain a balance between supply and demand for network resources.
Cross-Chain Token Support: Pay transaction fees in tokens from any IBC-enabled Cosmos chain.
IBC Hooks: Facilitate cross-chain smart contract calls, opening new use cases like multi-hop swaps.
Fee Conversions: Automatically convert IBC-denominated tokens to native fees before final settlement.
Streamlining cross-chain communication with robust packet forwarding:
Atomic Multi-Hop Flows: Secure and synchronized token transfers across multiple chains.
Asynchronous Acknowledgements: Track the outcome of multi-hop transfers from the initiating chain.
Simplifying token minting and burning through governance-approved mechanisms mainly aimed at reducing complexity of $DOCK to $CHEQ token migration:
MsgBurn: Allows manual burning of native tokens with full validation.
MsgMint: Enables governance-controlled token minting and distribution to specific addresses.
Improved User Experience: Transaction fees are simpler, predictable, and wallet-friendly.
Enhanced Token Utility: CHEQ’s role as the network’s core currency is strengthened.
Cross-Chain Opportunities: Broader support for IBC tokens ensures a seamless multi-chain experience.
Governance and Transparency: New tools for community-driven token supply management.
If the software upgrade proposal is approved, this upgrade will go live at block height 16502390, which is expected to be around Thursday, 12th December 2024, 9am UTC.
We’re excited to bring these advancements to the ecosystem and look forward to your feedback. Let’s build the future of Decentralised Identity together!
feat: Integrate feemarket + reworked ante, post handler decorator distinction by @vishal-kanna in https://github.com/cheqd/cheqd-node/pull/782
feat!: Integrate feemarket + reworked ante, post handler decorator distinction by @Eengineer1 in https://github.com/cheqd/cheqd-node/pull/786
feat: add fee abs module by @atheeshp in https://github.com/cheqd/cheqd-node/pull/780
feat: Added MsgBurn per signer by @vishal-kanna in https://github.com/cheqd/cheqd-node/pull/783
feat: add fee-abs docker tests by @atheeshp in https://github.com/cheqd/cheqd-node/pull/787
feat: add msg mint by @atheeshp in https://github.com/cheqd/cheqd-node/pull/784
ci: Bump relevant CI packages [DEV-4449] by @filipdjokic in https://github.com/cheqd/cheqd-node/pull/791
ci: Fix super-linter errors by @filipdjokic in https://github.com/cheqd/cheqd-node/pull/795
ci: Check linter rules by @ankurdotb in https://github.com/cheqd/cheqd-node/pull/798
chore(deps): Bump amannn/action-semantic-pull-request from 5.4.0 to 5.5.3 by @dependabot in https://github.com/cheqd/cheqd-node/pull/771
fix: Restore upgrade testing suite for v3.x line by @vishal-kanna in https://github.com/cheqd/cheqd-node/pull/789
feat: Update AssertionMethod Validator by @DaevMithran in https://github.com/cheqd/cheqd-node/pull/796
build: Bump direct + selectively indirect by @Eengineer1 in https://github.com/cheqd/cheqd-node/pull/806
chore(deps-dev): Bump semantic-release from 24.1.2 to 24.2.0 by @dependabot in https://github.com/cheqd/cheqd-node/pull/809
Full Changelog: https://github.com/cheqd/cheqd-node/compare/v2.0.2...v3.0.1
This document offers the information and instructions required for node operators complete an upgrade with a fresh installation.
We decided to remove the debian package as an installtion artifact and use our own installation tool. The main reason for this is to help our current and future node operators join the cheqd network or complete an upgrade in a more intuitive, simpler and less time intensive way.
For this upgrade from 0.5.0 to 0.6.0 there are 2 possible scenario:
upgrade by installing Cosmovisor
upgrade only cheqd-noded binary.
Cosmovisor is a tool from the cosmos-sdk team which is able to make an upgrade in a full-auto mode. It can download and exchange binary without any actions from a node operator. Beginning with version 0.6.0, and with all subsequent versions, we will leverage Cosmosvisor as a tool to handling our upgrade process.
For more information about interactive installer please see this documentation. You will find answers to common questions within this document, however of course feel free to reach out to the team on Slack or Discord.
As the installation and setting up the Cosmovisor can be difficult, and requires some additional steps for setting up the systemd service, we injected all this steps into our interactive installer.
The flow for installtion is:
systemd serviceMake sure that it was definitely stopped by using:
The output should be:
the main focus here: Active: inactive (dead)
cheqd-noded binary with the Cosmovisor installationIMPORTANT For running an Upgrade scenario you'll be required to setup a current home directory for a cheqd user as an answer on question Set path for cheqd user's home directory [default: /home/cheqd]:. This is because the upgrade scenario will only be used if this directory exists.
WARNING Please make sure that you answered yes for questions about overwriting existing configuration. It's very important when making a new installation with Cosmovisor.
systemd serviceIf you are updating a current installation the next steps can be used:
systemd serviceand make sure that it was really stopped by:
Output should be like:
the main focus here: Active: inactive (dead)
IMPORTANT For running an Upgrade scenario you'll be required to setup a current home directory for a cheqd user as an answer on question Set path for cheqd user's home directory [default: /home/cheqd]:. This is because the upgrade scenario will only be used if this directory exists.
WARNING. IF you are keeping just standalone a cheqd-noded, without Cosmovisor, it's crucial you keep your systemd service files without overwriting them. Please make sure that your answers were no.
Updates to the ledger code running on cheqd mainnet/testnet is voted in via governance proposals on-chain for "breaking" software changes.
We use semantic versioning to define our software release versions. The latest software version running on chain is in the v2.x.x family. Any new release versions that bump only the minor/fix version digits (the second and the third part of release version numbers) is intended to be compatible within the family and does not require an on-chain upgrade proposal to be made.
Network-wide software upgrades are typically initiated by the core development team behind the cheqd project. The process followed for the network upgrade is defined in our guide on creating a Software Upgrade proposal via network governance.
Additionally, these software upgrades are discussed off-chain on our discussion forum and on our Discord server.
You can find more details on the actual upgrade process under in our Upgrade Process Guide
This section lists previous software upgrade proposals and specific instructions on how to execute them.
Ubuntu's standard support for Ubuntu 20.04 LTS ("Long Term Support") version ends in April 2025. Ubuntu 20.04 LTS is currently the default Linux operating system used to build and run the binaries for our cheqd-node. To ensure continued stability and security, we need to upgrade to the latest Long-Term Support (LTS) version, Ubuntu 24.04.
Additionally, to ensure compatibility with Ubuntu 24.04, you'll need to upgrade to cheqd-noded v2.0.2. This upgrade will address any existing security vulnerabilities and ensure that we are running on the most up-to-date software and distribution, providing a secure and reliable environment.
Please follow the guide to transition both the operating system and our node software smoothly.
Backup critical data (e.g., keys, config files).
Be prepared for the expected downtime of your node (approx 1 hour)
Ensure all dependencies and software running on your node (except cheqd-node) support the latest Ubuntu LTS.
Stop and disable the cheqd-cosmovisor.service:
Update sources list and upgrade existing packages:
You'll probably need to restart your server after this step (you'll see the message if you run the do-release-upgrade command):
Trigger distribution upgrade
During the process, you'll be prompted for a lot of answers, here are the most important ones:
Feel free to continue over ssh, since this shouldn't cause any issues for most of the cloud providers.
This is required, so continue.
After you agree with this, the actual upgrade process will start.
There will be some configuration changes and you'll probably be asked if you want to install a new version of certain software (see the screenshots and examples below). In most cases, it is completely fine to overwrite configuration changes, but be cautious if you have some custom configurations, since these actions will overwrite them:
After that, you'll be asked if you want to remove obsolete packages. It's always a good idea to check details (by pressing d ), especially if you have other software running on your node. In our case, we agreed to remove unused packages:
Finally, you'll be asked to restart your system to apply the changes. Your server should automatically reboot, but it's good to check with your cloud provider documentation and make sure this action won't cause any data loss.
It's probable that SSH fingerprint is going to change after the upgrade, so you won't be able to ssh to your server immediately. To resolve that, you'll need to run the following command on your localhost:
Check the distribution version:
After you ssh again, you can check your distribution version, which should match Ubuntu 22.04 LTS if the upgrade was performed successfully.
Trigger another distribution upgrade:
The remaining steps should be the same as in Step 2, although you won't be asked the same questions as in the first upgrade.
Note that it's possible that you won't be able to proceed with this due to some package incompatibility:
On one of our nodes, it was the postgres-client-15.
We resolved this issue by removing this package and installing it again after a successful upgrade:
After you complete the upgrade and restart your node again, you should ssh to your server again and check the distribution version. If everything was successful, you should get output like this:
Download the latest version of the interactive installer:
Run the installer:
Select the first option UPGRADE existing installation and proceed by choosing the v2.0.2 version from the list.
For the remaining questions, answer based on your previous setup and complete the binary upgrade.
Check the version of your cheqd-node:
Re-enable cheqd-cosmovisor.service and start your node:
The final step would be to make sure that your node is up and running and that it managed to sync with the network.
Run cheqd-noded status and check for "catching_up":false and also check if the latest_block_height and latest_block_time looks good to you.
Upgrade process includes 2 main parts:
Sending a SoftwareUpgradeProposal to the network
Moving to the new binary manually
SoftwareUpgradeProposalIn general, this proposal is the document which includes some additional information for operators about improvements in new version of application or another additional remarks. There are not any requirements for proposal text, just recommendations and information for operators. And also, please make sure that this proposal will be stored in the ledger in case of success voting process in the future.
The next steps are describing the general flow for making a proposal:
Send proposal command to the pool;
After getting it, ledger will be in the PROPOSAL_STATUS_DEPOSIT_PERIOD;
After sending the first deposit from one of other operators, proposal status will be moved to PROPOSAL_STATUS_VOTING_PERIOD and voting period (2 weeks for now) will be started;
Due to the voting period operators should send their votes to the pool, get new binary downloaded and got to be installed;
After voting period passing (for now it's 2 weeks) in case of success voting process proposal should be passed to PROPOSAL_STATUS_PASSED;
The next step is waiting for height which was suggested for upgrade.
On the proposed height current node will be blocked until new binary will be installed and set up.
The main parameters here are:
proposal_name - name of proposal which will be used in UpgradeHandler in the new application,
proposal_description - proposal description; limited to 255 characters; you can use json markdown to provide links,
upgrade_height - height when upgrade process will be occurred. Keep in mind that this needs to be after voting period has ended.
upgrade_info - link to the upgrade info file, containing new binaries. Needs to contain sha256 checksum. See example - https://raw.githubusercontent.com/cheqd/cheqd-node/refs/heads/main/networks/mainnet/upgrades/upgrade-v3.json?checksum=sha256:5989f7d5bca686598c315eb74e8eb507d7f9f417d71008a31a6b828c48ce45eb
operator_alias - alias of a key which will be used for signing proposal,
<chain_id> - identifier of chain which will be used while creating the blockchain.
In case of successful submitting the next command can be used for getting proposal_id:
This command will return list of all proposals. It's needed to find the last one with corresponding name and title.
After getting deposit from the previous step, the VOTING_PERIOD will be started. For now, we have 2 weeks for making some discussions and collecting needed vote count. For setting vote, the next command can be used:
The main parameters here:
<proposal_id> - proposal identifier from [step](#Command for sending proposal)
<vote_option> - the actual vote (it can be yes, no, abstain, no_with_veto)
Votes can be queried by sending request:
At the end of voting period, after voting_end_time, the state of proposal with <proposal_id> should be changed to PROPOSAL_STATUS_PASSED, if there was enough votes Also, deposits should be refunded back to the operators.
After the proposal status is marked as passed, the upgrade plan will become active. You can query the upgrade plan details using the following command:
This will return output similar to:
At block height 1000, the BeginBlocker will be triggered. At this point, the node will be out of consensus, awaiting the upgrade to the new version.
The log messages like these should be expected:
Once the new application version is installed and running and 1/3 of the voting power on the network is restored, the node will resume normal operations.
If your node is configured to use Cosmovisor, the upgrade action will be performed automatically at the specified block height.
To check if your node is configured to run with Cosmovisor, run the following command:
If there's a running systemd service, running this sub-process /usr/bin/cosmovisor run start, then your node is using Cosmovisor.
Additionally, you should make sure that in your cheqd-cosmovisor systemd service configuration file, you have these environment variables set to true:
By default, the configuration file can be found at this location - /usr/lib/systemd/system/cheqd-cosmovisor.service;.
If you are running a node built from source, you will need to:
Refer to the upgrade proposal details.
Check out the git tag corresponding to the latest release. This is important in cases code in our main branch doesn't match the latest release.
Build the updated binary.
For standalone nodes, follow the instructions in . Make sure to choose the release suggested in the software upgrade proposal.
Additionally, we're also publishing the docker images in our , so in case you're running cheqd node in Docker, you can always find the latest image there.