AZ-009 — Governance Constitution, Constitutional Parameters, and Emergency Powers v1

Status

Acest document definește constituția de guvernanță a ATLAS ZERO.

Scopul lui nu este să creeze „guvernanță totală”. Scopul lui este să limiteze și să structureze guvernanța astfel încât protocolul să poată evolua fără a-și distruge:

• predictibilitatea,
• finalitatea,
• disciplina economică,
• boundedness-ul execuției,
• și separarea dintre autoritate și arbitrar.

Acest document stabilește:

• ce poate schimba guvernanța;
• ce NU poate schimba ușor;
• cum sunt clasificate parametrii protocolului;
• cum sunt aprobate upgrade-urile;
• cum funcționează emergency powers;
• cum se păstrează audit trail și delay înainte de activare.

Acest document se bazează pe:

• AZ-002 pentru obiecte canonice;
• AZ-003 pentru reguli de validare și stare;
• AZ-004 pentru consens și finalitate;
• AZ-005 pentru bounded VM;
• AZ-006 pentru witness/proof/attestation;
• AZ-007 pentru economie;
• AZ-008 pentru modelul agenților.

Termeni:

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

1. Obiectiv

AZ-009 răspunde la 10 întrebări constituționale:

1. Ce înseamnă guvernanță în ATLAS ZERO?
2. Ce parametri sunt normali și ce parametri sunt constituționali?
3. Cine poate propune și aproba schimbări?
4. Cum devine o schimbare activă?
5. Cum se evită upgrade-ul arbitrar sau surpriză?
6. Cum sunt tratate emergency powers?
7. Ce protecții există pentru finalitate, boundedness și economie?
8. Cum se auditează traseul decizional?
9. Cum se suspendă sau anulează o propunere?
10. Cum rămâne protocolul upgradabil fără a deveni maleabil politic?

2. Principii constituționale

2.1 Limited governance

Guvernanța MUST fi limitată de constituție. Nu orice lucru care este posibil tehnic trebuie să fie modificabil politic.

2.2 Predictability over discretion

Protocolul SHOULD favoriza reguli previzibile și activări cu întârziere, nu intervenție discretionary instantanee.

2.3 Finality preservation

Guvernanța MUST NOT invalida finalitatea deja acordată prin consensul normal, exceptând un mecanism excepțional explicit și mult mai greu decât guvernanța obișnuită.

2.4 Bounded change

Schimbările SHOULD fi clasificate, scoped și versionate. Nu trebuie să existe „pachet opac care schimbă tot”.

2.5 Auditability

Orice schimbare de protocol MUST avea traseu verificabil:

• propunere,
• analiză,
• aprobare,
• timelock,
• activare,
• efect.

2.6 Emergency powers are real but bounded

Puterea de urgență MAY exista, dar MUST fi:

• îngustă în scope,
• limitată temporal,
• jurnalizată,
• revizibilă,
• incapabilă să devină guvernanță permanentă prin bypass.

2.7 Constitutional hierarchy

Parametrii protocolului SHOULD fi împărțiți pe niveluri:

• operaționali,
• de risc,
• economici,
• structurali,
• constituționali.

3. Ce este guvernanța

3.1 Definiție

Guvernanța este procesul protocolar prin care o comunitate, un set de stake-holders sau un mecanism constituțional aprobat poate modifica anumite părți ale sistemului.

3.2 Nu este

Guvernanța MUST NOT fi:

• un backdoor pentru a suprascrie execuția normală;
• o metodă de a rescrie arbitrar istoria finalizată;
• o justificare pentru parametri opaci;
• o „super-cheie” nelimitată.

3.3 Poate fi

Guvernanța MAY:

• ajusta parametri;
• aproba upgrade-uri versionate;
• activa/dezactiva anumite funcționalități permise de constituție;
• aproba recovery actions strict definite;
• aloca treasury în limitele stabilite.

4. Constitutional layers

4.1 Layer 0 — Immutable or near-immutable principles

