AZ-007 — Economic Model, Fees, Rent, Bonds, Rewards, and Slashing v1

Status

Acest document definește modelul economic al ATLAS ZERO.

Scopul lui nu este să producă doar un token. Scopul este să fixeze economic:

• securitatea consensului;
• costul utilizării rețelei;
• costul stocării persistente;
• responsabilitatea actorilor critici;
• penalitățile pentru comportament adversarial;
• rezerva de recuperare și continuitate.

Acest document se bazează pe:

• AZ-002 pentru obiecte și structuri canonice;
• AZ-003 pentru validare și tranziții;
• AZ-004 pentru consens și finalitate;
• AZ-005 pentru execuția bounded a logicii;
• AZ-006 pentru witness, proof și atestări.

Termeni:

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

1. Obiectiv

AZ-007 răspunde la 10 întrebări economice fundamentale:

1. Ce rol are activul nativ?
2. Cum sunt plătite taxele de rețea?
3. Cum este taxată starea persistentă?
4. Ce bond-uri trebuie să depună actorii critici?
5. Cum se distribuie reward-urile?
6. Cum sunt calculate penalitățile și slashing-ul?
7. Cum se finanțează recovery și continuitatea?
8. Cum se evită spam, griefing și umflarea stării?
9. Cum se corelează costul economic cu riscul indus protocolului?
10. Cum rămâne sistemul utilizabil fără a deveni ieftin pentru atacatori?

2. Principii economice

2.1 Cost explicit

Orice consum de resurse protocolare MUST avea cost economic explicit sau rezervare economică explicită.

2.2 Persistența nu este gratuită

Orice stare persistentă MUST aibă:

• taxă recurentă;
• sau preplată cu durată definită;
• sau alt mecanism economic clar echivalent.

2.3 Puterea cere bond

Orice actor care poate:

• finaliza epoci;
• emite atestări critice;
• opera oracles;
• coordona agenți cu expunere;
• produce clearing critic

SHOULD aibă bond sau stake suficient pentru a putea fi sancționat.

2.4 Reward pentru comportament util

Protocolul SHOULD recompensa:

• participarea corectă;
• finalitatea validă;
• disponibilitatea;
• comportamentul predictibil;
• contribuția la verificabilitate și audit.

2.5 Penalitate proporțională

Penalitățile MUST crește cu:

• severitatea fault-ului;
• impactul asupra siguranței;
• repetitivitatea;
• rolul economic al actorului;
• potențialul de daună sistemică.

2.6 Anti-subsidizare oarbă

Protocolul MUST NOT subvenționa nelimitat:

• stare persistentă inutilă;
• execuție grea fără valoare;
• issueri critici fără bond;
• spam cu witnessuri și intenturi.

3. Activul nativ

3.1 Nume

Activul nativ al protocolului este: AZR

3.2 Funcții obligatorii

AZR MUST putea fi folosit pentru:

• taxe de rețea;
• stake de consens;
• bond-uri de rol;
• rent pentru stare persistentă;
• slashing și penalități;
• recovery reserve funding;
• eventual rewards.

3.3 Funcții opționale

AZR MAY fi folosit ulterior pentru:

• governance staking;
• insured service tiers;
• delegation markets;
• fee rebates bazate pe comportament.

3.4 Principiu

AZR nu trebuie tratat doar ca token tranzacționabil. Trebuie tratat ca activul care măsoară și securizează consumul de resurse și riscul protocolar.

4. Supply model

4.1 Obiectiv

Supply model-ul MUST susține:

• bootstrap de securitate;
• participare a validatorilor;
• predictibilitate economică;
• disciplină pe termen lung.

4.2 Structura generală

Supply-ul total poate proveni din:

• alocare genesis;
• emisie pe epoci;
• taxe reintroduse parțial în circulație prin rewards;
• burn parțial.

4.3 Principiu de emisie

Emisia SHOULD fi:

• predictibilă;
• descrescătoare sau controlabilă;
• suficientă pentru bootstrap, dar nu nelimitată;
• ajustabilă doar prin proces greu de guvernanță.

4.4 Formula abstractă

