[META] Gno.land <> Union <> EVM connection

[HeesungB]

1. Background

The goal of this work is to enable IBC-based token transfers between the Gno.land chain and EVM-family chains (Ethereum, Base, etc.).

A direct connection is impractical due to differences in consensus mechanisms, so routing through the Union chain as a relay infrastructure is judged to be the most feasible path.

Packet payloads are encoded/decoded on both sides per the UCS03-ZKGM standard.
The light client only guarantees packet authenticity; payload semantics are handled by the ZKGM handler.

2. Options

There are three candidate paths for Gno.land ↔ EVM token transfer. All of them ultimately involve Union at one of the endpoints, so "can we eliminate the Union dependency?" is not a meaningful evaluation axis.
The actual evaluation axes are (1) UX, (2) engineering effort to mainnet, and (3) operational risk.

Option A — Current path: AtomOne ↔ Osmosis ↔ EVM

• Route: Gno —(IBC v2)→ AtomOne —(IBC v1)→ Osmosis —(Union ZKGM)→ EVM
• Pros
  • Already works in production. Almost no new stdlib, light client, or contract work required.
  • Uses only the standard Cosmos IBC v1.
  • Reuses already-shipped Cosmos IBC primitives end-to-end (IBC v2 between Gno and AtomOne, IBC v1 between AtomOne and Osmosis). No CometBLS verifier, no ZKGM contract on the Gno side.
• Cons
  • Two-signature UX (Gno→AtomOne, then AtomOne→EVM side). A 1-click flow is impossible.
  • Osmosis is in maintenance-only mode. After the failed Cosmos Hub merger, support for new integrations and routes is being phased down → operational risk grows over time.
  • The EVM endpoint is still handled by Union, so this is a double dependency on Osmosis + Union.
  • It also diverges from the original "AtomOne as the IBC hub" vision (because Osmosis sits in the middle).
  • Still needs an IBC v2 stack on the Gno side (light client + ICS26 router) and an AtomOne ibc-go v10 upgrade — so it is not zero-effort.

Option B — IBC Eureka (IBC v2 directly to EVM)

• Route: Gno → (IBC v2 / Eureka) → EVM
• Pros
  • Follows the standard IBC v2, so there is no dependency on a specific operator like Union.
• Cons
  • An SP1 (ZK prover) infrastructure is a hard prerequisite. Gno would have to operate SP1, and the cost is excessive.

Option C — Direct Union Bridge (selected)

• Route: Gno ↔ Union ↔ EVM (Ethereum, Base, …)
• Pros
  • One-hop UX (single signature). Denom tracking, failure surface, and latency all stay simple.
  • The Union mainnet (union-1) already runs CometBLS + Galois ZK Verifier + UCS03-ZKGM. We only need to add the integrations on both endpoints.
  • Once Gno gains a CometBLS Light Client + ZKGM contract, multiple EVM chains that Union is already connected to become reachable in one shot (no per-chain light client required).
  • A significant portion is already in flight: Alex has drafted a CometBLS Groth16 verifier in gnolang/gno#5583 in two variants — native-heavy and gno-heavy.
  • The Light Client can be derived from the existing gno.land/p/aib/ibc/lightclient/tendermint → assessed as trivial.
• Cons
  • Requires net-new implementation on Gno: CometBLS pairing / Groth16 verifier (as a native precompile or in gno), the Light Client, and the UCS03-ZKGM contract. Non-trivial effort.
  • Introduces a dependency on Union infrastructure (union-1 availability, Voyager relayer, UCS03 spec churn risk). That said, Option A also routes through Union at the endpoint, so the SPOF itself cannot be avoided.

Decision: Option C

• A is structurally weak due to Osmosis maintenance mode + the two-signature UX, and it diverges from the "AtomOne hub" vision.
• B was already ruled out due to SP1 cost.
• C is the only option where four things line up: 1-hop UX + simultaneous coverage of multiple EVM chains + reuse of Union's battle-tested infrastructure + work already in progress
  via PR feat: Implement CometBLS Groth 16 verifier in both gno-heavy or native-heavy versions #5583. The Union SPOF is accepted as a known trade-off.

3. Progress / Plan

