AZ-028 — Mainnet Launch Window Procedure v1

Status

Acest document definește procedura exactă pentru fereastra de lansare mainnet în ATLAS ZERO.

După AZ-001 până la AZ-027, există deja:

specificația protocolului și a subsistemelor lui;
criteriile de readiness;
pachetul genesis și release package;
manualul validatorilor și operatorilor;
ceremonia genesis și ceremonia de launch;
programul de testnet public și fluxul de bug intake.

AZ-028 răspunde la întrebarea: ce se întâmplă exact în fereastra reală de lansare mainnet, în ce ordine, cu ce checkpoint-uri, cu ce criterii de continuare sau abort și cum se trece din starea de ceremonie în starea de rețea activă monitorizată?

Scopul documentului este să fixeze:

fazele ferestrei de lansare;
cronologia operațională minimă;
checkpoint-urile obligatorii;
condițiile de go, hold, defer și abort în ultimele momente;
regulile de monitorizare live;
regulile pentru primele epoci și pentru ieșirea din restricted posture.

Acest document se bazează pe:

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

Termeni:

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

1. Obiectiv

AZ-028 răspunde la 10 întrebări critice:

Ce este exact launch window-ul?
Cum se împarte în faze și checkpoint-uri?
Ce trebuie să fie confirmat imediat înainte de bootstrap?
Ce se monitorizează live în momentul startului?
Când se continuă și când se ține hold?
Când se declară abort chiar dacă suntem foarte aproape de pornire?
Cum se tratează primele blocuri și primele epoci?
Cum se trece din launch ceremony în operațiuni restricționate de early mainnet?
Ce obiecte și jurnale trebuie emise în timpul ferestrei?
Cum evităm haosul de ultim moment, patch-urile improvizate și confuzia dintre probleme locale și probleme de rețea?

2. Principii

2.1 Launch window is a controlled execution interval

Fereastra de lansare MUST fi tratată ca interval operațional controlat, nu ca moment vag în care „pornim când pare bine”.

2.2 Final checks are still real checks

Verificările din ultimele minute MUST fi reale. Faptul că suntem aproape de start nu relaxează disciplina.

2.3 Abort remains valid until bootstrap truth begins

Până la emiterea efectivă a autorizării finale și bootstrap-ului, abort-ul sau defer-ul rămân rezultate legitime.

2.4 No surprise changes in launch window

În launch window MUST NOT apărea:

schimbări ad-hoc de artefacte;
schimbări informale de config consensus-critical;
înlocuiri tăcute de pachet genesis sau release;
resemnarea unor aprobări pe artefacte diferite sub aceeași identitate.

2.5 Restricted posture is part of launch

Lansarea nu se termină la primul bloc. Primele epoci sunt parte din procedură și SHOULD fi tratate ca fază specială.

3. Launch window definition

3.1 Definition

Launch window = intervalul operațional delimitat în care:

artefactele sunt înghețate;
verificările finale sunt active;
ceremonia de launch este închisă;
bootstrap-ul rețelei este autorizat;
primele epoci sunt observate sub regim restricționat.

3.2 Boundaries

Launch window SHOULD avea:

window_open_time
bootstrap_authorization_time
bootstrap_start_time
early_epoch_observation_end_time
restricted_posture_end_time

3.3 Rule

Aceste repere temporale SHOULD fi definite și jurnalizate clar.

4. Launch window phases

4.1 Standard phases

Launch window SHOULD fi împărțită în:

LW_PHASE_0_FREEZE_CONFIRMED
LW_PHASE_1_FINAL_CHECKS
LW_PHASE_2_GO_HOLD_POINT
LW_PHASE_3_BOOTSTRAP_AUTH
LW_PHASE_4_NETWORK_START
LW_PHASE_5_FIRST_BLOCKS
LW_PHASE_6_FIRST_EPOCHS
LW_PHASE_7_RESTRICTED_POSTURE
LW_PHASE_8_NORMALIZATION

4.2 Rule

Trecerea de fază SHOULD fi explicită și bazată pe checkpoint-uri, nu implicită prin trecerea timpului.

5. Freeze confirmed phase

5.1 Goal

Confirmăm că tot ce trebuie să fie înghețat este într-adevăr înghețat.

5.2 MUST confirm

