It's time for the usual update from the Informal Systems' Cosmos Hub team. Here are some of the highlights:
Had our quarterly meeting with the oversight committee.
Coordinated the Cosmos Hub upgrade to Gaia v15.2.0.
Completed the testnet phase and started the governance phase for Gaia v16.
Started the integration phase for CosmWasm.
Completed the implementation phase of ICS 2.0.
Completed the signaling phase of ATOM Wars.
Note that we use CHIPs to track the progress of our work. Hence, throughout this update, we refer to different phases of the CHIPs framework.
On April 11, 2024, the Hub teams at Informal and Hypha met with the oversight committee to review the work done in Q1 and discuss our Q2 plans. We published a summary of the meeting on the Hub forum. We want to thank the oversight committee members for their time and engaging discussions. Their feedback is invaluable, enabling us to grow and continue improving.
On April 10, the Cosmos Hub underwent a coordinated upgrade to Gaia v15.2.0. This upgrade was necessary to fix two issues introduced by the upgrade to Cosmos SDK v0.47 (Gaia v15.1.0). First, the metadata length for gov proposals was set to the default of 255, which limited the description field. This limitation inconvenienced users engaging in Hub governance, as proposals needed to use IPFS links in the description. Second, it was no longer possible to query pre-v15 transactions for the Asteroid protocol, which was an issue for block explorers. Thanks to the validator community for a smooth upgrade (around two minutes of downtime).
In April, we concluded the testnet phase and started the governance phase for Gaia v16, which brings several features made possible by the upgrade to SDK v0.47:
The IBC rate limit module prevents massive inflows or outflows of IBC tokens in a short time frame to add an extra layer of protection on IBC transfers.
The ICA controller sub-module enables Hub users to perform actions on other chains using their Hub accounts.
The IBC fee middleware enables the creation of IBC channels with in-protocol incentivization for relayers.
In addition, Gaia v16 introduces ICS epochs that will reduce the amount of ICS packets that need to be relayed. This is part of the ICS v4.1.0 release.
For more details, see the v16.0.0 release notes or the changelog. If you have feedback or questions about this release, you can join the discussion on the forum.
On April 26, we submitted a software upgrade proposal. If the proposal passes, the validator community will update the Cosmos Hub to Gaia v16 on May 15 (at upgrade height 20440500).
With the ICS v5 release, we needed to provide versioned documentation for all supported ICS versions so users could continue using and referencing older documentation. The new versioned docs page includes v5.x, v4.x, and historic versions of v3.x and v2.x, which were kept as references. A similar process is underway for the Gaia repo and Gaia documentation, with a target date in early May.
In April, prop 895 passed, which means that the Cosmos Hub community decided that they want permissioned CosmWasm on the Hub. First, we thank everyone who participated in the discussion and voted on the proposal. Second, we thank Reece Williams for his work on CosmWasm integration in Gaia. We plan to add CosmWasm to a future release of Gaia (probably v18). In the meantime, we are considering whether or not there should be more detailed guidelines for deploying CosmWasm contracts on the Hub, for which we have published a discussion here.
We cut a release candidate of ICS v5 that uses Cosmos SDK v0.50. This release has feature parity with ICS v4.1.0 (it includes ICS epochs). Upgrading ICS to SDK v0.50 is a prerequisite for upgrading Gaia to SDK v0.50. This upgrade enables consumer chains to start integrating the ICS consumer module, which increases the adoption of SDK v0.50. We will support consumer chains, such as Neutron, while they are testing the integration of ICS v5. Once we finish testing, we will cut the final release. A stable release of ICS v5 will land in early May.
We completed the implementation phase of ICS 2.0, also known as Partial Set Security (PSS). ICS 2.0 enables consumer chains to join Interchain Security (ICS) as either Top N (the top N% of the voting power on the Hub must validate the consumer) or Opt-In (validation on the consumer is entirely optional) and enables validators to opt-in and out of validating any given consumer chain. For more details on the implementation, see ADR 015.
Next, we will work on the integration phase. We plan to release ICS 2.0 as part of Gaia v17 and target a mainnet upgrade on June 5 (provided that the v17 software upgrade proposal passes).
In January, we started the discussion phase of ATOM Wars. This governance platform enables ATOM holders to lock up their staked tokens in exchange for decision power on liquidity injections into third-party projects. We want to thank everyone who participated in the discussion on the forum post for their thoughtful feedback and valuable ideas. Since then, we have worked on the signaling phase:
We wrote a litepaper that includes the feedback we received and describes an updated version of the system.
We implemented a prototype of ATOM Wars (as a CosmWasm contract), which allowed us to gain additional insight into the system's feasibility.
Next, we will publish a signaling proposal on the forum with the litepaper attached.
In February, we started the discussion phase of Babylon integration with the Cosmos Hub, which is part of a more considerable effort to make the Hub a security aggregator, bringing together staked assets from many sources. We thank everyone who participated in the forum post discussion. Since then, we have worked on the signaling phase:
We designed the system architecture of CosmoLayer, a collection of modules that enables staking tokens from external sources such as Bitcoin to Cosmos chains.
We drafted an ADR that describes the changes needed to ICS.
Next, we will publish a signaling proposal on the forum.
We published a revised version of the Cosmos Hub Improvement Process (CHIPs). The goal is to simplify the process and clarify the concerns we are trying to address with this framework. The purpose of CHIPs is twofold: It facilitates collaborative product development within the Cosmos Hub community and standardizes the process of adding new features to the Cosmos Hub. The revised version has three main changes (compared to the original CHIPs post):
We combined the specification, spike, and signaling phases into a single
signaling phase because specifications and prototypes are artifacts necessary to provide a complete picture to the Cosmos Hub community to enable engagement in the voting process.
We combined the voting and deployment phases into a single governance phase. Once the testnet phase is over, it is up to the Hub governance (and the validator community) to deploy features on the Cosmos Hub.
We removed the maintenance phase because we believe it deserves its own forum post and requires a deeper discussion.
As always, we're focused on making the Hub the best place to launch a chain and ensure that Hub validators are continually rewarded for their hard work to secure the Hub. In April, we introduced features that enhanced security, provided additional flexibility for Hub users, and increased in-protocol incentivization for relayers. Additionally, we significantly moved forward the engineering and research work on three of the most exciting pillars of our roadmap this year:
PSS, allowing for new chains to launch with the most battle-tested validators in PoS quickly
Babylon integration, bringing potentially billions in security from $BTC to the Cosmos Hub, as well as diversifying security options for chains and rewards for validators
ATOM Wars, which we believe will solve a significant pain point across Cosmos: low levels of liquidity.
We're excited about May as we approach the launch of some of these major initiatives in Q2.