18. Layer 0 Finality Hub
18.1 Scope and Trust Model
The L0 Finality Hub builds Quantos checkpoint proofs and connects them to chain-specific adapters. It is an interoperability and attestation subsystem, not a claim that every external chain has a trustless light client. The security of each supported chain depends on the verifier actually implemented for that chain:
| Chain | Validator Set Tracking | Trust Model | Cryptographic Verification |
|---|---|---|---|
| Bitcoin | SPV (full Merkle proof, tx_hash + tx_index) | Majority hashrate | ✅ BitcoinLightClient verifies Merkle path against 80-byte header |
| Ethereum | Sync committees | Ethereum consensus | ✅ Sync committee signatures (BLS) verified natively |
| Cosmos / Tendermint | IBC-compatible validator transitions | BFT consensus | ✅ Validator set transitions signed by previous validator set |
| Solana | RPC polling (getVoteAccounts) | RPC operator | ⚠️ Oracle attestation; no succinct light client available |
| NEAR | RPC polling (validators) | RPC operator | ⚠️ Oracle attestation |
| Aptos / Sui | REST API polling | RPC operator | ⚠️ Oracle attestation |
| Tron | RPC polling (listwitnesses) | RPC operator | ⚠️ Oracle attestation |
| TON | RPC polling (getValidators) | RPC operator | ⚠️ Oracle attestation |
| Polkadot | SCALE-encoded session validators | RPC operator | ⚠️ Oracle attestation |
| Stellar | Horizon API (/quorum) | RPC operator | ⚠️ Oracle attestation |
| Tezos | RPC polling (baking rights) | RPC operator | ⚠️ Oracle attestation |
| Cardano | db-sync API (stake distribution) | RPC operator | ⚠️ Oracle attestation |
What this means: The repository contains different adapter and verifier strategies. A chain must not be advertised as cryptographically verified merely because an adapter exists. In particular, RPC-polled validator data is an oracle dependency; it does not inherit the source chain's consensus security. Each deployment must publish its adapter, verifier, relay quorum and operator assumptions.
18.2 EpochWatcher
EpochWatcher is a background tokio service that polls each registered chain's RPC endpoints and updates the ValidatorSetRegistry when validator sets change. Because the registry uses Arc<RwLock<…>>, all live LightClient instances see updates immediately.
For chains with cryptographic verification (Bitcoin, Ethereum, Cosmos), EpochWatcher is an optimization convenience; the light client could in principle verify transitions independently. For chains relying on RPC polling, EpochWatcher is a trust dependency.
18.3 Commitment-Based STARK Aggregation
l0/stark_prover.rs implements a Winterfell proof for a batch aggregation trace:
- Validator signatures are verified natively outside the arithmetic circuit.
- Each signer contributes
SHA3-256(pubkey || message || raw_signature)as a binding commitment. - The trace proves the commitment and signed-stake accumulation relation.
- A proof commitment is derived from the proof bytes and public inputs.
The raw proof can be verified by the Rust verifier. Some target-chain contracts store or compare a commitment rather than executing the full Winterfell verifier on-chain. Therefore the on-chain path is commitment-based unless a specific target verifier demonstrably verifies the complete proof.
Proof size, generation time, and supported committee size are benchmark-dependent. The repository must not claim sub-second generation or a universal gas cost without a reproducible benchmark and target-chain deployment evidence.
18.4 Finality Directionality
Cross-chain finality is not symmetric:
- Quantos → external chain: Bounded by the configured Quantos checkpoint/finality path, proof generation, relay, and target-chain settlement. No universal seconds figure is established by the repository.
- External chain → Quantos: Bounded by the source chain's own finality, relay policy, and verifier path. The L0 cannot compress another chain's consensus.