epoch_issuance(E) = base_issuance(E) * issuance_modifier(E)

unde:

• base_issuance(E) poate fi descrescătoare în timp;
• issuance_modifier(E) poate reflecta starea protocolului în limite stricte.

4.5 Limită

Protocolul MUST evita politici care permit emisie discretionary ad-hoc în afara mecanismelor prevăzute.

5. Fee model

5.1 Scop

Fee-urile trebuie să acopere:

• includerea tranzacției;
• verificarea sa;
• execuția sa;
• impactul asupra stării;
• impactul asupra consensului;
• externalitățile de rețea.

5.2 Fee components

Fee total SHOULD fi compusă din:

TotalFee =
  base_tx_fee +
  size_fee +
  verification_fee +
  execution_fee +
  state_write_fee +
  persistence_fee +
  congestion_multiplier_component

5.3 base_tx_fee

Cost minim pentru orice tranzacție validată.

5.4 size_fee

Crește cu dimensiunea canonicală a tranzacției și a obiectelor inline.

5.5 verification_fee

Reflectă costul de verificare a:

• semnăturilor;
• policy objects;
• witness/proof bundles;
• hash structures.

5.6 execution_fee

Reflectă exec_units_used pentru TX_MACHINE_CALL și alte operațiuni cu cost dinamic bounded.

5.7 state_write_fee

Cost pentru modificarea stării active:

• bytes scriși;
• număr de Cells create;
• witness records inserate;
• mașini deployate sau mutate.

5.8 persistence_fee

Costul de a lăsa obiecte persistente în sistem. Acest cost poate fi separat de rent și poate include:

• deploy fee;
• prepay rent;
• long-lived object fee.

5.9 congestion multiplier

Protocolul MAY crește taxele efective în perioade de congestionare. Acest multiplicator MUST fi determinist și derivabil public.

6. Fee settlement

6.1 Fee payment asset

V1 SHOULD privilegia plata fee-urilor în AZR.

6.2 Alternative assets

Fee în alte active MAY fi permisă ulterior doar dacă:

• conversia este deterministă sau foarte clar ancorată;
• nu complică validarea critică;
• nu deschide vectori de manipulare economică.

6.3 Fee collection

La aplicarea unei tranzacții valide:

• fee-ul este debitat;
• componenta sa este împărțită conform regulilor de distribuție;
• fee insufficiency invalidează sau exclude tranzacția.

7. Fee distribution

7.1 Destinații

Fee-urile SHOULD fi împărțite între:

• proposers / inclusion reward
• verifiers
• notaries / finality reward
• burn pool
• recovery reserve
• storage maintenance reserve

7.2 Formula abstractă

TotalFee = proposer_share + verifier_share + notary_share + burn_share + recovery_share + storage_share

7.3 Principiu

Distribuția MUST recompensa actorii care mențin:

• includerea;
• verificarea;
• finalitatea;
• retenția de stare;
• reziliența rețelei.

7.4 Limită

Protocolul SHOULD evita fee distribution care dă aproape totul unui singur rol dacă munca economică e distribuită între mai multe roluri.

8. Rent model for persistent state

8.1 Motiv

Starea persistentă este una dintre cele mai scumpe resurse ale protocolului. Fără rent, sistemul este vulnerabil la:

• state bloat;
• spam economic ieftin;
• logică care externalizează costuri pe toți nodurile.

8.2 Obiecte supuse rent

V1 SHOULD aplica rent cel puțin pentru:

• Bounded Machines
• machine state persistent
• anumite witnessuri de durată mare
• policy objects persistente
• alte obiecte long-lived

Cells simple din utxo_set pot avea regim diferit, dar MUST avea costuri asociate dacă devin mecanism de spam.

8.3 Model abstract

Rent per epoch pentru obiectul O:

Rent(O, E) = base_object_rent +
             byte_rent_rate * persisted_bytes(O) +
             complexity_factor(O) +
             criticality_factor(O)

8.4 Complexity factor

Poate reflecta:

• schema complexity;
• index burden;
• retention cost.

8.5 Criticality factor

Obiectele care necesită retenție mai strictă sau infrastructură auxiliară MAY suporta rent mai mare.