release package frozen
genesis package frozen
release manifest frozen
package approvals active și nerevocate
launch window scope frozen
no pending supersession on launch-critical artifacts

5.3 Rule

Dacă un artifact critic nu este frozen, launch window SHOULD NOT intra în faza de final checks.

6. Final checks phase

6.1 Goal

Verificările finale operaționale și de integritate imediat înainte de go/hold point.

6.2 Mandatory checks

operator preflight recency acceptable
binary hash reconfirmation
genesis hash reconfirmation
chain_id reconfirmation
validator readiness threshold
monitoring live
incident path staffed
release/genesis linkage intact
no newly opened critical blocker
public/private advisories reviewed for last-moment issues

6.3 Rule

Final checks MUST be documented as concrete pass/fail items.

7. Go/Hold point

7.1 Definition

Momentul formal în care lansarea nu este încă autorizată, dar toate verificările finale ar trebui să fie complete.

7.2 Possible outcomes

PROCEED_TO_BOOTSTRAP_AUTH
HOLD
DEFER
ABORT

7.3 HOLD meaning

HOLD = pauză scurtă și controlată pentru clarificare. Nu este nici GO, nici NO_GO final.

7.4 Rule

HOLD SHOULD have explicit timeout or review boundary. Nu trebuie să devină ambiguitate deschisă.

8. Bootstrap authorization phase

8.1 Goal

Emiterea efectivă a autorizației finale pentru start.

8.2 Preconditions

valid GO decision
no open critical blockers
no artifact mismatch
readiness confirmations above threshold
launch coordinator and go/no-go signers aligned with recorded scope

8.3 Output

LaunchAuthorizationRecord
possibly BootstrapStartInstruction or equivalent operational artifact

8.4 Rule

Bootstrap MUST NOT start before formal authorization is recorded.

9. Network start phase

9.1 Goal

Trecerea de la autorizare la pornirea efectivă a nodurilor/rolurilor în ordinea planificată.

9.2 Recommended order

validation-only nodes or validation-only mode
proposer enablement
verifier enablement
notary enablement
observer confirmation that first network state matches expected scope

9.3 Rule

Ordinea exactă MAY vary by launch design, dar SHOULD fi predeterminată și documentată.

10. First blocks phase

10.1 Goal

Verificăm primele rezultate concrete ale rețelei:

primele propuneri
primele validări
primele blocuri compatibile
primele evenimente de finalizare sau near-finalization

10.2 Monitor explicitly

chain_id consistency
genesis anchor consistency
first block acceptance/rejection patterns
validator participation
unexpected invalid object spikes
immediate BVM anomalies if active
witness/proof anomalies if active

10.3 Rule

Anomaliile din first blocks phase MUST avea threshold de escalare mai agresiv decât în steady state.

11. First epochs phase

11.1 Goal

Confirmăm că rețeaua nu doar pornește, ci se stabilizează minim.

11.2 MUST observe

first finalized epoch root(s)
cadence of finality
absence of unexplained deterministic divergence
expected committee/role functioning
no suspicious no-finality pattern
no scope mismatch emerging from real traffic
no unexpected governance activation behavior

11.3 Rule

Primele epoci SHOULD produce LaunchObservationRecord structurat, nu doar observații informale.

12. Restricted posture phase

12.1 Definition

Faza imediat următoare primelor epoci în care rețeaua este live, dar operațional rămâne sub regim strict.

12.2 Restrictions SHOULD include

no casual binary changes
no non-critical config drift
higher alert sensitivity
lower threshold for incident escalation
stricter approval for role changes
increased snapshot cadence
explicit review before enabling deferred optional features

12.3 Rule

Restricted posture SHOULD remain active for a predetermined minimum observation interval or until explicit normalization decision.

13. Normalization phase

13.1 Goal

Trecerea controlată către operațiuni normale.

13.2 Preconditions

no unresolved critical anomalies from early epochs
finality cadence healthy enough
operator fleet stable enough
no active launch-scope blocker
restricted posture exit approved

13.3 Rule

Normalization MUST be explicit. It should not happen merely because time passed.

14. Launch window actors

14.1 Core actors

launch coordinator
audit scribe
go/no-go signers
genesis custodian
release manager
consensus lead
ops lead
validator operators
security lead
incident commander

14.2 Rule

Each actor SHOULD know:

exact responsibilities
escalation path
what they may confirm
what they may not improvise

15. Launch window object model

15.1 Recommended objects

LaunchWindowRecord
LaunchCheckpointRecord
LaunchHoldRecord
LaunchProceedRecord
BootstrapStartInstruction
LaunchLiveStatusRecord
RestrictedPostureExitRecord

15.2 Rule

Not all need to be on-chain. But they SHOULD be canonical and auditable in launch operations scope.

16. LaunchWindowRecord

16.1 Canonical structure

LaunchWindowRecord {
  version_major
  version_minor

  launch_window_id
  target_network_class
  target_chain_id
  target_genesis_hash
  authorized_release_package_id
  authorized_genesis_package_id
  window_open_time_unix_ms
  restricted_posture_expected_end_hash?
  status
  metadata_hash?
}

16.2 status

OPEN
IN_FINAL_CHECKS
AT_GO_HOLD_POINT
BOOTSTRAP_AUTHORIZED
NETWORK_STARTED
EARLY_EPOCHS_ACTIVE
RESTRICTED_POSTURE_ACTIVE
NORMALIZED
DEFERRED
ABORTED

16.3 Rule

One launch window record SHOULD map to one exact launch attempt scope.

17. LaunchCheckpointRecord

17.1 Purpose

Captures passage through an explicit checkpoint.

17.2 Canonical structure

LaunchCheckpointRecord {
  checkpoint_id
  launch_window_id
  checkpoint_class
  checkpoint_scope_hash
  verdict
  blocker_root?
  evidence_refs?
  timestamp_unix_ms
}

17.3 checkpoint_class examples

freeze_confirmed
final_checks_completed
go_hold_review_completed
bootstrap_authorized
first_blocks_healthy
first_epoch_finalized
restricted_posture_entered
restricted_posture_exit_ready

17.4 verdict

pass
fail
hold
conditional

18. LaunchHoldRecord

18.1 Purpose

Formalizes a temporary hold.

18.2 Canonical structure

LaunchHoldRecord {
  hold_id
  launch_window_id
  hold_reason_hash
  severity
  expected_resolution_scope_hash?
  timestamp_unix_ms
}

18.3 Rule

Hold SHOULD be bounded and reviewable. A long unbounded hold SHOULD become DEFER.

19. LaunchProceedRecord

19.1 Purpose

Records explicit continuation after hold or checkpoint review.

19.2 Canonical structure

LaunchProceedRecord {
  proceed_id
  launch_window_id
  prior_hold_id?
  justification_hash
  timestamp_unix_ms
  signature_envelopes?
}

19.3 Rule

Proceed after hold SHOULD be recorded explicitly. Silence is not proceed.

20. BootstrapStartInstruction

20.1 Purpose

Operational bridge between authorization and actual node actions.

20.2 Canonical structure

BootstrapStartInstruction {
  instruction_id
  launch_authorization_id
  target_network_class
  target_chain_id
  target_genesis_hash
  start_window_hash
  role_activation_order_hash
  timestamp_unix_ms
}

20.3 Rule

This instruction SHOULD bind exact launch scope and operational order.

21. LaunchLiveStatusRecord

21.1 Purpose

Structured live status snapshots during launch.

21.2 Canonical structure

LaunchLiveStatusRecord {
  live_status_id
  launch_window_id
  phase_class
  observed_finality_health_class
  observed_validator_participation_root?
  anomaly_root?
  local_operator_status_root?
  timestamp_unix_ms
}

21.3 Rule

These records SHOULD capture live truth snapshots without replacing lower-level logs.

22. RestrictedPostureExitRecord

22.1 Purpose

Marks the formal exit from early strict mode.

22.2 Canonical structure

RestrictedPostureExitRecord {
  exit_id
  launch_window_id
  justification_hash
  observation_root
  timestamp_unix_ms
  signature_envelopes?
}

22.3 Rule

No silent exit from restricted posture for serious production scope.

23. Final checks matrix

23.1 The launch window SHOULD maintain a final checks matrix including:

release artifact integrity
genesis artifact integrity
package compatibility
binary integrity
operator readiness threshold
role readiness threshold
monitoring readiness
incident path readiness
blocker review
latest advisory review

23.2 Rule

Each row SHOULD have:

owner
status
evidence ref
timestamp

24. Operator readiness threshold

