Headers And Ingress
How headers, finality signals, and related evidence enter a consumer chain so light clients can advance.
This chapter is technical.
Ingress roles
| Role | Responsibility |
|---|---|
| Source node | Zcash / Crosslink full node (e.g. zebrad family) exporting headers, finality, or RPC |
| Relayer / operator | Formats and submits UpdateClient (and packet/proof messages) to the consumer chain |
| Wasm light client | Validates updates against current client state; advances consensus state |
| Application | Reads verified heights/roots; may gate contract logic or IBC handlers |
Typical flow
Zcash / Crosslink tip
│
▼
Header / finality export (RPC, indexer, custom feeder)
│
▼
Relayer builds client update message
│
▼
Consumer chain: 08-wasm UpdateClient
│
▼
Client state height / root advanced
│
▼
App / contracts act on verified state
Design tips for public verify
- Idempotent updates — submitting an already-known tip should be a no-op or cheap reject, not a halt.
- Multiple relayers — prefer update formats that allow independent operators (historical update support where required).
- Checksum pinning — document the Wasm LC checksum your deployment expects.
- Observability — log client height, last update time, freeze status for public dashboards.
- Separation of concerns — header ingress is not proof verification; keep ZK proof submission as a separate message path.
Related demos
See Demos for developer-facing verify paths that exercise public clients and contracts.