Skip to content
~/sultan
Chapter 3 crest
Chapter 3 · § 3.5 · Recipe

Cross-Chain Primitives

Committee today. ZK light clients in 12–18 months.

By · Originally published April 2026 · Next review October 2026 · ~5 min

Problem

How does StableZK communicate with peer chains without subordinating to any of them? The cross-chain question is the part of the design where most "sovereign" L1s quietly inherit a different chain's trust model.

Solution

Committee in Phase 1. ZK light clients in Phase 2. Symmetric in Phase 3.

  • Phase 1. Validator-committee-attested bridge primitives. The same trust model as the L1's own consensus, applied to bridge messages.
  • Phase 2. ZK light clients on peer chains, where StableZK proves its state to the peer chain via a verifier contract on that chain. This is the destination architecture. It is 12–18 months out as of this writing.
  • Phase 3. Symmetric ZK light clients on both sides, where each chain proves its state to the other without any committee assumption.

Discussion

This is one of the open work items the cookbook is honest about. Cross-chain ZK is real — there are production examples on specific chain pairs — but it is not production-ready across all the peer chains StableZK needs to bridge to. The Phase 1 committee model is acceptable as a transitional simplification because it does not introduce a new trust assumption; it reuses the trust assumption the L1 itself already operates under. It is not the destination.

△ Warning If you are evaluating StableZK and the bridge architecture matters more to you than the L1 properties, the bridge architecture is the part of the project most likely to take longer than projected. Plan accordingly.

See Also

  • Ch. 1 · Timeline — the Q2 2024 sovereign-L1 decision and why a rollup architecture would have been worse here too
  • FAQ — the bridge questions answered plainly
❦ ❦ ❦