Cosmos Hub Validator Call July 08 2026: Recap
A team introduction, Q3 delegations, the Injective USDC migration, Gauntlet’s Phase 1 findings, and Cosmos EVM on the Hub image 1638×919 444 KB The following is a recap of the July 8, 2026 Cosmos Hub validator call. These calls occur once per month, and recaps like this one are posted on the Cosmos Hub forums following each call. This was the third validator call, and it followed the same shape as last month’s : a set of ecosystem updates, a topic of the month, and an open Q&A. This month’s topic was Cosmos EVM and what it could look like surrounding the Cosmos Hub. The question on the table is how the Hub should host EVM, not whether to adopt it, and two options were presented for validator input. Validators have a new point of contact Dan Bryan, technical programs manager at Cosmos Labs, is taking over much of the day to day for the delegation program and validator inbound from me, and he will be the new point of contact for a lot of this work moving forward. He will also begin leading the validator calls. Any validators who would like to schedule time to chat and bring him up to speed on what you are working on, now is a great time to reach out to Dan in the…
Excerpt (1194 of 16751 characters). Read the whole post on the forum ↗
Great update.
Atlas Staking will gladly run a validator for a Hub EVM side chain.
Thanks for the detailed recap. The discussion around Cosmos EVM was particularly interesting, but what also stood out to me was how much emphasis was placed on the supporting infrastructure rather than just protocol features. Whether the Hub ultimately moves toward a multi-VM architecture or an EVM sidechain, the quality of cross-chain communication will become even more important. Reliable IBC relayers are easy to overlook when everything is working, but they’re a critical part of the user experience and ecosystem resilience. Bridging assets, relaying packets, and maintaining consistent connectivity between chains all depend on operators running robust relayer infrastructure. Our team recently published a technical overview of IBC relayers, covering how they work, what differentiates providers, and the operational considerations behind running them reliably. Some of the topics discussed there are directly relevant to the infrastructure challenges mentioned in this validator call: Cosmos IBC – How to Choose a Trusted Provider in 2026 I’m also curious how the community sees relayer infrastructure evolving if the Hub expands its EVM strategy. As more applications and…
Excerpt (1190 of 1346 characters). Read the whole post on the forum ↗
Great read, Crouton team! Relaying and attestation, IMO, can become a native role for validators and a new revenue stream if we focus on developing the interop front up. The more chains IBC reaches that are “non standard” (aka non-Cosmos), the more distinct relaying/attestation/etc we will need to keep these routes healthy and available.
From a wallet UX perspective, relayer reliability becomes most visible when an IBC transfer takes longer than expected and the user cannot tell whether the wallet, route, or destination chain is responsible.
As relayer and attestation infrastructure evolves, could there also be a standardized way for wallets to consume user-facing route-health information—such as recent packet success, degraded-route warnings, estimated completion, and recovery guidance?
That kind of information could help wallets distinguish a delayed IBC transfer from a wallet error and provide users with a much clearer status. This would also be useful input for how we think about cross-chain transaction visibility in Gem Wallet.