> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molpha.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Architecture
> Components and design invariants.
## Component map
* **Gateway** — the HTTP front: accepts execution requests, dispatches rounds, returns completed `DataUpdateResult` payloads.
* **Node network** — registered operators with secp256k1 signing keys; a deterministically selected subset signs each round.
* **Solana program** — registry, subscriptions, settlement, and maintained `Feed` accounts; permissionless `submit_data_update` re-verifies every write.
* **Stateless verifiers** — one per EVM chain plus Starknet; mirror of the node-key set + `verify()`.
* **SDK** — [`@molpha/sdk`](https://www.npmjs.com/package/@molpha/sdk) (v0.1.0): the facade over gateway + Solana, plus framework-agnostic EVM/Starknet argument builders.
## Design invariants
1. **Stateless verification on EVM/Starknet.** `verify()` holds no feed, round, feed, or reward state; everything arrives in calldata. This is what allows one signed payload to be valid on every chain simultaneously.
2. **No `chainId` in the signed message.** One signing round, every chain.
3. **The signer set is committed by the signature.** `signersBitmap` is inside the signed message.
4. **Selection is derivable on-chain.** The eligible group comes from `(feedId, registryVersion, canonicalTimestamp)` — verifiers re-derive it; nothing about selection is trusted from the caller.
5. **Registry snapshots are immutable.** Historical rounds remain verifiable; freshness/replay policy belongs to the consumer.
6. **Plain-sum aggregation + PoP.** No delinearization coefficients, no precomputed global key; rogue-key safety comes from registration-time proof-of-possession.
The signing math, selection algorithm, and domain separators behind these invariants are detailed in [Cryptography](/protocol/cryptography).