AZ-017 — Mainnet Readiness Checklist v1

Status

Acest document definește checklist-ul de readiness pentru lansarea mainnet ATLAS ZERO.

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

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

AZ-017 răspunde la întrebarea: când putem spune onest că protocolul este pregătit pentru mainnet și care sunt condițiile minime fără de care lansarea ar fi imprudentă?

Scopul lui este să fixeze:

• criteriile obligatorii de go/no-go;
• evidențele necesare înainte de lansare;
• pragurile minime de audit, testare și conformitate;
• condițiile economice și operaționale;
• condițiile pentru genesis, rollout și primele epoci;
• criteriile de rollback sau amânare înainte de start.

Acest document se bazează pe:

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

Termeni:

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

1. Obiectiv

AZ-017 răspunde la 10 întrebări finale de lansare:

1. Ce înseamnă „mainnet ready”?
2. Ce defecte blochează lansarea?
3. Ce documente și dovezi trebuie să existe?
4. Ce audituri și teste sunt obligatorii?
5. Ce condiții economice și de securitate trebuie îndeplinite?
6. Ce condiții de operare și recovery sunt obligatorii?
7. Ce condiții de guvernanță și genesis trebuie să fie închise?
8. Cine decide go/no-go și pe baza căror artefacte?
9. Ce risc rezidual este acceptabil?
10. Cum evităm lansarea prematură din presiune socială sau de calendar?

2. Principii

2.1 Mainnet readiness is evidence, not confidence

Readiness MUST fi bazată pe:

• artefacte,
• teste,
• audituri,
• replay-uri,
• drill-uri,
• checklist-uri complete, nu pe optimism sau reputație.

2.2 No known criticals

Mainnet MUST NOT fi lansat cu vulnerabilități critice cunoscute și neînchise.

2.3 Determinism before performance

Sistemul MUST demonstra:

• corectitudine,
• conformitate,
• deterministic replay, înainte de optimizare agresivă.

2.4 Blast radius must be bounded at launch

Prima fază de mainnet SHOULD porni cu:

• parametri conservatori,
• feature scope limitat,
• caps stricte,
• safe mode și halt testate.

2.5 Residual risk must be named

Riscul rezidual acceptat MUST fi:

• explicit,
• documentat,
• clasificat,
• înțeles de cei care dau go.

2.6 No hidden launch exceptions

Nu trebuie să existe:

• config secretă,
• bootstrap power nedeclarată,
• bypass operațional nepublicat,
• patch local neanunțat care schimbă adevărul protocolului.

3. Readiness state model

3.1 Standard statuses

Fiecare domeniu SHOULD avea una dintre stările:

• NOT_STARTED
• IN_PROGRESS
• BLOCKED
• READY_WITH_NOTES
• READY
• GO_SIGNED
• NO_GO

3.2 Overall launch statuses

Lansarea generală SHOULD folosi:

• PREPARING
• READINESS_REVIEW
• GO_PENDING
• GO_APPROVED
• LAUNCH_WINDOW_ACTIVE
• DEFERRED
• ABORTED_PRE_LAUNCH
• POST_LAUNCH_MONITORING

4. Go / no-go philosophy

4.1 Go

GO înseamnă:

• toate criteriile MUST sunt îndeplinite;
• toate excepțiile deschise sunt documentate și sub pragul acceptat;
• artefactele de lansare sunt înghețate;
• echipele și rolurile critice sunt pregătite;
• nu există blocker critic nerezolvat.

4.2 No-go

NO_GO înseamnă că unul sau mai multe dintre următoarele este adevărat:

• există bug critic deschis;
• există divergență deterministică nerezolvată;
• există audit sever nerezolvat;
• drill-uri critice nu au fost trecute;
• genesis/release artifacts nu sunt finalizate;
• governance bootstrap este ambiguă;
• ops/recovery nu este practic funcțional.

4.3 Rule