9. Prepaid rent

9.1 Model preferat v1

Pentru simplitate și determinism, v1 SHOULD folosi rent preplătit:

• deployer-ul sau operatorul plătește până la un anumit paid_until_epoch.

9.2 Reguli

1. O mașină nouă MUST avea rent prepaid minim.
2. Obiectele care expiră la rent deadline MAY intra în stare neactivă.
3. Protocolul MUST defini clar diferența între:
   • obiect existent istoric;
   • obiect activ;
   • obiect cu rent expirat.

9.3 Top-up

Rent-ul MAY fi reînnoit prin tranzacții de top-up validate canonical.

10. Rent expiration behavior

10.1 Mașini

Dacă rent expiră pentru o Bounded Machine:

• mașina poate deveni neapelabilă;
• poate intra în halt economic;
• starea ei poate rămâne istoric accesibilă;
• poate necesita top-up pentru reactivare.

10.2 Witnessuri

Witnessurile cu TTL natural nu necesită neapărat rent lung. Witnessurile persistente și indexabile mult timp MAY necesita retention fee.

10.3 Policy objects

Policy objects persistente MAY deveni neactive dacă rent expiră, conform regulii tipului.

10.4 Interdicție

Protocolul MUST NOT șterge arbitrar obiecte critice fără comportament normativ definit.

11. Stake model for consensus

11.1 Stake purpose

Stake-ul de consens servește la:

• selecția comitetelor;
• rezistența Sybil;
• suportul economic pentru slashing;
• stimularea participării corecte.

11.2 Active stake

Un validator este eligibil doar dacă are:

• stake activ;
• stake minim;
• lockup valid;
• fără penalități care îl scot din eligibilitate.

11.3 Locking

Stake-ul MUST fi blocat pentru o perioadă suficientă încât:

• slashing-ul să poată fi aplicat;
• actorul să nu evadeze imediat după fault.

11.4 Unbonding

Protocolul SHOULD introduce:

• unbonding_delay_epochs

Scop: fault-urile descoperite târziu să poată fi încă penalizate.

12. Bond model for critical roles

12.1 Distincție

Nu toate rolurile critice sunt validatori de consens. Unele roluri cer bond separat.

12.2 Roluri candidate pentru bond separat

• oracle operators
• committee attestors
• agent service operators
• batch executors / solvers
• settlement relayers
• special witness issuers

12.3 Principiu

Dacă un actor poate produce informație sau acțiune care:

• poate bloca fonduri,
• poate declanșa decizii sensibile,
• poate induce pierderi, atunci SHOULD avea bond slashable.

12.4 Formă

Bond-ul poate fi:

• în AZR;
• separat de stake-ul de consens;
• blocat pe rol și scope.

13. Bond sizing

13.1 Regula

Bond-ul minim SHOULD depinde de:

• rol;
• volum maxim permis;
• impact sistemic;
• frecvența acțiunilor;
• trust tier.

13.2 Formula abstractă

RequiredBond(role, scope) =
  role_base_bond *
  exposure_multiplier(scope) *
  criticality_multiplier(role) *
  trust_tier_multiplier

13.3 Principiu

Bond-ul trebuie să fie suficient de mare încât fault-ul să fie economic dureros, nu doar simbolic.

14. Rewards

14.1 Categorii

Rewards de protocol MAY include:

• issuance rewards
• fee shares
• availability rewards
• verification rewards
• finality rewards
• special service rewards

14.2 Reward conditions

Actorii SHOULD fi recompensați doar dacă:

• sunt eligibili;
• participă efectiv;
• nu au comis fault major în epoca relevantă;
• contribuția lor este verificabilă.

14.3 Consensus role rewards

Proposers

Recompensă pentru:

• includere validă;
• latență bună;
• blocuri non-spam;
• comportament onest.

Verifiers

Recompensă pentru:

• validare corectă;
• participare consecventă;
• rapoarte utile despre fraudă.

Notaries

Recompensă pentru:

• finalizare validă;
• participare la quorum;
• semnare corectă și la timp.

15. Reward withholding

