5. Chain identity and chainspec

A chain is defined by one document of pure data, the genesis chainspec, and by the genesis block built from it. This chapter defines chain_id, states what the chainspec commits, fixes the shape of genesis and the way a node installs it, defines the two consensus profiles, and states what a reset creates. Every namespace in the protocol derives from the value this chapter defines, so nothing signed for one chain verifies on another.

5.1 Chain identity

chain_id identifies a chain and is derived from the genesis chainspec:

chain_id = BLAKE3("makechain.chainspec" || canonical(GenesisChainSpec))

Networks are chainspecs, not names, and there is no network enumeration.

R-5.1. The chainspec MUST NOT contain its own chain_id.

R-5.2. Every Makechain consensus, DKG, p2p, command, and settlement-import wrapper namespace derives from chain_id, so a Makechain signature or certificate produced for another chain cannot verify.

An external Tempo certificate retains Tempo's own namespace and trust domain, and the chain-bound import wrapper prevents Makechain-envelope replay. The same external fact may independently satisfy another chain's pinned Tempo profile, under the reset rule of section 5.7.

5.2 What the chainspec commits

The genesis chainspec commits:

Other chapters name further chainspec values where they define them, among them the set-once multisig_recovery_factory (chapter 7), the username parameters (chapter 8), and the root-affecting storage parameters (chapter 17).

R-5.3. Genesis contains no credit allocation and no pre-created credit ledger.

5.3 Genesis

Genesis has two parts. The chainspec is pure data and is reproducible from its bytes. The public threshold output and the epoch-zero EpochInfo are carried by the published genesis block, whose hash is published alongside chain_id; the origin of those two artifacts and their binding to the chainspec depend on consensus_profile, as defined in sections 5.5 and 5.6. The light-client trust anchor is therefore chain_id plus the published genesis block, never the chainspec alone. The bounded initial protocol records of the genesis block are defined in the encoding contract.

R-5.4. Genesis construction from the chainspec plus the applicable EpochInfo is deterministic and MUST reproduce the published genesis block exactly.

R-5.5. No parameter depends on an operator environment after genesis.

R-5.6. The genesis block has:

a. height zero; b. an all-zero parent hash; c. epoch zero and view zero; d. the declared genesis timestamp; e. an empty command list; f. the profile's genesis-only epoch artifact.

R-5.7. Genesis creates no user accounts and no credit ledgers.

R-5.8. The native membership and history databases retain their bootstrap commit only, with size one and floor zero, and their genesis targets MUST NOT be produced by an additional empty batch.

R-5.9. On a fresh genesis installation with no selected peer-sync floor, a node seeds the current-state member once, before the execution host opens the members, by applying the deterministic sorted genesis write batch to the native initial target and awaiting its finalize barrier, and never by ordinary block execution.

R-5.10. A node whose reopened current-state member already matches the expected genesis current root and target performs no further genesis work, a reopened member that matches a different target is fatal, and those root and target values are the idempotence marker rather than a separate mutable initialization flag.

R-5.11. A peer-floor or state-sync installation skips preseeding and imports the certified operations instead.

R-5.12. A crash during seeding retries from recovered native initial state, or recognizes the durable genesis target.

Bootstrap handles are dropped before the execution host opens the members (../docs/architecture.md). Genesis and header reproduction and crash-cut vectors must qualify this path (../docs/validation.md).

5.4 Consensus profiles

consensus_profile is a canonical enum with exactly two variants.

Because chain_id covers the whole chainspec, the profile is part of the bytes hashed into it.

R-5.13. Startup, proposal, verification, replay, sync, proof verification, and command validity all dispatch from consensus_profile, and no command-line flag, environment variable, database marker, or other node-local setting selects or overrides it.

INV-CONS-07. Every node derives the consensus profile from the genesis chainspec; no node-local option can change profile validity, committee lifecycle, epoch admission, or block shape.

5.5 FixedEpochZeroV1

