Makechain module and process architecture

This document defines responsibility, dependency direction, and process assembly before repository or crate layout. It preserves protocol-first development, the separate consuming application, and trusted permissioned operators. It introduces no generic blockchain framework, database framework, custom consensus, production hardware profile, or application/product scaffold.

Status labels used below: fixed by the current specification or an accepted owner decision; proposed for review; deferred with a named gate; open pending a decision or evidence.

1. Design rules

1. Fixed: canonical protocol meaning is independent of processes, cloud services, and storage products. One Rust implementation produces native and wasm verification behavior.
2. Fixed: one deterministic executor owns command semantics for proposal, verification, and application. Admission may call it for an advisory dry-run but never becomes validity authority.
3. Fixed: Commonware owns Simplex, marshal, stateful orchestration, DKG progression, database-set barriers, pruning, and sync mechanics. Makechain supplies the exact application, membership, release, schema, mesh-set, and storage-adapter contracts those primitives require.
4. Fixed: three authenticated database members have distinct proof and retention semantics. They are not hidden behind an all-purpose key/value repository or transaction abstraction.
5. Fixed: finalized events, query tables, and status are derived views. Object availability is a separate external fact; it cannot be reconstructed from a chain commitment. Proof verification starts from caller trust material and authenticated headers, never a service claim.
6. Accepted development direction: the first disposable devnet uses a fixed committee and one epoch, then resets to real DKG/reshare qualification. Its minimal process co-location is fixed in §5; production placement remains deferred. Correctness within the enabled profile is mandatory; production hardening follows its stated gates.

2. Domain modules and dependency direction

clients / external services
   └─ admission, proof, query, export adapters
process assembly
   ├─ Commonware actors ── runtime / mesh / storage / custody
   └─ Makechain application adapter
         ├─ application executor ── schema / release / command authentication
         │       └─ owned typed-state interface
         └─ three-member state adapter ── exact glue DatabaseSet / QMDB types
proof verifier ── schema / release profiles / Commonware crypto and proof types

Arrows point toward dependencies. Process composition is outside the modules; co-location does not permit a dependency to reverse.

Inner dependencies on the specifically selected Commonware codec, cryptography, BMT, and QMDB primitives are intentional. A broad trait wall around them would hide consensus-critical behavior without providing a second real adapter.

Forbidden edges

• Schema, releases, authentication, execution, and proof verification → cloud SDKs, HTTP servers, object storage, query engines, or node configuration.
• Executor → Simplex rounds, marshal archives, durable database handles, wall-clock time, admission pools, indexers, or availability reads.
• Consensus/state → query tables, events as inputs, service “not found,” object presence, or gateway status.
• Proof verifier → gateway trust, server-selected chain identity, unauthenticated header/format hints, or native-only code unavailable to wasm.
• DKG/mesh transport → application authorization; transport membership never selects voters.
• Any service → a second implementation of canonical encoding, signing, release rules, or command transitions.

3. Core domain interfaces

These are semantic interfaces, not Rust trait or crate prescriptions.

ExecuteOrderedBlock is shared by propose, verify, and apply. Proposal mode may discard an invalid candidate before fixing the body; verification rejects a body containing any invalid command; apply reconstructs ancestors/winners. Those control outcomes differ, but EvaluateCommand, overlay order, resource reservation, roots, and events do not. Verify is cancellable and side-effect free. Apply returns database operations to Commonware; it does not persist them itself.

3.1 Stateful application adapter

The Makechain adapter implements the pinned glue::stateful::Application interface directly. The following contract is fixed even though Rust module paths and canonical field layouts remain P3/P5 work.

ExecuteOrderedBlock and its overlay are one implementation used by the first three execution calls. Adapter control flow may differ, but command evaluation, reservations, MerkleizeBlock root construction, and header comparison may not. Commonware owns ancestry reconstruction, pending-branch lifetime, database application, barriers, pruning, and marshal acknowledgement.