Acestea SHOULD fi aproape imposibil de schimbat și, în v1, tratate ca fundament constituțional:

• necesitatea finalității notarizate pentru hard-finality;
• separarea dintre Value Layer, Logic Layer și Witness Layer;
• determinismul execuției;
• boundedness-ul BVM;
• slashing pentru double-signing critic;
• existența costului pentru stare persistentă;
• existența bond-urilor/slashing pentru roluri critice;
• imposibilitatea finalității „prin opinie” fără reexecutabilitate.

4.2 Layer 1 — Structural protocol parameters

Acestea afectează profund sistemul și SHOULD necesita guvernanță grea:

• threshold-uri de finalitate;
• mărimea și regula comitetelor;
• opcode families admise;
• capability tiers majore;
• clase de statement/proof normative;
• reguli de upgrade.

4.3 Layer 2 — Economic and safety parameters

Acestea MAY necesita guvernanță puternică, dar nu constituțional maximă:

• fee schedule;
• rent rates;
• reward shares;
• bond minima;
• slash multipliers;
• congestion parameters;
• recovery reserve shares.

4.4 Layer 3 — Operational parameters

Acestea pot fi ajustabile mai frecvent:

• cache windows;
• indexing preferences non-consensus;
• soft admission thresholds;
• advisory scoring weights fără efect constituțional direct.

5. Parameter classes

5.1 Classification

Fiecare parametru protocolar MUST aparține exact unei clase:

• CLASS_OPS
• CLASS_ECONOMIC
• CLASS_RISK
• CLASS_STRUCTURAL
• CLASS_CONSTITUTIONAL

5.2 Rule

Clasa unui parametru determină:

• quorum-ul necesar;
• tipul de propunere;
• timelock-ul;
• cerința de analiză;
• dreptul sau lipsa dreptului de emergency path.

5.3 Registry

Protocolul SHOULD avea un registry canonical:

GovernanceParameterRegistry {
  parameter_id
  parameter_class
  current_value_hash
  admissible_range_hash?
  change_method
  min_delay_epochs
  required_quorum_profile
}

6. Governance actors

6.1 Possible actors

ATLAS ZERO MAY folosi unul sau o combinație dintre:

• token/stake holders
• validator set
• constitutional council
• risk council
• emergency committee
• technical review committee
• treasury committee

6.2 Role separation

Actorii care votează economic, tehnic și de urgență SHOULD fi separabili logic, chiar dacă există overlap parțial.

6.3 Minimum requirement

Pentru decizii cu impact structural sau constituțional, SHOULD exista mai mult decât un simplu vot de popularitate brută. Este recomandată o combinație de:

• stake-weighted signal
• technical admissibility
• constitutional admissibility

7. Governance objects

7.1 Core objects

Guvernanța operează cu obiecte canonice:

• GovernanceProposal
• GovernanceReview
• GovernanceVote
• GovernanceOutcome
• GovernanceActivation
• EmergencyAction
• EmergencyReview
• EmergencyExpiry

7.2 Principle

Nicio schimbare cu efect normativ MUST NOT exista fără obiect canonical verificabil.

8. GovernanceProposal

8.1 Abstract structure

GovernanceProposal {
  version_major
  version_minor

  proposal_id
  proposal_type
  proposer_policy
  target_class
  target_objects
  change_set_hash
  rationale_hash
  risk_analysis_hash?
  compatibility_analysis_hash?
  activation_profile
  review_requirements
  expiry_epoch?
  metadata_hash?
}

8.2 proposal_id

proposal_id = H("AZ:GOV_PROPOSAL:" || canonical_body)

8.3 proposal_type

Poate fi:

• PARAMETER_CHANGE
• PROTOCOL_UPGRADE
• TREASURY_ALLOCATION
• EMERGENCY_ACTION_APPROVAL
• COMMITTEE_RECONFIG
• RECOVERY_ACTION
• CONSTITUTION_AMENDMENT

