Fixed epoch-zero development profile

Status: Accepted semantic profile, first incorporated in specification revision 4 and current against specification revision 14, 2026-09-22. This document explains the profile and its source evidence; spec/SPECIFICATION.md takes precedence. Canonical schema and byte-format work is still required before implementation. The disposable profile does not relax the dynamic production protocol.

1. Decision

The first Makechain devnet profile uses exactly seven genesis validators, one epoch numbered zero, one threshold output and seven pre-generated threshold shares from a trusted dealer, and no live DKG or reshare actor. It retains the production-shaped BLS threshold VRF/certificate scheme, Random V1, Simplex, Stateful/Deferred execution, three database members, the Makechain executor, and real proofs and receipts.

This profile is disposable. Moving to bootstrap DKG, continuing reshare, dynamic membership, or production custody starts a new chain with a fresh identity. Qualification testnet must later run those production paths; success here is no evidence that they work.

2. Canonical profile and trust anchor

The profile is consensus-visible, never a node-local switch. Its canonical chainspec inputs include:

• consensus_profile = FixedEpochZeroV1 (the production variant is DynamicReshareV1);
• the ordered seven-validator identity and network directory;
• the fixed public threshold output and epoch-zero EpochInfo, never secret shares;
• fixed epoch length u64::MAX and all normal consensus parameters;
• the complete Tempo settlement profile committed by the chainspec (specification section 5.2); and
• a fresh deployment_incarnation_nonce for this one chain run.

Exact field names and numeric encoding tags belong to the data contract. Their semantics do not. Canonical chainspec bytes determine chain_id as specified today. The fixed public output is generated before hashing the chainspec; the chain-derived namespaces are then constructed from chain_id. The genesis block reproduces the committed epoch-zero EpochInfo, including the dealer output. Validators pin both chain_id and the genesis block hash. The two use different hash functions: chain_id is a BLAKE3 digest over the canonical chainspec, while the genesis block hash is the Keccak256 digest of the canonical header and is the first step of the proof path (specification section 6.2). Regenerating a dealer output or resetting a run requires a new incarnation nonce; reusing the old chain_id with different threshold material is invalid.

Private shares and dealer randomness are not chainspec or block fields. They must not enter source control, images, logs, or public artifacts. Each validator receives only its own real share, through the test secret-delivery path, before readiness.

3. Seven-validator threshold fixture

Fixture preparation must satisfy all of these checks before a validator can report ready:

1. Decode seven distinct validator identity keys and sort them by ascending canonical public-key bytes. This is the sole participant order used by dealer generation and consensus.
2. Run the pinned Commonware trusted feldman_desmedt::deal helper with that ordered set, the same DKG mode and BLS variant selected for the production profile, and a seed chosen as below. The helper does not consume the Makechain namespace, which is why it can run before chain_id exists. It must return one public Output and exactly one share for each key.
3. Require Output.players to equal the ordered seven-key set, total == 7, and threshold required == quorum<N3f1>(7) == 5. Require no missing or extra dealer/player identities.
4. Build the canonical chainspec containing that public output and the epoch-zero EpochInfo, then derive chain_id from it, then derive the Makechain consensus namespaces from chain_id and the committed namespace inputs.
5. On validator i, construct the threshold signer against the derived chain-bound namespace, the committed participant set, the public polynomial, and its delivered share. Construction must succeed, which checks the share index and public evaluation. A missing, duplicated, misindexed, or mismatched share is a fatal-local startup failure. It must never downgrade a configured validator to verifier-only operation.
6. Construct the genesis block, and require all nodes to reproduce identical canonical bytes and digest for the public output and genesis EpochInfo. Observers may construct verifier-only roles, but they are not committee members and do not count toward the seven.

The order of steps 1, 2, 4, 5, and 6 is fixed: identities are sorted before dealing, the chainspec is built from the dealer's public result before chain_id is derived, and signers and the genesis block are constructed only after the namespaces exist.

The trusted dealer is a test convenience, not a simulated DKG. No transcript or fake acknowledgement is created. The fixed genesis EpochInfo.outcome = Success is only usable-fixture metadata, as specified in §5.5; it is not evidence of a DKG ceremony. A deterministic dealer seed is used only in local reproducible tests. A shared disposable network uses a system RNG and never publishes or commits that seed; a committed deterministic seed would disclose all signing power.

