AZ-026 — Genesis Ceremony and Launch Ceremony Protocol v1

Status

Acest document definește protocolul formal pentru:

• ceremonia de verificare a pachetului genesis;
• ceremonia de lansare a rețelei;
• confirmările obligatorii înainte de network start;
• ordinea semnărilor și aprobărilor;
• trecerea controlată de la artefacte validate la rețea activă.

AZ-022 a definit pachetul genesis concret. AZ-025 a definit manualul operațional pentru validatori și operatori. AZ-026 răspunde la întrebarea: cum transformăm aceste verificări și pachete într-o ceremonie disciplinată, auditată și suficient de formală încât pornirea rețelei să nu fie un act informal, ambiguu sau bazat pe presupuneri?

Scopul documentului este să fixeze:

• fazele ceremoniei genesis;
• fazele ceremoniei de launch;
• actorii și rolurile;
• artefactele care trebuie confirmate;
• obiectele de aprobare și închidere;
• condițiile de abort, defer și retry;
• dovada formală a faptului că rețeaua a pornit din exact package-ul și exact release-ul aprobate.

Acest document se bazează pe:

• AZ-002 până la AZ-025, cu accent direct pe AZ-016, AZ-017, AZ-022 și AZ-025.

Termeni:

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

1. Obiectiv

AZ-026 răspunde la 10 întrebări:

1. Ce este ceremonia genesis și ce este ceremonia de launch?
2. Ce artefacte trebuie confirmate înainte de start?
3. Cine confirmă ce și în ce rol?
4. În ce ordine se închid verificările și aprobările?
5. Ce dovadă rămâne că ceremonia a fost executată corect?
6. Ce se întâmplă dacă apar mismatch-uri în timpul ceremoniei?
7. Cum se declară oficial GO și cum se declară NO_GO?
8. Cum se trece de la package verification la bootstrap de noduri?
9. Cum evităm „lansarea prin chat” sau prin presupuneri neverificate?
10. Cum facem ceremonia repetabilă, auditabilă și compatibilă cu runbooks și release package?

2. Principii

2.1 Ceremony is not theater

Ceremonia MUST reprezenta verificări reale, nu simple declarații simbolice.

2.2 Check then sign

Orice confirmare SHOULD urma după verificare efectivă și verificabilă. Semnătura fără verificare este invalidă operațional, chiar dacă este criptografic validă.

2.3 Exact artifact binding

Ceremonia MUST ancora explicit:

• exact release package;
• exact genesis package;
• exact genesis_hash;
• exact chain_id;
• exact release candidate / final release ids;
• exact operator readiness scope.

2.4 Abort is a valid ceremony outcome

Ceremonia MUST putea produce:

• GO
• DEFER
• NO_GO fără presiune procedurală de a ajunge obligatoriu la start.

2.5 Shared truth, not individual guesses

Actorii ceremoniei MUST folosi aceleași artefacte și aceleași hash-uri, nu copii „aproape aceleași”.

2.6 Audit trail first

Ceremonia MUST lăsa:

• timeline,
• hash-uri,
• aprobări,
• semnături,
• verdicturi,
• blockers,
• eventuale abort reasons.

3. Ceremony classes

3.1 Two main ceremonies

ATLAS ZERO SHOULD distinge:

1. GENESIS_CEREMONY
2. LAUNCH_CEREMONY

3.2 Genesis ceremony

Scopul ei este:

• confirmarea pachetului genesis;
• confirmarea identității lanțului;
• confirmarea validator bootstrap set;
• confirmarea derived roots;
• confirmarea că exact acest package este eligibil pentru launch.

3.3 Launch ceremony

Scopul ei este:

• confirmarea release package final;
• confirmarea compatibilității cu genesis package;
• confirmarea readiness operațională a validatorilor;
• emiterea verdictului formal de lansare;
• autorizarea bootstrap-ului de rețea.

4. Ceremony roles

4.1 Recommended roles

Ceremonia SHOULD include, după caz:

• ROLE_LAUNCH_COORDINATOR
• ROLE_GENESIS_CUSTODIAN
• ROLE_RELEASE_MANAGER
• ROLE_SECURITY_REVIEWER
• ROLE_CONSENSUS_LEAD
• ROLE_OPS_LEAD
• ROLE_VALIDATOR_OPERATOR
• ROLE_NOTARY_OPERATOR
• ROLE_AUDIT_SCRIBE
• ROLE_OBSERVER
• ROLE_GO_NO_GO_SIGNER