Under FixedEpochZeroV1 the chainspec commits the ordered seven-validator identity set and transport directory, the BLS12-381 threshold VRF variant and pre-chain_id namespace inputs, the trusted-dealer public output, the epoch-zero EpochInfo, and fixed epoch length u64::MAX. Observers MAY be verifier-only, and are not committee members.

R-5.14. Participant order is ascending canonical identity public-key bytes.

R-5.15. The trusted-dealer public output MUST:

a. name exactly those seven dealers; b. have total = 7; c. have required = quorum<N3f1>(7) = 5.

R-5.16. The public output in the genesis block MUST equal the chainspec value byte for byte.

R-5.17. Private shares and dealer randomness MUST NOT be chainspec or block fields.

R-5.18. Retired; the procedure is in development profile.

R-5.19. Retired; the procedure is in development profile.

R-5.20. Retired; the procedure is in development profile.

R-5.21. Retired; the procedure is in development profile.

R-5.22. Retired; the procedure is in development profile.

R-5.23. The committed fixed EpochInfo has outcome = Success, epoch = 0, and output.dealers, output.players, players, and next_players all equal to the same ordered seven-member set, with output.revealed empty and a directory that matches exactly that set.

Success describes the usable public fixture, does not assert that a DKG ran, and creates no transcript or certificate. That artifact occupies the genesis-only genesis_epoch_info body field, which is distinct from the optional per-block dkg_outcome field.

R-5.24. dkg_outcome remains None under FixedEpochZeroV1.

R-5.25. FixedEpochZeroV1 uses FixedEpocher::new(NonZeroU64::MAX), whose epoch zero is finite and covers heights 0..=u64::MAX - 1.

R-5.26. Height u64::MAX is rejected, and every node MUST stop before it.

R-5.27. Retired; its content is R-13.9.

R-5.28. Retired; its content is R-13.9.

5.6 DynamicReshareV1

Under DynamicReshareV1 the chainspec instead commits the finite epoch schedule and the bootstrap ceremony inputs, namely the participant set, the namespace, the sharing and reveal modes, the epoch length, the parameters, and the bounds.

R-5.29. The threshold identity is the output of the one-shot trustless bootstrap DKG in which every participant deals and plays, so no single party knows the group secret.

That ceremony's public output and epoch-zero EpochInfo enter the genesis block, and continuous reshare governs later epochs (chapter 13). FixedEpochZeroV1 success does not qualify this ceremony, reshare, membership changes, or production custody.

5.7 Reset

R-5.30. Changing a profile, a fixed committee or any of its members, a fixed directory snapshot, a fixed output, a group key, or an epoch construction is reset-class (chapter 18), never a local reconfiguration and never a release.

R-5.31. A reset creates a fresh deployment_incarnation_nonce, chainspec, chain_id, threshold output and shares, genesis block and hash, storage namespace, consensus journal, and peer namespace, and imports no Makechain state, credits, release or validator schedule, history, certificate, receipt, or proof root.

Artifacts of the pre-reset chain fail the new chain and genesis binding. An mkit content identity or a Tempo proof may remain valid in its own external domain, and confers no new-chain state.

R-5.32. A Tempo proof affects the reset chain only through a new canonical IMPORT_CREDITS envelope that independently passes that chain's complete settlement profile and ordinary strict-advance rules.

5.8 Rationale

This subsection is informative.

Deriving chain_id from the chainspec bytes binds every profile, namespace, domain, and certificate to one genesis definition, so nothing can be replayed across networks and no separate network name can drift from the parameters it stands for. The group public key is a ceremony output rather than a governed continuing-chain value: under DynamicReshareV1 the DKG primitive produces it and keeps it invariant across reshares, while under FixedEpochZeroV1 the chainspec commits the test fixture explicitly. A new key is a new chain, which is the property light clients rely on. Genesis is seeded by a deterministic write batch rather than by ordinary block execution, because executing a block at height zero would append extra log commits and move the committed genesis targets.