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:- Verify a header against an MMR commitment.
- Verify account proof against header
state_root. - Verify storage proof against account
storage_root. - Optionally persist selected verified fields for later reads.
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.
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/...).
Why this architecture matters
The design separates concerns:- commitment state (MMRs),
- proof checking,
- messaging,
- and operations/maintenance.

