2. System overview

This chapter is informative. It is the map of the system: which parties exist, what each one owns, how a command travels from a signature to a finalized fact, and which store holds what. Every statement here is made precisely by a later chapter, and where the two differ the later chapter governs.

Makechain is a small consensus core surrounded by services that hold no authority. The core orders and executes seventeen kinds of command (chapter 8), commits three authenticated data structures in every block header (chapter 11), and produces finalized events (chapter 14). Everything a reader or user touches is built from those outputs and can be re-derived and checked against them.

Three external systems are named once, with what each provides:

• Commonware, at the pinned version v2026.9.0, provides the consensus, ordering, storage, and cryptography primitives. The component-to-primitive map is in ../docs/architecture.md.
• Tempo is the external settlement source for credit imports (chapter 16) and the reference for account-address derivation and configuration bounds (chapter 7).
• mkit is the reference content store and the primary registered commitment scheme mkit-blake3 (chapter 8).

2.1 Roles and boundaries

A commitment on chain implies nothing about object availability. There is no single availability layer: a project may have several, each disclosing content fully, to selected parties, or not at all. The chain records no locator, and a project's layers are discovered off chain (chapter 17 and ../docs/availability-profile.md). A derived view is never a trust boundary (section 4.1), and the obligations it carries, including exposing the finalized height it reflects, are in ../docs/history-query.md.

Seven roles exist, of which only the first participates in consensus. The store and the mirror are storage rather than roles: the exporter writes them, and the proof service, the indexer, and the checker read them. Together they hold complete history in two copies: bodies, certificates, both operation logs from location zero, settlement evidence, and, under DynamicReshareV1, DKG artifacts. The checker, which compares the store's roots against certified headers, and the replay job, which re-executes stored blocks under the ruleset of each height, are duties of the operator who runs the history services rather than roles of their own (chapter 17).

flowchart LR
  subgraph clients["Clients"]
    CLI["CLI, SDK, browser"]
  end
  subgraph edge["Edge (no authority)"]
    GW["Gateway: admission, fan-out, pass-through"]
    IX["Indexer: query tier over the store, receipts"]
    AV["Availability layers: per-project object stores, outside the protocol"]
    RL["Relayer: Tempo proofs to credit imports"]
  end
  subgraph core["Consensus core (validators, n >= 7)"]
    V["Validators: Simplex BFT, marshal, glue, 3-member database set"]
  end
  subgraph history["History (non-voting)"]
    EX["Exporter: executes and prunes like a validator, publishes from a durable queue"]
    ST["Store: blocks, certificates, operation logs, history tables"]
    MI["Mirror: per-block objects, height index, watermark"]
    PS["Proof service: membership inclusion and block-history ancestry at any size"]
  end
  TP["Tempo: settlement deposits, on-ramp only"]
  CLI -- "signed commands" --> GW
  CLI -- "object bytes" --> AV
  GW -- "forward" --> V
  V -- "finalized blocks and certificates" --> EX
  EX -- "blocks, certificates, log slices, history rows" --> ST
  EX -- "blocks, certificates, log slices" --> MI
  ST -- "operation logs" --> PS
  ST -- "stored blocks and history tables" --> IX
  EX -- "current and within-window proofs" --> GW
  PS -- "historical proofs" --> GW
  IX -- "query reads and receipts" --> GW
  GW -- "reads, proofs, receipts" --> CLI
  AV -- "layer-controlled retrieval" --> CLI
  TP -- "certified header and storage proof" --> RL
  RL -- "IMPORT_CREDITS" --> GW

Validators vote and execute, and serve their consensus peers only: votes, block backfill, and state-sync sources for a joining validator or for the exporter, plus diagnostics to their operator. No validator answers a client-facing read. The exporter is a non-voting mesh peer that executes every finalized block, prunes exactly as a validator does, and publishes what it executed; the proof service answers historical proofs from the stored operation logs. Gateways, indexers, and relayers are rebuildable from certified outputs. Availability layers alone hold bytes the chain does not. None of these is a trust boundary (chapter 17), and Tempo is an on-ramp for credits and nothing more (chapter 16).

2.2 The write path

One command, from signature to receipt.

sequenceDiagram
  participant C as Client
  participant G as Gateway
  participant P as Proposer (validator)
  participant Q as Other validators
  participant A as Exporter
  participant S as Store
  participant I as Indexer
  C->>G: signed command with BLAKE3 digest, family wrapper, witnesses
  G->>G: advisory admission on signature, sequence, rate limits
  G->>P: forward
  P->>P: execute candidates under rules_for(active_release) and drop invalid
  P->>Q: proposal of header and body
  Q->>Q: verify by re-executing and re-deriving every header field
  Q-->>P: Simplex votes, then finalization certificate
  P->>A: finalized block and certificate
  A->>A: queue block, certificate, and log slices durably
  A->>S: upload the block, the certificate, the slices, and the block's history rows
  I->>S: read the block's history rows and its events
  I-->>C: CommandFinalized event, and a publication receipt on request

A block is valid only if every command in it is valid. The proposer executes while building, so an invalid command never reaches a block, and verifiers re-execute rather than trust (chapter 12). Every derived header field is re-derived by every validator, and there is no derived field a proposer can assert (chapter 11). Admission at the gateway is advisory only and decides nothing (../docs/operations.md).

2.3 Storage by role

Each store holds one kind of thing, and only some of them are committed in the block header.

The backing primitive chosen for each store, the reason for that choice, and the alternatives rejected are recorded in ../docs/architecture.md.

flowchart TB
  subgraph val["Validator"]
    s1["validity state (full, priced per record)"]
    s2["membership log (window only)"]
    v3["block-history accumulator (compact)"]
    v4["blocks and certificates (retained_marshal_blocks)"]
  end
  subgraph exp["Exporter"]
    e1["validity state (full, priced per record)"]
    e2["membership log (window only)"]
    e3["block-history accumulator (compact)"]
    e4["durable publication queue"]
  end
  subgraph sto["Store"]
    o1["blocks and certificates (forever)"]
    o2["both operation logs, complete"]
    o3["per-block objects, height index, watermark"]
    o4["history tables, projected per block"]
  end
  val -- "finalized blocks and certificates" --> exp
  exp -- "publish" --> sto

Every role that opens the database set commits the same roots and the same floor, and those roles differ only in which bytes they keep (chapter 17). The exporter retains exactly what a validator retains, and completeness lives in the store, which keeps every block, certificate, and operation-log slice forever in two copies of different form.

Two consequences follow. A validator's history retention is bounded while its footprint grows with funded resident state: ordinary account-created records are paid for at creation, deposited families carry a deposit that deletion returns, state creation is rate-limited per block, the membership log is windowed, block bodies are pruned, and the accumulator is compact (chapter 9). And every service outside the core is a projection, so a gateway, an indexer, or a query engine can be wrong or malicious without affecting what the chain attests, which is why the proof kinds of chapter 15 exist for the facts that matter.