15.1 Regula

Un actor MAY pierde parțial sau total reward-ul epocii dacă:

• nu a participat suficient;
• a semnat obiecte conflictuale;
• a fost marcat ca faulty;
• nu și-a respectat rolul minim de disponibilitate.

15.2 Principiu

Reward withholding este penalizare mai blândă decât slashing și SHOULD fi folosit pentru fault-uri mai puțin severe sau non-participare.

16. Slashing model

16.1 Principiu

Slashing-ul este penalitatea economică principală pentru comportament adversarial sau grav neglijent.

16.2 Surse slashable

• stake de consens
• bond-uri de rol
• eventual rewards acumulate dar neclaimate

16.3 Condiții generale

Un slashable event MUST fi:

• determinabil;
• demonstrabil prin obiecte canonice și/sau fraud proofs;
• atribuit unui rol și unei chei/policy clare;
• cuantificabil.

17. Slashing offenses by role

17.1 Proposers

Slashable pentru:

• dublă propunere incompatibilă în același slot;
• falsificare de metadata critică;
• propagare repetată de blocuri structural invalide cu rea-credință demonstrabilă;
• participare la conflicte deliberate.

17.2 Verifiers

Slashable pentru:

• semnare simultană de valid și invalid pentru același obiect;
• aprobări incompatibile de fronturi exclusiv conflictuale;
• susținere repetată a unor blocuri demonstrabil invalide.

17.3 Notaries

Slashable pentru:

• semnarea a două notarizări incompatibile în aceeași epocă;
• semnarea unei notarizări nereexecutabile;
• participare la comitet fals.

17.4 Oracle/Bonded issuer

Slashable pentru:

• emitere de claims contradictorii în scope exclusiv;
• claims frauduloase dovedite;
• feed replay neautorizat;
• atestări fără respectarea policy.

17.5 Agent operator / executor

Slashable pentru:

• acțiuni în afara mandatului dovedite canonical;
• falsificare de execution logs;
• depășire deliberată de exposure caps;
• suprimarea obligației de journaling unde aceasta e obligatorie.

18. Penalty classes

18.1 Minor fault

Exemple:

• indisponibilitate moderată;
• întârziere repetată;
• neparticipare ocazională.

Consecințe:

• reward withholding;
• mic slash;
• reputație scăzută.

18.2 Major fault

Exemple:

• semnături contradictorii;
• feed inconsistent repetat;
• verificări grav eronate.

Consecințe:

• slash mediu/mare;
• suspendare temporară;
• pierdere de eligibility.

18.3 Byzantine fault

Exemple:

• notarizare incompatibilă;
• fraudă deliberată;
• oracle fraud sistematic;
• dublă semnare critică.

Consecințe:

• slash sever;
• excludere;
• confiscare parțială sau totală a bond-ului relevant.

19. Slash sizing

19.1 Principiu

Slash size SHOULD crește cu:

• severitatea fault-ului;
• rolul;
• stake/bond-ul implicat;
• impactul estimat;
• recidiva.

19.2 Formula abstractă

SlashAmount =
  base_slash(role, fault_class) *
  severity_multiplier *
  recidivism_multiplier *
  systemic_impact_multiplier

19.3 Limită

Slash-ul MUST fi bounded și normativ. Nu poate fi arbitrar sau politic în runtime normal.

20. Slashing destination

20.1 Sumele slash-uit

Fondurile slash-uite SHOULD fi împărțite între:

• burn
• recovery reserve
• fraud proof reward / reporter reward
• protocol treasury limitat

20.2 Principiu

Distribuția SHOULD descuraja fault-ul și în același timp recompensa detectarea sa.

21. Fraud proof rewards

21.1 Rol

Detectarea fault-urilor utile este un serviciu economic. Protocolul SHOULD recompensa raportarea validă.

21.2 Condiții

Reward-ul pentru fraud proof MAY fi acordat dacă:

• dovada este validă;
• fault-ul era nepenalizat anterior;
• reporterul respectă formatul și fereastra de raportare.

21.3 Limită

Protocolul MUST evita reward farming prin dovezi duplicate sau triviale deja cunoscute.