Genesis database handoff

Pinned Stateful does not call Application::apply for genesis. On the marshal-start path it opens the database set, treats genesis as the already-processed anchor, and compares the committed targets with sync_targets(genesis); a mismatch enters rewind recovery, which cannot advance a fresh database to a post-bootstrap genesis target. A redelivered genesis is acknowledged without running the application hooks. Makechain therefore owns one pre-Stateful bootstrap task; no second component may seed genesis records.

The task first derives the complete chainspec, chain_id, body, and every genesis-header input that does not depend on application state. It opens only the current-state member at its native bootstrap target and builds one bounded batch containing the canonical protocol-genesis records in increasing state-key order. Merkleization is speculative: the task uses its canonical root and sync target to construct and verify the complete genesis block and hash before applying any current-state operation. It then applies the exact batch, starts and awaits that member's durability handle, drops the handle, reopens the member, and requires both canonical root and sync target to equal the genesis reference before Stateful or a network actor starts. Mutation failure consumes the owned database handle and is fatal-local; recovery reopens the partition rather than continuing with an in-memory object.

Membership and history remain at their pinned native bootstrap commitments for genesis. The task does not merkleize an empty batch for them because a keyless empty batch still appends a commit operation. The expected current root and target are the idempotence marker: native bootstrap means the task may build and apply once, exact genesis means it must not apply again, and any other target or root is fatal-local. No separate local marker or database initialization flag selects this path. When the application SyncPlan has a selected or persisted peer-sync floor, the task skips genesis seeding and state sync reconstructs the certified operations in fresh members. Ordinary restart also skips seeding because its committed current member already equals or advances from the genesis anchor.

Source basis at v2026.9.0: glue/src/stateful/actor/syncer/mod.rs:380-451 opens and reconciles the marshal anchor; glue/src/stateful/actor/core/processing.rs:425-445 treats that anchor's redelivery as a no-op; and the current, standard-keyless, and compact-keyless ManagedDb::initial_sync_target implementations use the native bootstrap commitment at operation size one. This source behavior is the reason genesis seeding is an engine-assembly responsibility rather than an executor transition.

3.2 Admission and proposal interfaces

Admission and proposal deliberately use separate state and work adapters.

The snapshot interface is separate from OpenParentView: advisory admission sees one finalized cut; proposal, verification, and replay receive branch-scoped Commonware batches. They share canonical schema, authentication, and EvaluateCommand, but no mutable view, semaphore, queue, or work budget. This resolves A3 without relying on a generic repository interface.

In the first devnet, OpenAdmissionSnapshot reads a separately owned derived projection updated by certified sequential block replay. The projection commits its explicit admission records and checkpoint together, then atomically swaps the readable snapshot. It may lag and return NotReady; it never reads the live QMDB batches. A later production adapter may use an authenticated follower or proof-backed snapshot without changing callers.

3.3 Finalized export interface

EnqueueFinalized is a count-and-byte-bounded in-memory hint channel. It is deliberately lossy: Queued, Coalesced, Full, and Closed are observable outcomes, and neither Full nor process exit blocks Stateful. The exporter owns one durable at-least-once staging queue and one durable ExportWatermark { chain_id, next_height, predecessor_hash }.

The exporter enforces its durable queue bound before Commonware enqueue using tip - ack_floor plus the encoded bytes of non-pruned entries, recomputed during restart replay. At the bound the finalized hook waits for space instead of skipping the append, which holds back the block's marshal acknowledgement until the drain frees an entry (R-17.10); no height is left unstaged. Commonware supplies durable FIFO positions and restart redelivery, while Makechain owns this admission bound and never treats queue presence as exported progress.

The worker always computes work from the watermark and the queue, never from a hint; the queue entry is the only source of a height's material (R-17.10):

