AZ-016 — Genesis Specification v1

Status

Acest document definește specificația genesis pentru ATLAS ZERO.

După AZ-001 până la AZ-015, protocolul are:

• obiecte canonice,
• reguli de validare,
• consens,
• BVM,
• witness/proof,
• economie,
• agenți,
• guvernanță,
• securitate,
• conformitate,
• arhitectură de nod,
• fraud/slash evidence,
• runbooks de incident.

AZ-016 răspunde la întrebarea: din ce stare exactă pornește rețeaua și cum se garantează că toate nodurile pornesc din aceeași origine?

Scopul documentului este să fixeze:

• formatul obiectului genesis;
• parametrii inițiali ai protocolului;
• validatorii și rolurile inițiale;
• activele și alocările inițiale;
• registries și politici inițiale;
• starea de guvernanță inițială;
• feature flags inițiale;
• hash-urile și rădăcinile de pornire.

Acest document se bazează pe:

• AZ-002 până la AZ-015.

Termeni:

• MUST = obligatoriu
• MUST NOT = interzis
• SHOULD = recomandat puternic
• MAY = opțional

1. Obiectiv

AZ-016 răspunde la 10 întrebări de bootstrap:

1. Ce este genesis în ATLAS ZERO?
2. Ce obiecte și rădăcini trebuie să existe la epoch zero?
3. Cum sunt definite activele și alocările inițiale?
4. Cum sunt definiți validatorii și comitetele inițiale?
5. Ce parametri de consens, economie și guvernanță sunt activi la start?
6. Cum sunt fixate registries inițiale pentru tipuri, politici și proof-uri?
7. Cum este calculat genesis hash?
8. Cum se validează un genesis file?
9. Cum se fac rețele diferite fără ambiguitate?
10. Cum se face upgrade de la testnet genesis la alt genesis fără a confunda rețelele?

2. Principii

2.1 Genesis is protocol law at time zero

Genesis MUST fie tratat ca obiect constituțional de pornire. Nu este „config local”. Este intrarea normativă din care derivă:

• chain identity,
• parameter state inițială,
• stake snapshot inițial,
• rights și balances inițiale.

2.2 Canonical and immutable

Genesis MUST avea o formă canonică unică și hash-uibilă. După lansarea rețelei, genesis MUST NOT fi modificat.

2.3 Complete enough to reproduce state zero

Genesis MUST conține sau ancora tot ce este necesar pentru a reconstrui:

• finalized state at epoch 0;
• validator set inițial;
• registries și parametri inițiali;
• root-urile inițiale.

2.4 Network separation by construction

Două rețele distincte MUST avea chain identity distinctă prin genesis. Nu trebuie să existe ambiguitate între:

• mainnet,
• testnet-uri,
• devnets,
• private forks.

2.5 Deterministic bootstrap

Orice nod conform MUST produce exact aceleași:

• genesis hash,
• state roots,
• committee derivation seeds,
• parameter state, din același genesis blob canonical.

3. Genesis object overview

3.1 Abstract structure

GenesisSpec {
  version_major
  version_minor

  chain_identity
  network_class
  genesis_timestamp_unix_ms
  genesis_epoch_index

  genesis_parameters
  genesis_assets
  genesis_allocations
  genesis_validators
  genesis_committees
  genesis_registries
  genesis_policies
  genesis_machines?
  genesis_witnesses?
  genesis_governance_state
  genesis_feature_flags
  genesis_recovery_state?
  genesis_metadata_hash?

  derived_roots_commitment
}

3.2 Rule

Toate câmpurile top-level MUST avea encoding canonic și ordine canonică.

4. Chain identity

4.1 Purpose

chain_identity separă rețeaua la nivel criptografic și semantic.

4.2 Abstract structure

ChainIdentity {
  chain_id: hash32
  chain_name_hash: hash32
  chain_domain_separator: bytes_fixed<16>
}

4.3 chain_id derivation

chain_id = H("AZ:CHAIN_ID:" || canonical_genesis_core)

unde canonical_genesis_core exclude doar câmpurile explicit marcate ca metadata non-consensus, dacă există.

4.4 Rule

Toate obiectele context-sensitive SHOULD ancora chain_id direct sau indirect pentru replay protection cross-network.

5. Network class

5.1 Allowed values

• MAINNET
• PUBLIC_TESTNET
• PRIVATE_TESTNET
• DEVNET
• SIMNET

5.2 Purpose

Network class ajută:

• tooling,
• conservative defaults,
• ops expectations,
• governance expectations.

5.3 Rule