4.2 Rule

Rolurile MUST fi clare. O persoană poate îndeplini mai multe roluri, dar conflictul de rol SHOULD fi minimizat pentru scope critic.

4.3 Audit Scribe

Un rol explicit pentru jurnalizare SHOULD exista obligatoriu la ceremonii serioase.

5. Ceremony phases overview

5.1 Genesis ceremony phases

1. package intake
2. independent verification
3. root and identity confirmation
4. validator bootstrap confirmation
5. attestation sufficiency confirmation
6. genesis ceremony close

5.2 Launch ceremony phases

1. release package confirmation
2. compatibility lock confirmation
3. operator readiness confirmation
4. go/no-go review
5. launch authorization
6. bootstrap execution
7. early epoch observation close

6. Ceremony artifacts

6.1 Mandatory ceremony inputs

Ceremony MUST reference exact ids/hashes for:

• release package
• release manifest
• genesis package
• genesis package manifest
• genesis_hash
• chain_id
• validator set root
• parameter root
• derived roots commitment
• required attestation roots

6.2 Optional but recommended inputs

• launch-critical conformance bundle ref
• residual risk register hash
• incident runbook package hash
• operator manual bundle hash
• public communication template hash

6.3 Rule

Ceremony MUST not proceed on artifact descriptions alone. It needs exact identifiers and hashes.

7. Ceremony object model

7.1 Core objects

Ceremonies SHOULD produce canonical objects:

• GenesisCeremonyRecord
• GenesisCeremonyConfirmation
• LaunchCeremonyRecord
• LaunchCeremonyConfirmation
• GoNoGoDecisionRecord
• LaunchAuthorizationRecord
• LaunchAbortRecord
• LaunchObservationRecord

7.2 Rule

Even if some communication occurs off-chain, final ceremony truth SHOULD be represented by canonical auditable records.

8. GenesisCeremonyRecord

8.1 Canonical structure

GenesisCeremonyRecord {
  version_major
  version_minor

  ceremony_id
  ceremony_type
  target_network_class
  target_chain_id
  target_genesis_hash
  genesis_package_id
  genesis_package_manifest_id
  validator_set_root
  parameter_root
  derived_roots_commitment_hash
  attestation_root
  start_time_unix_ms
  status
  metadata_hash?
}

8.2 status

• OPEN
• VERIFYING
• CONFIRMED
• FAILED
• ABORTED
• SUPERSEDED

8.3 Rule

One genesis ceremony record SHOULD map to one specific genesis package scope.

9. GenesisCeremonyConfirmation

9.1 Canonical structure

GenesisCeremonyConfirmation {
  confirmation_id
  ceremony_id
  confirmer_policy_ref
  confirmer_role_class
  confirmation_class
  confirmation_scope_hash
  statement_hash
  verdict
  evidence_refs?
  timestamp_unix_ms
  signature_envelopes
}

9.2 confirmation_class examples

• genesis_package_verified
• genesis_hash_confirmed
• chain_id_confirmed
• validator_root_confirmed
• parameter_root_confirmed
• attestation_bundle_confirmed
• package_scope_match_confirmed

9.3 verdict

• CONFIRM
• REJECT
• CONDITIONAL
• INCONCLUSIVE

9.4 Rule

For critical confirmation classes, CONDITIONAL or INCONCLUSIVE SHOULD block ceremony close until resolved or explicitly deferred.

10. LaunchCeremonyRecord

10.1 Canonical structure

LaunchCeremonyRecord {
  version_major
  version_minor

  ceremony_id
  ceremony_type
  target_network_class
  target_chain_id
  target_genesis_hash
  release_package_id
  release_manifest_id
  linked_genesis_ceremony_id
  launch_window_hash
  start_time_unix_ms
  status
  metadata_hash?
}

10.2 status

• OPEN
• VERIFYING
• READY_FOR_DECISION
• GO_APPROVED
• NO_GO
• DEFERRED
• ABORTED
• COMPLETED

10.3 Rule

Launch ceremony MUST bind exact release package + exact genesis package lineage.

11. LaunchCeremonyConfirmation

11.1 Canonical structure

LaunchCeremonyConfirmation {
  confirmation_id
  ceremony_id
  confirmer_policy_ref
  confirmer_role_class
  confirmation_class
  statement_hash
  verdict
  evidence_refs?
  timestamp_unix_ms
  signature_envelopes
}

11.2 confirmation_class examples

