Props 1060 and 1061, IBC joining LF Decentralized Trust, ATOM on Paxos, remote signers, and a delegation program update
The following is a recap of the November 11, 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.
The call covered the result of Prop 1060 and the open vote on Prop 1061, IBC joining LF Decentralized Trust, ATOM on Paxos and the Blockworks TTF filing, remote signers and Cosmos KMS, and a change to how commission is checked in the delegation program. Last month’s recap is on the forum, and the slides from this call are available to view.
Prop 1060: the community pool’s USDC.n is now USDC.inj
Prop 1060 passed on November 3, and the funds were back in the community pool as USDC.inj on November 4. The community pool did not have a mechanism to do the swap by itself, so the proposal was a community pool spend that sent the full USDC.n balance to a DAODAO multisig of six community members and validators, which executed the swap and sent the funds back. The 566,067.06 USDC.n was swapped to USDC.inj in two tranches through DAODAO proposals posted publicly ahead of the vote and returned in full on November 4. Thank you to everyone who helped make that a success.
Circle pauses Noble USDC on January 12, 2027. The migration guide is there for anyone still holding USDC.n, and questions about the USDC migration can go to Dan Bryan, Neil, or Syed Haziq.
Prop 1061: voting on the Gaia v29.1.0 upgrade is open until November 17
Prop 1061, the Gaia v29.1.0 upgrade, is on chain now. Voting closes on November 17 at 11:57 UTC, and validators who have not voted yet still have time.
If it passes, the upgrade is planned for block 33,935,300, about November 18 at the current block time. The upgrade is state-breaking, so validators need the new binary at that height.
Gaia v29.1.0 restores decoding of old parameter-change proposals, which fixes governance queries and state export, and it updates wasmd to v0.60.10 and wasmvm to v2.3.6. It has already run on the testnet. If the upgrade passes, the governance queries that have been failing work normally again, and tools no longer need a pagination workaround. Supporting pagination is still good practice.
IBC is becoming an LF Decentralized Trust project
Cosmos and the Interchain Foundation contributed IBC to LF Decentralized Trust (LFDT) at the Linux Foundation, announced on November 9. A lot of open source software has moved to the Linux Foundation, including Kubernetes and MCP. One of the main reasons for the contribution is that institutions are more comfortable building on open source infrastructure that sits with a neutral foundation and is not controlled by a single company.
Protocol governance runs under a public charter, and LFDT holds the IBC trademark. The neutral home makes it easier for new contributors to join. IBC is used in projects with central banks and regulated financial platforms, and Cosmos stays a long-term maintainer.
On the Hub, there is nothing to migrate. ATOM stakers govern the Hub, existing IBC connections carry on as they do today, and IBC stays free and open source for anyone building on it. You can read more in the announcement on the cosmos.network blog.
ATOM is live on Paxos, and the Blockworks TTF filing is published
ATOM is live on Paxos Crypto Brokerage, so fintechs, brokerages and platforms built on it can now offer ATOM to their customers. The integration was funded from the community pool by Prop 1054, which passed September 17.
The Cosmos Hub’s Blockworks TTF filing is also published. The Token Transparency Framework is a standardized, open-source disclosure format, and the Hub’s filing covers allocation, governance, funding and more. If you have questions about Paxos or the TTF filing, let us know.
Remote signers: what we have heard so far
About a week before the call, we sent out a survey on the remote signers validators are using on cosmoshub-4 and on other chains. Thank you to everyone who answered.
Three themes have come up so far. The first is high availability: keeping the validator signing through a node failure or a signer failure. The second is keys: keeping the key in OpenBao or HashiCorp Vault, or splitting it across several signers the way Horcrux does. The third is track record: several validators said their current signer works well, and they want to see Cosmos KMS proven in production first.
The survey is still open and takes about two minutes. Anonymous answers are welcome, and so is your moniker. We are interested in knowing who is running which remote signers, particularly versions of Horcrux or TMKMS, and specifically who is maintaining versions of them.
Cosmos KMS at a glance
Cosmos KMS is a remote signer written in Go on CometBFT’s own libraries, and its first release, v0.1.0, shipped in July 2026. Validators can run any signer that speaks CometBFT’s privval protocol, and Cosmos KMS is the one Cosmos Labs maintains and supports. Double-sign protection is built in for every chain it signs for, and the signer dials out to the validator nodes, so its host needs no open inbound port. Keys stay on a PKCS#11 HSM or in AWS KMS and sign in place, and one signer can serve several chains and validators.
The Cosmos KMS docs are on docs.cosmos.network, and feature requests and bug reports are tracked as issues on the cosmos/kms repository.
High availability with Cosmos KMS
Cosmos KMS supports high availability in the connections to the validator nodes. Multiple nodes can each run a privval listener, and the signer can be configured to talk to all of them. If one node stops, the signer keeps signing through the others.
The signer and its key run as one process, so if that host goes down, signing stops until it is back. This was designed this way on purpose. One signer keeps one sign state, so it never signs two different messages for the same height, round and step.
Run one signer per key. Two signers running on the same key can double sign, and on the Hub that is a 5 percent slash and a permanent tombstone.
Key backends: OpenBao and Vault are not supported today
Cosmos KMS keeps the validator key in a backend and signs there. PKCS#11 HSMs and AWS KMS are supported today, and a file backend is included for testing.
OpenBao and Vault are not supported today. OpenBao can’t serve its keys over PKCS#11, and Vault’s PKCS#11 provider is Enterprise only and has no Ed25519. OpenBao has an open request for a PKCS#11 interface, labeled help wanted, and with Ed25519 support it should work through the existing backend.
Interest in OpenBao support came up in the survey and on the call, and it has been passed on to the Cosmos KMS team.
MPC and threshold signing are not planned
Cosmos KMS does not split the key across several signers the way Horcrux does, and that is not on its roadmap. There are two reasons. Cosmos KMS is built around HSMs and cloud KMS, and some institutions’ security rules require an HSM and do not allow MPC-based key management. Cosmos KMS also supports post-quantum keys like ML-DSA-65, and threshold signing for those keys is still mostly research.
Several validators value this feature, and that feedback has been noted. At this point there are no plans to implement it. If you know of anything public on threshold signing for post-quantum keys, let Dan know.
Try Cosmos KMS on the testnet
For validators who want to see Cosmos KMS proven in production first, our recommendation is to start getting experience with it on the testnet, which is a low-stakes environment. You can set up two testnet nodes, try the high availability configuration, and watch the signer switch between them.
Another option is your own devnet: set up a small network, make sure it works, then shut down one of the nodes and see if it still works. This can be done in a safe environment on low-end hardware with Docker.
We encourage validators to do some research on Cosmos KMS and make a decision, and questions about it can go to Dan.
Delegation program: commission is now checked across the whole quarter
From the December 31 snapshot on, commission is checked at every block of the quarter, not only at the snapshot. Commission must be at or below 10 percent at every block of the calendar quarter, which for the December 31 snapshot means every block from October 1 through December 31, 2026 (UTC). Every later round works the same way. A validator whose commission goes above 10 percent at any point in the quarter, even for one day, does not qualify for that round.
Until now the 10 percent limit was only checked at the snapshot block. A snapshot-only check allows a validator to lower its commission just before the snapshot or raise it right after, and checking every block closes both. All other default delegation criteria stay as they are, and the details are in the default delegation criteria on the Cosmos Forum.
The Q4 snapshot is the last block of December 31 UTC, and the process will be the same as for Q3. The other criteria are unchanged, including governance participation above 80 percent over the 12 months before the snapshot, uptime above 95 percent over the 90 days before it, and at least 6 testnet points across the quarter. The full list is in the forum topic linked above.
Applications for the Sponsored Endpoint Provider RFP closed on October 28 and are under review. The selection will be announced in the RFP topic on the forum.
Q&A themes
One question was whether more than one team will supply the sponsored endpoints. The RFP selects one provider. Many validators already offer public RPC endpoints for the community, and that continues. The selected provider receives a delegation for four quarterly rounds for running the endpoints and meeting the service requirements in the RFP.
Next steps
The next validator call will occur on December 9 at 9:00 AM ET. If you are an active set validator and have not yet joined the channel, message @totalspud or @robomcgobo on Telegram for an invite.