network_class MUST NOT schimba singur semantica de consens. Doar activează seturi de parametri genesis distincte.

6. Genesis timestamp and epoch

6.1 genesis_timestamp_unix_ms

Reprezintă timpul de referință al pornirii rețelei.

6.2 genesis_epoch_index

În v1 SHOULD fi 0.

6.3 Rule

Toate calculele de epoch/slot MUST avea origine deterministă din genesis parameter state.

7. Genesis parameters

7.1 Purpose

Setul complet de parametri activi la pornire.

7.2 Abstract structure

GenesisParameters {
  protocol_version
  consensus_params_hash
  economic_params_hash
  bvm_params_hash
  witness_params_hash
  governance_params_hash
  agent_control_params_hash
  security_limits_hash
}

7.3 Expanded view

În practică, genesis SHOULD ancora parametrii inițiali expliciți, nu doar hash-uri opace, prin registry-uri referite.

7.4 Rule

Același genesis MUST duce la aceeași ProtocolParamState inițială.

8. Consensus genesis parameters

8.1 Required initial fields

Genesis MUST defini:

• slot_duration_ms
• slots_per_round
• rounds_per_epoch
• stake_snapshot_lag
• finality_threshold
• committee sizes or derivation params
• proposer/verifier/notary role params
• no-finality handling defaults

8.2 Seed initialization

Genesis MUST defini sursa de seed inițial:

genesis_epoch_seed = H("AZ:GENESIS_SEED:" || chain_id || validator_root || parameter_root)

8.3 Rule

Committee derivation pentru primele epoci MUST fie deterministică pornind din acest seed și regulile din AZ-004.

9. Economic genesis parameters

9.1 Required initial fields

Genesis MUST defini:

• activul nativ AZR
• fee schedule inițial
• rent rates inițiale
• reward split inițial
• slash schedule inițial
• bond minima inițiale
• issuance baseline
• burn shares
• reserve shares
• unbonding delay

9.2 Rule

Parametrii economici inițiali MUST fi complet derivați din genesis, nu din config local.

10. BVM genesis parameters

10.1 Required fields

Genesis MUST ancora:

• BVM format version activ
• allowed opcode families for v1
• verifier mode flags
• max module/code sizes
• max stack/memory defaults
• max exec unit bounds
• host interface enablement set

10.2 Rule

Un nod MUST NOT porni pe rețea dacă BVM parameter state derivată din genesis nu corespunde cu runtime-ul său suportat.

11. Witness and proof genesis parameters

11.1 Required fields

Genesis MUST defini:

• initial statement type registry root
• initial proof type registry root
• revocation semantics defaults where global
• trust tier defaults if protocol-global
• retention defaults if protocol-global

11.2 Rule

Tipurile normative inițiale MUST fi cunoscute și stabile din momentul zero.

12. Governance genesis parameters

12.1 Required fields

Genesis MUST defini:

• governance parameter classes initial registry
• quorum profiles initial
• chamber model initial
• timelock minima initiale
• emergency powers initial scope
• constitutional guard baseline
• challenge window defaults

12.2 Rule

Constituția inițială a guvernanței MUST fi parte din genesis, nu anexă informală.

13. Agent control genesis parameters

13.1 Required fields

Genesis SHOULD defini:

• standard mandate classes available at launch
• baseline cap classes
• journaling requirement defaults
• emergency halt hook baseline
• aggregate portfolio scope policy defaults where protocol-wide

13.2 Rule

Dacă agent layer este activ de la lansare, parametrii săi de bază MUST exista în genesis.

14. Genesis assets

14.1 Purpose

Definește activele existente la pornire.

14.2 Abstract structure

GenesisAssetEntry {
  asset_id
  asset_symbol_hash
  asset_class
  divisibility
  total_initial_supply?
  mint_policy_ref?
  burn_policy_ref?
  transfer_policy_ref?
  metadata_hash?
}

14.3 Required asset

AZR MUST exista ca activ nativ.

14.4 Optional assets

Genesis MAY include și alte active:

• wrapped test assets on testnet
• bootstrap governance assets if constitution permits
• operational service bond classes if represented explicitly

14.5 Rule

Supply-ul inițial declarat pentru active conservative MUST corespunde exact alocărilor sau mecanismului de mint inițial.

15. Genesis allocations

15.1 Purpose

Definește cine primește ce la pornire.

15.2 Abstract structure

GenesisAllocation {
  allocation_id
  recipient_policy
  asset_id
  amount
  allocation_class
  vesting_profile_ref?
  lock_profile_ref?
  metadata_hash?
}

15.3 allocation_class examples

