> ## Documentation Index
> Fetch the complete documentation index at: https://docs.herodotus.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> Satellite design: MMR commitments, proof verification, and contract composition

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.