Orice NO_GO onest MUST avea prioritate asupra presiunii de calendar.

5. Main categories of readiness

Readiness MUST fi evaluată pe cel puțin aceste categorii:

1. Specification completeness
2. Conformance and determinism
3. Consensus and finality
4. BVM and execution safety
5. Witness/proof correctness
6. Economic soundness
7. Agent control safety
8. Governance and emergency readiness
9. Genesis and release artifacts
10. Operational readiness
11. Security assurance
12. Ecosystem/tooling readiness

6. Specification completeness gate

6.1 Mandatory document set

Înainte de mainnet, SHOULD exista în stare READY sau echivalent:

• AZ-002
• AZ-003
• AZ-004
• AZ-005
• AZ-006
• AZ-007
• AZ-008
• AZ-009
• AZ-010
• AZ-011
• AZ-012
• AZ-013
• AZ-014
• AZ-015
• AZ-016
• AZ-017

6.2 Rule

Mainnet SHOULD NOT lansa dacă un subsistem consensus-critical este încă descris vag sau contradictoriu.

6.3 Required closure

Trebuie să existe un proces care marchează:

• sections unresolved,
• known ambiguities,
• deferred items,
• explicit non-launch features.

7. Conformance and determinism gate

7.1 Mandatory evidence

Înainte de mainnet MUST exista:

• AZ-011 conformance suite rulată complet pe implementarea de referință;
• rezultate consistente pe cel puțin o implementare independentă acolo unde este fezabil;
• zero divergențe nerezolvate în vectorii consensus-critical;
• deterministic replay pentru cazurile principale.

7.2 Required categories

MUST pass:

• encoding
• hashing
• policy evaluation
• tx validation
• state transitions
• consensus/notarization
• BVM execution
• witness/proof lifecycle
• economics core
• governance activation
• genesis derivation

7.3 Rule

Orice mismatch între două implementări pe comportament consensus-critical este launch blocker până la clarificare.

8. Consensus and finality gate

8.1 Mandatory criteria

Înainte de mainnet MUST exista:

• simulări și teste pentru committee derivation;
• front scoring/tie-break determinism demonstrat;
• notarization threshold logic testată end-to-end;
• no-finality path testat;
• fraud proof pentru double-signing testat;
• slashing pentru fault-uri critice de consens testat pe mediu de pre-lansare.

8.2 Required incident coverage

Trebuie să existe exerciții trecute pentru:

• proposer equivocation
• verifier contradictory votes
• notary double notarization
• partition/no-finality
• invalid notarization rejection

8.3 Rule

Orice incertitudine nerezolvată privind finalitatea sau front selection este blocker absolut.

9. BVM and execution gate

9.1 Mandatory criteria

Înainte de mainnet MUST exista:

• bytecode verifier complet;
• interpreter semantic de referință;
• cost model implementat și testat;
• bounds enforcement testat;
• effect digest conformance;
• deterministic execution across environments relevante.

9.2 Mandatory negative cases

Trebuie testate și respinse corect:

• invalid opcode
• jump invalid
• recursion/unbounded loop
• memory out-of-bounds
• permission surface mismatch
• effect bound exceeded
• loss envelope exceeded

9.3 Rule

Orice bypass cunoscut al boundedness sau permission surface este blocker critic.

10. Witness / proof gate

10.1 Mandatory criteria

Înainte de mainnet MUST exista:

• registry inițial de statement types și proof types finalizat;
• proof verifiers pentru tipurile active auditate și testate;
• revocation și supersession logic testate;
• contradiction handling testat;
• replay protection cross-context testată.

10.2 High-risk families

Tipurile folosite în:

• settlement,
• halt,
• treasury,
• oracle,
• agent control, MUST avea coverage suplimentar și review suplimentar.

10.3 Rule

Witness semantics ambigue sau proof verifiers insuficient specificate sunt launch blockers pentru domeniile afectate.

11. Economic readiness gate

