This is the eighteenth of Hub Weekly Thursday recaps, straight from the Hub Unit team, per the cadence we committed to in the From Chaos to Stability to Growth post.
Every Thursday, we will call out significant Cosmos Hub updates on the forum, with a short companion thread on X, recapping announcements, live events like validator or community calls, and ecosystem updates!
For more info, see the linked posts, and contact @RoboMcGobo on Telegram to submit news for the weekly.
This week: the Hub roadmap update we promised, covering the long-term vision and the interim products we are looking into for building a roadmap, the full story behind September’s two private security patches now that the CosmWasm advisory is public, a high-level look at the tokenomics Phase 2 findings and what comes next, and the Neutron postmortem plus the recovery plan proposal for the ATOM held by the Hub multisig.
-
Hub roadmap update: the long-term vision is the Hub as the retail connection point between traditional finance and onchain finance. Within this vision, we have product ideas we are validating for roadmap build-out
-
CosmWasm vulnerability: CWA-2026-006 is public. The Hub was affected but not exploited, and v28.1.0 and v28.2.0 were the private patches that mitigated and then fixed it. No funds were lost.
-
Tokenomics: Gauntlet’s Phase 2 recommendations are in review, and a wrap-up post with the full report and a timeline is next
-
Neutron recovery: Neutron’s postmortem is live, and the recovery plan proposal for the 1,227,121 ATOM held by the Hub multisig is on the forum for discussion ahead of a Hub governance vote
Hub Roadmap Update: the long-term vision is the Hub as the retail connection point between traditional finance and onchain finance, within this vision, we have two product ideas we are validating for roadmap build-out
The vision, in short
Weekly #12 set the thesis: the Hub as the connection point between traditional finance and onchain finance. Each side wants what the other has and cannot reach it: institutions issue into closed venues, one chain and one distributor at a time; DeFi’s best assets are scattered across chains, each locked where it was issued. Institutions will serve their own clients through their own channels. The opportunity is the open, everyday user side: the place where assets from either side can be accessed, held, combined and moved across chains by anyone with a wallet. That is the Hub’s job, in both directions.
We said then that issuance, distribution, and access were where to start. Since then, the work has been testing that. This is what that work surfaced. It is not the roadmap.
The opportunity: three frictions nobody has removed properly
-
Issuing is expensive and confining. An issuer picks one chain and one venue; every additional chain is a wrapped copy with its own liquidity and risk, usually provided by bridge partners that add friction, limits, fees, and wrapping. The largest tokenized fund took about eight months to reach six chains, each a separate share class. Compliance is repeated at every door, and tokenizers bind each asset to one distributor’s catalog. Result: tokenized real-world assets cover roughly a third of a normal portfolio, mostly large stocks and government bonds; whole asset classes retail uses every day have no onchain version.
-
Access is gated and fragmented. Most institutional tokenized assets require a full identity check just to hold (one leading issuer asks for a EUR 500k portfolio or $1M net worth), and outside the US, EEA and Switzerland there is no lawful local offer from anyone. There are some interesting no-KYC onchain products, but they force you onto one chain and are not equally liquid. Onchain, the yields that stand out from a market compressed to four or five percent are each imprisoned: reinsurance on Ethereum in one pool, GPU financing on Arbitrum with 30-day exits, reinsurance on Solana with monthly-gated redemption, receivables vaults that are KYC-only with no secondary market. Moving between them is the problem. In August we tested the routes: one issuer’s bridge moved $450k a day per asset per direction, shared by all users, in about 20 minutes; another cost roughly ten percent on a $30 transfer and sent us to Discord for size; every path forced a swap, and more. The same move over IBC cost under one percent all-in, with no cap.
-
Nothing is programmable across all of it. Yield attracts capital once the asset can be used: USDe went from zero to $10B and syrupUSDC to $1B in five months once they could be posted as collateral. Tokenized securities cannot be used that way anywhere, and nobody can combine a tokenized fund with an on-chain lending position, non-custodially, into one instrument a holder can carry to any chain. Those with securities machinery cannot run open products; those with open vault infrastructure cannot touch securities; neither owns rails without a bridge vendor in the middle.
The leading idea
It is the product idea the validation work has surfaced as the strongest answer to the three frictions above, and it stays on the table alongside other options until it is validated enough to commit to. We are sharing it now because the roadmap will be better if the ideas are argued in public before they are decided, and because we want to know which parts of it you would use, build on, or run, as in many cases it will require new kinds of participation.
If assets from both sides can be issued onto the Hub or reached over IBC, two things become possible that are not possible anywhere else:
-
Issuance and distribution. An asset is issued once on the Hub and reaches every connected chain from day one, as the same asset rather than a wrapped copy, with no swap, no cap, and no operator holding keys. For an issuer: one register, one policy, every venue. For a holder: from whatever chain you are on, you ask for the asset; it is minted on the Hub and delivered over IBC, and when you are done, it goes back and is retired. No pool to find, no swap, no liquidity to hunt for chain by chain, so small tickets are not eaten by fees and large ones are not blocked by shallow pools. Because anyone can mint and redeem at the asset’s value, the market keeps the price honest for free. That is the difference between an asset that is distributed and one that is merely bridged. The same rail brings on-chain yield from any connected chain to the Hub.
- For example: let’s say you are on Ethereum, and you want an asset the Hub distributes. You request it from the wallet you already use (e.g., metamask). It is minted on the Hub at its value and arrives as the same asset, not a wrapped copy, with no bridge interface, no pool to find, and no cap on size. When you are done, you redeem it the same way.
-
Orchestration. With assets from both worlds running over the same rail, the Hub can turn them into baskets, indices, and vaults that hold positions across several chains and pay a blended yield through one token, exported anywhere IBC goes to be held, traded, or used as collateral. A token holding reinsurance, GPU-financing and receivables yield from three chains cannot be self-assembled anywhere today. Over time, creating such products could open to vetted curators, so the Hub becomes the place assets get composed rather than the party choosing them. This is uncovered territory, at scale, and it benefits from the same issuance rails.
- For example: a single Hub-issued index token that holds, in set proportions, a reinsurance position on Ethereum, a GPU-financing position on Arbitrum, and staked ATOM on the Hub. The token does not rebase; its redemption rate rises as the basket earns, the way a liquid staking token does. You hold it, trade it, or post it as collateral on any IBC-connected chain.
Around these sit different support features: accounting and pricing across chains, an access path that checks identity once at the edge, and non-custodial orchestration on the chains where assets live.
Why we like it.
-
Real fee space, because distribution and liquidity are the expensive parts of this market, and better rails leave more of the fee as margin.
-
It builds on what exists: Eureka as the rail, Skip as the coordinator, the Hub’s role as the ecosystem’s router, the enterprise pillar’s work with institutions. It creates roles for the community: validators as operators of the pricing and relaying of these needs at scale, community capital as the liquidity that makes issuance and redemption fast, curation by the ecosystem’s own managers and protocols.
-
And it sits on top of the tokenomics work rather than fighting it: Phase 2 includes a place for Hub revenue to go and a way for issuance to respond to it, so a product like this can plug into ATOM’s economics without changing them; if it does not win, they are not materially affected.
Also interesting, not leading today as single-handed products.
-
Canonical distribution alone. Moving existing tokenized assets over Eureka because it is cheaper, safer and more composable than the bridges issuers use today. This is real, and it is why IBC wins on cost. But on its own it does not beat an issuer who subsidizes its own liquidity on every chain, and single-issuer distribution is becoming a common pattern on institutional ledgers, so by itself it is not a differentiator. An important piece of the puzzle, and part of the rails above, but probably not the whole product.
-
Direct issuance of institution-grade assets by the Hub itself. Tokenized funds, deposits, and securities issued on the Hub under our own program rather than someone else’s. This is where the vision ends up for us, and it is the version of issuance with the most fee space. TradFi and DeFi assets need to meet for interesting things to happen. But it also needs a regulated legal setup that takes months to stand up and has to be right the first time, which is why it is not where we would start, and why the onchain assets side steps would come first.
One way it could sequence
If the ideas hold, they can be built in an order where each step is a self-contained product that stands on its own, and each one adds a piece the next step needs, so the sequence compounds toward the bigger vision:
-
Rails first. Issuance, distribution over IBC, accounting and pricing across chains, the any-chain no-KYC access path. The most validated part and the foundation for the rest.
-
First Hub-built products, on the DeFi side, reachable today without waiting on TradFi counterparties or regulatory structures. The candidates are a few indices at different risk levels, possibly one including ATOM staking. Those yields exist today, scattered; nowhere can a holder get them as one diversified token. Aggregation would be a product to be issued/distributed over the rail. What you would see: a small number of Hub-issued indices at different risk levels, from blue-chip onchain lending yield to newer sources like reinsurance and private credit, each a single token you can hold anywhere IBC reaches
-
Traditional-finance assets on the same rails. First tokenized stocks, funds, and bonds from specialized tokenizers who hold the underlying and handle compliance once, at issuance, so a security issued on one chain is not stranded there. Later, products issued by institutions themselves, on their own timelines. What you would see: a tokenized bond or equity fund from a specialized tokenizer, issued once, reachable from a Cosmos wallet or DEX without a second identity check, and usable as collateral where protocols accept it
-
Products that need both sides. Baskets holding a tokenized fund next to onchain yield, built by vetted curators on the Hub’s infrastructure. By the time institutional products arrive, the Hub should already be the place their onchain distribution works. We would have a working product to sell them. What you would see: baskets built by vetted curators, for example a tokenized treasury fund paired with onchain credit yield, with a protocol fee to the Hub and a curator fee to the manager
Traditional-finance assets wait on two slow things: the legal structure we need before issuing or distributing regulated assets, and the institutions’ own approvals before their products reach a customer. DeFi-side assets need neither and can be reached today. So we can start there, use that time to build the rails the regulated side will need, and nothing built early would be wasted.
What could still change this, and what defines the shape of the roadmap:
None of this is a roadmap. Any piece can be invalidated or need a setup the Hub or the ecosystem cannot operate under; if so we adapt or drop it, and say so.
What decides it:
-
legal, which structure and jurisdiction, for whom, and what curators may do;
-
technical, how the Hub verifies assets on other chains, which sets architecture and audit scope, and which connections beyond Ethereum are ready;
-
Hub safety, nothing that comes to the Hub may widen its attack surface, and after this September we will take the time to be confident in the structure before anything touches it;
-
cost, what each step costs to build, audit and operate, and what it earns;
-
demand, whether people want this, which is partly what this post is for and if Hub participants would like to be involved in this and find it exciting
We only talk about products we can stand behind, and we only pursue products that meaningfully improve ATOM’s utility. Ideas that fail either test do not make the roadmap, however interesting they are.
The answers to these validation workstreams decide what makes the roadmap and in what order; other options stay open until they do. The roadmap goes through review with the ICF before it is final, and after two months of incidents, getting there will take us a bit more time and the buy-in of the people who run and secure the Hub as we committed to getting feedback early on ideas:
Where the Hub community fits
The roles we see, and want to test with you:
-
Validators as the operators of the pricing, accounting, and relaying that assets held across chains require. That is new fee-earning work for the active set, and the set’s security model is what makes the Hub a credible home for these assets in the first place
-
Cosmos protocols and asset managers as curators of baskets built on the Hub’s infrastructure, under a published methodology and a curator fee
-
Ecosystem venues and DEXs as the places these assets are held, traded, and used as collateral. New opportunities will be created for DEXs to help serve RFQs and host inventory for new and interesting assets. Cosmos users and ATOM holders will also hold an expanded role here as liquidity providers and traders of those assets.
Individuals and organizations who are interested in any of these opportunities should stay tuned on the forums for more details. For validators specifically, make sure you’re joining our monthly validator calls. When these updates are more defined, we plan to share them there.
Where we want your input.
-
Which of the three frictions have you hit yourself, and where does our description miss?
-
What matters more to you: the Hub as where assets are issued and distributed, or where products are built on top of them? Would you prefer the Hub to stay minimal or single-focus, or would we be open to more features coming in?
-
If you run a validator, protocol or fund: is there a role here you would want (pricing, relaying, liquidity, curation)?
-
Which onchain yields or traditional assets would you have reachable through the Hub first?
Reply on the thread for more details rather than responding in telegram. We will address a lot of the replies here directly! We will fold what we hear into the validation work and report back.
CosmWasm Vulnerability: No Funds Were Lost, and Two Private Security Patches Mitigated and Then Fixed It
On Monday, September 28, the CosmWasm team published CWA-2026-006, the public advisory for the vulnerability behind September’s two emergency Hub upgrades after conducting a safe private disclosure period, and that period expiring. We explain what the vulnerability was, how it affected the Hub, and what happened in the weeks between the first notification and the two public patches.
The short version first: the vulnerability was not exploited on the Hub or on any other chain we are aware of, and the vast majority of the CosmWasm ecosystem has mitigated it. The Hub is fully patched as of September 21. Everything below is the account of how that happened.
What the vulnerability was
The advisory describes a sandbox escape in the Wasmer Singlepass compiler, the component wasmvm uses to run CosmWasm contracts. A code generation flaw made it possible for a specially crafted WebAssembly contract to break out of the execution boundary and run native instructions inside the node process. In practice, that meant an attacker could mint tokens (including ATOM) without authorization, and the resulting balances would be indistinguishable from ordinary ones and would survive a node restart.
Exploiting it required storing and instantiating an attacker-controlled contract on the chain. On permissionless CosmWasm chains, no governance approval or privileged access was needed. The issue was rated critical with potential for fund loss.
How it affected the Hub
The Cosmos Hub runs CosmWasm, and the versions of wasmd and wasmvm in production on the Hub were within the affected range. The Hub was exposed but not exploited, and because the same flaw affected every CosmWasm chain, the fix had to be coordinated under a disclosure embargo so that no chain would be left exposed by another chain’s patch becoming public.
That embargo is the reason both Hub patches shipped as private releases with binaries only. Publishing the source for either patch would have disclosed the vulnerability to anyone reading the diff while other chains were still unpatched.
The timeline
-
August 18. The vulnerability was reported to the CosmWasm team
-
September 3. Affected chains, including the Hub, were notified privately, along with an interim mitigation. A full fix was not yet available
-
First week of September: Gaia v28.1.0, the mitigation. Hub validators coordinated an emergency upgrade to apply an interim mitigation, restricting the ability to upload and instantiate new contracts on the Hub, which is the path an attacker would have needed. This was the fastest way to take the exploit off the table before a full fix existed. 179 of 180 active validators upgraded
-
September 16. The private full patch was distributed to affected chains, followed by an updated version addressing a separate liveness bug found during testing
-
September 17 to 21: Gaia v28.2.0, the full fix. The Hub’s full-fix release ran through the Cosmos Hub testnet on September 17 and went to mainnet through Proposal 1055, an expedited 72-hour governance vote. The upgrade executed at height 33,073,000 on Monday, September 21, upgrading the Hub’s wasmvm to the patched version and lifting the interim restrictions
-
September 28. Public disclosure and public patch release from CosmWasm, closing the embargo. By the time the advisory went public, the vast majority of CosmWasm chains had already mitigated or fully patched, which is the outcome a coordinated disclosure is designed to produce. No exploitation has been reported on any chain
One related note: the v28.3.0 binary used to restart the Hub after the Neutron incident on September 23 was also cut as a private release, for the same reason. Nothing in the diff between v28.2.0 and v28.3.0 was sensitive, but publishing the source would have meant publishing the source for v28.1.0 and v28.2.0, which were still under embargo at the time.
All three binaries are now available to build from source here:
v28.1.1 : Release v28.1.1 · cosmos/gaia · GitHub
v28.2.1 : Release v28.2.1 · cosmos/gaia · GitHub
v28.3.1 : Release v28.3.1 · cosmos/gaia · GitHub
What we changed because of it
We covered the process changes in the validator call two weeks ago: every Hub binary now ships with a checksum and GPG signature the moment it is published; the validator contact database has been rebuilt so upgrade notifications reach the full active set; and a cross-chain security council is being formed so that triage and disclosure decisions on shared-code vulnerabilities are made with broader ecosystem representation. Node operators who want email-based upgrade notifications can send their validator name, operator address, and operations contact to nodes@cosmoslabs.io.
Thank you to the Hadron Labs and Cosmos SDK teams for the coordinated disclosure, to the Cosmos Labs Ecosystem team that cut and tested both releases, and to every validator, exchange, and node operator who upgraded twice on short notice.
Tokenomics: Gauntlet’s Phase 2 Recommendations Are in Review, and a Wrap-Up Post With the Full Report and a Timeline Is Next
Phase 1 of the ATOM tokenomics research with Gauntlet was about measurement: how ATOM moves, why, and when, across 16 stakeholder cohorts and 10 activity types, and what that means for issuance and sell pressure. Phase 2 is about design: what the Hub could change in response.
Gauntlet has begun sharing some Phase 2 recommendations, and we’re actively reviewing and giving them feedback now. Phase 2 focuses on proposing and designing new tokenomic mechanisms/tweaks that address the findings of Phase 1.
At a high level, the Phase 2 recommendations respond to the findings:
-
The Hub pays more for security than it needs to. The research indicates the Hub is paying more in issuance than its security requires, which means part of today’s inflation is a subsidy rather than a security requirement. Phase 2 proposes a framework for adjusting issuance parameters against a defined security floor and in response to revenue. Meaning, designing a path where the Hub issues less and replaces that issuance with revenue distribution
-
Staking rewards are the largest and most liquid source of sell pressure. Rewards are paid continuously and can be sold immediately, and Phase 1 traced a meaningful share of outflows back to them. Phase 2 proposes new incentive designs that reward longer-term staking over immediate liquidation
-
The Hub has no place for revenue to go. As the products above start generating fees, the Hub needs a mechanism to receive, hold, and direct those fees into the network’s reward lifecycle. Phase 2 takes this into account as well.
One caveat. We are deliberately not sharing specific numbers or full mechanisms this week. The recommendations are still in revision, and we would rather present the full brief, document, and presentations with Gauntlet so that non-final work doesn’t get taken out of context.
What comes next:
-
A Phase 1 and Phase 2 wrap-up post on the forum. A post is coming soon that lays out every issue the research surfaced, attaches Gauntlet’s report, and sets out the sequence and timeline for addressing them. We expect that the implementation of each tokenomic change in response to each issue will be handled as an individual proposal on its own timeline, rather than bundled into one omnibus proposal
-
A tokenomics dashboard goes public with the report. The ATOM tokenomics dashboard the ecosystem team has been building will be published alongside the wrap-up post, so that anyone can check the findings against the data
We will begin working on these together with the Quarterly update, as of next week. We plan to bundle this and any major updates to the roadmap into the next quarterly.
Neutron Recovery: The Postmortem Is Live, and Neutron’s Recovery Plan for the 1,227,121 ATOM Held by the Hub Multisig Is Now on the Forum
Two updates since last week’s recap of the Neutron governance attack and the Hub’s response.
Neutron’s postmortem is published. Neutron’s maintainers released their full postmortem of the attack on Tuesday, September 29. It covers the governance exploit itself, the drained protocols, and the network’s relaunch with new mitigations in place. Our own Hub-side recap on the forum, covering the halt, the restart on v28.3.0, and the recovery multisig, has been updated to link to it. Read both together for the complete picture.
The recovery plan proposal is on the forum. The Hub-side recap set out three requirements before the ATOM held by the validator multisig moves anywhere: Neutron’s network is stable, Neutron’s teams have a recovery plan with evidence of losses, and Hub governance passes a proposal authorizing the multisig signers to transfer the funds. The first is complete: Neutron resumed operations on September 25 with protections against a repeat attack. The second landed on Wednesday, September 30, when Solva, the team leading the Neutron relaunch, posted the recovery plan proposal for discussion. The third, the Hub governance vote, is what that thread leads to.
What the proposal contains:
-
The accounting of losses. The attacker drained 1,723,180 ATOM across three contracts on Neutron: the Drop dATOM converter, the Drop withdrawal manager, and the Astroport ATOM/dATOM pool. Of that, roughly 665,000 ATOM was sold. The 1,227,121 ATOM in the Hub multisig is the recoverable remainder
-
The destination. A Neutron recovery multisig at neutron1yr29fd7uzdjp2jsq8hrta8mvyd6ex7vumn0shy, with signers from 01node, Stake&Relax, Polkachu, Newt Node, and Solva
-
The Hub proposal. A text proposal authorizing the six Hub multisig signers to send the balance, minus fees, to the Neutron recovery multisig as a standard ICS-20 transfer over channel-569, with a 1 ATOM test transfer first, and the transaction hashes, IBC acknowledgements, and final balances published back to the thread
-
The return on Neutron. Once the ATOM arrives, a Neutron governance proposal returns all recovered funds to the original contracts on their restored code and original admins, so that users withdraw through the Drop and Astroport interfaces they used before
The multisig signers have committed to holding the funds until Hub governance gives them a mandate, and to moving them only on that mandate. Discussions are expected to run for a week in the forum before any action is taken to governance by the involved parties.
That’s all for this week - thanks to everyone engaging across the forum, validator channels, and Telegram. Looking forward to next week’s update! Please let us know if you like the Weekly format, and what else you’d like to hear from us.
-
Join the monthly validator call: Wednesday, October 14, 9:00 AM ET
-
Join the next community call, featuring the ICF Q&A: new date to be announced. Register for the community calendar here