• release_package_verified
• release_genesis_compatibility_confirmed
• binary_hash_confirmed
• operator_readiness_confirmed
• monitoring_live_confirmed
• key_readiness_confirmed
• incident_path_staffed_confirmed
• validator_role_ready_confirmed
• notary_role_ready_confirmed
• launch_window_ready_confirmed

11.3 Rule

Operator confirmations MUST be scoped to actual nodes/roles where relevant.

12. Confirmation scope binding

12.1 Need

A generic “I approve” is insufficient.

12.2 Rule

Each confirmation SHOULD bind to:

• exact ceremony_id
• exact package ids
• exact role scope if role-specific
• exact network class / chain_id / genesis_hash where relevant

12.3 Result

A launch confirmation for one ceremony MUST NOT be reusable for another launch candidate.

13. Genesis ceremony preconditions

13.1 Genesis ceremony SHOULD NOT start unless:

• genesis package is frozen
• package manifest exists
• attestation bundle exists
• validators can access package
• ceremony participants know exact target scope
• audit scribe is assigned
• blocker list is explicit

13.2 Rule

Genesis ceremony with floating artifacts or unstable package ids is invalid by design.

14. Genesis ceremony steps

14.1 Step order

1. open ceremony record
2. announce exact package ids and hashes
3. distribute/confirm access to identical package scope
4. independent package verification by required roles
5. independent genesis_hash recomputation
6. independent chain_id recomputation
7. validator set root confirmation
8. parameter root confirmation
9. attestation sufficiency confirmation
10. collect confirmations
11. resolve blockers
12. close as CONFIRMED or FAILED/ABORTED

14.2 Rule

The ceremony SHOULD NOT skip recomputation merely because hashes are already published.

15. Independent verification requirement

15.1 Need

Ceremony should not rely on a single verifying machine or person.

15.2 Rule

At least multiple independent actors or environments SHOULD recompute:

• genesis_hash
• chain_id
• derived roots for critical launches.

15.3 Strong recommendation

For mainnet-class launch, genesis verification SHOULD be independently reproduced by more than one party or more than one implementation if feasible.

16. Genesis ceremony close conditions

16.1 Ceremony MAY close CONFIRMED only if:

• all mandatory confirmations are CONFIRM
• no unresolved blocker remains
• package scope is exact and stable
• no artifact mismatch exists
• no critical attestation gap exists

16.2 Ceremony MUST close FAILED or ABORTED if:

• package mismatch detected
• roots mismatch detected
• validator set mismatch detected
• attestation insufficiency unresolved
• chain identity ambiguity exists

17. Launch ceremony preconditions

17.1 Launch ceremony SHOULD NOT start unless:

• genesis ceremony is CONFIRMED
• release package is frozen
• release package approvals exist
• operator manual released
• launch window defined
• go/no-go signers assigned
• incident path staffed
• operators have completed local preflight or are in the process with explicit status

17.2 Rule

Launch ceremony without closed genesis ceremony is invalid for production scope.

18. Launch ceremony steps

18.1 Step order

1. open launch ceremony record
2. restate exact release package and genesis package identities
3. verify release package approvals and linkage
4. verify release/genesis compatibility
5. collect operator readiness confirmations
6. collect role readiness confirmations
7. collect monitoring and incident readiness confirmations
8. review blockers and residual risks
9. produce go/no-go decision
10. if GO, produce launch authorization record
11. authorize bootstrap start
12. collect early epoch observation records
13. close ceremony as completed or escalated

18.2 Rule

The launch ceremony SHOULD make the transition from “approved packages exist” to “authorized network start” explicit and auditable.

19. Operator readiness confirmations

19.1 Each validator/operator SHOULD confirm:

• local release artifact hash verified
• local genesis package verified
• genesis_hash matches ceremony target
• chain_id matches ceremony target
• preflight passed
• keys loaded and mapped correctly
• monitoring live
• incident escalation path reachable

19.2 Optional role-split confirmations

May be separate:

• proposer ready
• verifier ready
• notary ready
• validation-only ready

19.3 Rule

A participant MUST NOT issue readiness confirmation if it has not run local checks.

20. GoNoGoDecisionRecord

20.1 Canonical structure

GoNoGoDecisionRecord {
  decision_id
  launch_ceremony_id
  decision_class
  blocker_root?
  residual_risk_root?
  approved_scope_hash
  timestamp_unix_ms
  signer_refs
  signature_envelopes
}

20.2 decision_class

• GO
• NO_GO
• DEFER
• ABORT

20.3 Rule

