Light Clients
Light clients in this stack are consumer-side programs (often IBC 08-wasm CosmWasm clients) that track Zcash-related consensus and privacy-adjacent state without running a full Zcash node on every appchain.
This chapter is ecosystem-level: which designs exist, how they use Zcash zero-knowledge and consensus primitives, and when to pick one. Implementation repos are maintained by their respective teams—we integrate and document; we do not claim authorship of those libraries.
Credits And Upstream Sources
Libraries and specs below are curated by their upstream teams. Prefer their repositories for correctness, releases, and contribution norms.
| Project | Curated by / origin | Repository |
|---|---|---|
| ICS-08 Wasm light clients (IBC-Go) | Cosmos / IBC-Go maintainers | cosmos/ibc-go — 08-wasm |
| IBC light-client architecture | IBC community | IBC docs, cosmos/ibc (specs including client semantics) |
| IBC v2 / Eureka-oriented programs | Cosmos Solidity IBC Eureka contributors | cosmos/solidity-ibc-eureka |
| cw-ics08-wasm-crosslink | Eureka programs tree (+ monorepo packaging) | programs/cw-ics08-wasm-crosslink |
| cw-ics08-wasm-eth (structural peer) | Same Eureka tree | programs/cw-ics08-wasm-eth |
| Zebra / Crosslink node stack | Shielded Labs / Zebra lineage; permissionlessweb fork for integration | ShieldedLabs/zebra-crosslink, permissionlessweb/zebra-crosslink |
| ics08-wasm client crates (Rust) | IBC-rs maintainers / forks | permissionlessweb/ibc-rs — ics08-wasm (upstream CosmWasm / IBC-rs ecosystem) |
| Tendermint light client crates | Informal / tendermint-rs maintainers | Tendermint-rs light-client packages in the monorepo vendor path |
| CosmWasm contract & host model | CosmWasm core teams | CosmWasm/cosmwasm, book.cosmwasm.com, docs.cosmwasm.com |
Spec-oriented reading for integrators:
- IBC light clients overview (docs site may version-shift; follow current IBC-Go version).
- ICS-08 Wasm module README and ADR notes in ibc-go.
- IBC v2 / multi-hop and Eureka design notes in solidity-ibc-eureka (
docs/, program READMEs) and related monorepo notes such as Mercurydocs/ibc-v2.mdwhen present.
What “Powered By Zcash ZK Primitives” Means
Zcash contributes more than “a hash chain.” Light-client designs in this ecosystem can draw on:
| Primitive family | Role for light clients |
|---|---|
| Proof-of-work headers | Canonical chain work, confirmation depth, pure PoW clients — see Pure PoW Path |
| Crosslink / hybrid finality | Faster finality certificates layered on Zcash work — Crosslink Path |
| ZIP-221 FlyClient-style ideas | Succinct PoW header verification patterns for sparse sampling |
| Halo2 / Orchard-class proving | Validity proofs over batch state, selective disclosure, circuit VKs on the host |
| Nullifiers / note commitments (conceptually) | Privacy-preserving membership and spend-auth adjacent app protocols (via VM + composition, not always inside the LC Wasm) |
The proof VM verifies circuits on the consumer chain; light clients provide verification ability of which Zcash (or hybrid) tip and roots to trust. Together they enable “verify Zcash-grade crypto and headers in CosmWasm.”
Design Families (Summary)
| Design | Trust model | ZK / crypto angle | Status (honest) |
|---|---|---|---|
| Crosslink path | Hybrid finality over PoW | Finality + parent PoW; often paired with app-level Halo2 | Primary implemented LC path in monorepo |
| Pure PoW path | Confirmation depth only | Header work, no Crosslink committee — details & fixtures | Second trust dial; dual-path narrative |
| FlyClient / sparse PoW | Probabilistic PoW proofs | Succinct work proofs (ZIP-221 lineage) | Design / research adjacency for ingress |
| 08-wasm CosmWasm LC | On-chain Wasm client | Host may verify signatures/proofs depending on client | Deployment shape for Crosslink (and peers) |
| IBC v1 classic + IBC v2 / Eureka | Channel / client models per IBC version | Same Wasm packaging; different wire and routing assumptions | Choose stack by consumer chain IBC version |
| App-gated roots via proofs | Application policy | proof_instance_verify on VM after LC tip advances | Composition pattern, not a separate LC binary |
Details: Design Survey. Paths: Crosslink Path, Pure PoW Path, Headers And Ingress.
Integrator Checklist
- Choose a trust dial (pure PoW vs hybrid Crosslink vs future succinct PoW).
- Pin the Wasm checksum / store flow for the 08-wasm client.
- Define ingress (who feeds headers / certificates).
- Separate header advancement from application ZK verification (proof host).
- Align with IBC v1 vs v2 capabilities on the consumer chain.
- Plan for multi-source ecosystems later—the LC section is Zcash-first, not Zcash-only forever.
Next
- Design Survey
- Proof VM for on-chain circuit verify