8.4 Rule

Tipul propunerii MUST limita exact ce poate fi schimbat.

9. ChangeSet model

9.1 Need

Schimbarea reală nu trebuie ascunsă în text liber. Trebuie ancorată printr-un set de schimbări canonical.

9.2 Abstract structure

ChangeSet {
  changed_parameter_ids
  old_value_hashes
  new_value_hashes
  code_hash_changes?
  activation_conditions
  compatibility_flags
  rollback_profile?
}

9.3 Rule

ChangeSet-ul MUST fi:

• explicit;
• diff-like;
• bounded;
• auditable.

Un proposal MUST NOT spune doar „upgrade protocol”. Trebuie să spună exact CE.

10. Review objects

10.1 Purpose

Anumite propuneri SHOULD necesita review formal înainte de vot final.

10.2 GovernanceReview

GovernanceReview {
  review_id
  proposal_id
  reviewer_policy
  review_type
  verdict
  findings_hash
  constraints_hash?
  issued_at_epoch
}

10.3 review_type

Poate fi:

• TECHNICAL_REVIEW
• ECONOMIC_REVIEW
• SECURITY_REVIEW
• CONSTITUTIONAL_REVIEW
• EMERGENCY_REVIEW

10.4 verdict

• PASS
• PASS_WITH_CONSTRAINTS
• FAIL
• ADVISORY_ONLY

10.5 Rule

Pentru propunerile cu impact structural sau constituțional, lipsa review-urilor obligatorii MUST împiedica activarea.

11. Governance votes

11.1 GovernanceVote

GovernanceVote {
  vote_id
  proposal_id
  voter_policy
  vote_type
  weight_commitment
  justification_hash?
  epoch_index
}

11.2 vote_type

• YES
• NO
• ABSTAIN
• YES_CONSTRAINED

11.3 Weight model

Greutatea votului MAY depinde de:

• stake;
• committee role;
• constitutional chamber;
• delegate mechanism.

11.4 Rule

Modelul de greutate MUST fi determinist și cunoscut înainte de vot.

12. Multi-chamber governance

12.1 Motivation

Pentru schimbări sensibile, un singur mecanism de vot poate fi prea slab.

12.2 Recommended chambers

ATLAS ZERO SHOULD suporta conceptual mai multe camere:

• economic chamber
• validator / liveness chamber
• constitutional chamber
• technical admissibility chamber

12.3 Rule

O propunere structurală sau constituțională SHOULD putea cere aprobare în mai multe camere. Exemplu:

• stake majority + constitutional council supermajority + technical pass

13. Governance quorum profiles

13.1 Profiles

Protocolul SHOULD defini profile standard:

• QP_OPS_LIGHT
• QP_ECONOMIC_STRONG
• QP_STRUCTURAL_HEAVY
• QP_CONSTITUTIONAL_SUPER
• QP_EMERGENCY_LIMITED

13.2 Each profile defines

• quorum minimum
• approval threshold
• chamber requirements
• review requirements
• timelock minimum
• veto or challenge window

13.3 Rule

Profile-ul aplicabil MUST fi derivat automat din clasa țintei și tipul propunerii.

14. Activation profile

14.1 Need

O propunere aprobată nu trebuie să intre automat în efect instant.

14.2 ActivationProfile

ActivationProfile {
  earliest_activation_epoch
  timelock_epochs
  can_be_cancelled_before_activation
  requires_final_confirmation
  progressive_activation_stages?
}

14.3 Rule

Propunerile sensibile MUST avea timelock suficient pentru:

• audit final;
• exit/adjustment pentru participanți;
• challenge dacă apare problemă gravă.

15. GovernanceOutcome

15.1 Definition

După închiderea votului și verificarea condițiilor, protocolul produce un rezultat canonical:

GovernanceOutcome {
  outcome_id
  proposal_id
  outcome_status
  satisfied_quorum_profile
  chamber_results_hash
  review_results_hash
  activation_profile_hash?
  issued_at_epoch
}