4. Epoch-zero engine contract

The engine uses FixedEpocher::new(NonZeroU64::MAX). That is a finite library contract: epoch zero covers heights 0..=u64::MAX-1; height u64::MAX would map to epoch one, whose bounds overflow and are unsupported. A node must stop before an unsupported height. This is a practical single-epoch profile, not an assertion that Commonware has an infinite-epoch type.

Only Epoch(0) is admissible. ConstantProvider is insufficient enforcement because it returns the same scheme for every requested scope. The Makechain engine boundary must therefore reject before signing or certificate use when any round, proposal, vote, certificate, recovered block context, or ancestry relation names a nonzero epoch or a height outside epoch zero. The Epocher, block context, and certified ancestry must agree; a successful constant-provider lookup grants no epoch authority.

There is one Simplex engine. The DKG bootstrap chain, orchestrator, reshare application wrapper, reshare actor, DKG probe/state-sync plan, dealer/reveal network channels, and SecretStore are absent. Every block must encode dealer_log, dkg_outcome, and their optional header commitments as None wherever those fields occur. Some(empty) is also invalid; the separate genesis public EpochInfo is not a reshare outcome payload. genesis_epoch_info and its matching header genesis_epoch_info_hash must be present exactly at height zero and both must be None thereafter.

Removing DKG also removes only the DKG boundary-history constraint that couples retained marshal blocks to the dealing/acknowledgement window. The implementation must not derive retention from the u64::MAX epoch length. Ordinary marshal, stateful execution, restart, proof, exporter, and recovery retention rules remain in force.

This profile has no inherent healthy-path latency advantage. It removes ceremony and boundary failure modes; proposal, voting, network, execution, persistence, and certification timing remain to be measured. It retains the specified Random V1 rotating-leader policy and introduces no profile-specific stable-leader or timeout change.

5. Exact command and release behavior

Disabled commands fail deterministic validity before mutation. They are never successful no-ops:

Consensus-critical surfaces are the current exhaustive manifest enumeration: signing and handshake namespaces, RandomVersion, TermLength, timeouts, DKG sharing and reveal modes, Transcript version, committee bounds, marshal variant, and p2p wire codec. Any future surface classified as consensus-critical inherits the same rejection. There is no future epoch start at which such a release could fulfill the existing two-epoch lead and lock contract.

Non-critical parameter, format-preserving, and versioned-state releases retain their current command semantics and activation-height rules. A change to the profile discriminator, epoch construction, committee, threshold output/group key, canonical encoding, or chain identity is reset-class and cannot be smuggled through a non-critical manifest.

6. Tempo-backed funding and deterministic fixtures

Every deployed Makechain network uses real Tempo-certified cumulative deposits. Devnets and qualification testnets pin a complete Tempo Moderato settlement profile; mainnet pins the complete Tempo Mainnet profile. These are chainspec values, not substitute enum labels: Tempo chain id, settlement contract address and code hash, admin policy, accepted asset, beneficiary-slot derivation, amount width, initial threshold identity and checkpoint, finalization-certificate profile, trust/skew limits, and every other verifier input are explicit and chain-bound. A partial profile, sentinel address, or node-local selection is invalid.

IMPORT_CREDITS.Credit and IMPORT_CREDITS.Refresh retain their existing normal validity rules. There are no genesis credit allocations, test-credit realm, Makechain faucet, mint command, or bypass. The first funded application slice is therefore:

1. verify and apply a strict-advance IMPORT_CREDITS.Credit, creating the beneficiary ledger under the normal first-import rule;
2. use that beneficiary to run INIT_ACCOUNT, delegation, project creation, and publishing; and
3. verify the resulting real receipts through the same reference verifier used by the network.

The present global-issuance contract cannot be named as the required profile merely because it is already deployed. At inspected contracts revision 13945e9209b6f543f346604909aced9dda560b8a, StorageRelay stores only a global issuedUnits, grants unpaid units, and does not expose the per-beneficiary monotonic cumulative assumed by the Makechain specification. Its proxy/upgrade shape also needs an explicit proof-identity rule. The owner selected dedicated cumulative-credit contracts on Moderato and mainnet, leaving the existing deployment intact. The settlement interface defines the ABI, slot-zero uint256 mapping, 256-bit Makechain amounts, and source epoch floor. Implementation and deployment are external future work. The settlement profile cannot be completed, and its funded slice cannot run, until that work supplies a compatible Moderato deployment. Potential reuse of existing certificate/header verification code does not make the existing monetary state compatible.