1. Select exactly next_height, take its canonical body/header/finality evidence and both operation-log ranges, each with its operation-range proof and pinned nodes, from its queue entry, and verify continuity from predecessor_hash.
2. Upload the operation ranges, the block, the certificate, and the projected history rows to the exoware store in one batch, and publish the same per-block object to the mirror with create-if-absent semantics; an existing different digest is fatal-local. Re-derived event inputs are built from the same material. Uploads are idempotent and may overlap or arrive out of order, so a retry repeats the identical range.
3. Verify the uploaded rows and the published mirror object, then atomically persist the next watermark. Only afterward acknowledge/prune the staging entry.
4. Repeat until the highest staged height. A hint can wake or coalesce work, but can never skip a height.

On restart the Commonware queue re-delivers every non-pruned item and the drain resumes from the watermark; marshal redelivers every block above the processed height, whose hooks stage it again. If the queue is unavailable after an interrupted mutation, reopen it from its partition; a height above the watermark and at or below the highest returned hook with no queue entry, outside a state-synced range, is a fatal publication gap: stop publication and alert (R-17.10). The scan keeps only watermark sequencing and the mirror height-index comparison. This resolves A4 without making exporter durability part of any validator's consensus acknowledgement; the wait at the queue bound holds back only the exporter's own marshal acknowledgement (R-12.25).

4. Commonware assembly and ownership

Fixed production baseline: Tokio runtime; authenticated lookup mesh; Simplex with Random V1 rotating terms; marshal::standard::Deferred; dkg::reshare::Application; stateful::Stateful; the Makechain application; a three-tuple DatabaseSet; one shared application SyncPlan; one injected parallel strategy; and the separate DKG sync plan/fence/gate. Coding marshal and stable terms require later release decisions; an upstream Commonware fork is prohibited.

The canonical header carries history as CompactTarget { root, size }. Every node role, validator and exporter alike, runs the compact history adapter and consumes that target directly, and every role supplies inactivity floor zero when merkleizing a history batch, so all roles execute the same encoded operation stream and obtain the same root. The full operation history lives in the store, rebuilt from the slices the exporter uploads, and the full target Target { root, range: 0..size } is derived there as a proof-service reconstruction step rather than by any node's startup check. That reconstruction must not use Commonware's native TryFrom<&CompactTarget>: at the pinned revision it deliberately creates size - 1..size, which retains only the last operation. Commonware's compact keyless implementation documents that compact and full databases compute the same root when they receive the identical encoded operation stream and inactivity floor (storage/src/qmdb/keyless/compact.rs; conversion in storage/src/qmdb/sync/target.rs:112-128, revision pinned below).

Background work and fault ownership

The finalized application hook sees readable state before the database-set durability barrier and may be redelivered or skipped by state sync. It hands off bounded owned data promptly. Exporters and indexers advance their own watermarks only after durable publication; an exporter publishes only from its queue entries (R-17.10), and an indexer fills gaps from the stored blocks. A finalized event is never a receipt; proof availability is a separate milestone.

Pinned source basis, not Makechain qualification evidence: Commonware v2026.9.0 (d476a2361ce6840d2b9d0aa6fb30a924429046d4), especially glue::stateful, glue::dkg::{bootstrap,reshare}, consensus::marshal::standard::Deferred, and the QMDB adapters.

The exact primitive mapping at that revision is: application calls and cancellation from glue/src/stateful/mod.rs:124-390; tuple member batches/barriers/readers from glue/src/stateful/db/mod.rs:210-435,966-1084; staged current-state reads from glue/src/stateful/db/current.rs; and the export staging buffer from storage/src/queue/{mod,shared,storage}.rs. The queue is durable and at least once, exposes cloned writers and one reader, and persists pruning only on sync; it does not provide Makechain's byte limit, certified gap choice, artifact idempotence, or exporter watermark, so those remain in the Finalized export module rather than being attributed to Commonware.

5. Process assemblies