• Phase 1. Verify Union infrastructure
  • Confirm mainnet union-1 v1.2.2 in operation → https://docs.union.build/infrastructure/mainnet/
  • Confirm Galois ZK prover → https://docs.union.build/architecture/galois/
  • Confirm Voyager relayer → https://github.com/unionlabs/union/tree/main/voyager
  • Ethereum/Base light client → https://github.com/unionlabs/union/blob/main/evm/contracts/lib/CometblsZKVerifier.sol
  • UCS03-ZKGM message standard → https://docs.union.build/ucs/03/
• Phase 2. Add CometBLS to Gno
  • Spec review
    • https://github.com/unionlabs/union/blob/main/evm/contracts/lib/CometblsZKVerifier.sol
    • https://github.com/unionlabs/union/blob/main/cosmwasm/lightclient/cometbls/src/zkp_verifier.rs
  • Implementation progress
    • feat: Implement CometBLS Groth 16 verifier in both gno-heavy or native-heavy versions #5583
    • A - native-heavy
    • B - gno-heavy
• Phase 3. Add Gno CometBLS Light Client
  • Spec review
    • https://github.com/unionlabs/union/tree/main/cosmwasm/lightclient/cometbls
    • https://github.com/unionlabs/union/tree/main/cosmwasm/lightclient/tendermint
    • https://github.com/allinbits/gno-realms/blob/master/gno.land/p/aib/ibc/lightclient/tendermint/verify.gno
    • https://github.com/unionlabs/union/tree/main/cosmwasm/lightclient/state-lens-ics23-mpt
    • https://github.com/unionlabs/union/blob/main/lib/state-lens-light-client-types/src/client_state.rs
    • https://github.com/unionlabs/union/blob/main/lib/state-lens-light-client-types/src/header.rs
    • https://github.com/unionlabs/union/tree/main/lib/state-lens-ics23-mpt-light-client-types
    • https://docs.union.build/concepts/conditional-light-clients/
  • Implementation progress
    • state-lens-ics23-mpt on Gno (verifies EVM state via Union)
    • TBD
  • Union header test vectors
    • Even after the Light Client is built, validate against real data
• Phase 4. Union IBC core spec on Gno, ZKGM Contract
  • Spec review
    • https://github.com/unionlabs/union/tree/main/cosmwasm/app/ucs03-zkgm
    • https://docs.union.build/ucs/03/
    • https://github.com/unionlabs/union/tree/main/cosmwasm/core
    • https://github.com/unionlabs/union/tree/main/evm/contracts/core
  • Implementation progress
    • UCS03-ZKGM encode/decode
    • TokenOrder
    • channels / packets / handler (Union variant, not standard ibc-go)
    • TBD
• Phase 5. Register Gno Light Client on Union
  • Implementation progress
    • Review the Tendermint Light Client on the Union side
    • Verify Gno header compatibility
    • Register the Gno chain spec
• Phase 6. Contract deployment + Voyager relayer channel opening
  • Reference
    • https://docs.union.build/connect/integration-requirements/
  • Implementation progress
    • Deploy the Union Light Client contract on Gno
    • Deploy the Gno Light Client contract on Union
    • Set up the Voyager instance
    • Open the channel
    • End-to-end transfer test
    • Voyager indexing readiness for gno.land
      • Confirm gno.land RPC ≈ standard Tendermint RPC (https://rpc.gno.land)
      • Identify gaps and fix on Gno side or via Voyager adapter
    • State lens client deployment per target EVM chain
      • On Gno: state-lens client tracking each EVM chain
      • On each EVM: state-lens client tracking Gno

4. Open Decisions

TBD

5. Dependencies & Risks

TBD

[clockworkgr]

Just a slight correction. Option A is IBC v2 between GNO and AtomOne and IBC v1 from AtomOne to Osmosis (for the sake of completeness)

[HeesungB]

Just a slight correction. Option A is IBC v2 between GNO and AtomOne and IBC v1 from AtomOne to Osmosis (for the sake of completeness)

@clockworkgr Thanks — fixed in the issue body. Option A's "Pros" line now reflects the IBC v2 (Gno↔AtomOne) + IBC v1
(AtomOne↔Osmosis) split, and a Cons bullet is added to make explicit that this still needs an IBC v2 stack on Gno + an ibc-go
v10 upgrade on AtomOne.