22. Congestion pricing

22.1 Need

În perioade de încărcare mare, fee-urile trebuie să reflecte raritatea resursei.

22.2 Model

Protocolul MAY ajusta:

• base_tx_fee
• execution_fee multiplier
• state_write_fee
• per-object admission minima

în funcție de congestion state.

22.3 Determinism

Congestion pricing MUST depinde doar de metrici protocolare publice și reconstructibile.

22.4 Goal

Sistemul SHOULD:

• respinge economic spam-ul;
• rămâne utilizabil pentru acțiuni valoroase;
• nu devină gratuit pentru state-heavy abuse.

23. Spam resistance by object type

23.1 Transactions

Cost minim și size fee.

23.2 Witness records

Cost SHOULD crește cu:

• dimensiunea;
• retenția;
• index burden;
• criticality class dacă cere infrastructură suplimentară.

23.3 Intents

Intenturile MUST plăti fee suficientă pentru a evita:

• order spam;
• path spam;
• solver griefing.

Intenturile cu fereastră lungă sau complexitate mare SHOULD plăti mai mult.

23.4 Machine deploys

Deploy-urile MUST plăti:

• deploy fee;
• prepay rent;
• eventual risk tier surcharge.

24. Risk tier pricing

24.1 Need

Nu toate mașinile și serviciile au același risc.

24.2 Capability tiers

Legat de AZ-005:

• Tier 0 = low-risk bounded state
• Tier 1 = custody bounded
• Tier 2 = market logic bounded
• Tier 3 = agent coordination bounded

24.3 Economic implication

Deploy fee, rent, audit requirements și bond requirements SHOULD crește cu capability tier.

24.4 Goal

Actorii cu suprafață de risc mai mare trebuie să internalizeze mai mult cost.

25. Recovery reserve

25.1 Scop

Protocolul SHOULD avea o rezervă economică pentru:

• bug bounties;
• incidente sistemice;
• recovery procedures;
• instrumente de continuitate și patching controlat;
• compensări strict guvernate, dacă modelul o permite.

25.2 Surse de finanțare

Recovery reserve MAY primi:

• share din fee-uri;
• share din slashing;
• alocare genesis limitată;
• yield temporar pe active rezervate, dacă politica o permite.

25.3 Limită

Recovery reserve MUST avea utilizare strict normată. Nu trebuie să devină buget politic discretionary.

26. Burn model

26.1 Motiv

Burn-ul poate:

• reduce diluția;
• ancora valoare economică în utilizare reală;
• penaliza fault-uri severe.

26.2 Surse posibile

AZR poate fi ars din:

• share de fee;
• share din slashing;
• costuri speciale de deploy sau spam;
• rent penalties.

26.3 Limită

Burn-ul SHOULD fi stabil și predictibil, nu manipulat frecvent.

27. Treasury / protocol reserve

27.1 Distincție

Protocolul MAY avea un treasury separat de recovery reserve.

27.2 Utilizări permise

• dezvoltare protocolară aprobată;
• audit extern;
• granturi tehnice;
• infrastructură publică critică.

27.3 Limită

Treasury-ul MUST avea reguli stricte de guvernanță și trasabilitate.

28. Economic state variables

28.1 ProtocolParamState SHOULD include:

• fee schedule
• congestion multiplier state
• rent rates
• bond requirements by role
• slash schedule
• reward schedule
• burn share
• reserve shares
• issuance parameters
• unbonding delays

28.2 Determinism

Orice tranzacție economică MUST folosi exact parametrii activi ai stării protocolare pentru acel moment.

29. Fee formulas by object

29.1 Simple transfer

Fee_transfer =
  base_tx_fee +
  size_fee +
  signature_verification_fee +
  input_output_count_fee

29.2 Machine call

Fee_machine_call =
  base_tx_fee +
  size_fee +
  execution_fee(exec_units_used or bounded estimate) +
  state_write_fee +
  witness_access_fee +
  proof_verification_fee

29.3 Machine deploy

Fee_machine_deploy =
  deploy_base_fee +
  code_size_fee +
  static_analysis_fee +
  initial_state_write_fee +
  prepaid_rent +
  capability_tier_surcharge