Logical roles remain distinct even when one process hosts several adapters.

Minimal development composition (fixed design): run each of the seven validator identities as a separate engine process, and co-locate its local admission adapter only. One exporter process may also host the store and the proof service for the first slice; gateway, indexer/query, settlement fixture tool, and the availability-layer test adapter remain separate processes only when their scenario is exercised. Preserve interfaces, separate durable partitions/watermarks, and proof trust boundaries. Use the real three-member database set and executor from the first end-to-end slice. Deterministic-runtime test adapters may replay captured authentic Tempo evidence and replace availability/object-storage transport, while using the real codec/verifier contracts. No adapter may synthesize a positive Tempo certificate or bypass import verification. Devnets/testnets require Moderato proofs; mainnet requires Tempo mainnet proofs. No genesis credit allocations or Makechain faucet bypass are permitted. The first funded slice imports credits before account initialization; see operations.

Co-location is a process-count choice only. Seven identities in one project, cluster, region, or administrative team are not claimed as independent trust or failure domains. SDK, CLI, explorer, website, and the separate consuming application are deferred consumers; no early scaffold is part of this architecture definition.

Production composition (fixed responsibilities, open placement): separate validator identities; one active exporter and one standby, failure-isolated from each other so their durable queues cannot be lost in one event; two failure-isolated store copies, the exoware store and the mirror bucket; independently scalable admission, export/query, and relayer processes, plus the availability layers described below. Low/medium/high workload and machine counts remain operating-envelope/P4 inputs; module boundaries do not change with size.

Availability is not one service. A project may be served by several availability layers, each with its own authentication, disclosure and retrieval policy, and the chain records no locator for any of them: a project's layers are announced off chain by messages signed with the project's keys. No protocol role depends on a particular layer, and object unavailability never changes the validity of a finalized publication. The nine obligations a layer takes on when it serves a Makechain project are in availability profile.

For the accepted first shared devnet, the mirror's per-block objects use the GCS adapter defined in operations. That decision excludes repository objects, does not authenticate protocol bytes, and does not select production replication or store placement.

5.1 Exporter, store, and proof service

An exporter is a real non-voting Stateful node on the same binary, not a file mirror. It executes every finalized block with the production executor, uses the same three-member tuple and root parameters, and prunes exactly as a validator does: validity state at active size, the membership log windowed to [floor, size), and the block-history accumulator compact. It checks all three targets plus canonical state_root at each certified cut. Its marshal block store prunes after retained_marshal_blocks like a validator's; a block it has not yet published stays readable from its durable queue, which releases an entry only after the store and the mirror both accepted it. Proof workers receive read-only handles; they never mutate the live databases.

An exporter state-syncs at its first installation and never again; afterwards it follows marshal, which is glue's own rule for a node whose sync has completed. Under R-17.21 state sync installs a height range without running the finalized hook, so nothing that range contains reaches the installing node's queue. On completion the node records its sync anchor A durably, and its own queue coverage begins at A + 1. From the start of the installation until A is recorded, the node re-evaluates at every retargeting of its sync that every height in (W, current target] is durable elsewhere, W being the publication watermark observed in both the store and the mirror at the start of the installation: either the publication watermark has reached the current target, or the other roster member is healthy, meaning its queue coverage is at least the current target and its publication watermark has advanced within the exporter publish-lag bound. If neither holds at any evaluation, the node aborts the installation and alerts; an installation that completes anyway loses (W, A] under the first cause of the history-range-loss risk in specification section 4.4 (R-17.21). Because that coverage carries the safety, the sync target is free, which is what lets a fresh installation, including a replacement standby, sync to a recent target and start with an empty queue. The finalization the plan pins as that target is read from the store's finalized-by-height record and is certificate-verified before the plan adopts it, since the store authenticates no writer. An exporter for which max(own queue coverage, publication watermark) lies below the validators' retained window has no source for the missing range, so it stops and alerts instead of syncing. The same rule binds the standby.