15.2 outcome_status

• APPROVED
• REJECTED
• EXPIRED
• CHALLENGED
• SUPERSEDED
• CANCELLED

15.3 Rule

Doar APPROVED poate duce la activare.

16. GovernanceActivation

16.1 Definition

Activarea este obiectul care mută protocolul la noii parametri sau noua versiune.

GovernanceActivation {
  activation_id
  proposal_id
  outcome_id
  effective_epoch
  applied_change_set_hash
  activation_witness_hashes?
}

16.2 Rule

O schimbare nu este activă până nu există activare validă și punctul temporal efectiv este atins.

16.3 Compatibility

Implementările SHOULD putea pregăti schimbarea înainte de effective_epoch, dar MUST NOT o aplice anticipat.

17. Constitutional admissibility

17.1 Principle

Nu orice propunere validă procedural este și admisibilă constituțional.

17.2 Constitutional guard

Protocolul SHOULD avea o funcție logică sau un review chamber care verifică dacă propunerea:

• nu violează principiile Layer 0;
• nu introduce finalitate fără reexecutabilitate;
• nu elimină boundedness-ul;
• nu abolește costul pentru stare;
• nu elimină slashing-ul pentru fault byzantin critic.

17.3 Rule

O propunere constituțional inadmisibilă MUST NOT deveni activă chiar dacă are majoritate politică obișnuită, exceptând procedura explicită de amendament constituțional.

18. Constitutional amendment

18.1 Need

Unele principii fundamentale pot avea nevoie de schimbare rară.

18.2 Requirements

Un CONSTITUTION_AMENDMENT SHOULD necesita:

• quorum profil maxim;
• multiple chamber approval;
• review tehnic + constituțional obligatoriu;
• timelock lung;
• explicit impact statement;
• eventual phased activation.

18.3 Rule

Amendamentele constituționale MUST fi rare, explicite și imposibil de ascuns în propuneri normale.

19. Upgrade classes

19.1 Parameter-only upgrade

Schimbă doar valori din registry. Nu schimbă bytecode rules sau object schemas majore.

19.2 Protocol rules upgrade

Schimbă reguli de validare, consens, BVM sau semantics.

19.3 Object schema upgrade

Schimbă structuri canonice, ABI, statement registries etc.

19.4 Emergency restriction upgrade

Activează temporar mod mai restrictiv. Nu SHOULD extinde puteri, ci doar reduce sau îngustează.

19.5 Rule

Clasa upgrade-ului MUST fie declarată explicit și determină procedura de aprobare.

20. Upgrade compatibility requirements

20.1 Every non-trivial upgrade SHOULD define:

• backward compatibility status
• migration requirements
• replay compatibility impact
• storage migration needs
• light client impact
• risk to agent mandates
• risk to witness semantics
• economic impact

20.2 Rule

O propunere structurală fără analiză de compatibilitate SHOULD fi inadmisibilă.

21. Timelocks

21.1 Principle

Timelock-ul este o protecție constituțională, nu o formalitate.

21.2 Recommended minimums

• ops change: scurt
• economic/risk change: mediu
• structural change: mare
• constitutional amendment: foarte mare

21.3 Rule

Emergency path MAY scurta timelock-ul doar pentru acțiuni limitative și temporare, nu pentru schimbări expansive permanente.

22. Challenge windows

22.1 Need

Între aprobare și activare, unele schimbări trebuie contestabile.

22.2 Challenge grounds

• constitutional violation
• hidden incompatibility
• demonstrable implementation unsafety
• invalid quorum/review path
• change-set mismatch

22.3 Rule

Dacă challenge-ul valid reușește, activarea MUST fi suspendată sau anulată conform procedurii.

23. Proposal cancellation and supersession

23.1 Cancellation

O propunere poate fi anulată înainte de activare dacă:

• proposer-ul o retrage și clasa permite;
• review critic FAIL și profilul o impune;
• challenge valid o blochează;
• este supersedată de o propunere nouă compatibilă.