29.4 Witness emit

Fee_witness_emit =
  base_tx_fee +
  witness_size_fee +
  proof_bundle_fee +
  retention_fee_if_applicable

29.5 Intent submit

Fee_intent_submit =
  base_tx_fee +
  size_fee +
  time_window_fee +
  complexity_fee +
  solver_burden_fee

30. Deposits for spam-sensitive flows

30.1 Need

Unele acțiuni creează externalități chiar dacă fee-ul simplu e insuficient.

30.2 Deposit model

Protocolul MAY cere depozit/refundable bond pentru:

• intenturi pe termen lung;
• oracle feeds;
• high-rate witness emission;
• special queryable objects.

30.3 Release / forfeiture

Depozitul poate fi:

• returnat la expirare sau comportament corect;
• parțial confiscat pentru spam/fault;
• folosit pentru costuri de retenție.

31. Economic treatment of no-finality epochs

31.1 Need

Dacă o epocă nu finalizează, actorii nu trebuie recompensați ca și cum sistemul ar fi mers normal.

31.2 Rule

În epoci de NO_FINALITY:

• rewards MAY fi reduse;
• non-participation penalties MAY crește pentru rolurile responsabile;
• issuance MAY fi ajustată conform regulilor predefinite.

31.3 Interdicție

Protocolul MUST evita să plătească integral finality rewards când finalitatea nu a avut loc.

32. Availability scoring

32.1 Motivation

Participarea utilă nu este binară. Poate fi măsurată prin score.

32.2 Components

Availability score MAY include:

• timely block proposal rate;
• verifier vote participation;
• notary participation;
• oracle freshness;
• agent journaling compliance.

32.3 Use

Availability score MAY influența:

• rewards;
• eligibility;
• bond requirements;
• trust tier.

33. Reputation vs economics

33.1 Principiu

Reputația poate ajuta, dar nu înlocuiește bond-ul. Pentru roluri critice, penalitatea reputațională fără cost economic este insuficientă.

33.2 Rule

Rolurile cu impact direct mare asupra fondurilor sau finalității SHOULD aibă bond/stake slashable, nu doar reputație.

34. Economic coupling with Witness Layer

34.1 Need

Issuerii de witnessuri critice trebuie să suporte costul responsabilității.

34.2 Model

Witnessurile critice SHOULD implica:

• fee mai mare;
• bond requirement pentru issuer;
• slash path dacă atestarea e frauduloasă;
• retention fee dacă impactul lor persistă.

34.3 Goal

O afirmație protocolară importantă nu trebuie să fie ieftin de emis și imposibil de sancționat.

35. Economic coupling with BVM

35.1 Need

Contractele mai puternice și mai riscante trebuie să plătească mai mult.

35.2 Components

BVM economic burden SHOULD depinde de:

• capability tier;
• state bound;
• max exec units;
• effect bound;
• asset scope;
• custody risk;
• external dependency count.

35.3 Goal

Costul economic să fie corelat cu suprafața de risc și costul operațional.

36. Loss envelope and economics

36.1 Principiu

Loss envelope nu este doar control tehnic. El influențează și economia rolurilor.

36.2 Rule

Mașinile și operatorii cu:

• envelope mai mare,
• lock duration mai mare,
• asset scope mai larg, SHOULD aibă:
• fee mai mare,
• bond mai mare,
• audit burden mai mare.

37. Bonded service markets

37.1 Potential

Protocolul MAY permite în viitor piețe de servicii bond-uite:

• oracle providers
• execution solvers
• risk monitors
• settlement relayers
• attestation services

37.2 Requirement

Aceste piețe MUST păstra:

• bond clarity;
• slash rules;
• service scope;
• replay and fraud resistance.

38. Economic attack surfaces to resist

Protocolul trebuie să reziste sau să reducă:

1. cheap state bloat;
2. witness spam;
3. intent spam;
4. gas/exec griefing;
5. low-bond oracle fraud;
6. slash-evading fast exit;
7. artificial congestion;
8. proposer-only fee extraction;
9. no-finality reward farming;
10. storage externalization onto passive nodes.

