Hey folks! This is the second Cosmos Quarterly, and the first one in the format every edition will use from now on: the quarter’s news, pillar by pillar, and what each team is working on next.
If you want the story of how Cosmos Labs is structured and why, that lives in Quarterly #1 and we won’t retell it here. The Thursday Hub Weekly continues as it is.
The short version of the quarter: The tokenomics phase 2 is finished, the Hub roadmap passed validation, and both are preparing for a review process in governance, ATOM went live on Paxos, an institutional staking API is coming through InfStones, the USDC migration is past halfway, post-quantum keys shipped, the IBC release for EVM and Besu networks is weeks away, and the enterprise team took the tokenization suite to banks and to SWIFT’s ledger.
It was also a security-hardening quarter. Two vulnerabilities in shared code and one governance attack on an ecosystem chain hit between August and September. The Hub responded to all three quickly and lost no funds. Since then, the team has published new security policies and expanded the security operations team, so the ecosystem is better covered for the long term.
At a glance, this quarter
Ecosystem. The tokenomics research is complete, and the Hub roadmap is validated enough to prepare for public review. Both go to governance in pieces from December, one proposal at a time; the process and timeline for each come out around November 20. 12.7 million USDC migrated, with the community pool’s own migration now on-chain. The team ran five Hub releases, three of them security updates. ATOM went live on Paxos, and an institutional staking API is coming via InfStones.
Open Source. Two vulnerabilities in shared code were handled without loss on the Hub, and the security operations behind the stack were rebuilt around them: signed releases, strengthened security practices, AI-assisted triage and patching, verified patch distribution. Post-quantum consensus keys and key rotation shipped. The release that makes IBC deployable on any EVM network, and on Besu, is around the corner.
Enterprise. The Cosmos Tokenization Suite now connects bank cores to SWIFT’s shared ledger. The team launched a 17-member Partner Network for institutional customers. The team demoed at conferences and trade shows and was on the ground at industry conferences.
Collaborations across all pillars. Paxos, InfStones, SWIFT, Zeeve, and the Partner Network with +17 participants.
Structural. Hub operations have been fully onboarded to CLK, and the ecosystem team also refreshed the Cosmos Hub’s documentation and is stabilizing relaying on the network.
Ecosystem: ATOM tokenomics phase 2 is done; the roadmap shape is sound enough. Polishing, review, and governance are next
The ecosystem team has been hard at work on the roadmap and tokenomics workstreams, supporting as well security response processes and the USDC migration.
Tokenomics: Phase 2 is finished with clear action items. Next, governance.
Last quarter, Gauntlet’s Phase 1 measured how ATOM actually moves. This quarter, Phase 2 designed the responses, and both phases are complete.
Phase 2 started from the Phase 1 finding that sell pressure comes from how quickly rewards become liquid and reach exchanges, not from the inflation rate itself, and set out to design three proposals:
-
An issuance rule that holds a defined security floor and can respond to revenue once Hub products earn it.
-
Staking incentives that reward longer-term staking over immediate liquidation.
-
A place for Hub revenue to go, so fees feed the reward lifecycle instead of having nowhere to land.
These proposals address the main findings and move the Hub’s tokenomics toward a stronger staking asset with room for new products. If you followed the weeklies, you saw the last stretch: the past few weeks went into stress-testing the recommendations, checking whether exchanges, custodians, or other sophisticated players could game the proposed mechanisms, and reviewing how each one would be implemented.
That review process has concluded. Next: Public reviews & governance.
We are now drafting the report, with its associated proposals, as a tokenomics roadmap that we will take to governance for review, debate, and signaling: every issue the research surfaced, the full report attached, and the sequence for addressing them, with each change handled as its own proposal on its own timeline rather than one omnibus vote.
How and when it goes to governance is in the section below, alongside the Hub roadmap: one post, one schedule, and a separate proposal for each proposed tokenomics change.
The public tokenomics dashboard we promised in July is built on the Phase 1 data and is also already live, and you can take an early look here.
The Hub Roadmap: validation is complete; plan polishing and review come next
The last roadmap update was Hub Weekly #18, on October 1. It set out the long-term vision, the product ideas that came out of validation, a possible order for building them, and the five things we still had to check: legal, technical, Hub safety, cost, and demand.
We spent October checking them. The vision and findings from #18 held, with a few changes to what goes in each phase and in what order. We now know enough to turn those phases into a detailed, multi-year roadmap.
Phase by phase, what we shared in the last update (Then) and what changed (Now):
Phase 1: prove the rail.
-
Then: “rails first”, issuance and distribution over IBC.
-
Now: narrowed to one Hub-native asset, issued once on the Hub, reaching a connected chain as the same asset, with the Hub’s accounting holding. Existing connections only, hard limits, nothing touching consensus or the VM. The primitive it builds is canonical issuance and distribution.
Phase 2: the first Hub-built products.
-
Then: a few indices at different risk levels.
-
Now: indices and curated baskets on the rail from Phase 1, which adds the curator framework (who can build a basket, under what methodology, for what fee), redemption flows, and cross-chain pricing and verification. The primitive is orchestration: holding and pricing positions across chains and paying through one token.
Phase 3: traditional-finance assets on the same rail.
-
Then: tokenized stocks, funds, and bonds via specialised tokenizers, later institutions themselves.
-
Now: Unchanged in content, but validation fixed its place: it is the phase that needs the legal entity, so it comes third, and that entity work should start earlier to prepare the phase. The primitive is compliant issuance of regulated assets.
Phase 4: products that need both sides.
- Then and now: baskets of tokenized funds next to onchain yield, built by vetted curators, with a fee to the Hub. It needs the primitives from Phases 2 and 3 and adds little of its own, which is the point: by then the Hub is the place institutional products get distributed onchain.
What validation found, and what changes it drove:
-
Legal set the order. A Hub-native asset needs no new legal vehicle; issuing regulated assets ourselves needs an entity that takes months to set up, and renting a tokenization platform is out because none supports the open, no-KYC access the thesis needs. So Phases 1 and 2 use on-chain assets that need nothing new, and progress doesn’t wait on lawyers.
-
Test the rail first. Multi-chain indices raise hard questions: how the Hub verifies assets on other chains, how it prices positions it doesn’t custody, which connections are ready. Phase 1 needs none of that. Issuance and distribution over IBC work today, so we prove the rail now and bring verification in when Phase 2 needs it.
-
Where the Hub earns beyond issuing. We evaluated how these assets and products create work for the Hub: relaying, cross-chain pricing and accounting, keeping routes clear. The validator set can run those services for a fee, which is new income for the active set and the first concrete answer to “where does Hub revenue come from” beyond issuance, yield, or index fees.
The work now is turning what validation produced into the four phases in depth: scope, dependencies, and timeline for each, and that is the plan that goes to the forum and to governance. That will be the roadmap.
The plan will be sequential by design. Each phase has one goal, builds one primitive the next phase needs, and has to prove it before the next phase starts. It is the same loop a product team runs: build the smallest thing that can prove the idea, prove it, then take the next step.
When and how it goes to governance is in the section below.
Governance: the tokenomics & roadmap review schedule
The tokenomics findings and the Hub roadmap are getting ready for community review, and we are going to run them through governance on a schedule, one item at a time.
Around November 20, we publish the process post. It will contain:
-
The schedule: a date for the review and discussion of each tokenomics step, and a date for the roadmap.
-
The tokenomics roadmap, broken down into its individual steps, with Gauntlet’s full report and the dashboard attached.
-
A snapshot of the Hub roadmap: the phases, what each proves, and the order. A full roadmap will be published separately at a later date, in time for its discussion and review date.
From early December we will walk through each review step in order, through December, past New Year and into January: the tokenomics steps first, in sequence, and the roadmap last, once the steps that prepare the Hub for it have been decided.
Each item will follow the same process, at a minimum:
-
A forum thread, opened well ahead of any vote, with the proposal in full.
-
A monthly discussion and showcase: the item is presented and argued on the validator call and the community call, with the team on the call to answer.
-
Room to adjust: if the discussion changes the approach, the proposal changes before it goes on chain, and the timeline moves where it needs to.
-
Only then a proposal on chain, shaped by what came out of the discussion.
Each step will be its own proposal and will stand on its own. This is not an all-or-nothing omnibus set of proposals: if one step is rejected, the rest can still pass, and meaningful change happens either way. We designed the steps so that is true.
The schedule is spread out on purpose. There is a lot to get through, and one item at a time is easier to follow than everything at once. Thanksgiving and the end-of-year holidays fall inside these windows, so the schedule leaves room around them; nothing gets decided while half the ecosystem is away.
Safe to say, we are very excited to share all of this!
USDC Migration: past the halfway mark, with the community pool next
The USDC migration has passed the halfway mark. We are updating timelines around the one-click migration tool:
-
Status & Timeline: Two-click migration shipped in September. One-click migration is waiting on an Injective chain upgrade (now scheduled for mid-November after security precautions following their September incident).
-
How to Migrate Now: Thanks to ~$1.5M in USDC.inj liquidity in Osmosis transmuter pools, zero-fee migrations remain available for most users. Migrate via Skip:Go or Keplr wallet using this migration guide.
-
Progress & Key Dates (per Hub Weekly #21): As of Oct 16, 12.70M USDC migrated to Injective, with 93.97M USDC.n remaining ecosystem-wide (mostly on dYdX). Circle stopped new Noble minting on Oct 13; CCTP V1 burn limits go to zero Oct 31; Noble contract pauses Jan 12, 2027.
-
Community Pool Funds: Voting is active on Proposal 1060 to migrate 566,067 USDC.n via a 4-of-6 community multisig using Skip:Go. Details and discussion are in the forum post.
Hub operations: five releases, three incidents, no funds lost
Cosmos Labs’ Korean subsidiary assumed Hub releases starting with v28.0 on September 2. The transition was immediately tested by several critical security events and updates that were handled successfully.
-
v27.6: Shipped in August to unblock Hydro’s migration.
-
v28.1.0: Emergency private binary mitigation for a CosmWasm vulnerability, deployed across 179 active validators.
-
v28.2.0: Full CosmWasm fix executed via an expedited 72-hour vote (Proposal 1055) on September 21.
-
v28.3.0: Restarted the Hub on September 23 following the Neutron governance exploit.
-
v29 (v29.0.1): Upgraded to SDK v0.53.8, removed the legacy params module, and applied a Go runtime security patch (Proposal 1059) on October 28.
In response to these events, release processes were overhauled to require GPG-signed binaries, updated validator contact directories and refreshed documentation at docs.cosmos.network/hub.
Finally, the Neutron recovery concluded with 1,227,121 ATOM returned to Neutron’s recovery multisig following a governance vote, while AADAO returned its ATOM LP to the community pool.
ATOM integrations: Paxos is live, InfStones is next
Paxos. Proposal 1054 passed in September, and ATOM is now a supported asset on Paxos Crypto Brokerage for trading and custody, which means the fintechs and brokerages that embed Paxos can offer ATOM through an existing integration. The main deliverable is the integration, now done. The institutional staking integration outlined in the proposal as a follow-up is still under consideration, and we’re speaking with the Paxos team now about an approximate timeline and mechanism by which to activate it.
As a next step, Paxos’s partner managers have begun circulating details on the listing to their partners, and the ecosystem team will begin sharing the listing details with brokerages, custodians, and exchanges that we want to see list ATOM. The public announcement of the integration on social media is planned for next week, and Paxos’s marketing team has begun planning a press release cycle.
InfStones. An Ecosystem Growth delegation for an open-source, institutional-grade ATOM staking API, so custodians and brokerages can offer ATOM staking through channels they already run. The delegation is released in three tranches: one on signature, one on API delivery or a first closed institutional customer, and one on final delivery plus a closed customer, so receiving all of it requires bringing real stakers in. The terms are in Hub Weekly #21, and the agreement has been finalized. We will share an announcement with InfStones soon.
Two questions came back on the forum, and they deserve straight answers here:
-
These delegations are ICF ATOM, not community pool spend. We publish them so you can see their impact; the design of the delegations is decided by ICF.
-
There is no customer for this API yet, and usage is not guaranteed. When a customer signs, we will work with InfStones to provide information to the community, subject to what those partners allow. InfStones was chosen for its network of institutional partners. They are the best-positioned team we have spoken with to bring it.
Delegation program
The program has two tracks: default delegations, which any validator earns by meeting published performance criteria, and Ecosystem Growth delegations, by application or targeted RFP.
This quarter we moved the cadence to calendar quarters with fixed snapshot dates, so every round runs the same way at the same time, and we clarified in public how growth delegations stack with default ones.
The Q3 round’s results were published for validators to check before anything moved on-chain; execution runs through the ICF’s custodians, with screening on every round, and the transaction hashes go up once it’s done. As of this day, custodians have executed delegations and the process is completed. A summary will be posted soon.
As for the ICF’s growth delegation program, two targeted RFPs ran this quarter.
-
The PebbleDB snapshots RFP was awarded to Solva, providing a faster way to sync nodes, readily available.
-
The sponsored endpoint RFP, for the public RPC, API, and gRPC endpoints builders use, opened October 6 and closed October 28 with more than eighteen applications. We have finalized this RFP and will announce the awarded team in November.
Also on the Hub
Stargaze Messages shipped on the Hub on September 30: private, encrypted wallet-to-wallet messaging, running as CosmWasm contracts on Hub infrastructure. A consumer feature on the Hub, built by a team that chose to deploy here.
Similarly, Hydro has announced plans to launch a new ATOM LST on the Cosmos Hub in collaboration with Moonkitt. This LST will have no protocol fee and will interact with Hydro’s inflow vaults on the Hub to create new DeFi opportunities for ATOM holders.
What we’re working on now
-
The process post is for around November 20, and the first tokenomics proposals that follow it in December.
-
Phase 1 of the roadmap: technical scoping and a small closed test.
-
USDC: one-click when Injective ships, the community pool migration, and chasing the last USDC.n with validators and wallets.
-
The endpoint RFP award, the InfStones API build, and the next round of delegations.
Open Source: a quarter of hardening, and IBC for any EVM network
The Open Source (Foundations) team spent the quarter on two things: hardening security and incident response after the incidents, and accelerating IBC for EVM networks, because that is where the demand for IBC is coming from.
Security: two vulnerabilities, and what we changed because of them
Two vulnerabilities in code were disclosed this quarter. The third incident of the quarter, the governance attack on Neutron, was a Hub operations matter and is covered in the Ecosystem section above.
- Cosmos EVM, August. A vulnerability in the Cosmos EVM module was discovered and actively exploited on six chains. Around forty chains were coordinated through the disclosure for safe upgrade. The team published a post-mortem detailing the finding, response, and the changes implemented to avoid scenarios like these in the future.
- CosmWasm, September. CWA-2026-006, a sandbox escape in the Wasmer compiler that wasmvm uses, which in practice meant a crafted contract could mint tokens, was reported. The Hub was remediated successfully. The patch was distributed via a private patching process to affected chains.
- On top of those: the SDK shipped security patches in July (v0.53.8, v0.54.4) and v29 carries a Go runtime security fix.
What changed and improved in the security process as a result:
Due to the rise of AI-assisted attacks and bug-bounty reporting, we continued to strengthen our security practices this quarter as a main focus:
-
An expanded security operations team within the company to provide greater support for bug bounty triage, code hardening, and vulnerability remediation.
-
The bug bounty moved to ImmuneFi, providing the team with additional capabilities to triage and coordinate with researchers.
-
Updated code of conduct and ImmuneFi program policies. Read more here.
-
A new security patching and distribution policy to improve planning and coordination between the security team and users of the Cosmos stack. Teams using the Cosmos stack are encouraged to provide their contact information to security@cosmoslabs.io to be added to the private security contact lists.
-
Signed releases on every Hub binary, to ensure the source of code and binaries.
To support these initiatives, the ICF has also set up a $3M discretionary security grant program for incident recovery, hardening, monitoring, and contributions to shared ecosystem security.
Interoperability: IBC for any EVM network, and for Besu
While IBC v2 brought native interop to Ethereum, the team is working on extending that connectivity to any EVM-compatible environment, from public L2s to Hyperledger Besu. These networks are where institutions and L2s are asking us for interoperability, which is why it took priority above other options. Hyperledger Besu does not have a de facto interoperability standard, and the new updates to IBC will provide Besu-based ledgers with these much-needed features.
In July, we said an IBC integration took nine or more manual transactions and that we were collapsing it into a single step. We fulfilled that promise by rebuilding the entire experience around one unified tool: the IBC CLI. A single binary now runs the relayer and attestor, deploys contracts, connects counterparties, and handles packet recovery.
Testing & Coverage:
-
Public EVM & Besu Testnets: Connected a local Besu network to 14 public testnets (including Ethereum Sepolia, Base, Arbitrum, OP, Linea, zkSync Era, Unichain, Celo, Avalanche Fuji, Hedera, XRPL EVM, and partner testnets) using the CLI alone.
-
Two-Way Token Transfers: Proven burn-and-mint flows across pairs without wrapped copies or middle bridges (in a demo setup with one attestor per chain).
Release Readiness:
- Core Features Built: Auto-relaying with missed-packet recovery, on-chain transfer rate limits, and documented runbooks for contract upgrades, pausing, and relayer and attestor rotation.
Final Stretch: The team is finalizing the Besu light client, conducting final tests and security audits before shipping the verified CLI releases.
What it unlocks:
-
Any EVM network to any other, L2s included, with no Cosmos chain in the middle.
-
Any EVM network to Cosmos. This was already possible (the Hub has run IBC to Ethereum since April); the release makes it a CLI setup instead of a bespoke integration.
-
Besu to any EVM network, with Besu state verified directly by its own consensus (QBFT and IBFT 2.0) instead of attestors, which is what a bank or a consortium needs before it will trust a connection.
-
Assets that stay the same asset: burned on the source chain, minted on the destination, no wrapped copies and no bridge in the middle.
-
Guardrails: rate limits on transfers, restricted registration of new clients and apps, auto-relay that recovers missed packets, and the ability to pause transfers, the router, and light clients during an incident.
Solana. The IBC programs for Solana are substantially complete in the open cosmos/ibc-contracts repo. What remains to take them to production (relayer support for Solana’s RPC model, a packet-sequence design that works with auto-relay, and a fresh audit) is scoped in cosmos/ibc#1569 and is not part of this release. Besu came first because that is where the demand is. Solana will follow when we have a use-case lined up; that could be the Cosmos Hub. If you have a concrete use case for IBC on Solana and want to help take it to production, talk to us.
Cosmos SDK and CometBFT: Post-quantum support
The July release we promised landed on July 28: Cosmos SDK v0.55.0 and CometBFT v0.40 bring post-quantum consensus key types (ML-DSA) and zero-downtime validator key rotation, with Cosmos KMS as the recommended remote signer, and PoA v1.1.0 carries the same to permissioned chains. Read more on the blog: Post-Quantum Ledger Security 2026.1.
What the team is working on now
-
Shipping the IBC release for EVM and Besu networks once internal audits are through, and the versioned CLI releases after it.
-
Providing the monthly patch under the updated security patching policy, and extending the automated patching pipeline from Cosmos EVM to the SDK and CometBFT while working down the report backlog.
-
Light clients from contributors, and research spikes on consensus clients.
-
The ibc-go release that carries SDK v0.55, so chains, the Hub included, can move to v30.
Enterprise: the tokenization suite in front of banks
The enterprise pillar has been focused on expanding the reach of Cosmos’ Tokenization Suite and related offerings.
Swift’s ledger
On September 28, we announced that the Cosmos Tokenization Suite gives banks connectivity to SWIFT’s blockchain-based shared ledger, an EVM and Hyperledger Besu environment, for 24/7 cross-border payments.
For a bank, that means standing up its own tokenized deposit ledger, keeping it in sync with the core it already runs, like Fiserv, FIS, or Jack Henry, and connecting it to networks like SWIFT’s ledger, Canton, Partior, Ethereum, and Solana through one integration rather than one per network. Ledger Insights and Finextra covered it.
The Partner Network
On September 9, we launched the Cosmos Partner Network: seventeen vetted providers across custody, compliance, security, infrastructure and systems integration that banks can draw on around the tokenization suite.
Anseta, Balance, BCW Group, BitGo, Blockchain.com, Blockdaemon, Coinbax, DFNS, Galaxy Digital, Hypernative, InfStones, OpenZeppelin, Peersyst, Silence Laboratories, Ubyx, Utila and Zeeve, with a directory at cosmos.network/partners.
On stage and at the booth, events
Last quarter, this team spent its time in payments and banking rooms rather than crypto conferences. Highlights from events this quarter include:
-
FinovateFall (New York, Sep 10): The team demoed programmable cash sweeps on the tokenization suite live on stage, on a Jack Henry core; watch on our YouTube.
-
Sibos (Miami, Sep 28 – Oct 1): The team was present on the floor and Barry gave a booth talk on making tokenization work across ledgers; the takeaways are on the blog.
-
Jack Henry Connect (Kansas City): The team had a booth on the show floor, demonstrating Cosmos Tokenization Suite’s native integration with Jack Henry cores.
-
LF Decentralized Trust Privacy Workshop (New York): Eran joined a panel discussion.
That is the start of an education track for banks early in their digital-asset path, and there will be more of these sessions.
Other updates from the team
The blog saw a lot of content highlights this quarter:
-
Coinbax on adopting ledger infrastructure without inheriting digital-asset risk
-
Barry’s op-ed on interoperability
-
In August, Wells Fargo announced tokenized deposits for corporate and commercial clients, and as our co-CEO noted publicly, their ledger is built on Cosmos technology.
-
Cosmos also joined LF Decentralized Trust as a member in September.
What the team is working on now
- Expanding bank integrations beyond Fiserv and Jack Henry.
Partnerships, recap:
We’ve mentioned several partnerships in this post so far; for the recap:
-
Paxos: ATOM on their brokerage
-
InfStones: Institutional staking API
-
Solva: PebbleDB snapshots
-
Gauntlet: Tokenomics research
-
Range: Screening and delegation data
-
Partner Network: 17-member ecosystem (including Anseta, Balance, BCW Group, BitGo, Blockchain.com, Blockdaemon, Coinbax, DFNS, Galaxy Digital, Hypernative, InfStones, OpenZeppelin, Peersyst, Silence Laboratories, Ubyx, Utila, and Zeeve.
Wrapping up, the community call, and how to plug in
Our last community call
The ICF joined us on the October 15 community call and took the questions aimed at them that we collected in July. The next validator call is November 11 at 9:00 ET; the October recap is on the forum.
Commitments from the last Quarterly
In Quarterly #1 we listed some commitments from the July call. Where each one stands:
-
Launch this Quarterly series. Done. This is the second one, and the Hub Weekly ran every Thursday in between.
-
Cover the questions aimed at the ICF on a community call with them. Done, October 15.
-
Build a Cosmos Hub ecosystem page. Still to come. The Hub docs are now owned by the ecosystem team; the page is next.
-
Build a public tokenomics dashboard. Built and ready!
How to plug in
There is a lot coming up, and most of it works better with you in it. Where to jump in, depending on who you are:
-
On governance and roadmaps. The process post lands around November 20, and the first review starts in early December. Read it, argue with it on the forum, bring it to the validator call, and vote. Each step stands on its own, so you can weigh in on one without waiting for the rest.
-
If you run a validator. The endpoint RFP award comes in November, with more targeted RFPs after it. The monthly validator call is the second Wednesday; that is where the delegation program and the upcoming proposals will get discussed first.
-
If you build. Got news for the Thursday Hub Weekly? Send it to @RoboMcGobo. If you run an EVM or Besu network and want to try the IBC release, or you have a real use case for IBC on Solana, we want to hear from you.
-
If you run nodes. Send your validator name, operator address, and an operations contact to nodes@cosmoslabs.io, and you’ll get upgrade notices directly.
That’s the quarter. Follow the weekly, argue with the roadmap, and see you on the forum. Until next time!
Follow the Hub on X · Join the validator calls · Register for the community calendar