Publication starts in the capture hook, which runs before apply, and continues in the finalized hook, which runs after apply and before pruning (R-17.10). In capture the exporter extracts the block's slices of the membership-log and block-history operation logs from the two members' merkleized batches: the raw canonical operation bytes of each range together with that range's Commonware operation-range proof and pinned nodes, which are exactly the inputs the exoware writer authenticates against a caller-supplied root. It cannot do this later, because a compact batch proves its operations only until it is applied and the compact member keeps no history (storage/src/qmdb/keyless/compact.rs:1-8), and finalized receives readers but no batch (glue/src/stateful/actor/processor/mod.rs:939-962). In finalized it appends the block, its finalization certificate, and those two ranges to a local durable queue (commonware_storage::queue) and returns. A drain task uploads each entry to the store and to the mirror, retries forever, and acknowledges the queue position only after both have accepted it. An outage grows the local queue; only at the queue bound does the hook wait, holding back the block's marshal acknowledgement. Uploads are idempotent, so a retry repeats the identical range rather than reconstructing one.

The drain commits block batches to the store strictly in height order, one at a time, because a query bounded by a published watermark H would otherwise miss the rows of a lower height whose batch had not landed yet. Concurrency is admitted in two places that cannot reorder a height: the qmdb node rows staged ahead of the ordered batch, and the mirror uploads, which are content-addressed per block and carry their own watermark advanced only after the per-block object and its height-index entry are both readable.

The store is two copies of the same history, and either is rebuildable from the other.

• The exoware store: exoware-simplex for blocks and certificates, keyed by digest for headers and blocks, by epoch and view for Notarized and Finalized records, with a finalized-by-height index; exoware-qmdb for both operation logs, which persists Merkle nodes as ranges arrive and answers historical roots and proofs at any caller-chosen size; and exoware-sql for the history tables, which is the query tier described in history-query.md. The exporter projects each block's rows for those tables inside the same upload batch, so the rows land atomically with the block, its certificate, and both slices. All three sit behind exoware-server, a backend-agnostic ConnectRPC router over the Sequence, Ingest, Query, Prune, Log, and Retention capability traits, on a RocksDB backend hardened from the simulator implementation and placed on a persistent disk with snapshots. exoware ships no replication, snapshot, or backup of its own, and its server carries no authentication, so the disk snapshots, the mirror, and the private-network placement in section 3.3 of operations.md are all Makechain's.
• The mirror: one raw object per block, holding the block, the certificate, and both slices, content-addressed by block_hash, with a height index and a durable watermark, on an object-storage bucket under a retention lock, kept forever. A second provider may be added later by replaying the mirror.

The proof service is the exoware operation-log service plus the Makechain checker. exoware answers membership inclusion for any location against the operation-log root at any size, and block-history ancestry, from its persisted Merkle nodes; Makechain writes no prover. exoware verifies a proof's internal consistency but never compares it against an external commitment, because the trusted root is the caller's input. The checker supplies that comparison: at every ingested block it asserts that the store's root at that size equals the header's membership_target and history_target, and a mismatch fails ingestion loudly rather than failing a proof request later.

The checker takes those targets from certificate-verified headers only. It verifies each header's finalization certificate against its own trust anchor before it compares anything, because the store authenticates no writer and performs no certificate verification of its own, so a header and a log read back from the store are self-consistent whoever wrote them. Reading the comparand from the store would therefore compare the store against itself. The checker is detective rather than preventive, since proofs are servable from the moment a watermark is published, and its unique value is detecting a foreign write or corruption; the periodic replay job verifies certificates the same way. Stopping ingestion is a concrete act: the checker signals the active exporter's drain to halt, so nothing further enters the store, while the store keeps serving the range it already holds.