• validator_stake
• treasury
• recovery_reserve
• ecosystem_allocation
• foundation_or_bootstrap
• public_distribution
• testnet_faucet
• operator_bond_bootstrap

15.4 Rule

Genesis allocations MUST fi transformabile determinist în Cells sau stake records inițiale.

16. Vesting and lock profiles

16.1 Need

Unele alocări inițiale pot fi blocate sau vesting-bound.

16.2 Abstract structure

GenesisLockProfile {
  lock_profile_id
  lock_type
  valid_from_epoch?
  unlock_schedule_hash
  associated_policy_ref?
}

16.3 Rule

Locking semantics la genesis MUST fi deja expressibile prin politici/cells/machine constraints standardizate, nu prin excepții ad-hoc.

17. Genesis validators

17.1 Purpose

Setul inițial de participanți eligibili pentru consens.

17.2 Abstract structure

GenesisValidatorEntry {
  validator_id
  identity_policy_ref
  proposer_key_ref?
  verifier_key_ref?
  notary_key_ref?
  initial_stake_amount
  role_flags
  eligibility_flags
  metadata_hash?
}

17.3 Rule

Cheile de rol MUST fi clar separate sau explicit unify dacă modelul o permite. Stake-ul inițial MUST fi suficient pentru rolurile activate.

18. Genesis committees

18.1 Need

Pentru epoch 0/1, protocolul are nevoie de roluri inițiale determinabile.

18.2 Two models

Genesis MAY:

1. defini doar validatorii și seed-ul, iar comitetele se derivă automat;
2. ancora explicit primele comitete pentru un număr foarte mic de epoci bootstrap, dacă specificația o permite.

18.3 Recommendation

V1 SHOULD favoriza derivarea din seed pentru simplitate și verificabilitate.

18.4 If explicit bootstrap committees exist

Structura SHOULD fi:

GenesisCommitteeBootstrap {
  epoch_index
  proposer_set_root
  verifier_set_root
  notary_set_root
}

19. Genesis registries

19.1 Purpose

Protocolul pornește cu registries deja populate.

19.2 Required registries

Genesis SHOULD ancora:

• statement type registry
• proof type registry
• governance parameter registry
• opcode/profile registry roots if needed
• capability tier registry
• fault family registry
• runbook/risk class registry roots where protocol-relevant

19.3 Rule

Registries care afectează consensul sau semantics normative MUST fi parte din genesis roots.

20. Genesis policies

20.1 Need

Unele politici trebuie să existe de la zero.

20.2 Typical initial policies

• treasury policy
• recovery reserve policy
• genesis governance bootstrap policy
• initial issuer policies for protocol-native witnesses
• genesis mint/burn/transfer policies for assets
• emergency committee bootstrap policy if used

20.3 Rule

Toate politicile inițiale critice MUST fi canonicale, referibile și incluse în state/indexes inițiale.

21. Genesis machines

21.1 Optionality

Genesis MAY include mașini deployate inițial dacă protocolul sau ecosistemul are nevoie de ele la start.

21.2 Examples

• treasury machine
• reserve machine
• governance proposal machine
• recovery coordination machine
• bootstrap registry manager machine

21.3 Requirements

Pentru fiecare maşină genesis:

• code_hash
• abi_hash
• initial_state_root
• bounds
• policies
• rent/prepaid model
• permission surface MUST fi complet specificate.

21.4 Rule

Genesis machines MUST fi tratate exact ca deploy-uri protocolare inițiale, nu ca entități magice.

22. Genesis witnesses

22.1 Optionality

Genesis MAY include witnessuri inițiale dacă sunt necesare pentru:

• bootstrap approvals
• constitutional attestation
• initial committee attestations
• initial governance anchoring

22.2 Rule

Genesis witnessuri MUST respecta aceleași formate canonice ca witnessurile obișnuite.

23. Genesis governance state

23.1 Purpose

Definește starea de guvernanță la time zero.

23.2 Abstract structure

GenesisGovernanceState {
  constitutional_root
  active_parameter_registry_root
  active_quorum_profiles_root
  active_chambers_root
  emergency_powers_root
  active_proposals_root?   // usually empty
  active_outcomes_root?    // usually empty
  active_activations_root? // usually empty
}

23.3 Recommendation

În mod normal, active_proposals_root, active_outcomes_root, active_activations_root SHOULD fi empty la genesis, cu excepția cazului de bootstrap special.

24. Genesis feature flags

24.1 Purpose

Nu toate capabilitățile definite în specificații trebuie pornite din prima.

24.2 Abstract structure

