19. Parameters
This chapter collects the values the protocol binds at launch, the positions that are fixed by architecture rather than by a parameter, and the values this specification names but does not fix. Every value here is referenced from the chapter that uses it.
19.1 Status
Each value in the launch table of section 19.2 is a chainspec value, fixed for the applicable consensus profile (section 5). A calibration item is a value this specification names and the calibration report fixes.
R-19.1. A launch value changes through the release process of section 18 where the table or section 5 states a governed path, and otherwise only by reset.
R-19.2. A calibration item binds no implementation until the qualification gate records a measured value for it.
R-19.3. Reversal of a position fixed by architecture (section 19.3) is a reset.
19.2 Launch values
| Parameter | Launch value | Basis |
|---|---|---|
| Validator committee | FixedEpochZeroV1: exactly 7 forever; DynamicReshareV1: 7 at genesis, bounds [7, 64], at most one addition and one removal per epoch |
seven gives f = 2 and quorum 5 |
| Membership window | 2^26 operations | a proof-anchored push stays valid for 2^26 / ops_per_second seconds |
| Growth measurement | resident bytes per live record measured at 10 million, 100 million, and 1 billion records and after churn; operator upgrade thresholds published with each client release | informative sizing, never a validity rule |
| Delegated key term | 2 years; root renewal extends only a current, unexpired generation and preserves replay state | expired or epoch-invalidated records are reclaimable |
| Transfer offer expiry | 30 days | |
| Record creation fees and deposits | per family, calibration items; every deposited family has a nonzero deposit | growth is priced |
max_new_records per block |
calibration item | growth is rate-limited |
max_exporter_roster |
2 | one active exporter and one standby (section 17) |
| Usernames | minimum 5 characters, 28-day rename cooldown, 1-year lease, 30-day grace | avoids selling scarce short names at a flat price |
| Carry-over escalation | under DynamicReshareV1, alert at 1, page at 2, written incident at 3 consecutive reshare carry-overs; inapplicable to FixedEpochZeroV1 |
a finalized event plus an operator alert, never an automatic halt, removal, or trust change |
| Commitment schemes | mkit-blake3 primary; git-sha1 and git-sha256 registered |
section 8 |
| Owner families and nesting | secp256k1, P256, WebAuthn P256; no nested owner accounts; Ed25519 delegated only | one configuration is one identity on Makechain and Tempo |
| Account model reference | Tempo TIP-1107 cluster (TIP-1108, TIP-1110, TIP-1112, TIP-1113, TIP-1114) text at the commit named in the chainspec | derivation formulas and bounds |
| Configured-genesis factory | multisig_recovery_factory unset at launch; set once by a release from Tempo's published constant |
Tempo keeps the factory unpublished until its own release activates |
| Settlement source and asset | Moderato plus pathUSD for every deployed devnet/testnet; Tempo mainnet plus pathUSD for mainnet; credits in microdollars | each deployment requires the complete dedicated immutable cumulative-contract profile of section 16 |
| Consensus-critical surfaces requiring a qualified handoff | under DynamicReshareV1, every surface listed in section 18.2; unavailable on FixedEpochZeroV1; no surface has a qualified handoff yet, and each becomes schedulable only when qualified (section 18.7) |
sections 18.2 to 18.7 and validation |
| Root WebAuthn origins | governed chain-wide allowlist | section 7 |
19.3 Positions fixed by architecture
These positions are not parameters, and reversing one is a reset:
- unordered current state, so consensus offers no exclusion proofs;
- state growth priced and rate-limited rather than capped;
- no operator grants;
- credits denominated in microdollars.
19.4 Calibration items
- Merkleization cost of the three databases and the command root under Keccak256 at the target throughput, measured against SHA-256 and BLAKE3 on the same workload; the proof-path hash of section 6 is final only when this passes.
- Work weights and maxima.
- Price table values and minimum initialized balance.
- Username price and
username_horizon_ms, which is at least the one-year term. min_activation_delay_blocks,min_emergency_delay_blocks,testnet_lead_blocks, andpost_activation_soak_blocks.- Simplex timeouts, empty-block interval, clock skew, and collateral delay under concurrent verify.
max_block_advance_ms.- The launch values of section 19.2, which are inputs to calibration and change only if a gate fails.
- Creation fees and deposits per family, including the retention component of each permanent
family's creation fee,
max_new_recordsper block, and the measured resident bytes per live record with the operator upgrade thresholds. - Membership window, window turnover at maximum rate, and the bootstrap time gate.
- Exporter publish-lag bound, and store ingestion-lag bound as measured by the checker, as a
fraction of the membership window;
max_anchor_agefor a joiner's anchor. - Store snapshot cadence, replay-job cadence, and the store growth projection.
retained_marshal_blocksagainst exporter publish-lag tolerance, independent ofFixedEpochZeroV1'su64::MAXepoch length.- History-table schema version and query-tier cache bounds.
- Settlement trusting period, source skew allowance, and evidence window.
- Root-witness work weights per owner family.
- Admission rate limits.
- Admission pool item-count cap, canonical-envelope byte cap, and per-
(key_id, generation)pending-depth cap (admission_pool_capacity). - Admission pool status-retention duration before a status is evicted to
Unknown(admission_status_retention_ms). max_ref_name_bytesand bounded preparation, receipt, and reconciliation response sizes.
The qualification gates that record a measured value are in validation.