The proof service maps the header's compact (root, size) to the full target Target { root, range: 0..size } from the store's published operation logs, requiring exact root equality and a nonzero valid size. That reconstruction happens in the proof service alone, never in a node's readiness check, and it must not use the library's compact-to-full convenience conversion, which retains only the last operation.

Historical current-state proofs are not offered. The exporter serves current-state proofs, with activeness, and within-window membership proofs from its live databases behind a read lock. A later release may add proofs at an older height by batch replay of stored blocks into a fresh instance; the live current database is never rewound for a request. Validators join and restart by state sync from validators, so no bootstrap artifact is on the startup path and the tiled bootstrap format is deferred.

One active exporter publishes and one standby follower runs with publication off, resuming from the store watermark when it takes over. That is a Makechain simplicity choice, not an exoware constraint: uploads may come from several workers concurrently, and only the publication watermark has one logical owner. This closes A5's assembly choice while keeping an unmeasured interval out of the protocol.

Publication off does not mean queue off. Under R-17.22 the standby follows every finalized block and appends the same durable queue entry the active appends, holding the block, its certificate, both operation-log slices, and the projected rows. It uploads nothing; it releases an entry only when it observes the store and the mirror watermark past that height. Its queue therefore holds exactly the range the active exporter has not yet made durable in both copies, which is what makes it the third recovery source when an active exporter loses its disk with an undrained queue. That value exists only if the two fail separately, so R-17.15 requires the standby to be failure-isolated from the active, sharing no host, no disk, and no power or network failure domain.

6. Reset-bound fixed-committee profile

Accepted owner policy: disposable pre-mainnet networks may be reset explicitly to a new genesis and chain_id; a reset makes no history or credit preservation promise.

Accepted by the owner, 2026-09-19: the first disposable devnet uses seven fixed validators in epoch zero with pre-generated threshold output/shares, threshold VRF, a constant signing-scheme provider, an effectively unbounded fixed epocher, and no continuous reshare actor. This follows the simpler fixed assembly demonstrated by Constantinople, while Commonware itself separates one-shot bootstrap from continuous reshare. The material is trusted-dealer custody, not trustless genesis. Removing reshare simplifies orchestration; it promises no intrinsic latency or throughput improvement. The constant scheme provider is not epoch authorization: engine, block-context, and proof checks must enforce epoch zero. See the source evidence ↗ (external site) for exact pinned mechanisms.

The specification binds FixedEpochZeroV1 or DynamicReshareV1 in the genesis chainspec (specification section 5.4). Canonical bytes remain to freeze. The fixed profile deterministically rejects validator-set schedule commands and consensus-critical release scheduling in both admission and execution. It may not accept them as no-ops, hide them behind a local feature flag, or claim all seventeen production commands work. Epoch length and the group identity cannot be changed in place under the current specification. The accepted development path moves from the fixed profile to DKG/reshare qualification by an explicit reset/new chain_id, with no history or credit migration promise. It does not require every pre-mainnet configuration change to reset.

Source basis, not qualification: Commonware glue/src/dkg/mod.rs:1-15, bootstrap/mod.rs:1-10, and reshare/mod.rs:18-165 at the pinned tag separate one-shot bootstrap from continuous reshare. Constantinople 42d0b3a demonstrates a fixed epoch-zero assembly with pre-generated output/share; it does not establish production custody or Makechain conformance.

Every pre-mainnet reset gets a new genesis and chain identity. Stable-leader experiments are a separate consensus choice and gain no approval from this simplification; Random/rotating remains the production baseline until an explicit specification decision and qualification.

7. Workflow ownership

8. Deferred work and validation gates

Deferred product SDK, CLI, explorer, website, and broad service work may begin only when the contract it consumes has the corresponding gate evidence. Fixed-profile evidence remains useful but is never credited to a blocked dynamic-profile gate.

9. Architecture decision disposition

P2 now has an owner and implementable semantic interface for every responsibility and process. Review does not change protocol validity, authorize deployment, or mark any qualification result as measured. P3 byte freeze and runtime qualification are downstream gates, not reasons to leave module ownership undecided.