23.2 Supersession

Supersession MUST referi explicit proposal-ul vechi și să spună ce înlocuiește.

23.3 Rule

Propunerile active sau aprobate MUST NOT lăsa ambiguitate despre care schimbare intră în vigoare.

24. Emergency powers

24.1 Motivation

Sistemele reale pot întâlni:

• exploit activ,
• failure de consens,
• bug critic de validare,
• oracle corruption masivă,
• incident economic sistemic,
• compromitere de comitet.

24.2 Principle

Emergency powers SHOULD permite doar acțiuni defensive și temporare, nu redesign politic instant.

24.3 Allowed emergency action classes

Set minim recomandat:

• halt subset of functionality
• raise safety thresholds
• disable risky feature flags
• force safe mode / exit-only for certain domains
• freeze certain issuers or committees pending review
• shorten active set to known-safe subset if constitution allows
• activate recovery mode already defined

24.4 Disallowed by default

Emergency powers MUST NOT, în mod implicit:

• rescrie finalitatea trecută;
• transfera arbitrar fonduri;
• elimina slashing pentru propriul comitet;
• activa noi puteri expansive permanente;
• schimba constituția.

25. EmergencyAction object

25.1 Abstract structure

EmergencyAction {
  emergency_action_id
  proposer_policy
  emergency_class
  target_scope
  restriction_set_hash
  justification_hash
  required_evidence_hashes
  effective_from_epoch
  expires_at_epoch
  review_profile
}

25.2 emergency_class

Poate fi:

• SAFE_MODE_ACTIVATION
• FEATURE_FREEZE
• COMMITTEE_QUARANTINE
• ISSUER_QUARANTINE
• RISK_THRESHOLD_RAISE
• RECOVERY_MODE_ENTER
• TEMPORARY_HALT_DOMAIN

25.3 Rule

Orice emergency action MUST avea:

• scope precis;
• justificare;
• durată finită;
• review path;
• expirare automată sau re-approval.

26. Emergency committee

26.1 Need

Pentru unele acțiuni defensive rapide, un comitet mic poate fi necesar.

26.2 Constraints

Emergency committee SHOULD fi:

• separat de guvernanța de zi cu zi;
• bond-uit sau responsabil;
• limitat în puteri;
• auditabil;
• supus review ex post.

26.3 Rule

Emergency committee MUST NOT avea puteri constituționale generale.

27. Emergency activation and expiry

27.1 Activation

Emergency actions MAY avea activare mai rapidă decât propunerile normale dacă:

• clasa permite;
• justificarea și dovezile există;
• quorum-ul de urgență e atins;
• scope-ul este limitativ și temporar.

27.2 Expiry

O emergency action MUST expira automat la termen dacă nu este:

• reaprobată prin canal normal relevant;
• înlocuită de recovery plan valid;
• sau revocată explicit.

27.3 Rule

Puterile de urgență MUST NOT deveni permanente prin simpla neglijență procedurală.

28. Emergency review

28.1 Requirement

Orice emergency action SHOULD primi review post-activare:

• technical review
• constitutional review
• economic/risk review dacă relevant

28.2 Outcomes

Review-ul poate recomanda:

• confirmare limitată;
• scurtare;
• extindere prin canal normal;
• anulare;
• escalare către amendment sau upgrade.

29. Recovery actions vs emergency actions

29.1 Distinction

Emergency action = restricție defensivă temporară. Recovery action = pași structurați pentru restabilirea funcționării normale.

29.2 Rule

Recovery actions cu efect structural SHOULD trece prin canal guvernat normal sau canal greu de recovery deja prevăzut. Nu trebuie mascate ca emergency quick-fix dacă schimbă profund protocolul.

30. Governance and finality

30.1 Core principle

Guvernanța nu decide direct ce tranzacție e validă retroactiv și nici ce stare finalizată „trebuia” să fie.

30.2 Hard rule