39. Governance over economics

39.1 Upgradable parameters

Protocolul MAY permite guvernanței să modifice:

• fee schedule;
• rent rates;
• reward shares;
• slash multipliers;
• bond minima;
• issuance modifiers.

39.2 Limită

Schimbările economice MUST:

• fie versionate;
• fie activabile cu delay;
• aibă traseu de aprobare verificabil;
• nu surprindă actorii instantaneu fără fereastră de adaptare.

39.3 Cvasi-constituțional

Protocolul SHOULD trata ca greu schimbabile:

• existența rentului;
• existența bond-urilor pentru roluri critice;
• existența slashing-ului pentru double-signing și fault byzantin;
• destinațiile majore ale fee-urilor.

40. Minimal testnet economics

40.1 Pentru testnet

Testnet-ul MAY folosi parametri simplificați:

• emisie mare și artificială;
• slash redus;
• rent redus;
• fee simbolică.

40.2 Limită

Chiar și testnet-ul SHOULD păstra:

• fee model structural;
• rent logic structural;
• bond/slash flows structurale; altfel testnet-ul nu validează arhitectura economică reală.

41. Mainnet readiness criteria

Protocolul nu SHOULD lansa mainnet până când există:

1. fee formulas implementate și măsurate;
2. rent behavior testat;
3. slash proofs testate;
4. bond sizing rationale;
5. recovery reserve governance;
6. no-finality economic handling;
7. simulation de atacuri economice majore.

42. Formal goals

Modelul economic urmărește patru obiective formale:

42.1 Resource pricing soundness

Orice consum semnificativ de resursă are cost economic internalizat.

42.2 Fault accountability

Orice rol critic are expunere economică la fault-uri relevante.

42.3 Sustainability target

Rewards + fees + reserves + burn trebuie să poată coexista fără a face protocolul fie nesustenabil, fie inutilizabil.

42.4 Anti-bloat target

Costul stocării persistente și al retention-ului trebuie să descurajeze supraîncărcarea stării.

43. Economic formulas summary

43.1 Total transaction fee

TotalFee =
  base_tx_fee +
  size_fee +
  verification_fee +
  execution_fee +
  state_write_fee +
  persistence_fee +
  congestion_component

43.2 Rent

Rent(O, E) =
  base_object_rent +
  byte_rent_rate * persisted_bytes(O) +
  complexity_factor(O) +
  criticality_factor(O)

43.3 Required bond

RequiredBond(role, scope) =
  role_base_bond *
  exposure_multiplier(scope) *
  criticality_multiplier(role) *
  trust_tier_multiplier

43.4 Slash

SlashAmount =
  base_slash(role, fault_class) *
  severity_multiplier *
  recidivism_multiplier *
  systemic_impact_multiplier

44. Formula modelului economic

Economic Layer = priced execution + priced persistence + bonded authority + reward for correctness + slash for harmful behavior + reserve for recovery

45. Relația cu restul protocolului

• AZ-003 spune dacă o tranzacție este validă.
• AZ-004 spune când devine finală.
• AZ-005 limitează costul logicii.
• AZ-006 limitează costul și responsabilitatea afirmațiilor.
• AZ-007 face toate acestea sustenabile și sancționabile economic.

Pe scurt: fără AZ-007, protocolul ar putea fi tehnic elegant și economic rupt.

46. Ce urmează

După AZ-007, documentul corect este:

AZ-008 — Agent Delegation, Mandates, Risk Caps, and Operational Control

Acolo trebuie fixate:

• modelul exact de delegare pentru agenți;
• mandate și scope;
• exposure caps;
• journaling obligatoriu;
• kill-switch, halt, rotate, recover;
• relația dintre agent, operator, owner și protocol.

Închidere

ATLAS ZERO nu tratează economia ca pe un strat cosmetic pus peste protocol. O tratează ca pe mecanismul prin care:

• resursele sunt prețuite,
• autoritatea devine responsabilă,
• fault-ul devine costisitor,
• iar continuitatea sistemului devine finanțabilă.

Acolo începe sustenabilitatea reală.