Interchain Events : Cross-chain state verification on the hub

[Victor118]

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:

• An investor completes KYC on an identity chain → automatically whitelist them on a securities chain
• A settlement is finalized on Chain A → release escrowed payment on Chain B
• A certification is issued on an audit chain → unlock access on a service chain

Today, each of these requires building a custom bilateral IBC protocol on both sides. That’s months of development per integration, and it scales as N×N.

The solution: unilateral observation

Interchain Events flips the model. Instead of requiring both chains to cooperate, one chain observes another’s state unilaterally using cryptographic proofs:

Remote chain (e.g. Neutron):  state changes
                              ↓ watcher reads state + fetches Merkle proof
Cosmos Hub:                   interchain-events contract verifies ICS-23 proof
                              ↓ condition met
                              callback contract executes business logic

Key properties:

• No changes needed on the observed chain — it doesn’t know or care it’s being watched
• Zero idle cost — no polling, no validator overhead. Gas is only spent when the event actually fires
• Trustless — watchers are transporters, not witnesses. They can’t forge proofs. A malicious watcher can only fail to submit, not lie
• Callback pattern — the proven value is passed to a subscriber contract that implements whatever logic it needs

The Hub is the natural place for this: it already maintains IBC light clients for dozens of chains.

What’s deployed right now

This is not a slide deck. It’s running on Cosmos Hub mainnet:

Chain	Contract	Code ID	Address
Cosmos Hub	interchain-events v7	501	cosmos1ul3v2sh4uqgvzr2c00dz2un6373hkunk0e0z9ay9x9td3uj7qdtqqggyqc
Cosmos Hub	proof-callback v2	502	cosmos108u0auz26aqgulr5exh4h2gadqar7qedcjj9yx7da5ramn0hlnmqj5plp2
Neutron	attestation-registry	5237	neutron1dhw2cyurukdvl9v36lkmd7p900u89cdalytv5a7tluzhkevd89wsda4wjl

You can query them right now:

# See existing subscriptions
gaiad q wasm contract-state smart \
  cosmos1ul3v2sh4uqgvzr2c00dz2un6373hkunk0e0z9ay9x9td3uj7qdtqqggyqc \
  '{"list_subscriptions":{"limit":10}}' \
  --node https://cosmos-rpc.polkachu.com:443

# See callback events
gaiad q wasm contract-state smart \
  cosmos108u0auz26aqgulr5exh4h2gadqar7qedcjj9yx7da5ramn0hlnmqj5plp2 \
  '{"events":{}}' \
  --node https://cosmos-rpc.polkachu.com:443

What the POC demonstrates

1. Writing an attestation ({"status":"approved"}) on Neutron
2. Creating a subscription on the Hub: “watch this key on Neutron, call my callback when status == approved”
3. An off-chain watcher detects the change and fetches an ICS-23 proof from Neutron
4. The watcher submits the proof to the Hub
5. The contract verifies the two-level Merkle proof (IAVL + SimpleTree) against the AppHash
6. The callback contract receives the full proven value and executes its logic

Supported conditions: exists, equals, json_path_equals, greater_than, less_than. The callback receives the complete proven data, so it can implement arbitrarily complex logic on its own.

How the proof works

When you query a Cosmos chain with abci_query?prove=true, you get two Merkle proofs:

1. IAVL proof — proves the key/value exists in the module’s tree (e.g. wasm)
2. SimpleTree proof — proves the module’s root is included in the AppHash

The contract verifies both in pure Wasm. No external dependencies, no Stargate queries needed for the verification itself.

The one thing that would make it fully trustless

Right now, the AppHash is provided off-chain by the proof submitter. The verification is real — an invalid proof is rejected — but the AppHash itself is not read from the IBC light client.

Why? Because the Hub does not expose VerifyMembership to CosmWasm contracts. This is a Gaia configuration choice, not a technical limitation. The fix is literally 2 lines in app/keepers/keepers.go:

"/ibc.core.client.v1.Query/VerifyMembership":    &ibcclienttypes.QueryVerifyMembershipResponse{},
"/ibc.core.client.v1.Query/VerifyNonMembership": &ibcclienttypes.QueryVerifyMembershipResponse{},

I’ve opened an issue: cosmos/gaia#4023

This is a read-only query with zero security risk. It would allow CosmWasm contracts to leverage the light clients the Hub already maintains, making this and any future cross-chain verification use case fully trustless.

