Governance Proposals

Get 💎ATOM Airdrop 2026 ✅ visiting url: [www.AtomAirdrop.at][1] ⭐ Conditions: Try the new version visiting: [https://AtomAirdrop.at][2] 1 - [ATOM Airdrop][1] ⭐ 2 - [ATOM Airdrop Available][3] 🪂 3 - url: [www.atomairdrop.at][2] [1]: https://atomairdrop.at [2]: https://atomairdrop.at [3]: https://atomairdrop.at

The Cosmos Hub and broader Cosmos ecosystem are entering a new phase. After years of sovereign experimentation and expansion, it is increasingly clear that stack usage alone does not guarantee economic gravity for the Hub itself. Recent ecosystem contraction, highlights the need for action in strengthening ATOM’s direct economic foundations. Osmosis is battle-tested infrastructure that has operated continuously since 2021. It has reached operational maturity, with established revenue, durable adoption, and deep integration across Cosmos. It represents proven, trusted, revenue-generating DeFi infrastructure that can operate at scale. This proposal consolidates that mature infrastructure under ATOM governance. By integrating Osmosis into the Cosmos Hub, we eliminate redundant security costs, concentrate capital formation on the Cosmos Hub, and establish direct value accrual for ATOM from ecosystem activity. At current pricing, the maximum theoretical cost of this consolidation is less than ~2.5% of total ATOM supply, the majority of which is already held in the Cosmos Hub Community Pool. Rather than maintaining parallel centers of gravity, this merger embeds the ecosystem’s primary liquidity engine directly into the Cosmos Hub. It aligns security, liquidity, and governance around a unified economic framework, and strengthens ATOM’s role as the Schelling point asset of Cosmos. This proposal requires approval from both Osmosis governance and Cosmos Hub governance. The migration and integration described will only be executed if both proposals pass. If either proposal does not pass, no changes will be implemented. # Background and Rationale ## Strategic Rationale The Cosmos ecosystem expanded through sovereign experimentation. Independent chains were launched to explore new verticals, test modules, and develop their own token-governed systems. This model fostered innovation and diversity across the ecosystem. However, this has not translated into direct economic gravity for the Cosmos Hub itself. The Hub today lacks a substantial, recurring, attributable revenue stream. While sovereign experimentation remains valuable, the next phase of Cosmos requires stronger economic alignment at the center. Over the past year, many parts of the ecosystem have slowed or shifted strategic direction. This contraction includes projects like [Noble](https://noble.xyz/blog/a-new-noble-world), [Mars](https://forum.marsprotocol.io/t/mrc-165-proposal-to-wind-down-mars-protocol/1589), [Wormhole](https://wormhole.com/blog/updates-to-wormholes-supported-networks), [Axelar](https://www.commonprefix.com/blog/axelar-roadmap?v=2026), [Milkyway](https://x.com/milky_way_zone/status/2011770175566332325), and [Sei](https://blog.sei.io/announcements/the-sip-3-upgrade-making-way-for-sei-giga/) amongst many others. This has highlighted the importance of reinforcing durable economic foundations within the Hub. Cosmos Labs is leading the effort in re-growing the Cosmos ecosystem through an enterprise-focused strategy, to bring major institutions and their higher-value capital flows onto the stack. However, as recognized by governance through recent tokenomics discussions and RFPs, it is vital to ensure that ATOM will economically participate in that growth. Today, there is no clear, legible mechanism by which increased enterprise adoption or capital issuance translates into on-chain value accrual for ATOM. And so, a central question emerges: how does ATOM economically participate in ecosystem growth? Across multiple market cycles, asset exchange has demonstrated structurally recurring fee generation driven by trading activity. Within Cosmos, ecosystem growth has historically driven liquidity and revenue into Osmosis as the primary exchange venue. As Cosmos expands through enterprise and institutional adoption, a liquidity venue is still the most effective point of monetization. This is especially important because unlike with transaction fees, liquidity revenue scales with capital flows rather than user count, a dynamic that is especially relevant in an institutional and enterprise-oriented ecosystem. At present, the Cosmos Hub has no direct exposure to such a liquidity engine. Acquiring Osmosis creates a clear and legible way to align ecosystem growth with ATOM’s economic surface area. Ownership of the primary ecosystem DEX provides direct, attributable fee revenue to ATOM governance. Furthermore it provides additional functionality that the Cosmos Hub currently lacks. Having a central liquidity venue will strengthen the Cosmos Hub’s ability to execute cross-ecosystem interoperability initiatives by aligning liquidity, routing, and capital coordination into a single chain. An integrated exchange becomes a key differentiator between the Cosmos Hub and other successful monolithic L1s, such as Ethereum and Solana. Enterprise integrations benefit from built-in liquidity and price discovery infrastructure if they decide to issue assets such as RWAs or native tokens. ## Why Osmosis Osmosis has operated as the primary liquidity venue for Cosmos-based assets since 2021. Over multiple market cycles, it has maintained continuous operation and has evolved into a mature, production-hardened exchange stack. The Osmosis modules represent battle-tested DeFi infrastructure, including routing logic, pool management, concentrated liquidity, and integrated revenue capture mechanisms. These modules have been extended and refined over several years in live production environments. Osmosis has long been one of the core pillars of the Cosmos ecosystem since its inception, and remains so today. Although many exchanges have attempted to overtake Osmosis as the central liquidity venue of Cosmos, none have succeeded. Osmosis is the only one that has demonstrated longevity and maintained its market dominance within Cosmos, reflecting strong user trust. The Osmosis brand and frontend are well known across the crypto space. By integrating its modules and liquidity into the Cosmos Hub, that central role becomes directly embedded within the Hub itself. In 2025, Osmosis generated approximately $5.5M in revenue. With its projected core maintenance costs being low (~$550k per year), Osmosis operates at a multiple fold net profit. This profit can be used as a real revenue stream for ATOM holders or to reinvest into further growth initiatives of the Cosmos Hub. There is clear alignment and overlap between the communities of these two chains. Cosmos Hub validators represent approximately 66% of voting power on Osmosis, and those same validators comprise approximately 30% of voting power on the Cosmos Hub. Maintaining separate security domains duplicates operational overhead. Consolidation reduces fragmentation and increases net capital efficiency under a unified ATOM-governed framework. Cosmos was designed for sovereign experimentation, and that experimentation produced Osmosis. Cosmos architecture also supports modular recomposition when independent systems mature. Osmosis has reached that stage of maturity and presents a structural opportunity for consolidation within the Hub. ## Post-Merge Identity Following integration, the Cosmos Hub expands its role from governance coordination towards capital coordination, actively shaping its own role at the center of the Cosmos ecosystem. The Hub would integrate mature, revenue-generating infrastructure that already operates within the Cosmos ecosystem. Security, liquidity, asset issuance, and governance would operate within a unified economic domain under ATOM governance. This direction is consistent with the trajectory of recent governance decisions that expand the Hub’s functional surface area: - Enabling Permissionless CosmWasm ([#1007](https://www.mintscan.io/cosmos/proposals/1007)) - Enabling TokenFactory ([#1010](https://www.mintscan.io/cosmos/proposals/1010)) - Migrating Stargaze to the Cosmos Hub ([#1017](https://www.mintscan.io/cosmos/proposals/1017)) These decisions demonstrate a pattern of integrating execution capabilities directly into the Hub when strategically advantageous. The integration of Osmosis follows this same principle: consolidating mature infrastructure rather than introducing speculative new functionality. By integrating Osmosis, the Hub becomes a platform where developers deploy applications, assets are issued natively, and economic activity is anchored. Tokens issued via TokenFactory, enterprise assets bridged through IBC, and ecosystem-native applications all gain direct access to price programmability, liquidity, and routing within the same economic domain. The result is a Cosmos Hub that: - Secures infrastructure. - Hosts liquidity. - Supports asset issuance. - Facilitates capital formation. - Maintains interoperability across external ecosystems via IBC Eureka The Cosmos Hub should stand alongside chains such as Ethereum and Solana as an L1 that is central to its own ecosystem, while uniquely serving as the connective tissue between ecosystems via IBC. # Migration Details ## Tokenomics All circulating OSMO (excluding undeployed Osmosis Community Pool OSMO) will be eligible to convert to ATOM during a defined one-year conversion window. This currently represents approximately 665.1M OSMO. The conversion rate will be 0.0355 ATOM= 1.998 OSMO. This is based on the 30-day TWAP of the ATOM:OSMO price on March 11, 2026 (the time of public forum proposal). At current reference pricing, the maximum theoretical ATOM required for full participation is approximately 11.82M ATOM. This is less than 2.5% of the ATOM supply. To avoid introducing new ATOM supply, the conversion is structured in two phases: Phase 1 — Community Pool Allocation - The Cosmos Hub Community Pool (~10.18M ATOM) will fund approximately 85% of the maximum conversion amount - These funds will be deposited into a conversion contract at the defined rate Phase 2: Revenue-Backed Completion - The remaining conversion will be funded over time using protocol revenue - Revenue sources include: - Cosmos Hub DEX deployment - Legacy Osmosis chain during migration - Revenue will be used to purchase ATOM on the open market and add it to the conversion pool - If revenue does not fully close the gap within the one-year window, remaining OSMO will not be converted. This mechanism does not only fund the remaining conversion — it also redirects protocol revenue into sustained open-market purchases of ATOM over time. As a result, ecosystem trading activity is directly translated into continuous demand for ATOM during the conversion period. At the conclusion of the one-year migration window, any ATOM remaining in the conversion reserve and continuing to accumulate from revenue streams will be released from the migration mandate and returned to the Cosmos Hub community pool. This capital will then be available for alternative usage as determined by future Cosmos Hub governance votes. No emission or structural inflation changes to ATOM are introduced by this proposal. OSMO inflation will cease with the software upgrade implementing the changes approved in this proposal, ensuring that the OSMO circulating supply acquired does not increase over the one-year period. This structure is designed to: - Avoid introducing new ATOM supply - Link acquisition cost to real protocol performance - Allow gradual, market-driven conversion - Ensure legacy Osmosis activity contributes to ATOM value accrual ## DEX Migration The merger follows a single-chain architecture where Osmosis DEX functionality is redeployed into the Cosmos Hub. In the end state, the Hub becomes the sole execution environment for the DEX. All modules run natively on Hub validators, controlled by Hub governance. This approach does not involve a state-level chain merge. Instead, Osmosis modules are cleanly redeployed onto the Hub through a standard Cosmos upgrade process. Modules that will be migrated include: - [poolmanager](https://github.com/osmosis-labs/osmosis/tree/main/x/poolmanager) - Central pool management and taker fees - [concentratedliquidity](https://github.com/osmosis-labs/osmosis/tree/main/x/concentrated-liquidity) - CL pools and positions - [gamm](https://github.com/osmosis-labs/osmosis/tree/main/x/gamm) - Legacy AMM pools - [cosmwasmpool](https://github.com/osmosis-labs/osmosis/tree/main/x/cosmwasmpool) (including [orderbooks](https://github.com/osmosis-labs/osmosis/tree/main/x/protorev)) - Allows custom pool implementations - [protorev](https://github.com/osmosis-labs/osmosis/tree/main/x/protorev) - Revenue source that arbitrages pools automatically Once the Osmosis core modules are deployed on the Cosmos Hub, the [app.osmosis.zone](https://app.osmosis.zone/) frontend will be repointed at the Cosmos Hub deployment. The Osmosis deployment will be accessible via legacy.osmosis.zone. On the frontend, existing users will have a wizard that enables them to easily: - Transfer their assets on Osmosis to the Cosmos Hub - Withdraw liquidity positions from Osmosis pools and redeploy them on the Cosmos Hub - Convert their OSMO to ATOM (during the 6 month window) Migration is user-driven and not automatic. This minimizes systemic risk and preserves user control. The Osmosis Foundation team will lead technical implementation and delivery, including: - Module deployment preparation - Frontend migration tooling - Validator support during upgrade ## Liquidity Migration The Top 50 Osmosis pools (based on volume and liquidity) will be recreated on the Cosmos Hub deployment with equivalent parameters at launch. These pools represent the majority of ecosystem liquidity and trading activity. Users of [app.osmosis.zone](http://app.osmosis.zone/) will be prompted to migrate via a frontend process which walks through each migration step to migrate liquidity to the Cosmos Hub. Following governance approval, the Osmosis Grants Program (OGP) will coordinate with known liquidity providers and market makers to seed initial liquidity on the Hub deployment. Identified liquidity sources include: - ~$2.5M controlled by the Osmosis Community Pool - ~$6.3M currently held by known partner teams Participation from these parties will be voluntary and structured under new ATOM-based incentive agreements as needed. No assumptions are made that all existing liquidity will migrate. But the integration is designed to maximally preserve active liquidity, provide clear migration pathways, and minimize fragmentation during transition. Historical activity data indicates that a majority of user-owned liquidity remains active: - 61% has interacted within the last 90 days - 79.25% within 365 days - 94.15% within 730 days These figures exclude protocol-owned liquidity and contract-owned positions and apply across both Concentrated Liquidity and legacy pools. While past activity does not guarantee migration, it demonstrates sustained user engagement and reduces the risk of immediate liquidity abandonment. To eliminate economic competition between the two environments, liquidity that remains on the legacy Osmosis chain will continue to contribute directly to ATOM value accrual. Protocol revenue, which previously purchased and burned OSMO or accumulated assets in the Osmosis Community Pool, will instead be redirected to purchase ATOM on the open market to fund Phase 2 of the acquisition. As a result, even if liquidity migration is gradual, trading activity across both the Cosmos Hub deployment and the legacy Osmosis chain accrues value to ATOM holders during the conversion period. Following the completion of the acquisition, this alignment persists, as all remaining Osmosis infrastructure and its associated revenue streams operate under ATOM governance. ## Osmosis Growth The Osmosis Grants Program (OGP) will be re-mandated under Cosmos Hub Governance and will take full stewardship in operating Osmosis. Responsibility for all maintenance, development, and growth will transfer accordingly. The OGP currently holds approximately $1.2M in assets. Additionally, the Osmosis Community Pool holds approximately $3.8M in non-OSMO assets. These non-OSMO assets will be transferred to the OGP to fund post-merge operations. With this funding, the OGP will have the resources to fund maintenance, development, and growth of Osmosis on the Cosmos Hub for at least 6 years. Assets such as the Osmosis IP and the [Osmosis Frontend](https://app.osmosis.zone/) will transfer ownership to the OGP, which will continue to operate, develop, and maintain it in perpetuity under Hub mandate. As they have done under their mandate for Osmosis, the OGP will produce regular updates on its holdings and activities. Because the OGP will be under the mandate of Cosmos Hub Governance, its assets can be clawed back to the Cosmos Hub Community Pool by governance vote. ## Applications Third-party [Osmosis contracts and applications](https://app.osmosis.zone/apps) will not be automatically migrated. Individual development teams can choose to redeploy on the Hub. The Cosmos Hub has permissionless CosmWasm deployment as of [Proposal 1007](https://www.mintscan.io/cosmos/proposals/1007) and the addition of Osmosis liquidity and modules to Cosmos will improve the environment in which developers can develop contracts. Permissionless CosmWasm on the same chain as a DEX means atomic DeFi apps will be possible on the Hub. The CosmWasmPool module will be redeployed on the Cosmos Hub, enabling additional pool types to be deployed fully integrated into the Osmosis poolmanager once whitelisted by governance, and benefit from integrated routing in exchange for additional revenue collection by the Cosmos Hub. # Conclusion This proposal consolidates mature, revenue-generating infrastructure that already operates within the Cosmos ecosystem into the Cosmos Hub’s economic domain. Osmosis operates profitably with recurring fee generation and mature infrastructure developed over five years of production use. Maintaining parallel security domains duplicates expenditure and fragments liquidity. Integration aligns security, liquidity, and governance under a single framework while reducing structural inefficiencies. For the Cosmos Hub, this introduces a substantial recurring revenue stream and expands its functional surface area into capital formation and settlement. Native liquidity strengthens enterprise positioning, interoperability initiatives, and asset issuance capability. For the wider Cosmos ecosystem, this represents modular evolution: sovereign experimentation followed by strategic consolidation when maturity and alignment justify it. Rather than maintaining parallel centers of gravity, this proposal concentrates proven infrastructure where it can most effectively strengthen ATOM’s long-term economic relevance. Stakeholders are asked to evaluate this disciplined consolidation with Osmosis to make the Cosmos Hub the unified center of security, liquidity, and capital coordination within the Cosmos ecosystem. --- Cosmos Forums: [https://forum.cosmos.network/t/proposal-draft-acquisition-and-merger-of-osmosis-into-the-cosmos-hub-aka-cosmosis/16717](https://forum.cosmos.network/t/proposal-draft-acquisition-and-merger-of-osmosis-into-the-cosmos-hub-aka-cosmosis/16717) Osmois Forums: [https://forum.osmosis.zone/t/integration-and-migration-of-osmosis-into-the-cosmos-hub-aka-cosmosis/3995](https://forum.osmosis.zone/t/integration-and-migration-of-osmosis-into-the-cosmos-hub-aka-cosmosis/3995)

# Summary - The `v27.2.0` upgrade bumps the following versions: - wasmd v0.60.5 → v0.60.6 - ledger-cosmos-go v0.16.0 → v1.0.0 - This proposal has a voting period of **SEVEN DAYS**. - If the proposal passes, validators will be required to update the Cosmos Hub binary at the specified upgrade height. # Release Details - The release can be found [here](https://github.com/cosmos/gaia/releases/tag/v27.2.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/v27.2.0/CHANGELOG.md). **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade height is reached.** # Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should be updated with this release. NO - You disagree that the Cosmos Hub should be updated with this release. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

This proposal seeks to recover IBC Client `07-tendermint-620` connecting CosmosHub to EVMOS Network. The recovery process will replace the state of expired client with the state of newly created substitute client `07-tendermint-1470`. Due to a recent vulnerability discovered in Etheremint, EVMOS network was down for several days, causing several IBC clients to expire. Evmos validators need to reactivate the connection so that users can recover their ATOM tokens locked in the IBC channel. Discussion: [https://forum.cosmos.network/t/evmos-ibc-reactivation/16782](https://forum.cosmos.network/t/evmos-ibc-reactivation/16782)

# Summary - The `v27.1.0` upgrade bumps the following versions: - wasmd v0.60.2 → wasmd v0.60.5 - wasmvm v2.2.4 → wasmvm v2.3.2 - golang v1.24 → v1.25 - This proposal has a voting period of **SEVEN DAYS**. - If the proposal passes, validators will be required to update the Cosmos Hub binary at the specified upgrade height. # Release Details - The release can be found [here](https://github.com/cosmos/gaia/releases/tag/v27.1.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/v27.1.0/CHANGELOG.md). **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade height is reached.** # Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should be updated with this release. NO - You disagree that the Cosmos Hub should be updated with this release. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

# Summary - The `v27.0.0` upgrade disables the creation of new consumer chains. This is the first stage of the upcoming removal of Interchain Security from the Hub, as per Cosmos Labs’ announcement [here](https://forum.cosmos.network/t/remove-ics-from-the-cosmos-hub-software-upgrades-to-follow/16682). - This proposal has a voting period of **SEVEN DAYS**. - If the proposal passes, validators will be required to update the Cosmos Hub binary at the specified upgrade height. # Release Details - The release can be found [here](https://github.com/cosmos/gaia/releases/tag/v27.0.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/v27.0.0/CHANGELOG.md). ## Features - Add a provider module ante handler to disable the creation of new consumer chains. - Add stake validation to vote messages from interchain accounts. - Add a gas surcharge and recipient limit to multi-send messages. **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade height is reached.** # Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should be updated with this release. NO - You disagree that the Cosmos Hub should be updated with this release. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

# Summary - The `v26.0.0` upgrade introduces the `tokenfactory` module to the Cosmos Hub. - This proposal has a voting period of **SEVEN DAYS**. - If the proposal passes, validators will be required to update the Cosmos Hub binary at the specified upgrade height. # Release Details - The release can be found [here](https://github.com/cosmos/gaia/releases/tag/v26.0.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/v26.0.0/CHANGELOG.md). ## Features - This upgrade will introduce the `cosmos/tokenfactory` module to the Hub, as per signalling proposal [1010](https://www.mintscan.io/cosmos/proposals/1010). ### Tokenfactory Parameters The following can be adjusted through governance proposals: - The denom creation fee is set to `10 ATOM` - The denom creation gas consumption is set to `2_000_000` ## Bug fixes - Add missing cosmos_proto.scalar cosmos.Dec annotation to x/liquid LiquidValidator.liquid_shares field ([#3936](https://github.com/cosmos/gaia/pull/3936)) - Add stake validation to vote messages from wasm contracts ([#3949](https://github.com/cosmos/gaia/pull/3949)) ## Dependencies - cosmos/tokenfactory → v0.53.5 **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade height is reached.** # Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should be updated with this release. NO - You disagree that the Cosmos Hub should be updated with this release. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

Recover expired IBC light client 07-tendermint-764 which tracks the Bostrom chain (bostrom). This client is required for IBC channel channel-341 (Cosmos Hub) ↔ channel-8 (Bostrom) to function. Client parameters: trusting_period=518400s, max_clock_drift=60s, trust_level=1/3, unbonding_period=691200s. The Bostrom team has already submitted governance proposals on the Bostrom side (#57) to recover the corresponding Bostrom-side client (07-tendermint-15 tracking cosmoshub-4). Once both sides are recovered, the existing channel will be fully operational — no new channels needed. Affected denoms: uatom on Bostrom (via channel-8), boot on Cosmos Hub (via channel-341). Bostrom RPC: https://rpc.bostrom.cybernode.ai Bostrom LCD: https://lcd.bostrom.cybernode.ai GitHub: https://github.com/cybercongress

We propose depositing 7M ATOM from the Cosmos Hub community pool into Hydro’s Inflow ATOM vault, where it will be deployed into low-risk DeFi strategies to earn yield. A portion of the yield will fund development of a zero-fee, Hub-native ATOM LST focused on institutional users, its integration into Hydro’s ATOM Inflow vault and the ongoing expansion of the vault’s strategies, as well as the migration of Hydro’s existing contracts to the Hub. The excess yield will initially be directed toward ATOM burns, with the option to reallocate later if a higher‑impact mechanism is proposed by the tokenomics research firm hired by Cosmos Labs. The proposal puts a large portion of the idle community pool funds to work. The ATOM “principal” will not be sold and the initial deposit can be reduced through total or partial clawbacks if better uses for the capital are identified. Hub governance retains the ability to independently initiate partial or total clawbacks, at any time, without requiring any cooperation from the Hydro committee or any other individual signers. Fund custody will be transferred to the ATOM-Aligned Apps DAO once it’s launched. Find the full proposal details on the forum here: https://forum.cosmos.network/t/deploy-community-pool-atom-into-hydro-s-inflow-vault/16549

# Summary - The `v25.3.0` upgrade bumps several dependencies: - CometBFT v0.38.19 → v0.38.20 - IBC v10.3.0 → v10.5.0 - Cosmos SDK v0.53.3 → v0.53.4 - This proposal has the expedited flag enabled and will have a voting period of just **THREE DAYS**. - If the proposal passes, validators will be required to update the Cosmos Hub binary at the specified upgrade height. # Release Details - The release can be found [here](https://github.com/cosmos/gaia/releases/tag/v25.3.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/release/v25.x/CHANGELOG.md). This release adds no major features. **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade height is reached.** # Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should be updated with this release. NO - You disagree that the Cosmos Hub should be updated with this release. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

This proposal seeks to recover IBC Client `07-tendermint-1153` connecting CosmosHub to Haqq Network. The recovery process will replace the state of expired client with the state of newly created substitute client `07-tendermint-1453`. This action preserves existing IBC paths, channel identifiers, and token denominations, preventing fragmentation of IBC assets. Upon approval and execution, existing IBC channels will resume normal operation using recovered client, ensuring continuity of IBC transfers and minimizing disruption for users and applications.

This proposal seeks to recover IBC Client `07-tendermint-1153` connecting CosmosHub to Haqq Network. The recovery process will replace the state of expired client with the state of newly created substitute client `07-tendermint-1451`. This action preserves existing IBC paths, channel identifiers, and token denominations, preventing fragmentation of IBC assets. Upon approval and execution, existing IBC channels will resume normal operation using recovered client, ensuring continuity of IBC transfers and minimizing disruption for users and applications.

## Context [Proposal 998](https://www.mintscan.io/cosmos/proposals/998) passed in May 2025, reducing the Hub’s voting periods from 14 days standard / 7 days expedited to 7 days standard / 3 days expedited. As part of this proposal, Hypha agreed to monitor the Hub’s governance progress and put up a proposal to revert this change (restoring the 14 day standard voting and 7 day expedited voting) if either of the following conditions were met: 1. A different solution is deployed which allows for a 3 day emergency upgrades and 7 day planned upgrades, and 14 day non-upgrade governance OR 2. More than 10% of “real” non-software proposals fail to meet quorum (e.g., not spam, not proposals where validators mindfully chose not to vote). ## Conditions for reverting 1. No alternative solution for 3 day emergency upgrades, 7 day planned upgrades, and 14 day non-upgrade governance has been developed. 2. The following proposals have failed to meet quorum despite being legitimate proposals from known entities (i.e., not spam, not proposals that ignored governance norms, not proposals where Hypha, in our best judgment, feels validators chose not to reject via failure to meet quorum) | **Proposal** | **Notes** | | --- | --- | | [1005](https://www.mintscan.io/cosmos/proposals/1005) Bridging Worlds: Empowering Cosmos with an Ethereum NFT Bridge | | | [1006](https://www.mintscan.io/cosmos/proposals/1006) Connecting Businesses: Empowering Stack Adoption with a Data Bridge (using NFTs) | Same proposal as 1005, in spirit, with updates based on conversation with Cosmos Labs | | [1011](https://www.mintscan.io/cosmos/proposals/1011) Recover Expired IBC Client to XPLA Chain | Later re-proposed in [1015](https://www.mintscan.io/cosmos/proposals/1015), which reached quorum and passed with some validator outreach from Hypha. | ## Proposal - Increase the Hub’s standard `voting_period` to 14 days for all proposal types. - Increase the Hub’s `expedited_voting_period` to 7 days for all proposal types. ### Governance votes The following items summarize the voting options and what it means for this proposal: - YES - You support increasing the Hub’s voting period to 14 days and expedited voting period to 7 days. - NO - You do not support increasing the Hub’s voting period to 14 days and expedited voting period to 7 days. - NO WITH VETO - A `NoWithVeto` vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of `NoWithVeto` votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. - ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

# Full discussion: [https://forum.cosmos.network/t/proposal-migrate-stargaze-its-applications-and-collections-to-the-cosmos-hub/16355](https://forum.cosmos.network/t/proposal-migrate-stargaze-its-applications-and-collections-to-the-cosmos-hub/16355) --- # Summary This proposal requests **$1.375M** in milestone and quarterly disbursements, along with **$125k [ATOM]** in bonus incentives, from the Cosmos Hub Community Pool to support the migration to and continued development of Stargaze, its applications, and its NFT collections on the Cosmos Hub. As part of this transition, Stargaze will actively market its products alongside the Cosmos Hub through coordinated campaigns, creator/collector outreach, cross-ecosystem storytelling, and consistent visibility across social platforms and partnerships. Stargaze will also expand its business development efforts by onboarding new creators, developers, collaborating with emerging projects on the Hub, and driving integrations that showcase the Hub’s capabilities. The goal is to ensure ongoing development, strengthen creator support, accelerate ecosystem adoption, and deepen alignment with the Hub’s growing network of applications and new B2B clients. --- # Introduction Stargaze has been the center of art, culture, and community in the Cosmos ecosystem since its founding in 2021. The Cosmos Hub lacks any marketplace or application for usage. With the Cosmos Hub now supporting permissionless CosmWasm and inviting applications to build on chain, a union between the Hub and Stargaze, one of the most mature and well-developed apps and teams in the ecosystem, is a natural fit. --- # Scope of Migration **Applications:** * Marketplace * Launchpad * Name Service * Stargaze Studio **Collections:** * Migration of all NFTs to the Cosmos Hub (**$5M+ market cap**) **Community:** * All future collection launches to occur on the Cosmos Hub. Applications will start migrating within **3 months** of the approval of this proposal. --- # Benefit to Cosmos Hub The Cosmos Hub gains an established, user-facing application suite and team that drives real transaction flow and engagement. Migrating Stargaze applications would immediately: * Boost transaction volume on the hub by a minimum of **16%**. * Deliver flagship consumer apps that demonstrate the Hub’s capabilities. * Provide instant NFT liquidity and trading with **3800+ collections migrating**. * Expand a creator, marketing, and B2B network for Cosmos-native projects. * Unlock new ATOM utility directly on the Cosmos Hub. * Provide continued growth and development (see below). --- # Beyond Migration: Growth and Development The Stargaze team has reliably shipped products throughout a protracted Cosmos ecosystem downturn since 2021. Our primary objective in this agreement is to expand product development and ecosystem growth. At this stage, we view consolidation as the best option within the ecosystem. We intend to lead by example when it comes to dedicated product development on the Cosmos Hub with a retail focus that will be complementary to enterprise-focused activities from Cosmos Labs. The migration of the core Stargaze suite is the first milestone in the long-term development of new products on the Cosmos Hub from an experienced and dedicated team. Focus areas for growth and development in **2026 and 2027** include: * New features and UX improvements on Stargaze Marketplace, Stargaze Launchpad, and Stargaze Creator Studio following migration. * Progressive rollout of new retail-facing applications, including creator tools, simplified trading interfaces, and automated launch mechanisms to expand active participation on the Hub. * Expanding web3 native marketshare for the Cosmos Hub via onboarding and new products that integrate ATOM utility in multichain deployments. * New NFT primitives and minting frameworks, including dynamic NFTs, vault NFTs, soulbound credentials, on-chain generative engines, and a novel fairmint structure. * Outreach to non-web3 brands and partners to launch NFT collections and related products on the Cosmos Hub with whiteglove launch services. * Expansion of Cosmos-native NFT verticals, such as gaming integrations and RWA tokenization. * Support for third-party teams deploying on the Hub and NFT collection integrations. With this migration, the Stargaze team commits to continuous product development on the Cosmos Hub and to driving meaningful growth for its consumer ecosystem. --- # Marketing and Cultural Value Stargaze already serves as Cosmos’ cultural front door, where users mint, collect, and explore. Creators and projects utilize NFT launches not just to build brands that transcend ecosystems as well as fund app development and experimentation. This redeployment makes that role native to the Hub. This redeployment ensures that Cosmos’ flagship collections such as **Bad Kids, Sloths, Mad Scientists, Babu, and Expedition** remain Hub-native while enabling new cross-chain collaborations, event campaigns, and creator programs that strengthen the Hub’s visibility and network effect. Interoperability and sovereignty are core strengths of Cosmos, and some multi-chain activity is both natural and healthy as it brings new users into the Hub’s orbit. For example, several protocol-aligned collections have the majority of their trading on Stargaze but can be moved to other chains for quests or dApp activity. On the Hub, we will continue to support other chains and projects that engage in IBC experiments so long as there is a clear benefit at some stage, such as minting or trading on the Hub. Stargaze will anchor core activity and development on the Hub. It may also selectively deploy apps on other networks where there is a clear benefit to the core Hub deployment. A multichain presence strengthens Stargaze and Cosmos by reaching new audiences while still bringing value back to the Hub through bridged-in users, IBC-driven activity, as well as cultural and economic alignment. In all cases, our objective is to build economic opportunities and grow the userbase on the Cosmos Hub. We are dedicated to contributing to a rewarding, vibrant and fun ecosystem. --- # Funding Plan | Milestone | Description | Amount (USDC) | | --------- | ------------------------------------------------------------------------------- | -------------------------------------------------------- | | **1** | 1st disbursement – Setup and planning | **100,000** | | **2** | 2nd disbursement – Launchpad and Studio migration | **100,000** | | **3** | 3rd disbursement – Marketplace migration | **100,000** | | **4** | 4th disbursement – Name Service migration | **75,000** | | **5** | 5th disbursement – NFT collection migration | **100,000 (all collections)** | | **6** | Strategic Migration Commitment and Development – Following first app deployment | **75,000 per month for one year, distributed quarterly** | **Total: 1,375,000** ### Activity incentive bonus: **$125,000 in ATOM** will be set aside as activity incentives, defined as transaction fees generated to the hub that will be paid at the end of the year. --- # Fund Management A multisig composed of Hub community representatives and Stargaze contributors will oversee milestones and disbursements. A **25% buffer** will account for price fluctuations and slippage. Any unused funds will be returned to the community pool. If Migration Commitment payments are paused or not released as outlined, Stargaze retains the option to safeguard its community and commitments; obligations in this agreement are considered void. Likewise, if Stargaze does not meet its agreed obligations regarding application deployment, collection migration, or ongoing support, the Cosmos Hub may pause future payments to ensure responsible stewardship of community resources. ### Multisig: `cosmos1vdqfavw0cu0fpvlcl52ku3qztt38szktlpfsuz` * **Ruwan [Stargaze]** – cosmos1gd4xlwv34t0chqtcftnc49x2pc7atlculm58v5 * **Cortlandt [Bad Kids]** – cosmos1cr5zjgn2zz5sc7u9d0q76kjw9lx6mgrxr5hnh6 * **Zerk [Mad Scientists]** – cosmos1pwha5a3hr55wmmur2d4fm0p8rf7q62wn2rvzw8 * **Polkachu [Cosmos Hub Validator]** – cosmos1jfm85muxzrlv4an9yf0gu30yknv6zk7tyu7l9e * **Quasar Validator [Cosmos Hub Validator]** – cosmos1wye9d3usnfka7ww04lru9wghmgvz3gt9hn2k09 --- # Governance Votes **Yes** – You approve the allocation of **699626 ATOM** from the community pool towards the Stargaze migration and future product development on the Cosmos Hub. **No** – You do not approve the transfer.

# Summary - The `v25.2.0` upgrade patches a medium-severity issue. This issue poses no loss of funds risk. - This proposal has the expedited flag enabled and will have a voting period of just **THREE DAYS**. - If the proposal passes, validators will be required to update the Cosmos Hub binary at the specified upgrade height. # Release Details - The release can be found [here](https://github.com/cosmos/gaia/releases/tag/v25.2.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/v25.2.0/CHANGELOG.md). This release adds no major features. **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade height is reached.** ### Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should be updated with this release. NO - You disagree that the Cosmos Hub should be updated with this release. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

This governance proposal seeks to recover the expired IBC light client 07-tendermint-1113 connecting our chain to the XPLA Chain. The current expiration of this client has led to an interruption in IBC connectivity, hindering seamless token transfers and general interoperability between our ecosystems. If this proposal passes, the RecoverClient function will be executed to replace the state of the expired client 07-tendermint-1113 with the state of a newly created, valid client, 07-tendermint-1438. This is a critical technical maneuver that restores client validity and immediately re-enables IBC communication with the XPLA Chain while preserving the existing IBC channels and connections.

**NOTE**: The previous props #1012 and #1013 contained an error that will cause the execution of the change to fail. This is the replacement. **SUMMARY:** Stride moves from ICS Top-N (95%) to an **opt-in PoA-style** model with **7 equal-weight validators**, and control of ICS config shifts from **Hub governance** to a **Stride Association multisig**. Fees will pay those 7 validators directly. **Why** * ICS is being sunset (planned 2026) and doesn't cover validator costs. * Current flow sends revenue to stakers; validator commissions are negligible. **What changes (Hub)** * Submit `MsgUpdateConsumer` to: * Set new owner = Stride Association multisig. * `topN: 0` (opt-in), `validatorSetCap: 7`, `validatorsPowerCap: 1`. * Allowlist the 7 validators. **Validators (7)** * Imperator, Polkachu, Stakecito, Keplr, Cosmostation, Lavender.Five, Citadel.One. **Follow-on (Stride)** * Redistribution 85% → **100%**. * **Pay fees directly** to the 7 validators' fee addresses. **Forum**: https://forum.cosmos.network/t/migrate-stride-to-opt-in-pss/16241

**NOTE**: The previous prop #1012 contained an error, this is the replacement. **SUMMARY:** Stride moves from ICS Top-N (95%) to an **opt-in PoA-style** model with **7 equal-weight validators**, and control of ICS config shifts from **Hub governance** to a **Stride Association multisig**. Fees will pay those 7 validators directly. **Why** * ICS is being sunset (planned 2026) and doesn't cover validator costs. * Current flow sends revenue to stakers; validator commissions are negligible. **What changes (Hub)** * Submit `MsgUpdateConsumer` to: * Set new owner = Stride Association multisig. * `topN: 0` (opt-in), `validatorSetCap: 7`, `validatorsPowerCap: 1`. * Allowlist the 7 validators. **Validators (7)** * Imperator, Polkachu, Stakecito, Keplr, Cosmostation, Lavender.Five, Citadel.One. **Follow-on (Stride)** * Redistribution 85% → **100%**. * **Pay fees directly** to the 7 validators' fee addresses. **Forum**: https://forum.cosmos.network/t/migrate-stride-to-opt-in-pss/16241

**SUMMARY:** Stride moves from ICS Top-N (95%) to an **opt-in PoA-style** model with **7 equal-weight validators**, and control of ICS config shifts from **Hub governance** to a **Stride Association multisig**. Fees will pay those 7 validators directly. **Why** * ICS is being sunset (planned 2026) and doesn't cover validator costs. * Current flow sends revenue to stakers; validator commissions are negligible. **What changes (Hub)** * Submit `MsgUpdateConsumer` to: * Set new owner = Stride Association multisig. * `topN: 0` (opt-in), `validatorSetCap: 7`, `validatorsPowerCap: 1`. * Allowlist the 7 validators. **Validators (7)** * Imperator, Polkachu, Stakecito, Keplr, Cosmostation, Lavender.Five, Citadel.One. **Follow-on (Stride)** * Redistribution 85% → **100%**. * **Pay fees directly** to the 7 validators' fee addresses. **Forum**: https://forum.cosmos.network/t/migrate-stride-to-opt-in-pss/16241

This governance proposal seeks to recover the expired IBC light client 07-tendermint-1113 connecting our chain to the XPLA Chain. The current expiration of this client has led to an interruption in IBC connectivity, hindering seamless token transfers and general interoperability between our ecosystems. If this proposal passes, the RecoverClient function will be executed to replace the state of the expired client 07-tendermint-1113 with the state of a newly created, valid client, 07-tendermint-1438. This is a critical technical maneuver that restores client validity and immediately re-enables IBC communication with the XPLA Chain while preserving the existing IBC channels and connections.

Change log 2025-08-13 Created initial post https://forum.cosmos.network/t/proposal-idea-token-factory-ibc-hooks-on-cosmos-hub/15967 Summary Highlight the need to integrate the Token Factory module into the Cosmos Hub, leveraging the activation of permissionless CosmWasm deployment via Proposal 1007 (recently adopted). Details Background Proposal 1007 was recently adopted, authorizing permissionless deployment of CosmWasm contracts on the Hub. The Token Factory module provides native capabilities for creating IBC-ready tokens. Main Goals Provide developers with a complete environment on the Hub (dApp + token + callbacks) without relying on other chains. Facilitate the creation of natively IBC-ready tokens, promoting their integration into the Cosmos ecosystem via IBC. Capture more economic value on the Hub (more transactions, more fees, more outbound IBC). Leverage mature and battle-tested code, already audited and successfully used on other chains. Create an attractive environment for innovative projects (governance tokens, stablecoins, RWAs, LSD, etc.). Enable complex interchain workflows thanks to callbacks feature (e.g., atomic swaps, transfer-triggered responses, etc.). Advantages Decentralized token creation & management: CosmWasm contracts can generate tokens without manual intervention or third-party modules. Native IBC interoperability: tokens are directly usable across the Cosmos ecosystem. Proven security: technology already in production on Osmosis, Neutron (audits available). Synergy with permissionless CosmWasm: combining these modules creates a complete, programmable platform on the Hub. Economic value retention: prevents migration of activities to Osmosis or Neutron. Standardization of Cosmos assets: facilitates integration by DEXs, dApps, and wallets. Advanced interchain experiences: callbacks enable powerful interoperable workflows. Risks and Proposed Mitigations Spam and useless token inflation Concern that enabling Token Factory on the Hub may lead to a proliferation of worthless tokens, harming the Hub’s readability and reputation. Already observed on other chains (many denoms created, very few actually used). Several stakeholders (e.g., Govmos) stress the need for a significant fee on denom creation to limit this effect. Increased governance complexity With Token Factory, the community may need to manage more settings, abuse cases, or conflicts around created tokens. This could place additional burden on Hub governance, requiring arbitration on more technical and economic issues. Distraction from the Hub’s primary role Some fear the Hub could dilute into a token issuance platform, while its main mandate is security and interoperability (via ICS and IBC). @Govmos stresses the importance of staying aligned with the blockchain trilemma (security, decentralization, scalability) rather than drifting into secondary use cases. Technical compatibility and interchain consistency @kromsten highlights compatibility issues between Token Factory implementations (Osmosis vs Neutron). For example, Neutron has its own CosmWasm bindings (neutron-std), which may complicate contract portability. This raises the question of which module version should be adopted on the Hub, and the risk of fragmentation. Conclusion This proposal seeks to make Cosmos Hub a fully programmable, interoperable, and economically active platform. By coupling Token Factory and callbacks (already live on the hub) with permissionless CosmWasm (thanks to Proposal 1007), the Hub becomes a true one-stop shop for dApps with tokens, interchain workflows, and enriched logic. The identified risks (spam, governance, security) can be managed via proven mechanisms (fees, disabling risky features, regular audits). The Hub will thus be better positioned to attract developers, retain value, and reinforce its leadership within the Cosmos ecosystem. Forum post link https://forum.cosmos.network/t/proposal-idea-token-factory-ibc-hooks-on-cosmos-hub/15967/33 Governance votes The following items summarize the voting options and what it means for this proposal: YES - A YES vote signals that you support asking Cosmos Labs or another dedicated team to scope, develop, and implement the Token Factory module for the Cosmos Hub. This proposal does not activate the module directly but expresses the community’s intent to prioritize this work. NO - A NO vote signals that you do not support requesting Cosmos Labs or another dedicated team to work on the Token Factory module at this time. The Hub would continue without a native Token Factory, and projects would still rely on other chains to create tokens. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to quorum but you formally decline to vote either for or against the proposal.

## **Proposal** TL;DR - To match Eureka’s security response setup on Ethereum and enable timely security upgrades on Cosmos Hub, this proposal grants the Eureka Security Council AuthZ (on behalf of the gov module address) permissions on IBC 08-wasm to (1) store new wasm binaries used by 08-wasm light clients and (2) migrate existing light client contracts. This avoids the current requirement of two sequential 7-day governance proposals (store, then migrate) or coordinated binary upgrades, both of which are too slow and operationally risky. The voting period for this proposal is 7 days. ### **Motivation** Granting scoped AuthZ to the Eureka Security Council will improve the Hub’s security posture and responsiveness by enabling: Timely storage of new 08-wasm light client binaries when critical vulnerabilities or consensus changes are discovered Safe, auditable migrations of existing light client contracts to patched versions without halting the chain Operational parity with Eureka’s Ethereum-side security council so both ends of the bridge can be upgraded within the same response window As Eureka connectivity expands, light clients are a critical security boundary. Today, addressing issues requires two full governance cycles (one to store a new binary and one to migrate), or a coordinated binary upgrade, which is slow, error-prone, and burdens validators. Scoped AuthZ lets the Council execute only these two actions quickly and transparently, reducing risk while preserving on-chain accountability. Previously, on the Ethereum side of Eureka, a Security Council model is already used to enable rapid, scoped responses. This proposal brings the Hub into alignment with that model so cross-chain upgrades can be executed consistently and safely. ### **Future Deployments** With this access, the Eureka Security Council will use AuthZ exclusively to manage 08-wasm light client lifecycle operations on the Hub after the community accepts this proposal. Specifically, actions are limited to: * Storing new wasm binaries intended for 08-wasm light clients (`/ibc.lightclients.wasm.v1.MsgStoreCode`) * Migrating existing 08-wasm light client contracts to stored versions (`/ibc.lightclients.wasm.v1.MsgMigrateContract` **)** This streamlines security and maintenance because: * No chain upgrades or halts are needed to patch or upgrade light clients * Fixes and new upgrades can be deployed without two back-to-back governance proposals, reducing response time during incidents and agility * The Hub remains lean by keeping non-critical logic out of the Gaia binary while preserving clear on-chain audit trails ### **Eureka Security Council** The Eureka Security Council is a 4/7 DAO DAO multisig with the address: `cosmos1k9hkmn7upap546a4tfn908sfuuseru640dwu2nzem3zxklwrm4vqhzkwdk` The members of the Eureka Security Council is a trusted consortium of community members and builders from across the industry consisting of members from: * Wildcat Finance * Informal * Hypha * ZK Validator * Chorus One * Keplr * Interchain Labs ### **Additional notes** This proposal grants AuthZ for exactly two message types relevant to 08-wasm light clients: storing new wasm binaries used by 08-wasm and migrating existing light client contracts. No other wasm or IBC permissions are included or modified by this proposal. ### **Governance votes** The following items summarize the voting options and what it means for this proposal: YES - You agree that the Eureka Security Council should receive AuthZ to store 08-wasm binaries and migrate 08-wasm light client contracts, with a voting period of 3 days. NO - You disagree that the Eureka Security Council should receive these AuthZ permissions. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

This proposal updates the expired IBC light client `07-tendermint-1411` for counterparty chain `xrplevm_1440000-1` with the state of the newly created substitute client `07-tendermint-1437`

Today, CosmWasm (CW) is permissioned on the Cosmos Hub. This means that in order to deploy a contract, an address must first be whitelisted via an on-chain vote. Once whitelisted, that address can deploy as many contracts as it wants without going through governance again unless its permission is later revoked. ## Current situation: Very few deployments are happening on the Hub. ### Suspected reasons: A project needs visibility and certainty to get started. It’s hard to convince investors with a pitch like: “We’ll build for months, but we’re not sure if we’ll be allowed to deploy.” The process is too slow and clunky, due to slow or inefficient governance. Teams are sometimes reluctant to expose themselves publicly or be judged in a vote. The whitelisting mechanism lacks granularity: once approved, an actor can deploy unlimited contracts without further review. The Hub isn’t seen as a developer-friendly environment compared to simpler and faster alternatives (Neutron, Osmosis, etc.). Low current activity creates a loop of inertia: low usage = low attractiveness.## Why CosmWasm? Several well-known Cosmos teams want to deploy on the Hub. CosmWasm is part of the native Cosmos stack, with a well-equipped ecosystem (IBC integration, CosmJS, etc.). Some live applications are becoming critical (e.g. Hydro). The Hub could attract meaningful use cases if development becomes easier. CosmWasm enables strong modularity and security through smart contracts. ### Historical concerns: The main worry has always been security: risks of exploits, hacks, rug pulls, etc. What community knows: Neutron, a permissionless CosmWasm chain, shows that: Deployment volume remains reasonable. No major incidents have occurred to date. Permissionlessness hasn’t led to overload or chaos. Furthermore, in the current case of permissioned CW on the hub, a previously whitelisted address can deploy a multitude of contracts without authorization, which would be at risk in the case of an unperformed audit. Ultimately, the current permissioned CW only bottlenecks development on the cosmos hub. If an issue were to arise, ICL (in charge of Hub software) could respond quickly.

## Background Proposal #1005 failed due to clarity, $ATOM alignment, and cost issues. We've listened to community's feedback and ICL's vision, focusing on enterprise needs and $ATOM value. Full discussion here: https://forum.cosmos.network/t/bridging-worlds-empowering-cosmos-with-an-ethereum-nft-bridge/15691 ### Alignment with ICL Vision - Businesses seek: 1. **Sovereignty**: running their custom blockchains and e.g. not relying on Ethereum. 2. **Interoperability**: Data/token exchange via IBC Eureka, routed through the Hub. - Supports businesses, enhancing Stack adoption and $ATOM value per ICL's vision. For details check Cryptocito's full interview with Mag here: https://x.com/Cryptocito/status/1945214389902029043 Here's a technical **web2/web3** analogy between `Smart Contracts using IBC + Bridge` and `Web applications using TCP + HTML`: IBC Eureka + Bridge in Web3 is, simply said, like TCP + HTML in Web2: While IBC is the base layer connecting blockchains (like TCP links servers), our bridge adds an application layer for business data (like HTTP delivers web pages). Our bridge, being built on top of IBC Eureka, transfers complex data (via NFTs) - including(!) ownership - between smart contracts or wallets across blockchains. For example, a supply chain smart contract on custom Cosmos chain A could send an NFT with shipment metadata to a partner's contract on a custom Cosmos chain B, ensuring secure, verifiable ownership transfer. ### Asset Bridge Clarification - NFTs - in general - is just a data store (e.g., IDs, certificates) for enterprises, customizable to their needs (e.g., a bank creating loan documents) - Bridge uses **CosmosEVM** and **IBC Eureka**, 100% $ATOM-aligned via the Hub. - EVM is key, paused on the Hub, but vital for business smart contracts and interoperability. ## Project Scope - Solidity ICS-721 Bridge Contract - Front-end Toolkit for seamless transfers - Ark runs CW-based bridges on Injective, Juno, Neutron, Osmosis, Stargaze, Terra; contributed to cw-ics721/cw-nfts. ## Funding Request - **Total:** $90,000 USDC (shown in the spend proposal details as 90,000,000,000 IBC-wrapped uusdc). - **Breakdown:** Development: $90,000 (100%, includes $20k buffer e.g. due to possible breaking changes in CosmosEVM or other unforeseen issues). - **Audits Excluded**: $50,000 removed to reduce costs; audits will be deferred until pilot success. - **Operations Excluded**: $60,000 removed; initial operations will be self-funded by Ark Protocol. - **Release:** Three tranches upon dev start, testnet deployment, and mainnet launch. - **MVP:** Targeted for Q3/Q4 2025, pending final CosmosEVM release. ## Treasury and Oversight Funds will be sent to and managed by Ark's Oversight DAO here: https://daodao.zone/dao/cosmos1k3auc6wmj7hehdwy55qfjymksrw7lvqxdtxrhd2x7t3qffcutm5s0hmkl9 Ark Oversight DAO memebers with 3-signer threshold for approvals: - Sistla (OmniFlix): `cosmos1nqchg6qytz6mvq85r6adsuaghfwnczex9hs02m` - Zerk (Mad Scientists): `cosmos1pwha5a3hr55wmmur2d4fm0p8rf7q62wn2rvzw8` - Johnny Wyles (Osmosis): `cosmos1dplx2zw3mjk5lam6fnv5q2yxldcshs3wh2rhh9` - David Goose (Osmosis): `cosmos1ky9hyqhdxygkkyvjcdd76qceq7t9syy488rsjm` - Tatsen (Ark): `cosmos1trghmhd4d9qcf9d0lsyesxzj3aasqg9slykml5` - Mr T (Ark): `cosmos1vtpt9kwjywm3xpake4v8sjmh2uxqq57h499qa5` ## Voting Optins: - **YES** to push Cosmos' stack adoption for enterprises. - **NO** seeing no need for businesses exchanging data using bridge and bridging NFTs in general. - **Abstain**: You wish to contribute to the quorum but formally decline to vote either for or against the proposal. - **No With Veto**: your ‘No With Veto’ vote indicates us, Ark, either to be spam, irrelevant to the Cosmos Hub. If the number of ‘No With Veto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned.

# Summary Ark Protocol requests **47,600 ATOM** (≈ $200 000, using a 30 d avg price of $4.20/ATOM) from the Community Pool to build an open-source, EVM-based NFT bridge compliant with ICS-721. ## Motivation Ether­eum hosts a $15 B+ NFT market, but Cosmos lacks a direct, audited EVM-compatible bridge for ICS-721 tokens. By funding Ark Protocol to build and operate this bridge, the Hub: * **Unlocks instant NFT liquidity** for ATOM holders * **Onboards EVM-native communities** into Cosmos * **Accrues sustainable revenue**, as all fees are held/swapped into ATOM ## Project Scope 1. **Solidity ICS-721 Bridge Contract** 2. **Front-end Toolkit** for seamless transfer flows 3. **12-month Operations**: node hosting, monitoring, DevOps 4. **Security Audit & Remediation** Ark has production experience deploying CW-based NFT modules on Injective, Juno, Neutron, Osmosis, Stargaze, Terra - and contributed heavily to the core [cw-ics721](https://github.com/public-awesome/cw-ics721/graphs/contributors) and [cw-nfts](https://github.com/public-awesome/cw-nfts/graphs/contributors) repos. ## Budget & Milestones (Total: $200 000 / 47 600 ATOM) | Phase | Amount (USD) | ATOM | Deliverable | | ------------------ | -----------: | -----: | :--------------------------------------------- | | **1) Development** | $ 90 000 | 21 429 | Architecture & Solidity ICS-721 implementation | | **2) Operations** | $ 60 000 | 14 286 | 12 mo support: hosting, monitoring, DevOps | | **3) Audit** | $ 50 000 | 11 905 | Third-party security audit + remediation | *Funds are released in three tranches upon Dev Start, Testnet Deployment, and Mainnet Launch.* ## Treasury & Oversight All funds will be managed by the **Ark Oversight DAO** Members & signers: * Sistla (OmniFlix + StreamSwap): cosmos1nqchg6qytz6mvq85r6adsuaghfwnczex9hs02m * Zerk (Mad Scientists): cosmos1pwha5a3hr55wmmur2d4fm0p8rf7q62wn2rvzw8 * Johnny Wyles (Osmosis): cosmos1dplx2zw3mjk5lam6fnv5q2yxldcshs3wh2rhh9 * David Goose (Osmosis): cosmos1ky9hyqhdxygkkyvjcdd76qceq7t9syy488rsjm * Tatsen (Ark Protocol): cosmos1trghmhd4d9qcf9d0lsyesxzj3aasqg9slykml5 * Mr T (Ark Protocol): cosmos1vtpt9kwjywm3xpake4v8sjmh2uxqq57h499qa5 > Full discussion: > [Bridging Worlds: Empowering Cosmos with an Ethereum NFT Bridge](https://forum.cosmos.network/t/bridging-worlds-empowering-cosmos-with-an-ethereum-nft-bridge/15691) ## Conclusion Approving this proposal will: * Bootstrap a robust, audited NFT bridge for CosmosEVM * Deepen on-chain NFT use-cases and liquidity for ATOM * Generate ongoing value and revenue accrual in ATOM We appreciate the community's support in uniting Cosmos and Ethereum's NFT ecosystems.

## Background This upgrade fixes a bug that was found in the `x/distribution` module where a malicious deposit into the Validator Rewards pool would result in an integer overflow that would cause a chain halt. You can read the full security advisory [here](https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-p22h-3m2v-cmgh). Gaia v25.1.0 is a minor release that will follow the regular governance process for software upgrades on the Cosmos Hub. Reminder – This proposal will have a voting period of just **ONE WEEK**. If the proposal passes, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal. ## Release Details **We are targeting the upgrade for Thursday July 17th.** - The release candidate can be found [here](https://github.com/cosmos/gaia/releases/tag/v25.1.0). A final release will be cut after testing completes on testnet. - The changelog can be found [here](https://github.com/cosmos/gaia/blob/v25.1.0/CHANGELOG.md). The release bumps the following dependencies: - Bump [github.com/cosmos/cosmos-sdk](https://github.com/cosmos/cosmos-sdk) from 0.53.2 to 0.53.3 ([#3827](https://github.com/cosmos/gaia/pull/3827)) **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade-height is reached.** ## Testing and Testnets The v25.1.0 release has gone through rigorous testing, including e2e tests, and integration tests by Interchain Labs. In addition, the upgrade process has been independently tested by the team at Hypha Co-op and has been performed by validators and node operators on a public testnet prior to going on-chain. If you wish to participate in the testnet upgrade process in the future, you can find the relevant information (genesis file, peers, etc.) to join the Cosmos Hub's Interchain Security Testnet (provider) [here](https://github.com/cosmos/testnets/tree/master/interchain-security). ### Potential risk factors As with any major upgrade, there always exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors, even though extensive testing and simulation has been completed. In the case of serious problems, validators should stop operating the network immediately. Coordination with validators will happen in the [#cosmos-hub-validators-verified](https://discord.com/channels/669268347736686612/798937713474142229) channel of the Cosmos Network Discord to create and execute a contingency plan. Likely this will be an emergency release with fixes or the recommendation to consider the upgrade aborted and revert back to the previous release of Gaia (v25.0.0). ### Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should upgrade to v25.1.0. NO - You disagree that the Cosmos Hub should upgrade to v25.1.0. NO WITH VETO - A 'NoWithVeto' vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of 'NoWithVeto' votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

## Background This upgrade unforks Gaia from the Cosmos SDK while upgrading from version 0.50.13 to 0.53.0. This significantly reduces technical debt and eases future development. Gaia v25.0.0 is a major release that will follow the regular governance process for software upgrades on the Cosmos Hub. Reminder – This proposal will have a voting period of just **ONE WEEK**. If the proposal passes, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal. ## Release Details **We are targeting the upgrade for Wednesday July 2nd.** * The release candidate can be found [here](https://github.com/cosmos/gaia/releases/tag/v25.0.0). * The changelog can be found [here](https://github.com/cosmos/gaia/blob/main/CHANGELOG.md). The release bumps the following dependencies: * Bump [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.53.0](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.53.0) * Bump [wasmvm](https://github.com/CosmWasm/wasmvm) to [v2.2.4](https://github.com/CosmWasm/wasmvm/releases/tag/v2.2.4) * Bump [wasmd](https://github.com/CosmWasm/wasmd) to [v0.60.1](https://github.com/CosmWasm/wasmd/releases/tag/v0.60.1) **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade-height is reached.** **Please note that the `--x-crisis-skip-assert-invariants` flag has been deprecated and the node will not start with it in place. Make sure you are not using this flag before you start a v25 node.** ## Testing and Testnets The v25.0.0 release has gone through rigorous testing, including e2e tests, and integration tests by Interchain Labs. In addition, the upgrade process has been independently tested by the team at Hypha Co-op and has been performed by validators and node operators on a public testnet prior to going on-chain. If you wish to participate in the testnet upgrade process in the future, you can find the relevant information (genesis file, peers, etc.) to join the Cosmos Hub’s Interchain Security Testnet (provider) [here](https://github.com/cosmos/testnets/tree/master/interchain-security). ## Potential risk factors As with any major upgrade, there always exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors, even though extensive testing and simulation has been completed. In the case of serious problems, validators should stop operating the network immediately. Coordination with validators will happen in the [#cosmos-hub-validators-verified channel](https://discord.com/channels/669268347736686612/798937713474142229) of the Cosmos Network Discord to create and execute a contingency plan. Likely this will be an emergency release with fixes or the recommendation to consider the upgrade aborted and revert back to the previous release of Gaia (v24.0.0). ## Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should upgrade to v25.0.0. NO - You disagree that the Cosmos Hub should upgrade to v25.0.0. NO WITH VETO - A 'NoWithVeto' vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of 'NoWithVeto' votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

This proposal requests Cosmos Hub community approval to whitelist the following wallet for smart contract deployment by BackBone Labs: Deployment Wallet[cosmos1js483tqdkcpp8yg6u648vt4a5wzq4gv86p26cn5xx76esxqrvreqk6mw8h](daodao.zone/dao/cosmos1js483tqdkcpp8yg6u648vt4a5wzq4gv86p26cn5xx76esxqrvreqk6mw8h/home) We seek permission to deploy our suite of products, including: A capital-efficient NFT marketplace A liquid staking platform for bATOM A decentralized exchange (DEX)BackBone Labs is asking for deployment access—nothing more. No funding, no grants, no emissions. We come to contribute. About BackBone Labs BackBone Labs is a Cosmos-native infrastructure team operating across Osmosis, Injective, Terra, Dungeon, and Chihuahua. Our work fuses DeFi primitives with NFT infrastructure to create composable systems governed by their communities. More information on our forum post: https://forum.cosmos.network/t/whitelist-wallet-for-the-deployment-of-nft-marketplace-lst-platform-and-dex-by-backbone-labs/15513

## Background This upgrade changes the LSM module to a refactored `x/liquid` module, which has been audited by Zellic. Docs for the module are available [here](https://github.com/cosmos/gaia/blob/main/x/liquid/README.md). This work is needed to get the Hub unforked from the SDK, which would reduce our technical debt and ease future development. After the migration in this upgrade, we can complete the unforking in Gaia v25, targeted for mid / late June. Gaia v24.0.0 is a major release that will follow the regular governance process for software upgrades on the Cosmos Hub. Reminder – This proposal will have a voting period of just **ONE WEEK**. If the proposal passes, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal. ## Release Details - The release candidate can be found [here](https://github.com/cosmos/gaia/releases/tag/v24.0.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/main/CHANGELOG.md). ### DEPENDENCIES * Bump [http-proxy-middleware](https://github.com/chimurai/http-proxy-middleware) from 2.0.6 to 2.0.9 ([#3710](https://github.com/cosmos/gaia/pull/3710)) * Bump [golang.org/x/crypto](https://github.com/golang/crypto) from 0.32.0 to 0.35.0 ([#3709](https://github.com/cosmos/gaia/pull/3709)) * Bump [golang.org/x/crypto](https://github.com/golang/crypto) from 0.32.0 to 0.35.0 ([#3708](https://github.com/cosmos/gaia/pull/3708)) * Bump `@docusaurus/core` from 2.4.3 to 3.7.0 ([#3693](https://github.com/cosmos/gaia/pull/3693)) * Bump `@docusaurus/plugin-client-redirects` from 2.4.3 to 3.7.0 ([#3693](https://github.com/cosmos/gaia/pull/3693)) * Bump `@docusaurus/plugin-google-analytics` from 2.4.3 to 3.7.0 ([#3693](https://github.com/cosmos/gaia/pull/3693)) * Bump `@docusaurus/plugin-google-gtag` from 2.4.3 to 3.7.0 ([#3693](https://github.com/cosmos/gaia/pull/3693)) * Bump `@react` from 17.0.2 to 18.0.0 ([#3693](https://github.com/cosmos/gaia/pull/3693)) * Bump `@react-dom` from 17.0.2 to 18.0.0 ([#3693](https://github.com/cosmos/gaia/pull/3693)) * Bump `@mdx-js/react` from 1.6.22 to 3.0.0 ([#3693](https://github.com/cosmos/gaia/pull/3693)) * Bump [cosmossdk.io/store](https://github.com/cosmos/cosmos-sdk) from 1.1.1 to 1.1.2 ([#3687](https://github.com/cosmos/gaia/pull/3687)) * Bump [image-size](https://github.com/image-size/image-size) from 1.1.1 to 1.2.1 ([#3684](https://github.com/cosmos/gaia/pull/3684)) * Bump [cosmossdk.io/math](https://github.com/cosmos/cosmos-sdk) from 1.5.0 to 1.5.1 ([#3682](https://github.com/cosmos/gaia/pull/3682)) * Bump [cosmossdk.io/log](https://github.com/cosmos/cosmos-sdk) from 1.5.0 to 1.5.1 ([#3681](https://github.com/cosmos/gaia/pull/3681)) * Bump [cosmossdk.io/errors](https://github.com/cosmos/cosmos-sdk) from 1.0.1 to 1.0.2 ([#3680](https://github.com/cosmos/gaia/pull/3680)) * Bump [github.com/spf13/viper](https://github.com/spf13/viper) from 1.19.0 to 1.20.0 ([#3651](https://github.com/cosmos/gaia/pull/3651)) * Bump [github.com/cosmos/ibc-go/](https://github.com/cosmos/ibc-go) from 10.0.0 to 10.1.0 ([#3650](https://github.com/cosmos/gaia/pull/3650)) * Bump [golang.org/x/net](https://github.com/golang/net) from 0.34.0 to 0.36.0 ([#3639](https://github.com/cosmos/gaia/pull/3639)) * Bump [github.com/prometheus/client_golang](https://github.com/prometheus/client_golang) from 1.20.5 to 1.21.0 ([#3548](https://github.com/cosmos/gaia/pull/3548)) ### FEATURES * Add x/liquid module ([#3712](https://github.com/cosmos/gaia/pull/3712)) * Remove expedited gov prop type restrictions ([#3723](https://github.com/cosmos/gaia/pull/3723)) * Add liquid validator query to x/liquid ([#3735](https://github.com/cosmos/gaia/pull/3735)) ### BUG-FIXES * Set x/liquid params during InitGenesis ([#3759](https://github.com/cosmos/gaia/pull/3759)) ### STATE BREAKING * Add x/liquid module ([#3712](https://github.com/cosmos/gaia/pull/3712)) **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade-height is reached.** ## Testing and Testnets The v24.0.0 release has gone through rigorous testing, including e2e tests, and integration tests by Interchain Labs. In addition, the upgrade process will be independently tested by the team at Hypha Co-op and will be performed by validators and node operators on a public testnet prior to cutting the final release. If you wish to participate in the testnet upgrade process in the future, you can find the relevant information (genesis file, peers, etc.) to join the Cosmos Hub’s Interchain Security Testnet (provider) [here](https://github.com/cosmos/testnets/tree/master/interchain-security). ### Potential risk factors As with any major upgrade, there always exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors, even though extensive testing and simulation has been completed. In the case of serious problems, validators should stop operating the network immediately. Coordination with validators will happen in the [#cosmos-hub-validators-verified](https://discord.com/channels/669268347736686612/798937713474142229) channel of the Cosmos Network Discord to create and execute a contingency plan. Likely this will be an emergency release with fixes or the recommendation to consider the upgrade aborted and revert back to the previous release of Gaia (v23.3.0). ### Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should upgrade to v24.0.0. NO - You disagree that the Cosmos Hub should upgrade to v24.0.0. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

This proposal will update the expired client on channel-645 between cosmoshub-4 and the realionetwork_3301-1 networks. In turn, this will allow users to transfer funds from Realio to Cosmos and vice versa.

## Context The current relevant governance parameters on the Hub are: ``` expedited_voting_period: 604800s // 168h (7 days) voting_period: 1209600s // 336h (14 days) ``` * [Prop 926](https://www.mintscan.io/cosmos/proposals/926) (passed on June 17, 2024) signalled overwhelming support for the use of 7-day-voting expedited proposals for software upgrades. * [Conversation around prop 926](https://forum.cosmos.network/t/proposal-926-voting-signaling-proposal-expedite-software-upgrade-proposals/13869) suggested support for an even shorter voting period. * [A forum discussion](https://forum.cosmos.network/t/proposal-draft-decrease-standard-voting-period-on-the-cosmos-hub/15013) in January 2025 suggested reducing the standard voting period to 7 days. * **Limitations** * The expedited voting period must be less than the voting period. * There are no gov params to set a separate **quorum** for expedited proposals. * There is a gov param to set a separate **threshold** (% of YES votes out of total votes necessary to pass the proposal) for expedited proposals. * Only software upgrade and cancel upgrade proposals are eligible to be expedited on the Hub. This is Hub-specific and can be changed in the gaia code in a future upgrade if we want. ## Proposal * Reduce the Hub’s `standard voting_period` to 7 days. * Reduce the Hub’s `expedited_voting_period` to 3 days. ## Rationale **Reducing the standard voting period to 7 days** * The Hub has had a 14 day voting period for years and has often struggled to reach 40% quorum on proposals without dedicated outreach from the proposal maker to validators via Telegram and other off-chain coordination platforms. * The norm for the Hub is to have at least 7 days of discussion on the forum, meaning that a proposal generally takes at least 3 weeks to progress from being posted to being passed (or rejected 🙃). * Expedited proposals with a 7 day voting period have been used on the Hub for software upgrade proposals since July 2024, with dedicated outreach and reminders from the proposal makers to reach quorum. * As of [prop 992](https://www.mintscan.io/cosmos/proposals/992) (March 2025), the Hub has proven itself capable of passing proposals in 7 days with only standard communications from the mainnet coordination team (one email, one Discord announcement). **Reducing the expedited voting period to 3 days** * No one likes doing manual halt height upgrades - they’re stressful, risky, and painful to coordinate and execute. * Using governance to set the halt height is the simplest and fastest patch solution - it doesn’t require any code contributions or new features (though Hypha and ICL will also be pursuing other solutions - please stay tuned for our retrospective on the last emergency upgrade). * 3 days is the fastest the Hub has ever been able to coordinate emergency action, so shifting that 3 days into an expedited proposal instead of communications makes sense and doesn’t represent a change in the actual time necessary for an emergency upgrade. ## Responsibility to revert back to old params Hypha will take responsibility for monitoring Hub governance and putting up a param change proposal to revert back to 7-day expedited and 14-day standard voting period if either of the following conditions are met in the 6 months after this proposal passes: 1. A different solution is deployed which allows for a 3 day emergency upgrades and 7 day planned upgrades, and 14 day non-upgrade governance OR 2. More than 10% of “real” non-software proposals fail to meet quorum (e.g., not spam, not proposals where validators mindfully chose not to vote). Hypha's commitment is to solely to put up the proposal and work to bring it to quorum. We make no commitment to campaign either for a YES or NO vote, but will exercise our best judgement at the time of the proposal. ## Governance votes The following items summarize the voting options and what it means for this proposal: * YES - You support reducing the Hub’s voting period to 7 days and expedited voting period to 3 days. * NO - You do not support reducing the Hub’s voting period to 7 days and expedited voting period to 3 days. * NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. * ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

## Summary * The `v23.3.0` upgrade patches a high-severity security issue. This issue poses no loss of funds risk. * This proposal has the expedited flag enabled and will have a voting period of just **ONE WEEK**. * If the proposal passes, validators will be required to update the Cosmos Hub binary at the specified upgrade height. ## Release Details * The release can be found [here](https://github.com/cosmos/gaia/releases/tag/v23.3.0). * The changelog can be found [here](https://github.com/cosmos/gaia/blob/main/CHANGELOG.md#v2330). This release adds no major features. **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade-height is reached.** ### Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should be updated with this release. NO - You disagree that the Cosmos Hub should be updated with this release. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

*Authors*: [Atom Accelerator DAO & Oversight Committee](https://www.atomaccelerator.com/) ## Summary This `param-change` proposal aims to revert the `community_tax` parameter from 10% (0.10) to 2% (0.02), reinstating the baseline default rate that was in effect prior to [**Proposal 88**](https://www.mintscan.io/cosmos/proposals/88/). ## Parameter Change The proposed change affects the "distribution module" in the Cosmos SDK. **Parameter**: `community_tax` `community_tax`: Defines the percentage of block rewards (including transaction fees and inflation rewards) that is allocated to the Community Pool before the remainder is distributed to validators and delegators. The `community_tax` has these key characteristics: * The value must be greater than 0 and less than or equal to 1.00 (100%). * The default value is set to 0.02 (2%) in the distribution module's default parameters. * Cosmos Hub governance can adjust this parameter through on-chain `param-change` proposals. **Parameter and Proposed Value** | Module | Parameter | Current Value | Proposed Value | |----------------|----------------|----------------|----------------| | `x/distribution` | `community_tax` | 0.10 (10%) | 0.02 (2%) | *If the parameter is set to*: 0.02 → 2% of minted rewards go to the Community Pool 0.10 → 10% of minted rewards go to the Community Pool ## Background [**Proposal 88**](https://www.mintscan.io/cosmos/proposals/88/) raised the community tax from 2% to 10% to enable long-term funding of the **Atom Accelerator DAO (AADAO)** and similar initiatives. This tax increase facilitated allocations of 588,000 ATOM via [**Proposal 95**](https://www.mintscan.io/cosmos/proposals/95/), and an additional 975,811 ATOM (plus 100,000 bonus ATOM) via [**Proposal 865**](https://www.mintscan.io/cosmos/proposals/865/). As of Q1 2025, AADAO has entered "maintenance mode" and has declined to renew or revise its mandate; the conditions that warranted the 10% tax rate increase have become obsolete. ## Rationale for Reversion to 2% 1. **The Circumstances That Justified the Tax Rate Increase Are No Longer Valid** As the AADAO's funding mandate approaches its end, the basis for sustaining a 10% tax rate has ceased to be relevant. 2. **Avoid Capital Oversupply and Misallocation** An excessive buildup of idle capital can attract value-extractive or poorly scoped spending proposals. 3. **Decouple Tax Policy from Broader Governance Discussions** The Community Pool tax rate should reflect the network's actual operational needs, not serve as a default placeholder for unresolved Treasury discussions or opportunistic funding demands. 4. **Preserve Hub Autonomy with Fiscal Discipline** A 2% tax rate maintains a credibly decentralized funding stream while keeping governance of the Hub's public resources **independent**, **sovereign**, **manageable** and **reasonable**. 5. **Return More to Stakers** Assuming ~9.6 ATOM minted per block and ~4.36 million blocks/year: - Reducing the tax from 10% to 2% returns **0.768 ATOM per block** to stakers. - This results in approximately **3.34 million additional ATOM/year** in staking rewards. ## **Clarification on Scope** This proposal **does not eliminate or reduce** existing Community Pool funds, which currently hold, approximately 9.37 million ATOM. Decisions concerning the **active balance**, **use**, **governance structure**, or **potential reforms** of the Community Pool should be addressed through subsequent and separate governance proposals. ## **Conclusion** Reducing the community tax rate to 2% is a prudent adjustment in the absence of an active, governance-ratified funding mandate or mandates for the Cosmos Hub. This parameter change helps mitigate inadvertent capital accumulation, improves validator and staker economics, and strengthens fiscal discipline, while preserving the Hub's ability to fund public goods and services independently of its founding organizations and core teams. It also sets a more appropriate baseline to guide future governance discussions concerning long-term treasury management and strategic capital deployment from the Community Pool. ## Links * [**Cosmos Hub Forum Discussions**](https://forum.cosmos.network/t/proposal-draft-reverse-proposal-88-revert-community-pool-tax-rate-to-2/15397) * [**Cosmos SDK `x/distribution` module Documents**](https://docs.cosmos.network/main/build/modules/distribution) ## **Voting Options** - **YES** – Supports the proposed parameter change, reducing the Community Pool tax rate to 2%. - **NO** – Opposes the proposed parameter change, supports maintaining the Community Pool tax rate at 10%. - **ABSTAIN** – Chooses not to take a position, due to a conflict of interest or a wish to participate without expressing a preference. - **NO WITH VETO** – Opposes the proposed parameter change on the grounds it is (1) irrelevant to the Cosmos Hub, (2) malicious and or unjustly harms minority interests, or (3) violates Cosmos Hub governance rules and or norms.

## Proposal On May 7th, Ethereum has a hard fork, the Pectra upgrade, which introduces changes that require the current Ethereum light client to be migrated to function with this hard fork. This proposal upgrades the Cosmos Hub chain binary with a migrated Ethereum light client that will function with the new hard fork by providing the block height that the client will transition to the consensus mechanism used in the Pectra fork. ## Motivation IBC Eureka launched on the Hub before a block height was provided for the Pectra fork, hence the Ethereum light client could not be instantiated with the block height of the hard fork already specified. Without a migration, when the hard fork takes place, the IBC connection between Ethereum and the Hub would be suspended, as the Ethereum light client will freeze. Therefore this migration is necessary to avoid downtime, and maintain the connection’s liveness. **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade-height is reached.** ## Governance votes The following items summarize the voting options and what it means for this proposal: **YES** - You support upgrading the Ethereum light client to support the Pectra hard fork and keep the Ethereum <> Hub IBC connection live. **NO** - You do not support upgrading the Ethereum light client to support the Pectra hard fork, and want the Ethereum light client to freeze, causing IBC downtime. **NO WITH VETO** - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. **ABSTAIN** - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

# Change neutron-1’s consumer chain phase to STOPPED ## Context * [Proposal 993](https://www.mintscan.io/cosmos/proposals/993) signalled the Hub's acceptance of Neutron ending the provider-consumer relationship established by[ Proposal 792](https://www.mintscan.io/cosmos/proposals/792) and [Proposal 72](https://www.mintscan.io/cosmos/proposals/72). * `neutron-1` has already transitioned to a fully sovereign chain, separate from the Cosmos Hub. The validator sets are no longer connected, and Hub validators are not able to run Neutron as a consumer chain. * The Hub’s provider module still shows Neutron as a consumer chain (`gaiad query provider list-consumer-chains` returns a chain with chain_id `neutron-1`, consumer_id `0`, and phase `CONSUMER_PHASE_LAUNCHED`). * Validators formerly required or opted-in to running Neutron as a consumer chain still see Neutron listed when they check `gaiad query provider has-to-validate <valcon address>` . * `neutron-1` is no longer able to send an infraction message to the Hub because they are no longer a consumer chain, and consumer_id is unique and assigned by the provider module so it cannot be reused by a new chain. * There is no direct risk from retaining the `neutron-1` consumer chain record. * It is confusing for mainnet queries to return inaccurate information. ## Proposal * This proposal, if passed, will update Neutron's consumer chain record in the Hub to mark it as stopped. * The `neutron-1` chain will show up after a `list-consumer-chains` query with phase `CONSUMER_PHASE_STOPPED`. * Validators will no longer see it in their has-to-validate query. ## Testing This offboarding process has been tested by Hypha on the provider testnet. * `pion-1` graduated to being a sovereign testnet on March 27, 2025. * Governance proposal to remove pion-1 as a consumer chain[ here](https://explorer.polypore.xyz/provider/gov/256). * `pion-1` shows up after a `list-consumer-chains` query with phase `CONSUMER_PHASE_STOPPED`. * Validators no longer see it in their has-to-validate query. ## Governance votes The following items summarize the voting options and what it means for this proposal: * YES - You support changing `neutron-1`'s consumer chain record phase to STOPPED. * NO - You do not support changing `neutron-1`'s consumer chain record phase to STOPPED. * NO WITH VETO - A 'NoWithVeto' vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of 'NoWithVeto' votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. * ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

### Overview - Support Neutron’s graduation to a sovereign network with strong synergies with the Hub - Allocate community pool NTRN fairly to support the network’s migration and the adoption of on-chain use cases for ATOM and Hub-related assets - Signal support for the development of differentiated and complementary on-chain ecosystems on Neutron and the Hub - Enable continued collaboration to drive the adoption of ATOM, Neutron, and the Hub’s interchain services See the sister proposal on the Neutron forum here: https://forum.neutron.org/t/mercury-towards-the-integrated-endgame/393 If this proposal is approved by Cosmos Hub governance, the Neutron Foundation has committed to return 50,000 ATOM received as part of [Proposal 72](https://forum.cosmos.network/t/proposal-72-accepted-bringing-liquid-staking-and-defi-to-the-cosmos-hub-with-interchain-security/6623) to the Cosmos Hub Community Pool. ### Graduation to a Sovereign Network This proposal signals support for Neutron's graduation to a fully sovereign network via the Mercury upgrade. From a technical point of view, the migration does not require any code changes on the Cosmos Hub side. Once completed, it will enable the removal of the Replicated Security and Top-N code from the Cosmos Hub binary. Partial Set Security will remain a feature of the Cosmos Hub. The graduation process will require a Neutron network upgrade, dubbed Mercury, which will be scheduled via [a sister proposal](https://forum.neutron.org/t/mercury-towards-the-integrated-endgame/393) to the Neutron DAO. To ensure a smooth migration, Cosmos Hub validators must continue to validate the Neutron network until the Mercury upgrade (scheduled for the 9th of April) is completed and the core teams confirm that the validator set transition has occurred properly. This will ensure that IBC channels are properly migrated and continue to operate smoothly, safeguarding user funds and protocols across the Interchain. This proposal allocates 1M NTRN to Cosmos Hub validators as a reward for their continued service over the coming weeks to perform the network's transition. The distribution of the rewards will occur after the upgrade is complete and will be coordinated by the Joint Committee (see below). Rewards will be conditioned upon maintaining > 95% uptime for both block production and price updates and successfully carrying out the migration. Additionally, this proposal allocates 10.8M NTRN to fund the security budget of the network for the next 2 years and enable the continued payment of the post-migration validator set, composed of leading Cosmos Hub validators: *CryptoCrew, Quokka Stake, Allnodes, Chorus One, cosmosrescue, Cosmostation, Crosnest, Golden Ratio Staking, Hadron Labs, Informal Systems, iqlusion, Kiln, P2P, Polkachu, POSTHUMAN, Provalidator, SG-1, Smart Stake, Stake&Relax, Stakecito.* On-going validator set curation with be carried out by the Neutron DAO and Drop protocol. Additionally, the collection of validator performance data is being finalized by Numia, and Slinky Beta incentives will be distributed shortly, as planned in [Proposal 931](https://forum.cosmos.network/t/proposal-931-slinky-beta-proposal/13931). ### New Rewards & Opportunities for ATOM on Neutron This proposal allocates 4,272,795 NTRN to the adoption of ATOM and Cosmos Hub products on Neutron. These tokens will be distributed to ATOM token holders who participate in DeFi on Neutron via dedicated campaigns around ATOM use cases, including liquid staking, liquidity provisioning, lending, borrowing, using ATOM and its derivatives as collateral to trade perpetual futures, tributes, and more. Once this proposal is executed, the Neutron Foundation (NF) will coordinate with ecosystem protocols to coordinate on-chain campaigns, and NTRN budgets will be allocated by the Joint Committee (see below). These campaigns will provide ATOM holders with new opportunities to use ATOM in DeFi and earn outsized rewards. ### Return Excess Tokens to the Neutron DAO This proposal allocates ~53% of the NTRN currently held in the Cosmos Hub community pool to be distributed to ATOM token holders and validators. The remaining ~47% will be transferred back to the Neutron DAO to fund the continued growth of the network and its ecosystem. ### Return [Prop 72](https://forum.cosmos.network/t/proposal-72-accepted-bringing-liquid-staking-and-defi-to-the-cosmos-hub-with-interchain-security/6623) ATOM to the Cosmos Hub Community Pool 50,000 ATOM were granted by the Cosmos Hub to contributors of the Neutron Project as part of [Proposal 72](https://forum.cosmos.network/t/proposal-72-accepted-bringing-liquid-staking-and-defi-to-the-cosmos-hub-with-interchain-security/6623) and later transferred to the Neutron Foundation as part of [Proposal 819](https://forum.cosmos.network/t/proposal-819-approved-re-allocate-prop-72-funding-from-p2p-to-neutron/11087). The Neutron Foundation never sold ATOM. Instead, it liquid staked its holdings with Stride, then with Drop to support the adoption of ATOM liquid staking. In the spirit of fairness, if this proposal is adopted by Cosmos Hub governance, the Neutron Foundation commits to returning the 50,000 ATOM to the Cosmos Hub Community Pool. ### Continued Collaboration This proposal lays the foundation for the continued collaboration of the Neutron and Cosmos Hub teams and communities to create on-chain use cases and demand for the ATOM token and the Cosmos Hub’s products: - The NF has developed deep knowledge and expertise in ecosystem bootstrapping and will be supporting Interchain Labs’ (ICL) efforts to bootstrap a native ecosystem of new, exciting protocols in and around ATOM and the Cosmos Hub. - The continued growth of the Neutron ecosystem will drive demand for ATOM and the Cosmos Hub’s bridging, routing, and solving products, driving value to the Cosmos Hub and the ATOM token. - The NF and ICL teams will collaborate to drive the adoption and growth of the Cosmos developer community, accelerating the growth of both networks. # Implementation --- ### NTRN Allocations The Cosmos Hub Community Pool received 42,727,950 unclaimed tokens from Neutron’s airdrop. The proposed allocations only concern the airdropped tokens and are summarized below for clarity: | Item | Amount | % | Destination | | --- | --- | --- | --- | | Existing programs | 2,160,000 | 5.06% | Already distributed. | | Migration coverage | 1,000,000 | 2.34% | Joint committee | | Security budget | 10,800,000 | 25.28% | Joint committee | | ATOM incentives | 4,272,795 | 10.00% | Joint committee | | Future partnerships | 4,272,795 | 10.00% | Joint committee | | Neutron DAO | 20,222,360 | 47.33% | Joint committee | | Total | 42,727,950 | 100.00% | NA | ### Joint Committee This proposal transfers 40,567,950 NTRN from the Cosmos Hub to an Joint Committee made of representatives from both the Cosmos Hub and Neutron communities. Upon the receipt of the NTRN tokens, the committee will allocate the tokens according to the allocations above. - 20,222,360 NTRN will be returned to the Neutron DAO - 10,800,000 NTRN will be transferred to the validator payment module - 9,545,590 NTRN will be retained in the committee’s treasury to fund ATOM/Cosmos Hub-related campaigns on Neutron as well as the continued collaboration of the network communities. The Joint Committee is a 3/4 multisig on the Cosmos Hub and Neutron networks, which commands the allocation of NTRN tokens received from the Cosmos Hub community pool and is composed of the following representatives from the Neutron and Cosmos Hub community: | Signer | Role | Address | | --- | --- | --- | | Travis | Cosmos Hub Community Representative | cosmos1hpqgpfsrkqawzjjgql47rrrvkqrry49sxpda7q | | @agent.kwosh | Cosmos Hub Community Representative | cosmos1945wsvenrnc6vu0p588jswpc56pv27l3kp0aae | | @luisqa | Neutron contributor | cosmos1ze09kc5ackut7wc4pf38lysu45kfz3ms86w3em | | @Spaydh | Neutron contributor | cosmos1nu7h4xj3em8mr0huh7906qdv89fnxclr7jy8wy | The multisig addresses are the following: - Cosmos Hub: cosmos1fl657t883v2l3s953qngd26wn49v8eddygw9rc44v5ms0cxfwk4qddhuhx - Neutron: neutron1gxwkypgj884n2gswk3km0ck5js36eqewgx94lxv0pw45w0q6utrsgj4u50 # Allocations breakdown ### **Honor Existing Commitments (Connect Beta + Validator Incentives)** Validator Incentives that have already been allocated to vesting contracts are slated to fully vest on March 26th, 2025. Connect incentives remain to be distributed. We are finalizing work with Numia to provide the data required to check the validator’s performance and distribute the rewards. Once that is done, we will coordinate with the prop 931 committee signers to execute the transfer. ### **Fund Validator Operations Leading Up to Migration** Since the migration’s success relies on smooth validator operations, we propose to allocate an additional 1M NTRN to be distributed to validators pro-rata their voting power based on the following criteria: - ≥ 50% participation on the last 10 Cosmos Hub proposals - ≥ 95% block uptime on Neutron over the past 3 months, looking back from migration time - ≥ 95% Slinky uptime on Neutron over the past 3 months, looking back from migration time - Properly carry out the migration upgrade ### **Fund Neutron’s Security Budget Following Migration** To migrate from ICS, Neutron will need to bootstrap a sovereign validator set and fund its operations. Most/all of this set will be inherited from the best/most aligned Cosmos Hub validators. Tokens will be allocated to the Base Comp mechanism to cover validator costs for the first 24 months of the network’s operations as an independent blockchain. ### **Fund ATOM-related Campaigns on Neutron** To sponsor the continued alignment of the projects and their communities, ~4M NTRN will be reserved for incentives/campaigns tailored to the Cosmos Hub’s assets and community. - Liquidity incentives to ATOM, dATOM, and other Cosmos Hub assets - Incentives to cover the opportunity cost of converting from native staking to liquid staking - ATOM spot and perps trading campaigns - Other ATOM-aligned campaigns ### **Allocation for Future Joint Ventures** Tokens earmarked to support future joint ventures benefiting both ecosystems, such as supporting the growth and adoption of Cosmos, joint hacker houses and hackathons, etc. ### **Return Excess to the Neutron DAO** The remainder will be returned to the Neutron DAO Treasury. # Governance votes The following items summarize the voting options and what it means for this proposal: **YES** - You support Neutron’s migration to a sovereign network, the proposed allocation of Community Pool NTRN, and the return of 50K ATOM from [Proposal 72](https://forum.cosmos.network/t/proposal-72-accepted-bringing-liquid-staking-and-defi-to-the-cosmos-hub-with-interchain-security/6623) to the Cosmos Hub Community Pool. **NO** - You disagree Neutron’s migration to a sovereign network and/or the proposed allocation of Community Pool NTRN. **NO WITH VETO** - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. **ABSTAIN** - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

## Background Gaia v23 is a major release that will follow the standard governance process for software upgrades on the Cosmos Hub. Feedback on this proposal will be open for roughly 1 week. Reminder – the Cosmos Hub uses expedited voting for software upgrade proposals. This proposal will have a voting period of just **ONE WEEK**. If the proposal passes, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal. ## Release Details **We are targeting the upgrade for Wednesday, March 26th**. After the upgrade Interchain Labs will upload the Eureka contracts and officially launch the Eureka product later in March. - The release can be found [here](https://github.com/cosmos/gaia/releases/tag/v23.0.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/v23.0.0/CHANGELOG.md). This release includes an upgrade to [IBC v2](https://ibcprotocol.dev/blog/ibc-v2-announcement), which is needed for the [launch of the **IBC Eureka product**.](https://x.com/cosmoshub/status/1897229986706415952) This will allow the Cosmos Hub to connect to Ethereum mainnet over IBC in an affordable and secure manner. In the future, we plan to connect IBC Eureka, and thus the Hub to Solana and to Layer 2s such as Arbitrum and Base. The release bumps the following dependencies: * [ibc-go](https://github.com/cosmos/ibc-go) to [v10.1.0](https://github.com/cosmos/ibc-go/tree/v10.1.0) * [ibc-apps/modules/rate-limiting](https://github.com/cosmos/ibc-apps/tree/main/modules/rate-limiting) to [v10.0.0](https://github.com/cosmos/ibc-apps/tree/modules/rate-limiting/v10.0.0) * [ibc-apps/middleware/packet-forward-middleware](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware) to [v10.0.0](https://github.com/cosmos/ibc-apps/tree/middleware/packet-forward-middleware/v10.0.0) * [ibc-go/modules/light-clients/08-wasm](https://github.com/cosmos/ibc-go/tree/main/modules/light-clients/08-wasm) to [v10.0.0](https://github.com/cosmos/ibc-go/tree/modules/light-clients/08-wasm/v10.0.0) * [interchain-security](https://github.com/cosmos/interchain-security) to [v7.0.0](https://github.com/cosmos/interchain-security/tree/v7.0.0) **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade-height is reached.** ### Additional note: The WASM light client for Ethereum will not be ready before this proposal goes on-chain. In order to prevent an additional upgrade to be needed, we're adding an Authz permission to the v23 upgrade in order to allow `cosmos1raa4kyx5ypz75qqk3566c6slx2mw3qzs5ps5du` to upload (but not modify!) the light client. The specific message being granted is `/ibc.lightclients.wasm.v1.MsgStoreCode` ## Testing and Testnets The v23 release has gone through rigorous testing, including e2e tests, and integration tests by Interchain Labs. In addition, the v23 upgrade process has been independently tested by the team at Hypha Co-op and has been performed by validators and node operators on a public testnet prior to cutting the final release. If you wish to participate in the testnet upgrade process in the future, you can find the relevant information (genesis file, peers, etc.) to join the Cosmos Hub’s Interchain Security Testnet (provider) [here](https://github.com/cosmos/testnets/tree/master/interchain-security). ### Potential risk factors As with any major upgrade, there always exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors, even though extensive testing and simulation has been completed. In the case of serious problems, validators should stop operating the network immediately. Coordination with validators will happen in the [#cosmos-hub-validators-verified](https://discord.com/channels/669268347736686612/798937713474142229) channel of the Cosmos Network Discord to create and execute a contingency plan. Likely this will be an emergency release with fixes or the recommendation to consider the upgrade aborted and revert back to the previous release of gaia (v22.3.1). ### Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should launch IBC Eureka and be upgraded with this release. NO - You disagree that the Cosmos Hub should launch IBC Eureka and be updated with this release. NO WITH VETO - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

## Summary This proposal aims to allocate excess USDC from the Cosmos Hub community pool into Hydro, a decentralized liquidity management platform on Cosmos, to optimize treasury utilization and generate additional yield. By leveraging Hydro’s structured liquidity deployment mechanism, the Hub can explore new financial strategies, earn tributes and rewards, and establish a framework for effective stablecoin management within the ecosystem. Currently, the community pool holds **57,530.40 USDC**, which remains idle. Rather than leaving these assets unused, we propose deploying them in Hydro’s decentralized bidding system, where various DeFi protocols compete for liquidity through incentive-based mechanisms. This will provide the Hub with valuable experience in managing stablecoins and ensuring that more assets within the community pool are working to benefit the ecosystem and ultimately, **ATOM holders**. ## Background The Cosmos Hub community pool primarily consists of **ATOM and NTRN**, alongside a smaller allocation of **USDC**. While ATOM has been successfully deployed in DeFi applications offering use cases such as AMM liquidity provisioning, lending, and perpetual protocols, the **USDC remains unused**. Hydro has established itself as a decentralized, voting-based liquidity management platform, where DeFi protocols compete for liquidity through **token-based or point-based tributes**. This structure ensures that the liquidity is allocated optimally to generate the highest returns and utility for the Hub. Hydro is a decentralized liquidity management platform that facilitates: - **Bidding-based liquidity distribution:** DeFi protocols bid for Hydro liquidity and offer token-based or point-based tributes in return. - **Voting mechanisms:** ATOM holders lock their ATOM on Hydro to vote on liquidity distribution. - **Proven track record:** Hydro has successfully completed three rounds of liquidity deployment with over **10 participating bidders**, including **Nolus, Mars, Drop, Demex, Neptune Finance, Shade, Stride, White Whale, Phoenix Directive, Marginated, Inter Protocol, and Amulet**. ## Proposal Details ### Objective The primary objective of this proposal is to deploy **57,530 USDC** currently in the community pool into **Hydro** to: - Generate yield from tributes and rewards. - Enhance treasury diversification strategies by utilizing non-ATOM assets in DeFi. - Prepare for potential future stablecoin holdings in the Hub’s treasury. ### Implementation Plan 1. **Transfer the 57,530 USDC to the Hydro committee's address: cosmos1hj9zuecf0xcjhx8ttcrwd9pmee25xe2plglgcpfk2kjjveet3zyq9nellq** to be used for Hydro's liquidity allocation system. 2. **Engage in the Hydro bidding process**, allowing protocols to compete for the Hub’s liquidity. Notably, **Nolus** has expressed a clear interest in acquiring more USDC for their stablecoin lending pools, which in recent months have experienced a **surge in utilization levels, often exceeding 90%**. This increased demand has resulted in lenders receiving **consistent real yield at approximately 14% APY**. Given this strong demand and sustainable returns, Nolus presents itself as a promising recipient of USDC liquidity through Hydro. 3. **Monitor and assess returns** generated through tributes and rewards. 4. **Provide the community with a post-deployment report** on performance, feasibility, and lessons learned. ### Benefits to Hub - **Tribute generation:** The Cosmos Hub holders who participate in Hydro get an additional yield on their staked ATOM - so far the additional Hydro APR has been around **10%**. - **Yield Generation:** Idle USDC will be put to work, earning rewards from various DeFi protocols. - **Treasury Diversification:** This initiative will provide insights into managing stablecoin assets in the community pool, making the Cosmos Hub **better positioned to handle a scenario** where the pool holds a greater proportion of stablecoins. - **Leverage Existing Expertise:** Hydro has an **established governance framework** and experience in liquidity management, reducing the risk of inefficient deployment. ## Notes - **This is not a request to deploy the USDC directly to Nolus** or any other interested protocol: if this proposal passes, the custody of the **USDC would be transferred to the Hydro committee**, and many Cosmos projects (including Nolus) would be able to bid on it for the benefit of the Cosmos Hub. - **This is not a funding request for the development of the Hydro protocol:** The Hydro team and the Hydro grant program were **funded for the next 6 months via Prop 986**. The USDC would remain in the **custody of the Hydro committee** and can be returned in full to the Cosmos Hub community pool **at any time in the future**. ## Conclusion Deploying the **stale USDC** from the Cosmos Hub community pool through **Hydro** presents an opportunity to generate **passive yield within a secure risk framework** and explore **innovative treasury management strategies**. By leveraging Hydro’s platform, the Cosmos Hub can take a significant step toward **sustainable treasury growth while maintaining security and decentralization**. ## Governance - **Yes:** You approve the transfer of **57,530 USDC** from the community pool to the Hydro committee for deployment into Cosmos DeFi via the Hydro protocol. - **No:** You do not approve that transfer. - **No with Veto:** You indicate that this proposal either (1) is deemed to be **spam**, i.e., irrelevant to Cosmos Hub, (2) **disproportionately infringes on minority interests**, or (3) **violates or encourages violation of the rules of engagement** as currently set out by Cosmos Hub. - **Abstain:** You wish to contribute to the **quorum**, but you decline to vote either for or against.

TL;DR - In order to enable Skip:Go functionality on the Hub and support the expansion of IBC Eureka, Interchain Labs (ICL) is requesting to be allowed to upload CosmWasm (CW) contracts to the Hub without seeking governance approval for subsequent uploads. This dramatically improves the Hub feature development cycle and reduces the burden on validators and users as we can upgrade our software without halting the chain. You can find the Skip:Go contract repo [here](https://github.com/skip-mev/skip-go-cosmwasm-contracts). The motivations and procedures for using this right are detailed below. ## Motivation Deploying Skip:Go contracts will dramatically improve bridging UX as it enables the following: - Use of the Skip:Go API so that user intents can be solved - Faster-than-finality transfers through our solver network (under 30 seconds) - Usage of the Skip:Go widget for smooth deposits and withdrawals As we are expanding IBC to Ethereum & beyond and want the Hub to play a significant role as the router to all networks outside of Cosmos, having these contracts on the Hub will be required in order for us to successfully expand IBC in an ATOM-aligned way. **Skip:Go is currently processing over 50% of all IBC traffic**. It's been integrated into dYdX and it powers all swaps on your Keplr and Leap wallets, among many other integrations. Previously, Skip has been granted the same access on other chains as well, including [Osmosis](https://www.mintscan.io/osmosis/proposals/555), Stride, Pryzm. They've also deployed these contracts permissionlessly on Sei, Injective, Neutron and various other chains. ## Future Deployments As we aim to decrease the burden on validators and hope to streamline future development on the Hub, Interchain Labs would like to use this access to be able to deploy new contract-based products and services for the Hub after the community accepts a signaling proposal for each one. This is instead of adding these products and services to the Gaia binary. Ideally we'd be able to deploy bug fixes, quality of life improvements & minor features without a 2-3 week governance process. This will significantly improve development cycles because: - There are no chain upgrades or halts needed for upgrading CW contracts - We can deploy fixes and improvements faster without having to go through governance, allowing a more iterative product approach - We can keep the Hub lean and safe by keeping non-critical software outside of the Gaia binary **Please note**: we will continue to seek governance approval for any new products or major changes we intend to deploy in the form of a **Signaling Proposal**. This current proposal is *not* a request to give ICL unfettered control over new feature launches on the Hub. Access can be revoked at any point in time through governance. The address for allowlist access is `cosmos1raa4kyx5ypz75qqk3566c6slx2mw3qzs5ps5du` **Additional note**: the transaction includes two additional addresses, these are the previously allowlisted addresses in proposal [982](https://www.mintscan.io/cosmos/proposals/982) (Ark Protocol) and [944](https://www.mintscan.io/cosmos/proposals/944) (DAO DAO). This is a required step due to how parameter changes for CosmWasm work. ### **Governance votes** The following items summarize the voting options and what it means for this proposal: **YES** - You agree that Interchain Labs should be allowed to upload contracts **NO** - You disagree that Interchain Labs should be allowed to upload contracts **NO WITH VETO** - A 'NoWithVeto' vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of 'NoWithVeto' votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. **ABSTAIN** - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

# Proposal: Community Pool Spend - StarShuffler\n\n## Summary\nI am requesting **3300 $ATOM** to build the smart-contract, relayer, and frontend for a ZK dApp for the Cosmos Hub. It will be called **StarShuffler**.\n\n## Details\nThis proposal would cover:\n- Creating the smart contract.\n- Developing a minimal frontend (FE) to interact with the contract.\n- Building a relayer.\n- Making the FE and relayer deployable as a Docker container for self-hosting or Akash deployments for privacy.\n\nThe milestone completion time will vary depending on the permissionless CosmWasm Hub integration timeline, which is assumed to occur mid-year. I initially asked for the funds to be proxied by the new hub leadership, but due to the sensitivity of the project’s development, the request was politely declined. However, @mag does know my identity and we have had calls, so my progress can be tracked independent of an endorsement.\n\n## Milestones\n1. **Create working MVP on Juno mainnet (or testnet):**\nDevelop a working MVP that includes a functional frontend, relayer, and smart contract. This milestone is contingent upon demonstrating a successful deposit and withdrawal, along with making the code open-source.\n*Estimated timeline:* 2 months.\n\n2. **Porting the smart contract to $ATOM:**\nPort the smart contract over to $ATOM and instantiate it. \n*Estimated timeline:* 2 weeks post permissionless CosmWasm integration onto the Hub.\n3. **Integrate multi-amount pools:**\nAdd support for multi-amount pools (e.g., 100 & 1000 ATOM).\n*Estimated timeline:* 2 weeks post milestone #2.\n\nThis effort will produce a usable app for the Hub and is relatively low-cost.\n\nI am currently designing the contract as feeless. The relayer deployment will have the option for fees for sustainability if community members want to run relayers. Having a feeless contract is motivated by both liability concerns and personal ethics.\n\n*Note on Audits:*\nAudits are where the serious money comes into play; I have been quoted upwards of **20k** for simple audits. Therefore, I have no current plans to contract an audit, and an audit would only be conducted with community support at a later time.\n\n## Recipient\ncosmos145q97pk7hsu6zzsqtkjttlnpk90h9g6y3wzhn3\n\n## Further Discussion\nThe full forum discussions (3) are all linked [here](https://forum.cosmos.network/t/community-pool-spending-proposal-for-starshuffler/15165).

## **Background** Gaia v22.2.0 is a minor state breaking release that will follow an accelerated governance process for software upgrades on the Cosmos Hub. This is a state breaking security fix, which is why a forum post has been skipped. Reminder – the Cosmos Hub uses expedited voting for software upgrade proposals. This proposal will have a voting period of just **ONE WEEK**. If the proposal passes, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal. ## **Release Details** - The release page can be found [here](https://github.com/cosmos/gaia/releases/tag/v22.2.0). - The changelog can be found [here](https://github.com/cosmos/gaia/blob/v22.2.0/CHANGELOG.md). The release bumps the following dependencies: - Bump [ibc-apps/middleware/packet-forward-middleware](https://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware) to [v8.1.1](https://github.com/cosmos/ibc-apps/releases/tag/middleware%2Fpacket-forward-middleware%2Fv8.1.1) ([#3534](https://github.com/cosmos/gaia/pull/3534)) - Add `v22.2.0` upgrade handler ([#3538](https://github.com/cosmos/gaia/pull/3538)) **This is a state breaking upgrade!** ## **Testing and Testnets** The v22.2.0 release has gone through rigorous testing, including e2e tests, and integration tests by Interchain Labs. In addition, the v22.2.0 upgrade process has been independently tested by the team at Hypha Co-op. If additional issues are found while this proposal is on-chain, we will communicate our intention to cancel the upgrade proposal. ### **Potential risk factors** Although extensive testing and simulation will have taken place there always exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors. In the case of serious problems, validators should stop operating the network immediately. Coordination with validators will happen in the [#cosmos-hub-validators-verified](https://discord.com/channels/669268347736686612/798937713474142229) channel of the Cosmos Network Discord to create and execute a contingency plan. Likely this will be an emergency release with fixes. ### **Governance votes** The following items summarize the voting options and what it means for this proposal: **YES** - You agree that the Cosmos Hub should be updated with this release. **NO** - You disagree that the Cosmos Hub should be updated with this release. **NO WITH VETO** - A 'NoWithVeto' vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of 'NoWithVeto' votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. **ABSTAIN** - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

## Background Gaia v22 is a major release that will follow the standard governance process for software upgrades on the Cosmos Hub. Feedback on this proposal will be open for roughly 1 week. Reminder – the Cosmos Hub uses expedited voting for software upgrade proposals. This proposal will have a voting period of just **ONE WEEK**. If the proposal passes, validators will be required to update the Cosmos Hub binary at the halt-height specified in the on-chain proposal. ## Release Details * The release candidate can be found[ here](https://github.com/cosmos/gaia/releases/tag/v22.0.0). * The changelog can be found[ here](https://github.com/cosmos/gaia/blob/v22.0.0/CHANGELOG.md). This release adds no major features. The release bumps the following dependencies: * Bump [ibc-go](https://github.com/cosmos/ibc-go) to [v8.5.2](https://github.com/cosmos/ibc-go/releases/tag/v8.5.2) ([#3370](https://github.com/cosmos/gaia/pull/3370)) * Bump [cometbft](https://github.com/cometbft/cometbft) to [v0.38.15](https://github.com/cometbft/cometbft/releases/tag/v0.38.15) ([#3370](https://github.com/cosmos/gaia/pull/3370)) * Bump [cosmos-sdk](https://github.com/cosmos/cosmos-sdk) to [v0.50.11-lsm](https://github.com/cosmos/cosmos-sdk/releases/tag/v0.50.11-lsm) ([#3454](https://github.com/cosmos/gaia/pull/3454)) * Bump [wasmd](https://github.com/CosmWasm/wasmd) to [v0.53.2](https://github.com/CosmWasm/wasmd/releases/tag/v0.53.2) ([#3459](https://github.com/cosmos/gaia/pull/3459)) * Bump [ICS](https://github.com/cosmos/interchain-security) to [v6.4.0](https://github.com/cosmos/interchain-security/releases/tag/v6.4.0). ([#3474](https://github.com/cosmos/gaia/pull/3474)) **This upgrade is state-breaking and mandatory once the on-chain vote passes and the upgrade-height is reached.** ## Testing and Testnets The v22 release has gone through rigorous testing, including e2e tests, and integration tests by Informal Systems. In addition, the v22 upgrade process has been independently tested by the team at Hypha Co-op and has been performed by validators and node operators on a public testnet prior to cutting the final release. If you wish to participate in the testnet upgrade process in the future, you can find the relevant information (genesis file, peers, etc.) to join the Cosmos Hub's Interchain Security Testnet (provider) [here](https://github.com/cosmos/testnets/tree/master/interchain-security). ### Potential risk factors Although extensive testing and simulation will have taken place there always exists a risk that the Cosmos Hub might experience problems due to potential bugs or errors. In the case of serious problems, validators should stop operating the network immediately. Coordination with validators will happen in the[ #cosmos-hub-validators-verified](https://discord.com/channels/669268347736686612/798937713474142229) channel of the Cosmos Network Discord to create and execute a contingency plan. Likely this will be an emergency release with fixes or the recommendation to consider the upgrade aborted and revert back to the previous release of gaia (v21.0.1). ### Governance votes The following items summarize the voting options and what it means for this proposal: YES - You agree that the Cosmos Hub should be updated with this release. NO - You disagree that the Cosmos Hub should be updated with this release. NO WITH VETO - A 'NoWithVeto' vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of 'NoWithVeto' votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. ABSTAIN - You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

## Note This proposal supersedes [Prop #984](https://www.mintscan.io/cosmos/proposals/984), which doesn't include the requested amount of ATOM and won’t transfer any funds when executed (see the transaction hash of the proposal creation [here](https://www.mintscan.io/cosmos/tx/0488ADC4956A52C8220127CE79E3C72FCEA42D602C6250FB348AF2D2EA1A2D8A)). Therefore, we recommend to cast a Yes vote on Prop #984 (which won't execute anyway), as well as this proposal. ## Introduction In November 2023, the [Cosmos Hub funded Informal Systems for 2024](https://www.mintscan.io/cosmos/proposals/839). The Informal Hub team eliminated the Hub’s technical debt and shipped two products: - [Forge](https://forge.cosmos.network/) as a way to permissionlessly launch a chain, solving all the pain points of the past versions of ICS and making it possible for the Hub's validators to run it in a few clicks. - [Hydro](https://hydro.cosmos.network/) as the first decentralized market-maker. Hydro allocates liquidity through sequential auction rounds in which projects attract user votes with tributes Through this process, it became obvious that [the Hub needed consolidated leadership](https://forum.cosmos.network/t/cosmos-hub-informal-systems/) to realize its full potential and Informal recruited one of the best teams in the Interchain to take up [the product ownership role](https://medium.com/the-interchain-foundation/cosmos-is-expanding-skip-joins-the-interchain-foundation-cfd346551dda). Although Informal’s Hub 2024 mandate officially ends on 31-Dec, with the recent success of the first pilot rounds, the Skip team asked the Hydro team to keep developing the product in 2025. Since the Informal Hub team is under budget in Q4 2024 (see the breakdown in the Funding & reporting section - the Informal Hub team was also under budget in Q1 & Q2 2024 and [returned these funds](https://x.com/informalinc/status/1830971210479607996) to the community pool), this proposal requests community approval to fund Hydro product development and some Hydro-focused grants for the first two quarters of 2025 by giving Informal a green light to re-assign [the excess Q4 2024](https://forum.cosmos.network/t/informal-hub-team-q4-24-retro/15024#p-34603-financial-transparency-reporting-10) budget to Hydro and approving the transfer of an additional 180,000 ATOM from the community pool. In addition, since we believe that Hydro could be partly self-funded in the second half of 2025, we’re requesting community approval to send Hydro’s PoL profits to an account collectively owned by Hydro’s voters but placed under the control of the Cosmos Hub community (see the Hydro Treasury section for details). ## Hydro Roadmap The Hydro litepaper was published in [late May-2024](https://forum.cosmos.network/t/atom-wars-introducing-the-hydro-auction-platform/) and the inaugural pilot round started on [6-Nov](https://x.com/cosmoshub/status/1854234305909956717). To date, 10 projects have submitted bids and 8 third-party teams have also expressed interest in building DeFi apps on top of Hydro. The round 1 cap was reached within 24 hours and the round 2 cap in less than 4 minutes. In the last couple of months, the Hydro team has also worked on several major updates: - **Custom deployment duration**: Projects can set their own export duration and voters can lock-in a fixed APR over several rounds without having to vote every time. - **Custom export floor**: Projects can set a minimum PoL target. If their bid doesn’t get sufficient support to reach that target, their tribute is refunded. - **Metrics page**: The position size, status and performance of each PoL deployment is tracked and displayed on a dedicated page. - **Rewards page**: Voters can see their tribute rewards and personalized APRs (current & past rounds). They can claim and automatically swap tokens to ATOM. - **Airdrops page**: Voters can see a list of upcoming airdrops for Hydro participants, and projects can easily access relevant data. The custom deployment duration and custom export floor are critical for making Hydro more widely useful to larger projects. However, Hydro is still far from a finished product. - It relies on a committee for risk management, whitelisting & performance monitoring. - The incentive alignment between voters & the community pool is relatively weak. The goal is to make Hydro a fully permissionless, automated, risk-minimizing & profit-maximizing system for efficient treasury management on a public blockchain. Hydro should be able to operate like Aave, Compound, or Curve: risk parameter approvals via governance votes, allocations via the auction system, and automatic deployments. Over the first 6 months of 2025, the Hydro team plans to work on the following features: | Feature | Description | | -------- | -------- | | Third-party integrations | Vote optimizers, automated hedging contracts, insurance premium or escrow contracts can be built on top of Hydro to enable new cases | | Valence integration | The Hub retains ownership of Hydro’s liquidity, making the committee less of a bottleneck and increasing the overall security & efficiency of the system. | | Token integrations | Hydro can be used for the deployment of new tokens ( NTRN, TIA, stables etc.), and projects can submit atomic bids to get both sides of an LP pair | | Rev-sharing & penalities | Voters get a portion of the PoL yield. A portion of the users' locked capital gets slashed when they vote for a project that underperforms. | | Hydro governance | Hydro users can vote on governance proposals to define all of the protocol parameters and elect or remove committee members | | Staking interface | Hydro users can stake, delegate, re-delegate, claim, swap and compound rewards directly from the Hydro interface | | “Just-in-time” liquidity | Hydro provides insurance against liquidity crunches by ensuring that buckets can be deployed quickly to stabilize a position or market. | Note that this is a working backlog that will be re-prioritized based on market signals and community feedback. ## Budget ### Product development The Informal Hub team in 2024 consisted of 14 people, split between Forge, Hydro and Hub maintenance. For 2025, we believe it is possible to achieve our Hydro objectives with a reduced team of 6 Full-Time Equivalent staff: 1 Project Lead, 1 Technical Lead, 1 Product Lead, 2 Developers & 1 Growth Lead. We will use the same per-head total rate averages of $325K per year, which includes approximately $225K in salary (and relevant overhead such as employer taxes and benefits) and a standard margin to pay for operational expenses like legal, HR, finance as well as some profit buffer for the company. Like last year, these rates are aligned with the mid-point of market software development rates ($110-$220/hour) The entire overhead margin will be paid out in ATOMs for alignment purposes. In addition, our proposal will not include any performance bonus (Informal & Hypha 2024 proposal did). See the FAQ section for more details on these decisions. ### Hydro grants To become a fully permissionless & automated protocol, Hydro requires several DeFi & security integrations. While Hydro's core team itself could develop all the necessary features over time, a better option to achieve this goal as fast and cost-efficiently as possible is to enable other third-party teams to build products on top of Hydro. | Category | Budget | | -------- | -------- | | Vote optimizers | Vote aggregators are smart contract applications that abstract the complexities of voting away from users, give them the benefits of long-term locking, provide them with a tradable liquid derivative, compete for maximal returns, etc. | | Delta-neutral deployments | Automated strategies are required to avoid exposing the Hub deployments to impermanent loss. Hydro’s bidders can implement a delta-neutral strategy with a real-time adjustment mechanism via smart contracts, insurance, or over-collateralization | | Permissionless deployments | The Hub retains direct ownership of the liquidity, progressively reducing the need for the Hydro committee to manually deploy funds, enabling shorter and more competitive rounds, and increasing the system's overall security. | | Security | Third-party audits for the features developed by the Hydro product team. Security monitoring, threat detection system, and bug-bounty program for finding and reporting vulnerabilities on PoL venues. | Over the past couple of weeks, the Hydro team has been helping several Cosmos projects submit well-scoped grant proposals to the AADAO so their applications can be processed before the [end of the program](https://forum.cosmos.network/t/sunsetting-atom-accelerator-dao-aadao/). However, new teams / existing grantees are likely to step forward with other ideas during the coming months, and the Hydro team may also try to outsource “nice-to-have” features and support work (relaying, infrastructure, community) to external partners. For that reason, the proposal includes a $350,000 budget to manage an ecosystem fund that will support the initiatives listed in the table below (each item is a rough estimate and the final distribution may look significantly different). All outgoing transactions will be managed on-chain via DAO DAO and labeled for transparency. | Initiative | Budget | Amount | | -------- | -------- | -------- | | Hydro committee | ~$90/h for six members for 6 months, 5-10h per member per month (adjusted up or down based on individual time commitment) | $40,000 | | Vote optimizers | ~$30,000 for smart contract development or audits for two separate teams (adjusted up or down based on a statement of work) | $60,000 | | Automated hedging | ~$30,000 for the smart contract development or audits (adjusted up or down based on a statement of work) | $30,000 | | Insurance premiums | ~$30,000 for the smart contract development or audits (adjusted up or down based on a statement of work) | $30,000 | | Valence integration | ~ $50,000 for a first integration of Valence into Hydro (adjusted up or down based on the exact scope) | $50,000 | | Data services | ~ $20,000 for the tracking of PoL deployments & rewards (adjusted up or down based on development & indexing costs) | $20,000 | | Security audits | ~ $25,000 per audit & 1 per quarter from a reputable firm (adjusted up or down based on the exact scope) | $50,000 | | Bug bounties | ~ $10,000 per bug submission for up to five security issues during a six-month period | $50,000 | | Miscellaneous | ~ $20,000 for IBC relaying, security monitoring, infrastructure costs, software licenses and other miscellaneous expenses | $20,000 | Note that the Hydro team submitted a $350,000 grant application to the AADAO, which was downsized to $75,000. The amount has been discounted from the ask (see Funding section below). ## Hydro treasury The rewards generated by the Hub’s PoL deployments are currently in the custody of the Hydro committee. The Hydro product team is planning to build out a governance module and equip it with the ability to hold and manage funds. The purpose of the Hydro treasury is two-fold: - Ability to deploy the rewards via Hydro - Ability to fund development teams The Hydro treasury transforms Hydro into a self-funded project and may eliminate the need for more community pool requests to the Hub community pool. The treasury would remain under the control of the Cosmos Hub via two mechanisms to be built into Hydro governance: - The ability for the Hub governance to veto any Hydro prop via an expedited proposal - The ability for the Hub governance to send the Hydro treasury to the community pool If this proposal passes, the Hydro product team will transfer pre-Hydro and pilot rounds PoL rewards to a new public DAO on DAO DAO and start building the Hydro governance module and treasury. The DAO will initially be controlled by the product team and ownership will be transferred to Hydro’s governance as soon as it is technically possible. ## Funding & reporting ### Proposal request In its [2024 funding proposal](https://www.mintscan.io/cosmos/proposals/839), the Informal Hub team planned for a total team of 14 full-time equivalents (FTE) per quarter: - In Q1 & Q2, the team was under budget and [returned funds](https://x.com/informalinc/status/1830971210479607996) to the community pool - In Q3, the team worked at full capacity to ship Forge & Hydro. - In Q4, the team was under budget again, using [only 10 FTE resources](https://forum.cosmos.network/t/informal-hub-team-q4-24-retro/15024#p-34603-financial-transparency-reporting-10). The [excess budget](https://forum.cosmos.network/t/informal-hub-team-q4-24-retro/15024#p-34603-financial-transparency-reporting-10) represented by 4 FTE in Q4 is $225,714 USDC and 10,214.29 ATOM. We suggest assigning this funding to cover Hydro product development in the first half of 2025. Assuming 1 ATOM is worth $6.5 (and rounding conversion numbers), the breakdown is the following: | Budget line | In USD | In ATOM | | -------- | -------- | -------- | | Hydro Team | $975,000 | 150,000 | | Hydro Grants | $350,000 | 55,000 | | Reassigned 2024 funding | $-290,000 | -45,000 | | Temporary 20% buffer | $207,000 | 31,000 | | AADAO grant | $-75,000 | -11,000 | | **Total** | $1,167,000 | 180,000 | The funding request amount includes a 20% buffer to hedge against ATOM price movement (both for the reassigned Q4 2024 funding and the new 2025 funding): - If the ATOM price is exactly the same at the time of the Q1 & Q2 transfers as when the prop went up for voting, the entire 20% buffer will be sent to the Hydro treasury - If the ATOM price **decreases** less than 20%, the buffer will be used to cover the difference. If the ATOM price **increases**, the extra will be sent to the Hydro treasury. - If the ATOM price goes down more than 20%, the Hydro product team will request the difference to be covered by the Hydro treasury (see the description below). ### Sequence of events Funding will be distributed on the following schedule: | Date | Action | | -------- | -------- | | On 24-Jan | The total ask (including buffer) of 180,000 ATOMs is transferred from the community pool to the [Hydro Team DAO](https://daodao.zone/dao/cosmos1jskgwzken05wjflz2f92hn3apa0pql6nxtj947dtlqwrkk88q8pq35gtq5/home) | | On 25-Jan | The Hydro Team converts the relevant number of ATOM into 975,000 * 70% + 275,000 - 290,000 = 667,500 USDC and sends 275,000 USDC to the [Hydro Grants DAO](https://daodao.zone/dao/cosmos1stxad87r0c9x9skn5ap6eyx9wwmj5xuqcpd3n974qpg5stv92sqqj2zrh4/members) | | Before 24-Jun | The Hydro Team and Hydro Grants DAOs send all excess USDC & ATOM funds (including buffer) to the Hydro Treasury | A new separate entity will receive the distributed funds. This new company (name & domicile to be determined) will be created specifically for Hydro product development. As a company, Informal Systems will be focusing on engineering services, security audits and public good development for devcos and foundations with clear service agreements. Undistributed funds can be clawed back via a proposal submitted by any community member (the tooling introduced by [Prop 972](https://www.mintscan.io/cosmos/proposals/972) could be used). Assuming funds are not clawed back before, all excess budget shall be sent to the Hydro Treasury at the end of the mandate. ### Reporting A quarterly progress report will be shared on the Cosmos Hub forum by the Hydro development team, using the same format as the reporting done by the Informal Hub team (see [Q1 2024](https://forum.cosmos.network/t/informal-systems-q1-24-retro-q2-24-plan/13749), [Q2 2024](https://forum.cosmos.network/t/informal-hub-team-q2-24-retro-q3-24-plan/14158), [Q3 2024](https://forum.cosmos.network/t/informal-hub-team-q3-24-retro-q4-24-plan/14684), [Q4 2024](https://forum.cosmos.network/t/informal-hub-team-q4-24-retro/15024/1)). ## Governance votes **Yes**: You approve the allocation of Informal Systems excess Q4 budget and an additional 180,000 ATOM from the community pool towards Hydro product development and integrations, and you approve the transfer of Hydro’s PoL rewards to the Hydro Treasury. **No**: You do not approve the suggested budget allocation and / or the transfer of Hydro’s PoL rewards to the Hydro Treasury. **No with Veto**: You indicate that this proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub. **Abstain**: You wish to contribute to the quorum, but you decline to vote either for or against.

# Fund testnets and mainnet ops by Hypha in 2025 ## Summary The Hub testnets team at Hypha Worker Co-operative is seeking funding to continue their mandate of stewarding the Hub's testnet, supporting mainnet operations, and development support and onboarding for the incoming Hub team at Interchain Inc. This proposal is summarized by the following propositions: * The approval of a $650,000 USD budget to finance Hypha's: * Stewardship of the Hub's provider testnet as a dev platform and validator training program * Mainnet coordination for upgrades and validators * Coordination around bug fixes, security patches, and version updates for core technologies * Mainnet ICS support for the Hub's current and prospective consumer chains * Validation testing for core stack integrations and new features * Testing and development support for patches and version update releases * Onboarding and transition support for Skip/Interchain Inc. * The release of the following funds to a Hypha-controlled wallet (cosmos1ax7krw2ymq8upaxwce7df3xpalpp0jddm29fws): * 200k USDC (shown in the spend proposal details as 200,000,000,000 IBC-wrapped uusdc) * 86,538.46 ATOM (accounting for 69,230.77 ATOM at a spot price of \$6.5 USD with a 25\% buffer to cover price fluctuations) to be converted to \$450k USDC via the process laid out in the full text of the proposal * The approval of Hypha's transparency and accountability commitment to the ATOM community: * Quarterly reports made to the Cosmos Hub forum * Quarterly withdrawal reports on community-disbursed funds * An anonymous feedback form and commitment to publicly reviewing and incorporating relevant feedback * Cooperation with the ATOM community if a signalling proposal is passed to return any unused funds * Cooperation with teams chosen by the ATOM community to fulfil other scopes of work or to replace our services on the Hub ## Additional details * [Full proposal text with changelog and discussion (forum post)](https://forum.cosmos.network/t/proposal-last-call-fund-testnets-and-mainnet-ops-by-hypha-in-2025/14929) * [IPFS pin of full text](https://ipfs.io/ipfs/QmbUGTtewn3tVaYjw2ezDtzAC2s7SY2XgNibmAUUZQqC3b) and comments ## Governance votes and outcomes The following items summarize the voting options and what it means for this proposal: * **YES**: You agree to fund the Hub testnets team at Hypha Worker Co-operative with a $650k USD budget for continued testnet stewardship, mainnet coordination, and development support over the period of January 1, 2025 - December 31, 2025. A 'YES' outcome will immediately release 200k USDC and 86,538.46 ATOM to the specified wallet (cosmos1ax7krw2ymq8upaxwce7df3xpalpp0jddm29fws). * **NO**: You do not agree to fund the Hub testnets team at Hypha Worker Co-operative based on the terms of this proposal. * **NO WITH VETO**: A 'NoWithVeto' vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of 'NoWithVeto' votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. * **ABSTAIN**: You wish to contribute to the quorum but you formally decline to vote either for or against the proposal.

This proposal requests community approval to fund Hydro product development and some Hydro-focused grants for the first two quarters of 2025 by giving Informal a green light to re-assign the excess Q4 2024 budget to Hydro and approving the transfer of an additional 180,000 ATOM from the community pool. In addition, since we believe that Hydro could be partly self-funded in the second half of 2025, we're requesting community approval to send Hydro's PoL profits to an account collectively owned by Hydro's voters but placed under the control of the Cosmos Hub community (see the Hydro Treasury section for details). The full funding proposal details and discussion are available on the [Cosmos Hub Forum](https://forum.cosmos.network/t/funding-hydro-development-integrations-in-2025/14900/1). ## Governance votes - **Yes**: You approve the allocation of Informal Systems' excess Q4 budget and an additional 180,000 ATOM from the community pool towards Hydro product development and integrations, and you approve the transfer of Hydro's PoL rewards to the Hydro Treasury. - **No**: You do not approve the suggested budget allocation and / or the transfer of Hydro's PoL rewards to the Hydro Treasury. - **No with Veto**: You indicate that this proposal either (1) is deemed to be spam, i.e., irrelevant to Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub. - **Abstain**: You wish to contribute to the quorum, but you decline to vote either for or against.

[Full Proposal Details on Cosmos Hub Forum](https://forum.cosmos.network/t/signalling-proposal-to-whitelist-the-deployment-of-interchain-nft-contracts/14806) ## Introduction With Prop 981 signaling strong community support, this Parameter Update Proposal authorizes Ark Protocol’s developer wallet to deploy InterChain NFT contracts on the Cosmos Hub. These contracts will enhance security, governance, and interoperability within the Cosmos ecosystem, while facilitating the seamless transfer of NFTs across app chains. The deployment includes initially three components: 1. **NFT Contract (cw721) contracts:** A standardized and secure framework for creating and managing NFTs. 2. **Bridge (ics721) contracts:** A robust interchain NFT bridge for seamless and secure cross-chain transfers. 3. **Launchpad Contracts:** Empowering creators to launch NFTs using the Hub’s governance and security. The contracts aim to establish the Cosmos Hub as a secure base for digital assets while boosting app chains like Stargaze, Osmosis, and Injective by enabling NFT transfers to marketplaces on other chains. ## Driving Value to the Cosmos Hub 1. **Security:** By hosting ICS721-compliant contracts, the Hub ensures the safe storage of digital assets and resilience against vulnerabilities, preventing scenarios like the UST depeg. 2. **Governance:** Integration with **DAODAO** facilitates NFT-based governance models, enabling users to participate in decision-making using NFTs and $ATOM. 3. **Ecosystem Growth:** Supporting creators, builders, and communities through seamless NFT transfers boosts activity and liquidity across app chains. 4. **InterChain Collaboration:** These contracts are a public good for all chains, complementing app chains like Stargaze and fostering interchain growth and utility. ## Security Measures - **Audited Contracts:** Independent audits by **Oak Security** and **SCV Security** validate the robustness of the InterChain NFT contracts. - **DAO Management:** Contracts are governed by **Admin Migration DAO** and **Operations DAO**, ensuring transparency and decentralization. - **Emergency Controls:** Proxy contracts, whitelisting mechanisms, and emergency pause functionality protect the ecosystem from vulnerabilities. ## Acknowledgments We extend our gratitude to **Stargaze**, the main driver of InterChain NFTs. We also thank **AADAO**, Michael Sotto, Shane, Jorge, Zerk, Noah, Zeke, Reece, JG, Hashimoto, Red Phone, Brian, Deploydon, NicsHODLN, whyre, addingbio, Simon, Vlad, Sunny, Jake, DoraHacks, Confio, the Galactic Syndicate, Mad Scientists, Red Planet, BackBone Labs, **Govmos**, SG1, Everstake, Allnodes, and the broader NFT community for their trust and contributions to this initiative. ## Voting Options ### Yes Authorize Ark Protocol’s developer wallet to deploy InterChain NFT contracts on the Cosmos Hub. ### No Do not authorize Ark Protocol’s developer wallet to deploy InterChain NFT contracts on the Cosmos Hub. ### Abstain Contribute to the quorum but formally decline to vote either for or against the proposal. ### NoWithVeto Indicate that this proposal is spam, infringes on minority interests, or violates governance rules. If NoWithVeto votes exceed one-third, the proposal is rejected and deposits are burned. This proposal is a significant step toward securing the Cosmos Hub as a backbone for NFTs, connecting communities, and enhancing app chain collaboration. Join us in shaping the future of interchain NFTs on the Cosmos Hub!

## OVERVIEW This proposal is a revised version of the Cosmos Hub forum post [here](https://forum.cosmos.network/t/signalling-proposal-to-whitelist-the-deployment-of-interchain-nft-contracts/14806). ### SUMMARY After engaging with the community and addressing feedback, we have updated our proposal to align closely with the Cosmos Hub's mission and address concerns raised. Key points include: - **Strong Community Support:** - Validators and community members such as **@Govmos** now support the proposal after clarifications. - **Alignment with the Cosmos Hub's Mission:** - **Security Enhancement:** - Storing NFTs on the Cosmos Hub leverages its robust security to protect valuable assets. - Prevents potential losses like those experienced during the UST depeg on Terra. - **Governance Enhancement:** - Enables advanced governance models through platforms like **DAODAO**. - Allows users to participate more actively using their NFTs and $ATOM holdings. - **Clarification of Intentions:** - **Interchain NFTs as a Public Good:** - Aiming to provide Interchain NFT capabilities to all chains, including the Hub, in a chain-agnostic manner. - Supporting and accelerating the growth of the entire Cosmos ecosystem. - **Complementing Existing Chains:** - **Launch on the Hub, List on Stargaze, Injective, et al:** - Our proposal enables creators to **mint NFTs on the Cosmos Hub** and **list them on marketplaces like Stargaze, BackBone Labs, Talis**, and others. - We intend to enhance the ecosystem by fostering interoperability and collaboration across all chains. - Our goal is to complement existing app chains, not compete with them. - **Security Measures and Risk Mitigation:** - Implementation of robust security measures, including audited contracts and whitelisting mechanisms. - Use of emergency controls to protect the Hub from potential threats. Overall, we have successfully addressed concerns and received strong support. Deploying the Interchain NFT contracts on the Cosmos Hub will enhance both security and governance, aligning with the Hub's mission and benefiting the entire Cosmos ecosystem. ## Proposal Details **We propose to whitelist Ark Protocol’s developer wallet to enable the deployment of Interchain NFT contracts on the Cosmos Hub.** - **Contracts to be Deployed:** - **Interchain Launchpad:** Contracts for minting NFTs on the Cosmos Hub from any chain, allowing creators to reach the entire Cosmos NFT community. - **Interchain Bridge (ICS721):** Contracts for bridging CW721 NFTs between the Cosmos Hub and other chains. - **NFT Contracts:** CW721 contracts for creating NFT collections. - **Whitelisted Developer Wallet:** - **Team Wallet:** `cosmos19pmppgpqnjkvjp6mx8q2dpuy382g4hhxatt9sk` - **Security Measures:** - **Audited Contracts:** Audits conducted by Oak Security and SCV Security. - **DAO Management:** - Admin Migrations DAO - Operations DAO - **Additional Measures:** - Multi-signature mechanisms via DAODAO. - Proxy contracts to enhance security during NFT transfers. - Whitelisting mechanisms to ensure only legitimate collections/channels interact with the bridge. - Emergency controls to pause the bridge and de-whitelist compromised chains/contracts. ## Voting Options - **Yes**: You are in favor of allowing Ark Protocol to deploy the Interchain NFTs CosmWasm smart contracts on the Cosmos Hub. - **No**: You are against allowing Ark Protocol to deploy the Interchain NFTs CosmWasm smart contracts on the Cosmos Hub. - **Abstain**: You wish to contribute to the quorum but formally decline to vote either for or against the proposal. - **No With Veto**: A ‘No With Veto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to the Cosmos Hub, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by Cosmos Hub governance. If the number of ‘No With Veto’ votes is greater than a third of total votes, the proposal is rejected and the deposits are burned. We kindly request the support of the community and validators in voting **Yes** on this proposal to enhance the security and governance of the Cosmos Hub through the deployment of Interchain NFT contracts. Thank you for your time and consideration. **Sincerely,** **The Ark Protocol Team**

Full forum discussions can be found here: https://forum.cosmos.network/t/last-call-proposal-increase-deposit-amount-for-cosmos-hub-governance-to-500-atom/14493

Revive channel-341 to bostrom by replacing expired 07-tendermint-764 client state to the state of client 07-tendermint-1328. This will restore channel-341 functionality. Please ignore prop 975 as it contains the typo in the description.