Interchain Events : Cross-chain state verification on the hub

Interchain Events: Cross-chain state verification on the Hub — working POC on mainnet Hi everyone — I’ve been working on a cross-chain state verification primitive for the Hub and I’d love to get the community’s feedback on the approach, the architecture, and whether this is something that would be valuable for the ecosystem. TL;DR I built a CosmWasm contract on the Cosmos Hub that verifies the state of remote chains using ICS-23 Merkle proofs and triggers smart contract callbacks. It’s deployed on mainnet and works end-to-end today: write state on Neutron → watcher detects it → proof submitted to Hub → contract verifies proof → callback fires. No oracle, no trusted third party. The proof is either mathematically valid or rejected. Repo : GitHub - Victor118/interchain-event: Cross-chain state verification for Cosmos — subscribe to state changes on any IBC chain, verify with ICS-23 Merkle proofs, trigger smart contract callbacks. POC live on mainnet. · GitHub The problem IBC gives us trustless message passing between chains. ICS-20 lets us transfer tokens. But what about reacting to state changes on another chain without that chain’s cooperation? Examples: •…

Excerpt (1198 of 7831 characters). Read the whole post on the forum ↗

I think this is one of the more important Hub ideas I’ve seen in a while. What stands out to me is that this is not just a “visibility layer.” It is a verification and execution-trigger layer for cross-chain business logic. That matters because the real bottleneck for many serious cross-chain workflows is not token transfer. It is conditional coordination: • compliance / KYC gates • settlement finality • escrow release • treasury rebalancing • cross-chain business rules If this primitive works the way you describe, it changes the model from N×N bilateral integrations to something much closer to N×1 through the Hub. That feels especially relevant for enterprise, private, or semi-private sovereign chains. They may want interoperability without rebuilding custom bilateral logic for every new counterparty. A few things I find especially compelling: • Unilateral observation No changes needed on the observed chain. That is a very strong property. • No recurring on-chain polling cost You only spend gas when a proof is actually submitted and the callback executes. That feels like a very clean foundation for future Hub monetization if the tokenomics…

Excerpt (1199 of 2593 characters). Read the whole post on the forum ↗

Thanks Cedrik — really appreciate the thoughtful response. It’s great to see someone who shares the same enthusiasm for this idea and immediately gets the distinction between a visibility layer and a verification + execution-trigger layer. On the technical blocker: you’re right that `VerifyMembership` exposure is the key unlock. I’ve opened cosmos/gaia#4023 for this — it’s been labeled as an epic by the team, which is encouraging. It’s a configuration change, not a protocol change, so it could land in any Gaia upgrade. In the meantime, the POC works end-to-end with off-chain AppHash verification — the proof math is real, just the trust anchor needs to move on-chain. On the economic design — this is where the real conversation starts, and I don’t think there’s an obvious answer yet: Watcher economy : Should watchers be a public Hub service — operated by validators or funded by the community pool as shared infrastructure — or should they be private businesses building on top of a free protocol? Both models have precedents in Cosmos: relayers are largely treated as public goods, while indexers are private businesses. The answer probably shapes the entire value capture model.…

Excerpt (1196 of 2946 characters). Read the whole post on the forum ↗

New feature I’m considering for interchain-events: ICQ-style queries

So far the contract handles event subscriptions — watch a remote state, callback when a condition is met. I’m thinking of adding a one-shot query mode: a
contract on the Hub asks “give me the value at this key on chain X”, a watcher fetches it with proof, the contract verifies and returns the value via
callback. Basically ICQ, which the Hub doesn’t have natively.

The “key exists” case works with the VerifyMembership whitelist I’m already pushing for in [Feature]: Whitelist VerifyMembership for CosmWasm GRPC queries · Issue #4023 · cosmos/gaia · GitHub . The tricky part is the “key doesn’t exist”
response — VerifyNonMembership isn’t exposed as a gRPC query in IBC-go.

Pragmatic fix: also whitelist Query/ConsensusState. It already exists, it’s read-only, and it gives contracts access to the trusted AppHash so they can
verify non-membership (and any other ICS-23 op) in-contract. Same level of change as VerifyMembership. ( [Feature]: Whitelist VerifyMembership for CosmWasm GRPC queries · Issue #4023 · cosmos/gaia · GitHub )

Would unlock a real ICQ primitive on the Hub.