GO MUST be bound to exact ceremony scope and exact launch candidate. No generic “we approve launch in principle”.

21. Go criteria inside ceremony

21.1 Ceremony SHOULD issue GO only if:

• genesis ceremony confirmed
• release package verified
• operator readiness threshold satisfied
• no unresolved critical blockers
• no artifact mismatches
• no scope ambiguity
• launch window active and staffed
• residual risks acknowledged and within acceptable range

21.2 Rule

Any known critical mismatch in artifacts or validator readiness MUST force NO_GO or DEFER.

22. No-go and defer conditions

22.1 NO_GO recommended if:

• critical package mismatch
• unresolved genesis inconsistency
• release artifact revocation
• critical roles not ready
• incident path unavailable
• new critical vulnerability discovered

22.2 DEFER recommended if:

• artifacts are valid but not all operators ready
• launch window logistics fail
• monitoring incomplete but quickly fixable
• non-critical blockers remain but push launch safety below threshold

22.3 Rule

DEFER is not failure. It is disciplined postponement.

23. LaunchAuthorizationRecord

23.1 Canonical structure

LaunchAuthorizationRecord {
  authorization_id
  launch_ceremony_id
  linked_go_decision_id
  target_network_class
  target_chain_id
  target_genesis_hash
  authorized_start_window_hash
  authorized_release_package_id
  authorized_genesis_package_id
  timestamp_unix_ms
  signature_envelopes
}

23.2 Rule

Bootstrap start SHOULD require this authorization record for serious launch scope.

24. Bootstrap execution record

24.1 Need

Need formal evidence of actual start.

24.2 Canonical structure

BootstrapExecutionRecord {
  bootstrap_execution_id
  launch_authorization_id
  first_bootstrap_time_unix_ms
  participating_validator_root
  initial_observed_state_hash
  initial_peer_confirmation_root?
  notes_hash?
}

24.3 Rule

This does not replace genesis or release truth. It records the start event under authorized scope.

25. Early epoch observation

25.1 Purpose

Ceremony is not truly complete at time zero alone. Need initial observation of healthy start.

25.2 LaunchObservationRecord

LaunchObservationRecord {
  observation_id
  launch_ceremony_id
  observation_window_class
  observed_epoch_range
  finalized_root_samples_root
  anomaly_root?
  verdict
  timestamp_unix_ms
}

25.3 observation_window_class examples

• first_blocks
• first_epoch
• first_3_epochs
• early_stabilization

25.4 verdict

• healthy
• degraded
• incident_opened
• requires_safe_mode
• requires_recovery

26. Ceremony timeline discipline

26.1 Rule

Every critical event SHOULD have timestamped record:

• ceremony open
• artifact hash announcement
• confirmation received
• blocker declared
• blocker resolved
• decision issued
• authorization issued
• bootstrap started
• early observation completed

26.2 Purpose

Prevents memory-based reconstruction later.

27. Ceremony communications

27.1 Human communications SHOULD map to canonical statements like:

• “confirm genesis_hash X”
• “confirm chain_id Y”
• “confirm release_package_id Z”
• “operator N ready for verifier role”
• “launch blocker B remains open”
• “decision = GO”
• “bootstrap authorized”

27.2 Rule

Free-form chat MAY accompany the process, but critical truth SHOULD be reducible to structured confirmations and records.

28. Ceremony blocker model

28.1 Blocker structure

CeremonyBlocker {
  blocker_id
  ceremony_id
  blocker_class
  severity
  description_hash
  evidence_refs?
  status
}

28.2 blocker_class examples

• artifact_mismatch
• genesis_mismatch
• release_scope_mismatch
• validator_not_ready
• signer_not_ready
• monitoring_not_ready
• unresolved_security_issue
• network_partition_risk
• incident_path_missing

28.3 status

• open
• mitigated
• resolved
• accepted_residual
• invalid

28.4 Rule

Open critical blockers SHOULD prohibit GO.

29. Ceremony attestation policy

29.1 Recommended mandatory confirmations for genesis ceremony

• genesis package verified
• genesis_hash confirmed
• chain_id confirmed
• derived roots confirmed
• validator root confirmed
• parameter root confirmed

29.2 Recommended mandatory confirmations for launch ceremony

• release package verified
• release/genesis compatibility confirmed
• operator readiness threshold met
• monitoring live confirmed
• incident path staffed confirmed
• launch window ready confirmed

29.3 Rule

Policies MAY vary by network class, but mainnet class SHOULD be strictest.

30. Ceremony quorum model

30.1 Need

