How it works — the architecture
The entire architecture turns on one question you can ask of any piece of data:
"Does this need double-spend protection or composability?" — Yes → Base A. No → Base B.
That boundary isn't a guideline; it's enforced by the Asset Registry (the UAC primitive), so Base B can never hold value — by construction, not by good behaviour.
On top of that split sit five assurance tiers. Volume lives at the bottom, commitments at the top — so the three genuinely hard walls (ZK proofs, permanent data availability, consensus) only ever press on the small, valuable sliver:
| Tier | Core assurance | Data availability | Share of volume |
|---|---|---|---|
| T0 Root | Final settlement, ZK | Permanent | <0.01% |
| T1 Value | Double-spend protection, ZK validity | Long-lived | ~1% |
| T2 Interactive | Consistent state, ZK/fraud proof | Medium-term | ~9% |
| T3 Events | Tamper-evidence + timestamp + inclusion | Prune ~weeks | ~85% |
| T4 Edge | Attestation at checkpoint | Ephemeral | ~5% |
Two mechanisms make it fly:
- READ vs WRITE. Most cross-chain needs are just verifying "X happened on chain A" — a READ (via Interchain Queries): cheap, safe, effectively unlimited. Only atomic state change — a WRITE (via IBC v2/Eureka + ICA) — is expensive, and it is deliberately kept below 0.1% of traffic.
- Security follows the asset. Every asset carries a minimum security-class; a high-value asset simply cannot exist on Base B. So "downgrade" attacks vanish structurally, and the safety of value rests on ZK soundness plus global economic capital — not on trusting a handful of validators.
The magic, made concrete: a completely separate chain can prove that a single "like" happened — with one proof check, no stateful message, no re-execution. That is verify, don't re-execute, and it is the whole thesis in one diagram.