10. Commonware primitive map and storage decisions

This section holds material formerly stated in the specification and is not normative: the specification and its companions remain authoritative for every rule. It supports specification chapter 2 (system overview), chapter 6 (encoding and digests), chapter 9 (state and record lifecycle), chapter 11 (blocks and headers), and chapter 17 (node roles and the database set).

Section 4 of this document already carries an equivalent table at a different granularity: it maps each Commonware seam to what Makechain supplies, what Commonware owns, and the required check. The table in section 10.1 maps each component to the primitive it uses and that primitive's stability. The two are read together; neither replaces the other. The fixed production baseline paragraph in section 4 states the same assembly in prose.

10.1 Primitive map

Every component uses the Commonware primitive that fits, ALPHA included. Where no primitive exists, the component is named in section 10.4 so that nothing is assumed. Stability is recorded at v2026.9.0. Bumping an ALPHA dependency is presumed to need a release, classified by the specification's storage-and-dependency-change rules, and re-runs the ALPHA parity set in section 11 of validation.md.

Two notes on the hasher rows:

• The proof-path members and the command root use Makechain's local Keccak256 implementation of the pinned commonware_cryptography::Hasher (follow-up F13). The proof path is everything a verifier hashes between a finalization certificate and a proven fact: block_hash, the merkleization of the three authenticated databases, the membership leaf, the block-history leaf, and command_root. The two leaves a contract must bind to an outside fact are Keccak256 over the fact itself: the command-tree leaf is Keccak256(canonical SignedCommand bytes) and the membership leaf is Keccak256(project_id || scheme_id || native_id), so neither binding needs a BLAKE3 step on the target chain. BLAKE3 remains everywhere else, including content identity, command_id, CommitmentId, state keys, and every domain-separated preimage.
• The Keccak256 hasher is Makechain's own implementation of the pinned commonware_cryptography::Hasher trait, follow-up F13, cross-checked against the library's post-tag implementation once that ships. Neither a Commonware pin move nor a git submodule is used: a main-branch pin would split the dependency graph from exoware 2026.9.0, which pins the commonware-* crates at 2026.9.0. The Solidity verifiers for threshold certificates, QMDB, MMR, and BMT proofs are consumed separately from the pinned tag and do not require the Rust pin to move. Merkleization cost under Keccak256 at the target throughput is a calibration item, and the choice is final only when that measurement passes. The re-measurement is section 11.7 of validation.md.
• Code structure keeps the choice reversible: each proof-path tree names its hasher through one alias in makechain-protocol (block hash, command root, membership log, block-history accumulator, validity state), every proof-path site imports the alias, conformance vectors are generated from it, and a lint forbids naming a concrete hasher on the proof path. Moving one tree or the whole path to BLAKE3 is then a type change plus regenerated vectors, decided at SB-15's decision point in implementation-second-batch.md ↗ (external site).

The block-history accumulator has its own row above so that all three merkleized members appear together; the specification's own primitive map states its primitive in the database-set subsection rather than in the map table.

10.2 Two scoped constraints

Two rules from the specification's design principles are scoped here so they are not misread.

Hash maps on consensus paths. The rule governs Makechain-owned code, where iteration order could reach an encoding or a root. Commonware's internal unordered collections never determine consensus order: where one is iterated, its indices are sorted and deduplicated before any ordered work, and the resulting roots are pinned by conformance vectors. Those internals are therefore compliant.

Truncated identifiers. The rule governs stored, routed, and hashed values. The index translator shortens keys only to choose a bucket, and every read compares the full key before returning. Translation is not truncation, and the per-key memory figures stand.

10.3 External projects

Two projects are depended on that are neither Commonware nor Makechain-owned.

Dependency and pin policy is owned by repository.md.

10.4 Makechain-owned, with no Commonware primitive