11.1 Mandatory criteria

Înainte de mainnet MUST exista:

• fee schedule implementată și simulată;
• rent model implementat;
• bond/slash schedules implementate;
• no-finality economic handling testată;
• reward distribution testată;
• reserve split și burn logic testate.

11.2 Required simulations

Trebuie simulate:

• tx spam
• witness spam
• intent spam
• rent abuse / state bloat pressure
• low-bond issuer abuse
• fee congestion conditions
• slash application and reward to reporter

11.3 Rule

Dacă sistemul economic poate fi evident abuzat ieftin sau dacă slash-ul nu este executabil robust, mainnet MUST be deferred.

12. Agent control gate

12.1 If agent layer is active at launch

Înainte de mainnet MUST exista:

• mandate object lifecycle testat;
• risk caps enforceable;
• journaling required paths testate;
• halt/revoke/rotate flows testate;
• exit-only mode testat;
• aggregate portfolio cap model testat, dacă feature-ul este activ.

12.2 If not fully ready

Agent layer SHOULD be disabled or restricted by feature flags la lansare.

12.3 Rule

Nu se lansează agent execution high-impact doar pentru că există în specificație. Trebuie să fie dovedit operațional și sigur.

13. Governance and emergency gate

13.1 Mandatory criteria

Înainte de mainnet MUST exista:

• governance parameter registry finală;
• quorum profiles finale;
• review requirements active;
• timelock enforcement testată;
• challenge path testată;
• emergency action path testată;
• emergency expiry testată;
• constitutional inadmissibility gate testată.

13.2 Bootstrap governance

Dacă există bootstrap powers speciale, acestea MUST fi:

• explicite în genesis;
• limitate;
• auditate;
• înțelese de semnatarii go/no-go.

13.3 Rule

Governance ambiguă sau emergency powers prea largi sunt launch blockers constituționali.

14. Genesis and release artifact gate

14.1 Mandatory artifacts

Înainte de mainnet MUST exista:

• canonical genesis file final;
• genesis hash final;
• chain_id final;
• derived roots commitment final;
• validator bootstrap set final;
• initial parameter summary;
• release binary hashes;
• reproducible build outputs;
• signed release manifest.

14.2 Mandatory checks

Trebuie confirmate:

• genesis root recomputation by multiple nodes;
• supply reconciliation;
• validator stake reconciliation;
• feature flag correctness;
• policy/registy inclusion correctness;
• chain identity handshake checks.

14.3 Rule

Dacă genesis artefactele nu sunt înghețate și reverificate, lansarea MUST NOT începe.

15. Operational readiness gate

15.1 Mandatory criteria

Înainte de mainnet MUST exista:

• on-call rotație;
• incident commander list;
• runbooks AZ-015 mapped la persoane și tool-uri;
• monitoring și alerting active;
• snapshot and restore tested;
• replay from finalized checkpoint tested;
• safe mode / halt procedures rehearsed;
• key rotation procedures rehearsed.

15.2 Required environments

Operațiunile SHOULD fi trecute prin:

• internal staging
• public testnet or equivalent adversarial environment
• launch dress rehearsal

15.3 Rule

Fără ops readiness reală, protocoalele bune devin sisteme fragile.

16. Security assurance gate

16.1 Mandatory minimum

Înainte de mainnet MUST exista:

• audit extern pentru consens/core validation;
• audit extern pentru BVM/verifier/runtime;
• audit sau review expert pentru witness/proof families critice;
• review al governance/emergency path;
• internal security review pentru integrare și toolchain.

16.2 Vulnerability posture

La momentul GO:

• zero known critical open issues;
• zero known deterministic divergence issues;
• zero known authorization bypass open;
• zero known slashing-proof logic break open;
• zero known genesis ambiguity open.

16.3 High severity issues

Issue-uri high pot exista doar dacă:

• sunt clar documentate;
• au scope limitat;
• au mitigation activă;
• sunt explicit acceptate de GO signers;
• nu ating finalitatea, fundurile sau boundedness-ul critic.

17. Bug bounty and disclosure gate

17.1 Before mainnet

SHOULD exist:

• bug bounty program or controlled disclosure channel;
• security contact path;
• triage owner;
• severity rubric;
• ability to distribute advisories quickly.

17.2 Rule

Mainnet fără canal serios de vulnerability intake este un risc operațional inutil.

18. Toolchain and release engineering gate

18.1 Mandatory criteria

Înainte de mainnet MUST exista:

• reproducible builds sau echivalent puternic;
• signed release artifacts;
• dependency review;
• locked compiler/runtime versions;
• binary provenance documentation;
• rollbackable release process pre-launch.

18.2 Cross-checks

SHOULD include:

• independent rebuild verification;
• hash comparison;
• test vectors run on release artifacts.

18.3 Rule

Binary provenance neclară este launch blocker pentru noduri cu roluri critice.

19. Telemetry and observability gate

19.1 Mandatory criteria

Înainte de mainnet MUST exista:

• metrics for finality health
• metrics for invalid object rates
• metrics for BVM failures
• metrics for witness contradiction / proof failures
• metrics for governance activation events
• metrics for safe mode / halt states
• logs with correlation ids or equivalent structure

19.2 Rule

Fără observabilitate suficientă, primele incidente vor fi mai lente și mai confuze decât trebuie.

20. Rollout strategy gate

20.1 Launch SHOULD have explicit phases

• release freeze
• genesis finalization
• validator readiness confirmation
• binary distribution final
• dress rehearsal sign-off
• launch window open
• epoch 0 monitoring
• early epoch restricted posture
• staged feature confidence expansion

20.2 Conservative launch mode

V1 SHOULD launch with:

• conservative economic parameters
• conservative committee sizes if needed
• high-sensitivity telemetry
• limited experimental features
• high-impact agent features disabled or scoped if not fully proven

20.3 Rule

Ambitious parameter tuning SHOULD happen after stable operation, not at genesis for prestige.

21. Dress rehearsal requirement

21.1 At least one full dress rehearsal SHOULD exist

It SHOULD include:

• genesis load
• node startup
• validator role activation
• first epochs finalization
• emergency drill
• key rotation drill
• snapshot restore drill
• controlled shutdown and restart

21.2 Rule

Mainnet SHOULD NOT be first time all launch-critical procedures are executed together.

22. First-epoch readiness

22.1 Mandatory questions before go

• Are initial committees derivable and verified?
• Are initial keys loaded and confirmed?
• Are release artifacts identical across signers?
• Is genesis hash confirmed by all launch validators?
• Are monitoring dashboards live?
• Are incident channels staffed?
• Is safe mode / halt command path reachable and tested?
• Are governance bootstrap states understood and documented?

22.2 Rule

If any of these are unresolved in launch window, GO SHOULD revert to DEFERRED.

23. Early-mainnet restricted posture

23.1 Recommended initial period

For first epochs/days/weeks depending on design, protocol operations SHOULD adopt:

• heightened monitoring
• stricter operational thresholds
• conservative restart rules
• aggressive anomaly review
• limited config drift tolerance
• delayed enablement of optional high-risk features

23.2 Rule

Early mainnet is not “business as usual.” It is controlled proving ground under real conditions.

24. Launch blockers — absolute

The following SHOULD be treated as absolute blockers:

1. unresolved critical consensus bug
2. unresolved deterministic divergence
3. unresolved authorization bypass
4. unresolved BVM boundedness bypass
5. unresolved genesis mismatch or ambiguity
6. inability to produce reproducible or verified release artifacts
7. untested or broken emergency halt/recovery path
8. broken slashing evidence path for critical consensus faults
9. governance activation ambiguity
10. inability to replay finalized state deterministically

25. Launch blockers — conditional but strong