24.1 Need

Not every participant may confirm at the exact same second.

24.2 Rule

Launch policy SHOULD define:

minimum validator/operator readiness threshold
minimum notary readiness threshold
whether some specific critical operators are mandatory
whether observers alone can remain pending without blocking

24.3 Rule

Threshold logic MUST be explicit before launch window starts.

25. Artifact immutability rule during launch window

25.1 Absolute rule

After LW_PHASE_0_FREEZE_CONFIRMED, launch-critical artifacts MUST NOT change.

25.2 If change is required

Then:

current launch window MUST go to DEFER or ABORT
new artifacts MUST create new scope
new authorization path MUST be created

25.3 Rule

No “small correction” in-place is allowed for critical launch artifacts.

26. Live monitoring requirements

26.1 During launch window, SHOULD monitor at minimum:

peer compatibility
invalid object rate
proposal/vote/notarization flows
finality latency/cadence
node crashes/restarts
signer health
state root mismatches if any
BVM anomaly rate if active
witness/proof anomaly rate if active
resource pressure

26.2 Rule

Monitoring MUST be live and actionable, not batch-only.

27. Launch anomaly classes

27.1 Recommended classes

preflight mismatch
artifact mismatch
genesis mismatch
role readiness gap
peer compatibility anomaly
no-finality anomaly
contradictory notarization anomaly
deterministic replay anomaly
BVM anomaly
witness/proof anomaly
governance activation anomaly
telemetry blindness anomaly

27.2 Rule

Each anomaly class SHOULD map to:

escalation path
hold/abort guidance
evidence preservation rule

28. Continue / Hold / Defer / Abort logic

28.1 CONTINUE

Use when:

checkpoint passed
no critical blocker open
observations within acceptable band

28.2 HOLD

Use when:

anomaly requires clarification
artifact truth still stable
short pause likely resolves uncertainty

28.3 DEFER

Use when:

scope remains valid but readiness insufficient
artifact truth stable yet launch unsafe now
retry later with same or superseding window possible

28.4 ABORT

Use when:

critical artifact truth compromised
launch scope invalidated
severe security or consistency problem discovered
bootstrap must not proceed under current scope

28.5 Rule

These states MUST be explicit, not inferred socially.

29. Last-minute abort triggers

29.1 Strong abort triggers SHOULD include

binary hash mismatch discovered
genesis hash mismatch discovered
release/genesis incompatibility discovered
critical operator or notary readiness collapse
live critical vulnerability disclosure confirmed
monitoring/incident path unavailable in critical scope
unexplained deterministic divergence sign
conflicting launch-scope artifact copies discovered

29.2 Rule

Even if ceremony was close to GO, these triggers SHOULD override schedule pressure.

30. Bootstrap start conditions

30.1 Bootstrap may begin only when:

launch authorization recorded
bootstrap instruction recorded
role activation order understood
operator readiness threshold satisfied
no open critical blocker
exact launch scope confirmed one final time

30.2 Rule

Bootstrap start MUST be a positive authorized act, not an emergent side-effect of operators starting whenever they feel ready.

31. First blocks acceptance threshold

31.1 Need

We need to know what counts as normal vs concerning.

31.2 Launch policy SHOULD define acceptable early ranges for:

block production cadence
validation error rate
expected participation
tolerated transient startup delays
tolerated short initial no-finality before escalation

31.3 Rule

Thresholds SHOULD be defined before launch, not invented after anomalies appear.

32. First finalized epoch checkpoint

32.1 Strong checkpoint

The first finalized epoch SHOULD trigger a formal checkpoint.

32.2 MUST verify at this checkpoint

finalized root matches expectations of healthy execution path
no unexplained divergence reports
validator participation sufficient
no hidden artifact mismatch discovered after live traffic

32.3 Rule

This checkpoint SHOULD be recorded explicitly.

33. Early-mainnet restricted posture entry

33.1 Entry trigger

After first healthy launch observations, the network enters restricted posture.

33.2 Entry record SHOULD include

launch_window_id
observed_epoch_range
active restrictions summary hash
incident sensitivity policy hash
snapshot policy summary hash

33.3 Rule

Restricted posture entry SHOULD be explicit and communicated to operators.

34. Restricted posture rules

34.1 During restricted posture, SHOULD require:

