Skip to main content
Satellite is implemented as a modular proxy system (Diamond pattern) where functionality is split into modules (“facets”) and routed through a central contract.

Core architectural ideas

1) MMR-based block commitments

Satellite stores Merkle Mountain Range (MMR) roots and sizes per chain and MMR ID.
  • MMRs represent append-only commitments to block headers.
  • Roots are tracked by hashing function (Keccak and Poseidon are supported in the codebase).
  • Parent hashes are cached and reused for growth continuation and cross-chain syncing.

2) Verification pipeline

The verification flow is layered:
  1. Verify a header against an MMR commitment.
  2. Verify account proof against header state_root.
  3. Verify storage proof against account storage_root.
  4. Optionally persist selected verified fields for later reads.
This is why Satellite read functions can return historical data with cryptographic grounding.

3) Two growth modes

Satellite supports two ways to grow MMRs:
  • On-chain growth: append batches directly in-contract from block header chains.
  • SHARP/off-chain growth: verify Cairo fact outputs and update MMR roots/sizes from proven jobs.
Off-chain growth is designed for scalability while preserving verifiability.

4) Cross-chain transport

Satellite can send and receive parent hashes, MMR snapshots, and Cairo fact hashes across chains via messaging modules, using registry-defined chain connections.

Solidity + Cairo implementations

The repository includes both:
  • Solidity contracts for EVM deployments (solidity/src/...).
  • Cairo contract components for Starknet (cairo/src/...).
Both sides implement analogous concepts: MMR state, proof verification logic, and task/fact authentication modules.

Why this architecture matters

The design separates concerns:
  • commitment state (MMRs),
  • proof checking,
  • messaging,
  • and operations/maintenance.
That modularity helps evolve components without redesigning the whole system and keeps verification-critical logic explicit.