These MAY block launch unless tightly mitigated:

1. unresolved high severity issue in non-critical subsystem
2. insufficient performance headroom under expected launch load
3. incomplete operator staffing for launch window
4. weak observability in non-critical paths
5. partial agent layer readiness if agent layer intended for launch
6. incomplete documentation for key operational tasks

If mitigations are weak or uncertain, they become blockers.

26. Residual risk acceptance record

26.1 Need

Some risk will remain. It must be explicit.

26.2 Structure

Before GO, there SHOULD exist a ResidualRiskRegister listing:

• issue_id
• severity
• affected scope
• why not blocker
• mitigation active
• monitoring signal
• owner
• reevaluation deadline

26.3 Rule

Residual risks MUST be finite, named and assigned. “General uncertainty” is not a valid line item.

27. Go sign-off model

27.1 Recommended sign-off roles

• protocol lead
• consensus lead
• security lead
• BVM/execution lead
• ops lead
• governance lead
• release engineering lead
• incident commander or launch commander
• optional independent reviewer / auditor acknowledgment

27.2 Rule

A GO record SHOULD capture:

• signer
• scope of sign-off
• time
• blockers acknowledged absent/resolved
• residual risks accepted

27.3 Caution

Sign-off is not mere ceremony. It creates explicit accountability.

28. Mainnet readiness record

28.1 Abstract structure

MainnetReadinessRecord {
  readiness_record_id
  target_genesis_hash
  target_release_hashes
  readiness_status_by_category_hash
  residual_risk_register_hash
  required_audit_hashes
  required_drill_hashes
  go_signatures_hash
  launch_window_hash
}

28.2 Rule

This record SHOULD be generated and frozen before launch window opens.

29. No-go triggers during launch window

29.1 Even after tentative GO, switch to NO_GO if:

• release artifact mismatch discovered
• genesis mismatch discovered
• new critical vulnerability reported and confirmed
• validator committee not ready
• monitoring/control plane unavailable
• drill assumption proven false
• emergency communication path broken
• key compromise detected in critical launch role

29.2 Rule

Launch window is not sacred. Abort is allowed and preferable to unsafe launch.

30. Abort before launch procedure

30.1 If NO_GO triggered pre-launch

SHOULD:

1. freeze release status
2. preserve incident/readiness evidence
3. notify validators/operators
4. mark launch as deferred/aborted
5. identify next decision gate
6. avoid ad-hoc hotfix launch same day unless process explicitly supports it and evidence is strong

30.2 Rule

Unsafe urgency is worse than delay.

31. Post-launch monitoring gate

31.1 Launch is not done at epoch 0

There MUST be a post-launch monitoring phase.

31.2 Required monitoring

SHOULD track:

• epoch finalization regularity
• invalid block/object rates
• resource usage
• witness/proof failure anomalies
• slashing/fraud proof pipeline health
• governance event anomalies
• safe mode/halt incidents
• operator availability

31.3 Rule

Early mainnet anomalies MUST have lower threshold for escalation than mature network anomalies.

32. Feature enablement after launch

32.1 Principle

Not every planned feature must be active on day one.

32.2 Rule

Features SHOULD be enabled post-launch only if:

• launch baseline stable,
• prerequisite audits complete,
• conformance vectors updated,
• ops runbooks ready,
• governance path valid if activation is protocol-level.

32.3 Recommendation

High-risk optional domains SHOULD be phased in after baseline health proven.

33. Minimum documentation package

33.1 Before mainnet SHOULD exist:

• protocol spec set
• release notes
• genesis manifest
• validator/operator guide
• incident and recovery guide
• governance bootstrap guide
• security disclosure policy
• known limitations/residual risk note

33.2 Rule

If operators do not have correct docs, operations will invent local protocol interpretations. That is unacceptable.

34. Mainnet readiness scorecard

34.1 Suggested categories for internal scoring