GenesisFeatureFlags {
  enabled_flag_ids
  disabled_flag_ids
}

24.3 Examples

• BVM enabled
• agent layer enabled
• specific proof family enabled
• governance chamber type enabled
• experimental feature disabled

24.4 Rule

Feature flags active la genesis MUST fi clar listate și hashed în parameter state inițială.

25. Genesis recovery state

25.1 Optionality

De obicei empty. Dar protocolul MAY defini bootstrap recovery config.

25.2 Examples

• initial recovery reserve lock state
• emergency contact root hash for ops documentation (non-consensus metadata)
• initial safe mode thresholds

25.3 Rule

Numai elementele consensus-relevante MUST afecta derived roots.

26. Derived roots commitment

26.1 Purpose

Genesis trebuie să ancora explicit rădăcinile derivate pentru verificare rapidă.

26.2 Structure

DerivedRootsCommitment {
  genesis_hash
  parameter_root
  validator_root
  asset_root
  allocation_root
  policy_root
  machine_root
  witness_root
  governance_root
  feature_flag_root
  initial_state_root
}

26.3 Rule

Un nod conforme SHOULD recompute all roots and compare them exactly before joining network.

27. Genesis hash

27.1 Definition

genesis_hash = H("AZ:GENESIS:" || canonical_genesis_spec)

27.2 Role

genesis_hash servește la:

• chain boot identity
• checkpoint anchoring
• peer compatibility checks
• explorer/tooling identity
• anti-replay cross-network logic

27.3 Rule

Nodes with different genesis_hash MUST treat each other as different networks.

28. Initial state derivation

28.1 Principle

Genesis nu este doar listă de obiecte. Trebuie să derive o stare inițială completă.

28.2 Required derivations

Nodul MUST derive:

• initial utxo_set
• initial policy index
• initial validator/stake state
• initial machine registry and machine state index
• initial witness index
• initial governance parameter state
• initial feature flag state
• initial reserves/treasury/recovery objects if modeled on-chain

28.3 initial_state_root

Trebuie calculat determinist din această stare.

29. Genesis UTXO derivation

29.1 Rule

Fiecare GenesisAllocation care produce valoare liberă sau blocată MUST fi mapată determinist la una sau mai multe Cells.

29.2 Mapping model

Mapping-ul SHOULD fi standardizat:

GenesisAllocation -> one canonical Cell

sau, dacă lock/vesting o cere:

GenesisAllocation -> canonical machine lock state + associated Cell(s)

29.3 Rule

Supply total and resulting cells MUST reconcile exactly.

30. Genesis stake derivation

30.1 Rule

Pentru fiecare validator entry cu stake inițial:

• stake amount MUST fi derivat în validator/stake state;
• dacă stake-ul este reprezentat și economic prin Cells/blocări, mapping-ul MUST fi clar și non-duplicativ.

30.2 No double counting

Stake evidențiat în validator set și în allocations MUST NOT crea supply duplicat.

31. Genesis parameter state derivation

31.1 Rule

Parameter state activă la epoch zero MUST deriva din:

• genesis parameters
• registries
• governance state
• feature flags

31.2 Effective epoch

Toate aceste valori au effective_epoch = genesis_epoch_index.

32. Genesis validation pipeline

32.1 A node MUST validate genesis in this order:

1. canonical decode
2. schema/version compatibility
3. chain identity derivation
4. registry and parameter coherence
5. asset definitions validity
6. allocation validity and supply reconciliation
7. validator entry validity
8. committee bootstrap validity if present
9. policy validity
10. machine/witness genesis object validity
11. governance state validity
12. feature flag consistency
13. derived root recomputation
14. genesis hash recomputation
15. initial state root recomputation

32.2 Rule

Failure in any step means node MUST reject genesis and MUST NOT join that network.

33. Genesis signature / attestation layer

33.1 Need

Deși genesis este normativ prin conținut și hash, deployments MAY dori atestări de distribuție.

33.2 Optional structure

GenesisAttestation {
  genesis_hash
  attestor_policy
  attestation_type
  signature_bundle
}

33.3 Rule

Genesis validity MUST NOT depend on these attestations unless the deployment constitution explicitly says so. Genesis hash remains the source of truth.

34. Network boot compatibility checks

34.1 On peer handshake, nodes SHOULD compare:

• chain_id
• genesis_hash
• protocol major version
• supported feature set compatibility
• active genesis checkpoint reference

34.2 Rule

Mismatch on genesis_hash MUST cause network incompatibility classification.

35. Mainnet vs testnet genesis differences

35.1 Mainnet genesis SHOULD have:

• conservative feature flags
• production-grade validator set bootstrap
• full constitutional parameter roots
• real economic parameters
• minimal experimental features

35.2 Public testnet genesis MAY have:

• larger faucet/test allocations
• reduced bonds
• simplified economic ranges
• extra observability features
• intentionally enabled test hooks if non-consensus and clearly bounded

35.3 Rule

Even testnet genesis MUST remain canonical and fully replayable.

36. Devnet genesis

36.1 Purpose

Local development and experimentation.

36.2 Characteristics

Devnet genesis MAY:

• have tiny validator set
• use simplified seeds
• include debug-only non-mainnet flags
• have permissive allocations

36.3 Rule

Devnet flags MUST NOT be accepted silently on mainnet/public testnet genesis.

37. Genesis publication package

37.1 A serious deployment SHOULD publish:

• canonical genesis file
• genesis hash
• chain_id
• derived roots commitment
• human-readable manifest
• reference client compatibility note
• validator bootstrap list hash
• initial parameter summary
• signed release artifact hashes

37.2 Rule

The human-readable manifest is advisory. The canonical genesis file and its hash are normative.

38. Genesis conformance requirements

38.1 AZ-011 integration

Conformance suites SHOULD include:

• canonical genesis parsing
• root recomputation
• supply reconciliation
• validator set derivation
• parameter state derivation
• chain identity derivation
• mismatch rejection

38.2 Rule

A full node implementation MUST be able to derive genesis roots exactly from the published genesis file.

39. Genesis change impossibility after launch

39.1 Principle

Once a network launches, changing genesis creates another network.

39.2 Rule

Any post-launch change to genesis blob MUST be treated as:

• forked network,
• replacement testnet,
• or invalid attempt, not as “same chain updated.”

40. Bootstrap governance constraints

40.1 Need

Genesis can encode bootstrap governance powers. These must be constrained.

40.2 Rule

Genesis MUST NOT sneak in unlimited bootstrap powers inconsistent with constitutional claims. Any bootstrap exception SHOULD be:

• explicit,
• scoped,
• time-limited if possible,
• auditable.

41. Bootstrap emergency powers

41.1 Optionality

Some networks may want initial emergency guardrails stronger at launch.

41.2 Rule

If bootstrap emergency powers are stronger than steady-state:

• this MUST be explicit in genesis;
• expiry or transition path SHOULD be defined;
• governance constitution MUST acknowledge it.

42. Genesis security considerations

42.1 Dangerous anti-patterns

Deployments SHOULD avoid:

1. hidden allocation side files not hashed in genesis
2. validator lists published separately and inconsistently
3. supply totals not reconciling to allocations
4. feature flags implied by docs but not genesis
5. bootstrap committees not derivable or not listed
6. genesis machines with opaque code hashes or missing manifests
7. inconsistent chain name vs chain_id usage
8. emergency bootstrap powers with no expiry
9. ad-hoc local patches to genesis after launch
10. one genesis file, multiple unofficial “equivalent” encodings

42.2 Rule

Genesis must be boringly exact.

43. Formal goals

AZ-016 urmărește aceste obiective:

43.1 Genesis uniqueness

Același genesis canonical produce un singur genesis_hash.

43.2 Bootstrap reproducibility

Orice nod conform poate reconstrui aceeași stare inițială.

43.3 Network separation

Genesis diferite produc identități de rețea diferite și incomparabile direct.

43.4 No hidden initial power

Toate drepturile, parametrii și excepțiile inițiale relevante trebuie să fie explicite în genesis.

44. Formula documentului

Genesis = canonical chain identity + initial parameters + initial assets/stake/roles + initial registries/policies + derived roots + immutable network origin

45. Relația cu restul suitei

• AZ-012 spune cum arată nodul.
• AZ-015 spune cum răspunde la incidente.
• AZ-016 spune din ce realitate exactă pornește nodul și rețeaua.

Pe scurt: fără AZ-016, protocolul are reguli dar nu are origine normativă unică.

46. Ce urmează

După AZ-016, documentul corect este:

AZ-017 — Mainnet Readiness Checklist

Acolo trebuie fixate:

• condițiile obligatorii înainte de lansare,
• audituri minime,
• teste minime,
• conformance gates,
• economic and ops gates,
• go/no-go criteria.

Închidere

O rețea nu începe atunci când primul nod pornește. Începe atunci când toate nodurile care pornesc pot demonstra că au pornit din exact aceeași stare inițială, cu exact aceleași reguli, exact aceleași rădăcini și exact aceeași identitate de lanț.

Acolo începe originea protocolară reală.