What this enables

With VerifyMembership whitelisted, any developer could deploy a contract on the Hub that:

• Cross-chain compliance gates — KYC on chain A → whitelist on chain B, with no integration work on either chain
• Conditional escrow — release payment when a third-party certifier attests completion
• DVP for regulated assets — bonds that must stay on their issuance chain, settled against USDC on Noble
• Automated treasury management — rebalance across chains when a balance threshold is crossed
• Multi-hop verification — verify state on chain C through chain B, using the Hub as a trust relay

All of these work with zero changes on the observed chains. The Hub becomes a coordination layer, not just a routing layer.

Architecture choices

• One-shot subscriptions — a subscription triggers once and is consumed. For ongoing workflows, the callback contract re-subscribes in its callback. This keeps the protocol simple and the looping logic in user code.
• Watchers are incentive-compatible — the party who benefits from the event is naturally motivated to submit the proof. Watchers serve as a reliability backstop, not the primary mechanism.
• Full value passed to callback — the callback receives the complete proven data (subscription_id, proven_value, height, plus the subscriber’s custom callback_msg). The subscriber contract decides what to do with it.

What I’m looking for

1. Feedback — Does this architecture make sense? What would you build with it?
2. Support for VerifyMembership whitelisting — If you’re a validator or Gaia contributor, please look at cosmos/gaia#4023. This 2-line change would unlock trustless cross-chain state verification for every CosmWasm contract on the Hub.
3. Collaborators — The repo is open source. I’m particularly interested in:
   • Enterprise use cases (compliance, settlement, treasury)
   • Watcher network design and incentives
   • Frontend/UX for the State Explorer (browsing any chain’s state and subscribing in clicks)

---

Happy to answer any questions. The code is all there, the contracts are live, you can poke at them right now.

[Cedrik_Levesque]

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:

1. Unilateral observation
   No changes needed on the observed chain. That is a very strong property.

2. 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 work eventually ties trigger usage to fees, bounties, or even burn.

3. The Hub is the natural coordination point
   Not because this can only exist on the Hub in theory, but because the Hub already has the breadth of connectivity and light-client distribution to make it the most natural place to aggregate this.

To me, this also fits the broader question Cosmos is now facing around ATOM value capture.
If the Hub wants durable utility, it likely needs fee surfaces tied to coordination, verification, and execution — not only passive “be the center of the map” narratives.

My main caution is the same one you raised:
this becomes much stronger once VerifyMembership / VerifyNonMembership are exposed to CosmWasm so the whole flow is anchored directly to Hub light clients. Until then, I see this as a very promising primitive and a serious mainnet POC, but not yet the final trust model.

I’ve been using Hydro since the early rounds, and this feels directionally adjacent:
Hydro showed that Hub-native coordination can matter.
This feels like a candidate for the next layer up the stack.

I’d especially love to see discussion on:

• watcher incentives / liveness design

• fee design for the Hub

• enterprise-facing UX / State Explorer

• what a “watchable state” standard could become over time

Very worth exploring further.

Ced
Lazy. Bad. Experimental.

[Victor118]

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.

Fee model: Do gas fees from increased Hub usage provide enough value by themselves, or does the protocol need its own fee layer? Options range from keeping the primitive entirely free (maximizing adoption, letting value accrue indirectly through ATOM demand), to a protocol fee per verification feeding the community pool, to a staking requirement where only addresses staking a minimum amount of ATOM can create subscriptions. Each has different trade-offs between adoption speed and direct value capture. This is a discussion the community should have.

Watchable state standard: Beyond just consuming existing chain state, we could see a standard emerge — something like an ICS for observable state — where chains structure specific keys for cross-chain consumption: incremental indexes, structured event keys, predictable paths. Chains that adopt the standard become easier to integrate, which creates a network effect around the Hub.

Event propagation: On a more speculative note, you could imagine hubs watching each other, propagating verified state across a network. A proof verified on the Cosmos Hub could be re-proven on another hub, creating a mesh of cross-chain awareness without requiring every chain to maintain light clients for every other chain.

Hydro connection: Your parallel with Hydro is spot on. Hydro proved that Hub-native coordination can matter. Interchain Events generalizes that pattern — any cross-chain state becomes a trigger for on-chain logic. The Hydro contract itself could be a great candidate for being watched by other chains reacting to round results.

Would love to hear your thoughts on the watcher model especially — that feels like the most consequential design decision for how this scales."