Not every single participant may need to confirm every field.

30.2 Rule

Ceremony policy SHOULD define:

• mandatory role confirmations
• optional observer confirmations
• quorum thresholds for readiness
• whether all notaries or just threshold of notary operators must confirm readiness

30.3 Recommendation

Mainnet launch SHOULD require explicit confirmations from all core operational leads and sufficient validator role representatives.

31. Ceremony retry policy

31.1 If ceremony fails or defers

A retry MUST create:

• new ceremony record
• new decision record
• new timestamps and SHOULD reference previous failed ceremony.

31.2 Rule

Do not silently continue an old failed ceremony as if nothing happened.

32. Supersession of ceremonies

32.1 Need

If release package or genesis package changes, old ceremony is obsolete.

32.2 Rule

A ceremony bound to superseded artifacts MUST itself become superseded or invalid for GO.

32.3 Rule

New artifacts require new ceremony scope.

33. Abort during launch window

33.1 If NO_GO or ABORT occurs after launch ceremony opens but before bootstrap

SHOULD:

• emit LaunchAbortRecord
• preserve all blockers and evidence
• notify operators not to activate roles
• preserve artifact scope for next attempt or supersession

33.2 LaunchAbortRecord

LaunchAbortRecord {
  abort_id
  launch_ceremony_id
  abort_reason_hash
  timestamp_unix_ms
  evidence_refs?
}

34. Interaction with AZ-025 manual

34.1 Relationship

AZ-025 defines what each operator must do locally. AZ-026 defines how these local truths become shared launch truth.

34.2 Rule

A local preflight pass is not enough by itself for launch. It should feed into ceremony confirmation.

35. Interaction with AZ-017 readiness

35.1 Relationship

AZ-017 says when project is launch-ready. AZ-026 says how the final ritualized and auditable handoff into actual network start happens.

35.2 Rule

Readiness without ceremony risks informal mismatch. Ceremony without readiness is empty formalism. Both are needed.

36. Interaction with incident response

36.1 If anomaly appears during ceremony

SHOULD:

• preserve evidence
• open blocker
• possibly escalate incident
• avoid continuing to GO until resolved or formally deferred

36.2 Rule

Ceremony MUST integrate with incident runbooks, not bypass them.

37. Anti-patterns

Systems SHOULD avoid:

1. launch by verbal agreement only
2. one person announcing hashes without independent recomputation
3. confirmations not bound to exact package ids
4. mixing operator readiness with artifact approval in vague statements
5. continuing ceremony after critical mismatch “because deadline”
6. silent substitution of genesis or release package mid-ceremony
7. using screenshots or notes instead of canonical confirmation records
8. assuming “most validators are probably fine”
9. issuing GO before operator readiness threshold is checked
10. treating bootstrap time as separate from ceremony with no authorization bridge

38. Formal goals

AZ-026 urmărește aceste obiective:

38.1 Shared artifact truth

All launch participants converge on the same exact release and genesis identities.

38.2 Auditable authorization

The transition from readiness to actual launch is explicit and signed.

38.3 Blocker discipline

Critical mismatches force no-go/defer instead of social pressure based launch.

38.4 Repeatable launch protocol

The ceremony can be rerun or audited without ambiguity.

39. Formula documentului

Genesis/Launch Ceremony = exact artifact confirmation + role-scoped readiness confirmations + blocker review + signed go/no-go decision + explicit launch authorization + early epoch observation

40. Relația cu restul suitei

• AZ-022 definește genesis package.
• AZ-025 definește operator launch steps.
• AZ-026 definește ceremonia formală care leagă artefactele și operatorii de actul oficial al pornirii rețelei.

Pe scurt: AZ-022 dă pachetul, AZ-025 dă pașii locali, AZ-026 dă consensul social-procedural controlat care precede startul real.

41. Ce urmează

După AZ-026, documentul corect este:

AZ-027 — Public Testnet Program and Bug Intake Flow

Acolo trebuie fixate:

• obiectivele testnetului public,
• regulile de participare,
• canalele de raportare,
• severitatea bugurilor,
• triage și recompense sau recunoaștere,
• legătura dintre bug intake, conformance corpus și readiness.

Închidere

O rețea nu ar trebui să înceapă pentru că cineva a scris „go” într-un chat. Ar trebui să înceapă doar atunci când există: aceleași artefacte, aceleași hash-uri, aceleași confirmări, aceeași autorizație și un traseu clar de la verificare la bootstrap.

Acolo începe lansarea formală reală.