Stările deja hard-finalizate MUST rămâne finale în execuția normală.

30.3 Exceptional override

Dacă se definește vreodată un mecanism de excepție pentru finalitate istorică, acesta MUST fi:

• separat de guvernanța normală;
• constituțional super-greu;
• explicit;
• rar;
• justificat prin fault sistemic extrem.

V1 SHOULD evita un asemenea mecanism.

31. Governance and BVM

31.1 Principle

Guvernanța poate schimba parametri ai BVM sau seturi de opcodes doar prin upgrade structural explicit.

31.2 Rule

Guvernanța MUST NOT introduce retroactiv semantics noi pentru bytecode vechi fără versioning clar.

31.3 Compatibility

Mașinile existente SHOULD continua sub versiunea compatibilă definită sau să aibă migrare explicită.

32. Governance and Witness semantics

32.1 Principle

Statement types, proof types și semantics normative sunt sensibile.

32.2 Rule

Guvernanța MUST NOT schimba semantic retroactiv un witness deja emis într-un mod care alterează sensul său istoric fără versioning și constituency adequată.

32.3 Extension path

Tipuri noi MAY fi adăugate prin upgrade versionat. Tipuri vechi MAY fi deprecate, dar cu tranziție clară.

33. Governance and economics

33.1 Principle

Parametrii economici pot fi ajustabili, dar predictibilitatea trebuie păstrată.

33.2 Rule

Schimbările economice SHOULD avea:

• justificare metrică;
• delay suficient;
• intervale admisibile bounded;
• no surprise activation.

33.3 Anti-abuse

Guvernanța MUST NOT putea seta instant:

• fee la zero pentru bypass;
• bond la zero pentru roluri critice;
• rent la zero permanent;
• slash la zero pentru double-signing critic, decât prin amendament constituțional explicit.

34. Treasury governance

34.1 Scope

Treasury allocations MUST fi separate de protocol rule changes.

34.2 Rule

O propunere de treasury MUST defini:

• sumă;
• destinație;
• milestones dacă relevante;
• clawback/review conditions dacă relevante.

34.3 Constraint

Treasury proposal MUST NOT ascunde upgrade-uri de protocol în același change-set, decât dacă constituția definește clar pachetul mixt și procedura sa.

35. Committee governance

35.1 Committee reconfiguration

Reconfigurarea comitetelor speciale SHOULD necesita:

• motiv clar;
• review de competență și conflict;
• delay;
• effective epoch clar.

35.2 Quarantine

Guvernanța sau emergency path MAY pune un comitet/issuer în quarantine dacă există fault indicat. Aceasta SHOULD fi măsură defensivă, nu condamnare finală fără review.

36. Governance for agent controls

36.1 Principle

Protocol-level rules pentru mandat, journaling și halt pot fi ajustate doar atent.

36.2 Rule

Guvernanța MUST NOT transforma prin upgrade ușor un model bounded de agent într-un model cu autoritate nelimitată. Ar fi constituțional inadmisibil.

37. Proposal validity checks

37.1 Every proposal MUST pass:

1. canonical encoding validation
2. proposal type validation
3. target admissibility
4. parameter class compatibility
5. required reviews presence
6. review verdict compatibility
7. quorum profile derivation
8. activation profile legality
9. constitutional admissibility
10. conflict check cu propuneri deja aprobate/active

37.2 Rule

O propunere procedural incompletă MUST NOT intra în activare.

38. Proposal conflict model

38.1 Types of conflicts

• două propuneri schimbă același parametru incompatibil
• două upgrade-uri structurale au dependency order contradictoriu
• o propunere economică presupune un BVM version care nu e activ
• o emergency action restrânge exact funcția pe care o activare nouă vrea să o extindă

38.2 Rule

Protocolul SHOULD detecta conflictele și să le rezolve prin:

• reject,
• suspend,
• supersession,
• dependency ordering explicit.

39. Governance timelines

39.1 Suggested phases

