20. Invariant index

Draft protocolSource at 169cbd2 ↗Excerpt SHA-256 f38691b…7b4

Every invariant is stated in full, once, in the section that defines what it constrains. This index lists each identifier with the opening clause of its statement and that section. Identifiers are never renumbered or reused. The statement in the defining section governs.

20.1 Consensus

Invariant	Statement (opening clause)	Defined in
`INV-CONS-01`	Every validator derives identical validity from canonical bytes, parent state, `chain_id`, the active release, and finalized settlement inputs.	section 12.3
`INV-CONS-02`	Every derived header field is re-derived and must equal the committed value.	section 11.2
`INV-CONS-03`	A finalized command applies its complete transition.	section 12.3
`INV-CONS-04`	A block never exceeds any of the three resource dimensions, and they never convert.	section 10.1
`INV-CONS-05`	`command_root` binds the complete signed envelopes in execution order.	section 11.2
`INV-CONS-06`	A signature for one command binds tag, version, ruleset, price schedule, actor, and authorization context, and can never be lifted into another command or executed under another ruleset.	section 7.4
`INV-CONS-07`	Every node derives the consensus profile from the genesis chainspec.	section 5.4
`INV-CONS-08`	Under `FixedEpochZeroV1`, every consensus context and ancestry relation is in epoch zero and every DKG payload option is `None`.	section 11.3

20.2 Fault handling

Invariant	Statement (opening clause)	Defined in
`INV-FAULT-01`	Every failure is exactly one of permanent invalidity, transient inability, or fatal corruption.	section 12.4
`INV-FAULT-02`	No honest validator decides a command or block differently from another because of its wall clock.	section 11.4
`INV-FAULT-03`	An honest validator waits rather than votes on a future-stamped proposal.	section 11.4
`INV-FAULT-04`	Object unavailability never changes validity after publication.	section 12.4

20.3 State, replay, and deposits

Invariant	Statement (opening clause)	Defined in
`INV-STATE-01`	Spent cumulative plus locked deposits never exceed credited cumulative.	section 9.6
`INV-STATE-02`	Every counter starts at its base, increments checked, rejects `u64::MAX`.	section 9.2
`INV-STATE-03`	A delayed signed command cannot regain validity after its bound revision, generation, or lifecycle sub-revision changes.	section 9.6
`INV-STATE-04`	An expired or generation-invalidated record grants no authority.	section 9.6
`INV-STATE-05`	Every deposit is discharged exactly once, to its stored payer, by the transition that physically deletes or replaces its record.	section 9.6
`INV-STATE-06`	No handler performs a state-size-dependent scan.	section 9.2
`INV-STATE-07`	State growth is priced and rate-limited, never capped: a block reserves at most `max_new_records` gross record creations, counting implicit records and never netting deletions, and no valid block is ever rejected because of a node's local memory or disk.	section 9.6
`INV-STATE-08`	Every recreatable child's incarnation incorporates a monotonic counter from a surviving parent, so deletion never reuses an incarnation.	section 9.6
`INV-STATE-09`	A project-authorized command binds its control generation and, when authorized through a grant, its grant generation, and is invalid when either has moved.	section 9.6
`INV-STATE-10`	Every project has exactly one matching slug claim, and every slug claim names a project whose owner and canonical slug match the claim's key.	section 9.2
`INV-STATE-11`	Every command observes earlier successful commands in its block.	section 9.1

20.4 Accounts and authorization

Invariant	Statement (opening clause)	Defined in
`INV-AUTH-01`	`AccountId` is immutable.	section 7.1
`INV-AUTH-02`	A command is valid only if its sequence strictly exceeds the mark for `(key_id, generation)`.	section 7.6
`INV-AUTH-03`	Revocation is forward-only.	section 7.3
`INV-AUTH-04`	A role change or control transfer can never revive a command signed under an older generation.	section 7.6
`INV-AUTH-05`	Username ownership is unique.	section 8.5
`INV-AUTH-06`	A root witness is valid only for the account's current authority version, reaches the threshold exactly at its last signature, and contains no signature beyond it.	section 7.4
`INV-AUTH-07`	A delegated key grants authority only under its issuing delegation epoch, and bulk revocation never resets a replay mark or changes a finalized command.	section 7.3
`INV-AUTH-08`	A project-scoped key authorizes only that project's pushes and scoped social messages, always subject to the applicable account role, capability, and lifecycle checks.	section 7.3
`INV-AUTH-09`	Renewal never restores an expired, revoked, or epoch-invalidated key generation.	section 7.3
`INV-AUTH-10`	Third-party username extension never restores resolution or changes ownership, the current-name pointer, or the deposit payer.	section 7.1

20.5 Membership