• secp256k1 signing and recovery, through an external crate.
• SSHSIG, WebAuthn, and P256-direct verification, through external standard verifiers, because Commonware's public verifiers always prepend a namespace.
• EIP-712 framing.
• The mempool, admission, and gateway fan-out.
• Write forwarding.
• Object-store publication.
• The tiled bootstrap artifact format, which is deferred.
• The deterministic projection of history-table rows, which exoware stores and queries but does not derive.
• Ethereum MPT proof verification and Tempo certificate decoding.
• The Ed25519 governance multisig.
• P256 batch verification, if it is ever wanted.
• The multi-consumer event outbox.

The owning modules for these are already named in section 2; this list is the negative view, stating which of them cannot be delegated to a primitive.

10.5 Three wiring choices

The queue choice is already covered in section 3.3 and section 4, which assign the byte bound, the certified gap choice, artifact idempotence, and the exporter watermark to the Finalized export module rather than to Commonware. The mesh choice is expanded, with the channel plan and peer-set ownership, in section 8 of operations.md.

10.6 Storage decision table

Each store was chosen for one job. This table is the decision; the specification carries the rules. It is new to this document: section 2 assigns module ownership and section 4 assigns Commonware seams, but neither records why a store was chosen or what was rejected.

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.
• Every service outside the core is a projection. Gateways, indexers, and query engines can be wrong or malicious without affecting what the chain attests, which is why the specification defines proof kinds for the facts that matter. This restates design rule 5 in section 1 from the storage side.

The selected object-store backend for the first shared devnet, and its create-if-absent adapter contract, remain in section 3.2 of operations.md; the table above states the store class, not the vendor.

10.7 Execution-host adapter contracts

Three contracts sit between the executor and the pinned Commonware adapters. They are implementation guidance in form, and the first two are root-affecting or liveness-affecting in effect, so they are recorded rather than left to reading the adapter source.

Staged current-state reads. CurrentStaged::expand neither deduplicates earlier keys nor observes values computed for staged slots but not yet passed to merkleize. The Makechain overlay therefore owns both deduplication and command-visible writes, and expands staging only for previously unread keys. Its stable staged indices and final writes are submitted together at block merkleization. Violating either half changes which operations reach merkleize, and therefore the committed state_root. Sections 2 and 3 already assign typed reads and staged writes for validity state to the state adapter, and section 4 names glue/src/stateful/db/current.rs; the expansion rule itself is new to this document.

Lock discipline. No code holds a shared read guard across a batch operation that reacquires the same database, because the write-preferring lock deadlocks when finalization intervenes. New to this document.

Bootstrap handles. Bootstrap handles are dropped before the execution host opens the members. Already covered in section 3.1, whose genesis database handoff applies the batch, awaits the durability handle, drops the handle, and reopens the member before Stateful or a network actor starts.

10.8 Fixed-profile stack composition

Section 6 already covers the accepted fixed-profile decision, its epoch-zero guards, and the absence of a continuous reshare actor. The component inventory below completes it by naming what FixedEpochZeroV1 does not assemble.

FixedEpochZeroV1 retains Random V1 with rotating terms, marshal::standard::Deferred, stateful::Stateful, the same three-member database set, executor, journal, durability barriers, proofs, the exporter, and recovery paths. It has none of:

• a bootstrap DKG chain;
• an epoch orchestrator;
• a reshare wrapper or actor;
• a DKG probe or DKG state-sync plan;
• a dynamic registrar;
• a dealer or reveal channel;
• future-player activation;
• a DKG SecretStore.

The DKG state-sync plan, the fence, and the gate exist only under DynamicReshareV1, where they are separate from the application SyncPlan so that a state-synced node keeps certified epoch information the application sync may skip. Already covered in section 4 (the reshare and DKG seam) and section 5 (the DKG custody partition, via operations.md section 2.1). The absence list is new to this document.