1. proposal submission
2. review period
3. voting period
4. outcome issuance
5. challenge window
6. activation timelock
7. effective activation

39.2 Rule

Timeline-ul exact depinde de class/profile, dar pașii logici SHOULD rămâne aceiași.

40. Governance witnesses and audit trail

40.1 Witness usage

Guvernanța SHOULD folosi witnessuri și obiecte canonicale pentru:

• proposal submission attestation
• review attestations
• vote inclusion
• outcome confirmation
• activation confirmation
• emergency justification
• challenge success/failure

40.2 Goal

Un auditor SHOULD putea reconstrui de ce o schimbare a avut loc.

41. Delegation in governance

41.1 Need

Votul sau review-ul pot fi delegate.

41.2 Rule

Delegarea în guvernanță MUST fi:

• bounded;
• revocabilă;
• jurnalizată;
• clară ca scope.

41.3 Constraint

Delegarea pentru chamber constituțional sau emergency powers SHOULD fi mai strictă decât delegarea economică obișnuită.

42. Veto and brake mechanisms

42.1 Need

Unele sisteme pot beneficia de frâne instituționale.

42.2 Types

• constitutional veto
• emergency temporary brake
• technical inadmissibility veto
• delay extension trigger

42.3 Rule

Un veto MUST:

• avea bază normativă;
• fi jurnalizat;
• fi contestabil sau reviewable unde constituția o cere;
• nu fie pur arbitrar.

43. Implementation requirements

43.1 Nodes MUST know:

• active parameter registry
• active governance proposals relevant to consensus state
• effective epochs for approved changes
• emergency restrictions active
• chamber/quorum rules

43.2 Consensus safety

Toate regulile care influențează validarea MUST avea activare deterministă și versionată.

44. Formal goals

Constituția urmărește patru obiective:

44.1 Bounded governability

Protocolul este upgradabil, dar nu nelimitat remodelabil politic.

44.2 Constitutional safety

Principiile fundamentale nu pot fi abolite prin majoritate banală sau emergency shortcut.

44.3 Transparent evolution

Orice schimbare relevantă are traseu explicit, analiză și activare întârziată.

44.4 Emergency restraint

Puterile de urgență reduc risc imediat fără a deveni mecanism permanent de control arbitrar.

45. Anti-patterns de evitat

Protocolul SHOULD evita:

1. proposal care conține text vag și change-set opac
2. emergency powers care pot muta fonduri arbitrar
3. schimbări structurale fără technical review
4. activare instant a schimbărilor economice severe
5. redefinire retroactivă a finalității
6. bypass la boundedness prin „upgrade urgent”
7. comitet de urgență cu putere nelimitată și fără expirare
8. treasury vote care maschează upgrade de protocol
9. constitutional amendment ascuns în parameter change
10. review consultativ obligatoriu doar pe hârtie, dar fără efect normativ

46. Governance formula

Governance Constitution = classified parameters + explicit proposals + required reviews + chambered approval + timelocked activation + bounded emergency powers

47. Relația cu restul protocolului

• AZ-004 fixează finalitatea normală.
• AZ-005 fixează bounded execution.
• AZ-007 fixează disciplina economică.
• AZ-008 fixează controlul agenților.
• AZ-009 fixează cum se poate schimba toate acestea fără a le dizolva.

Pe scurt: ATLAS ZERO nu respinge guvernanța. O pune sub constituție.

48. Ce urmează

După AZ-009, documentul corect este:

AZ-010 — Security Assumptions, Threat Model, Failure Domains, and Verification Strategy

Acolo trebuie fixate:

• ipotezele de securitate;
• modelele de atac;
• failure domains;
• obiectivele de verificare;
• ce înseamnă „suficient de sigur” pentru mainnet.

Închidere

Un protocol matur nu este cel care spune doar „comunitatea decide”. Un protocol matur este cel care decide dinainte ce anume comunitatea nu are voie să distrugă ușor, chiar dacă vrea.

Acolo începe constituția reală.