Invariant	Statement (opening clause)	Defined in
`INV-MEMBER-01`	An accepted membership leaf is never erased from the canonical log.	section 9.3
`INV-MEMBER-02`	Membership locations are pre-assigned in flat command order before any lane runs.	section 9.3
`INV-MEMBER-03`	A non-delete signed ref op names its target commitment.	section 9.3
`INV-MEMBER-04`	Every finalized height has an agreeing `membership_target` after processing or recovery.	section 9.3
`INV-MEMBER-05`	Consensus offers no current-state exclusion proof at launch.	section 9.2
`INV-MEMBER-06`	Every role commits the identical inactivity floor for every log.	section 9.3
`INV-MEMBER-07`	Replacing a command's evidence never changes its signed intent or exceeds its signed `max_charge`.	section 9.3

20.6 Settlement

Invariant	Statement (opening clause)	Defined in
`INV-SETTLE-01`	A credit import finalizes only when it strictly advances the beneficiary frontier.	section 16.4
`INV-SETTLE-02`	A Tempo identity enters state only through genesis or a release's activation installer (section 18.6).	section 16.8
`INV-SETTLE-03`	Forward settlement transitions (credit import, refresh) are refused once the dual trust deadline of section 16 has passed, regardless of how the deadline was last extended.	section 16.6
`INV-SETTLE-04`	A relayer can never redirect credits: the beneficiary is the storage slot's owner and the amount is the contract's cumulative, both proven, never supplied.	section 16.4
`INV-SETTLE-05`	Only a deposit of the fixed accepted asset can raise a beneficiary cumulative that Makechain will honor.	section 16.2
`INV-SETTLE-06`	Trust ends at the earlier of the local-acceptance deadline and the source-checkpoint-age deadline, both evaluated in Makechain consensus time before any forward transition under the identity is authenticated.	section 16.6
`INV-SETTLE-07`	Settlement state is one identity anchor, one checkpoint, one pause flag, and the per-beneficiary frontiers.	section 16.5
`INV-SETTLE-08`	Genesis creates no credit ledger and allocates no credits.	section 16.2

20.7 Proofs

Invariant	Statement (opening clause)	Defined in
`INV-PROOF-01`	Verifier trust inputs are never learned from a response.	section 15.1
`INV-PROOF-02`	A finality proof authenticates the exact block hash through a direct certificate or an accumulator ancestry proof anchored at a directly certified descendant, logarithmic in height under every legal history.	section 15.5
`INV-PROOF-03`	Release lineage is one predecessor chain with the schedule state always proved.	section 15.6
`INV-PROOF-04`	A proof is verified only after its target header and proof format are authenticated, against both root and count.	section 15.2
`INV-PROOF-05`	A derived view never creates a consensus fact.	section 15.8
`INV-PROOF-06`	Serving a proof from the exporter's live databases never mutates them.	section 15.4
`INV-PROOF-07`	Row validity never implies completeness or freshness.	section 15.8
`INV-PROOF-08`	A publication receipt derives its actor, project, commitment, and occurrence from a finalized included PUSH, never from response summaries, object authors, or membership leaf equality.	section 15.9

20.8 Events

Invariant	Statement (opening clause)	Defined in
`INV-EVENT-01`	Redelivery is idempotent.	section 14.5
`INV-EVENT-02`	Every event batch is exactly reproducible from certified inputs.	section 14.6
`INV-EVENT-03`	Events enter no root.	section 14.6

20.9 Governance and validator schedule

Invariant	Statement (opening clause)	Defined in
`INV-GOV-01`	A release activates only through the finalized schedule, never by proposer or operator choice.	section 18.3
`INV-GOV-02`	A validator-set entry is immutable except by pure cancel.	section 13.3
`INV-GOV-03`	A departing validator remains dealing until a reshare excluding it is certified.	section 13.3
`INV-GOV-04`	The group public key is invariant across reshares and membership changes.	section 13.6
`INV-GOV-05`	The effective voting set is the last successful reshare's players.	section 13.4
`INV-GOV-06`	A validator-set entry cannot be cancelled after the final block of `target_epoch − 2` has embedded it.	section 13.3
`INV-GOV-07`	The rules applied at height h are a pure function of `chain_id`, the schedule, and the effective parameters in the executing parent's state.	section 18.5
`INV-GOV-08`	A `consensus_critical` release activates only at the first block of an epoch scheduled at least two epochs ahead.	section 18.3
`INV-GOV-09`	Activation work is deterministic, marker-guarded, bounded by a constant independent of state size, and committed with its marker in one batch.	section 18.6
`INV-GOV-10`	An activated release is never reverted.	section 18.3
`INV-GOV-11`	Every node role supports every ruleset from the chain's genesis release to the active one in a single binary.	section 18.8
`INV-GOV-12`	`FixedEpochZeroV1` rejects every validator-schedule command and every release-schedule operation that would create, move, or cancel a consensus-critical pending entry.	section 18.9