Each category may be scored:

• red
• amber
• green or numeric internally

Categories:

• spec closure
• conformance
• consensus
• BVM
• witness/proof
• economics
• agents
• governance
• genesis/release
• ops
• security
• monitoring

34.2 Rule

Visual scorecards are advisory. The MUST criteria remain normative.

35. Sample go/no-go questions

Before signing GO, each responsible lead SHOULD answer:

1. Can I name the top residual risks from memory?
2. Do we know our last trusted finalized checkpoint process?
3. Have we tested the exact release artifact being launched?
4. Could we rotate a compromised launch key today?
5. Can we freeze a dangerous domain without inventing new rules?
6. Are genesis and chain_id independently recomputed by multiple parties?
7. Do we have zero known critical consensus/BVM/auth bugs?
8. Are logs, metrics and alerts live right now?
9. Have we rehearsed incident response with the people actually on call?
10. Would I still say GO if launch had no marketing deadline?

If any answer is “no” on a MUST-critical question, launch should be deferred.

36. Anti-patterns

Teams SHOULD avoid:

1. launching to “find the real bugs later”
2. treating public testnet as optional
3. waiving audit findings because code changed “only a little”
4. enabling too many optional features at genesis
5. using different binaries across validators without exact provenance
6. accepting unresolved deterministic ambiguity because “unlikely”
7. trusting dashboards without replay capability
8. signing GO without reading residual risks
9. mixing bootstrap emergency powers with permanent governance silently
10. declaring success at launch time without early-mainnet restricted posture

37. Formal goals

AZ-017 urmărește aceste obiective:

37.1 Launch discipline

Mainnet launch happens only when evidence exceeds uncertainty by a sufficient margin.

37.2 Bounded residual risk

Risks remaining at launch are known, finite and mitigated.

37.3 Operational survivability

The system can handle early incidents without improvising the protocol.

37.4 Honest no-go capability

The project can delay launch when conditions are not met, without semantic self-deception.

38. Checklist summary — MUST before GO

Before mainnet GO, the following MUST all be true:

1. canonical genesis file, hash and derived roots finalized
2. release artifacts frozen, verified and reproducible/verified enough
3. zero known critical consensus/validation/BVM/auth bugs open
4. conformance suite passes for all consensus-critical domains
5. consensus/finality drills passed
6. BVM boundedness and verifier checks passed
7. witness/proof critical flows tested and reviewed
8. economics/spam/slash flows tested
9. governance activation and emergency path tested
10. incident runbooks and drills completed
11. key rotation and recovery paths tested
12. monitoring and alerting live
13. launch operators staffed and ready
14. residual risk register published internally
15. explicit GO sign-off recorded

If any item is false, mainnet GO MUST NOT be issued.

39. Formula documentului

Mainnet Readiness = frozen genesis + verified releases + passing conformance + no criticals + tested recovery + conservative launch posture + explicit accountable GO

40. Relația cu restul suitei

• AZ-016 fixează originea rețelei.
• AZ-017 fixează condițiile sub care acea rețea poate fi lansată responsabil.

Pe scurt: dacă AZ-016 spune de unde începe rețeaua, AZ-017 spune când avem dreptul să o pornim.

41. What comes after AZ-017

După AZ-017, suitea minimă de specificație pentru v1 este suficient de completă încât următorii pași nu mai sunt doar documente noi, ci artefacte de execuție:

1. genesis concrete package
2. reference implementation milestone plan
3. conformance corpus concret
4. audit queue and issue tracker
5. launch rehearsal package
6. operator manuals and automation

Închidere

Un mainnet nu este pregătit când echipa vrea să lanseze. Este pregătit când poate demonstra, în scris și prin artefacte verificabile, că a redus suficient riscul, a exersat suficient failure-ul și a închis suficiente necunoscute încât lansarea să fie un act de disciplină, nu de speranță.

Acolo începe lansarea responsabilă reală.