After a compatible Moderato contract exists, deterministic simulation may replay a captured, authentic certified header and storage proof. It must pass the unchanged production verifier and configured freshness/deadline rules; code must not replace verification with a fixture assertion. Consensus execution performs no live Tempo RPC. Relayers acquire and archive evidence outside execution, then submit the complete command.

Credits are non-transferable, so the owner must arrange a Tempo deposit and captured proof for every beneficiary that the concurrent-agent workload must fund. Open fixture inputs are the beneficiary identities, deposit cumulatives, certified Moderato checkpoint/proofs, and which actors share a beneficiary. They are external test data, not genesis state or implementation defaults. Until the settlement contract and these inputs exist, the real funded first slice is blocked; unfunded consensus testing must not invent credits to bypass it.

7. Reset boundary

Resetting this profile creates a fresh incarnation nonce, chain_id, threshold output and shares, genesis block/hash, storage namespace, consensus journal, and peer namespace. It imports no prior Makechain state, credits, release schedule, validator schedule, finalized history, or proof root.

Pre-reset chain command signatures, certificates, receipts, inclusion/state proofs, and bootstrap artifacts fail the new chain/genesis binding. Content-addressed mkit object identities and externally certified Tempo facts may still be valid in their own domains; reset does not revoke them. They confer no state on the new Makechain chain and are not imported automatically. A Tempo proof can affect a new run only if it independently passes that run's configured Tempo profile and normal import rules. Reuse of an externally valid proof still requires a new-chain canonical import envelope and creates only the new chain's own ledger state. IMPORT_CREDITS remains permissionless; this rule adds no account signature.

8. Commonware dependency decision

Use the released v2026.9.0 source at commit d476a2361ce6840d2b9d0aa6fb30a924429046d4, locked exactly in the dependency lockfile. It is the newest local tag and, as checked against the official Commonware GitHub origin on 2026-09-19, the newest remote release tag. Do not depend on a branch, moving revision, local fork, or unreleased HEAD.

The inspected local HEAD 3827a56dc76818bd31c42c2d6b8c7da261123f2a is 43 commits after the tag while package metadata still says 2026.9.0. Across codec, marshal, DKG, certificate provider, and epoch code, the delta is 69 files with substantial ownership/codec and marshal fetch/caching work, plus fixes such as bounded bitmap-overlay allocation and sync-gap detection (503c668951, 19e9953dab). The ConstantProvider and FixedEpocher behaviors relied on here remain materially the same, and no post-tag change is required to express this profile. Newer is therefore not a sufficient upgrade reason.

When Commonware publishes a later release, qualify its exact tag before adoption: inspect the full tag-to-tag delta and track relevant upstream fixes, rerun canonical codec/golden vectors, confirm trusted-dealer and signer checks, confirm fixed-epocher and provider scope behavior, and exercise the Makechain consensus/storage/restart conformance suite. A later dependency decision may select an exact upstream release or immutable commit after that review. Local patches and forks are outside this profile.

9. Qualification gates

The profile is ready for its intended stage only when evidence shows:

• all seven validators derive one chain_id, genesis hash, participant order, output digest, and quorum, and every validator's signer/share check succeeds;
• nonzero-epoch traffic, DKG payloads, both validator-schedule variants, and every critical release path are rejected identically by proposer admission and block verification;
• authentic captured Moderato evidence passes the normal import verifier; the funded workload then runs through the real executor and database adapters, produces real receipts, and survives ordinary restart without changing finalized roots;
• reset rejects every sampled pre-reset chain artifact while independently checking the stated continued meaning of sampled mkit and Tempo artifacts; and
• reports explicitly say that DKG, reshare, epoch transition, membership transition, custody, and production recovery remain unqualified.

10. Incorporation and remaining contracts

Source ledger

Facts below are pinned unless explicitly labelled HEAD.