change freeze except incident-required changes
explicit approval for restarts of critical roles after anomaly
higher snapshot cadence
faster triage on bug reports and incidents
tighter comms discipline
more conservative interpretation of uncertain anomalies

34.2 Rule

Optional features not in launch subset SHOULD remain disabled unless previously authorized.

35. Exit from restricted posture

35.1 SHOULD require:

stable finality over defined observation window
no unresolved launch-critical incident
acceptable operator health
no unresolved artifact or scope confusion
explicit exit approval

35.2 Rule

Exit MUST be explicit through RestrictedPostureExitRecord or equivalent.

36. Communication protocol in launch window

36.1 Human comms SHOULD use structured statements like:

“checkpoint freeze_confirmed = pass”
“hold issued for anomaly class X”
“go/no-go decision = GO”
“bootstrap authorized for chain_id Y, genesis_hash Z”
“restricted posture entered”
“abort issued for release_package_id X”

36.2 Rule

Important launch communications SHOULD map directly to canonical records.

37. Evidence preservation during launch window

37.1 MUST preserve at minimum:

exact artifact ids and hashes
confirmation records
decision records
bootstrap instruction
live status records
anomaly evidence
logs around bootstrap and first epochs
first finalized roots

37.2 Rule

Launch window without preserved evidence becomes impossible to audit later.

38. Interaction with incidents during launch

38.1 If incident occurs during launch window:

preserve evidence
map to anomaly class
decide continue/hold/defer/abort
if necessary open formal incident response flow
do not bypass incident process for speed

38.2 Rule

Launch window procedure MUST integrate with AZ-015 runbooks.

39. Interaction with public testnet learnings

39.1 Launch window SHOULD consume known lessons from AZ-027, such as:

known fragility classes
historically common operator mistakes
known edge thresholds
latest unresolved but non-blocking residual risks

39.2 Rule

Mainnet launch window SHOULD not ignore the structured knowledge produced by public testnet.

40. Anti-patterns

Systems SHOULD avoid:

treating launch window as informal coordination only
skipping final recomputation because artifacts were checked “yesterday”
changing binaries or genesis files after freeze
activating all roles simultaneously with no staged observation
leaving hold state ambiguous
using “probably fine” instead of checkpoint criteria
continuing after critical artifact mismatch because many operators are already online
ending restricted posture silently
mixing operator-local outages with protocol-wide abort criteria
losing the exact artifact/decision/evidence lineage for first live epochs

41. Formal goals

AZ-028 urmărește aceste obiective:

41.1 Deterministic launch execution

The launch window follows a known sequence with explicit checkpoints and decisions.

41.2 Last-mile safety

Critical last-minute problems can still stop launch before they become network truth.

41.3 Early-mainnet observability

The network is not only started but observed and classified correctly through first epochs.

41.4 Controlled normalization

The network exits early restricted posture only after explicit evidence of sufficient stability.

42. Formula documentului

Mainnet Launch Window = frozen artifacts + final checks + go/hold checkpoint + explicit bootstrap authorization + live checkpointed observation + restricted posture + explicit normalization

43. Relația cu restul suitei

AZ-026 definește ceremonia formală care duce la autorizare.
AZ-028 definește execuția exactă a acelei autorizări în fereastra reală de start și în primele faze live.

Pe scurt: AZ-026 decide dacă ai voie să pornești; AZ-028 spune cum pornești fără să pierzi controlul în ultimii metri.

44. Ce urmează

După AZ-028, pașii cu valoare maximă nu mai sunt doar documente noi, ci cristalizarea întregii suite în artefacte operative:

AZ-029 — Concrete Operator Checklists
AZ-030 — Launch Decision Ledger
AZ-031 — Early Mainnet Monitoring Profiles
AZ-032 — Post-Launch Stabilization Review Protocol
AZ-033 — Mainnet Artifact Archive and Audit Package

Închidere

Cele mai multe lansări nu eșuează din lipsă de idei bune. Eșuează în ultimii metri: când lumea presupune, când hold-ul nu e clar, când artefactele se schimbă, când primele anomalii sunt ignorate, când nimeni nu poate spune exact cine a autorizat ce și pe ce bază.

Acolo este valoarea reală a unei proceduri de launch window: transformă ultimii metri dintr-un spațiu de improvizație într-un spațiu de control verificabil.