AZ-047 — Treasury, Reserve and Public Financial Truth Canon v1

Status

Acest document definește canonul adevărului financiar public pentru ATLAS ZERO.

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

specificația protocolului și a subsistemelor;
modelul economic, guvernanța, launch-ul, upgrade-urile și recovery;
canonul constituțional al identității de rețea;
registrul parametrilor;
canonul legitimității validatorilor și al membership-ului;
arhivele, exporturile de audit și canonul de risk/threat.

AZ-047 răspunde la întrebarea: ce este adevărul financiar public al protocolului, cum sunt reprezentate treasury-ul, reservele, obligațiile și fluxurile economice critice și cum pot fi acestea verificate, auditate și păstrate ca memorie normativă fără ambiguitate peste launch, upgrade, incident, recovery și fork?

Scopul documentului este să fixeze:

modelul canonic al activelor și pasivelor publice ale protocolului;
treasury, reserve, reward pools, slash flows și obligațiile financiare;
obiectele de stare și de eveniment financiar;
regulile de legitimitate, reconciliere și audit;
relația cu governance, parameter canon, validator canon, archive și constitutional canon;
și exportul/public verification al adevărului financiar.

Acest document se bazează pe:

AZ-002 până la AZ-046, cu accent direct pe AZ-006, AZ-007, AZ-009, AZ-016, AZ-021, AZ-033, AZ-039, AZ-041, AZ-043, AZ-044 și AZ-046.

Termeni:

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

1. Obiectiv

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

Ce înseamnă „adevăr financiar public” în ATLAS ZERO?
Ce componente financiare sunt normative și auditabile?
Cum sunt reprezentate treasury-ul, reservele și pool-urile economice?
Cum sunt urmărite rewards, penalties, slashing, allocations și obligațiile?
Cum se reconstruiește soldul legitim pentru un boundary dat?
Cum distingem active, obligații, pasive condiționale și fluxuri tranzitorii?
Cum interacționează adevărul financiar cu governance, upgrade, recovery și fork?
Cum se exportă și se verifică public acest adevăr?
Cum evităm contabilitatea implicită, shadow balances și explicațiile informale?
Cum păstrăm pe termen lung memoria financiară publică a rețelei?

2. Principii

2.1 Public financial truth is normative protocol state

Adevărul financiar public MUST fi tratat ca stare normativă a protocolului, nu ca rezumat extern sau simplă analiză contabilă.

2.2 Treasury and reserve are not just labels

Treasury-ul, reservele și celelalte containere economice MUST avea definiții canonice, scope, reguli de mutație și proveniență.

2.3 Flows matter as much as balances

Soldurile fără istoria fluxurilor critice sunt insuficiente. Canonul SHOULD păstra atât starea, cât și transformările relevante.

2.4 Public verifiability must survive operational complexity

Chiar dacă implementarea internă este complexă, un auditor extern SHOULD putea verifica solduri, obligații și mutații materiale prin recorduri canonice.

2.5 Financial continuity must follow constitutional continuity

Dacă rețeaua suferă hard fork sau recovery excepțional, adevărul financiar MUST fi realiniat explicit cu noua continuitate sau noua ramură legitimă.

2.6 Economic legitimacy and accounting legitimacy are linked

Un flux economic nu este legitim doar pentru că s-a întâmplat tehnic. Trebuie să fie și normativ autorizat în canonul stării și al regulilor active.

3. Public financial truth purpose

3.1 Canonul SHOULD răspunde:

ce active publice și pool-uri există?
care sunt soldurile lor legitime?
ce obligații publice există?
ce fluxuri au modificat aceste solduri?
ce reguli și parametri au autorizat aceste fluxuri?
ce stare financiară era legitimă la boundary-ul X?
ce parte din adevărul financiar este constituțional relevantă?

3.2 Rule

Dacă nu poate răspunde clar la aceste întrebări, canonul financiar este insuficient.

4. Financial asset classes

4.1 Recommended asset classes

ATLAS ZERO SHOULD distinge cel puțin:

FA_TREASURY
FA_RESERVE
FA_REWARD_POOL
FA_SLASH_POOL
FA_GOVERNANCE_ALLOCATION_POOL
FA_RECOVERY_CONTINGENCY_POOL
FA_PROTOCOL_FEE_ACCUMULATOR
FA_ESCROW_OR_BOND_POOL
FA_PUBLIC_OBLIGATION_LEDGER
FA_BRANCH_SPECIFIC_FINANCIAL_STATE

4.2 Rule

Fiecare clasă SHOULD avea reguli explicite de mutație, surse de alimentare și destinații permise.

5. Financial container model

5.1 A financial container is a canonical bucket of public protocol value or obligation with:

identity;
scope;
allowed inflows;
allowed outflows;
balance semantics;
and archival/audit relevance.

5.2 Rule

Containers MUST be first-class objects in the financial canon.

6. Financial container identity record

6.1 Canonical structure

FinancialContainerIdentityRecord {
  version_major
  version_minor

  container_id
  canonical_name
  asset_class
  container_scope_class
  balance_semantics_class
  metadata_hash?
}

6.2 balance_semantics_class examples

liquid_balance
locked_balance
obligation_balance
accrued_not_disbursed
branch_specific_balance
contingent_balance

6.3 Rule

Container identity MUST remain stable across balance changes.

7. Container scope classes

7.1 scope classes MAY include:

global_network_scope
mainnet_scope
testnet_scope
branch_scope
upgrade_transition_scope
recovery_scope
governance_program_scope

7.2 Rule

Financial truth without scope is weak, especially around forks and recovery.

8. Financial state record

8.1 Canonical structure

FinancialStateRecord {
  version_major
  version_minor

  financial_state_id
  financial_scope_hash
  active_container_balance_root
  active_obligation_root?
  active_flow_policy_root?
  state_boundary_hash
  provenance_root?
  status
}

8.2 status

candidate
active
superseded
revoked
historical
disputed

8.3 Rule

A financial state record SHOULD summarize the authoritative financial truth for a scope and boundary.

9. Container balance record

9.1 Canonical structure

ContainerBalanceRecord {
  balance_record_id
  container_ref
  amount_hash
  currency_or_unit_ref
  balance_boundary_hash
  status
}

9.2 status

active
superseded
disputed
historical

9.3 Rule

Balances MUST be boundary-specific and historically queryable.

10. Obligation model

10.1 Public financial truth MAY include obligations such as:

pending validator rewards
governance-approved but not yet released allocations
slash liabilities or distributions pending finalization
reserve obligations
recovery-related funding obligations
bond refunds or escrow obligations

10.2 Rule

Obligations SHOULD be modeled explicitly, not hidden inside narrative “future payouts”.

11. Obligation record

11.1 Canonical structure

PublicObligationRecord {
  obligation_id
  obligation_class
  beneficiary_scope_hash?
  amount_hash
  obligation_boundary_hash
  maturity_or_trigger_hash?
  status
  authority_ref?
}

11.2 obligation_class examples

pending_reward
approved_treasury_disbursement
slash_distribution_pending
reserve_backing_obligation
escrow_release_pending
recovery_reimbursement_pending

11.3 status

pending
matured
satisfied
canceled
superseded
disputed

11.4 Rule

A protocol with public obligations SHOULD expose them canonically.

12. Financial flow model

12.1 A financial flow is a canonical movement or transformation of public protocol value or obligation.

12.2 Flow families SHOULD include:

fee accrual
fee burn if applicable
reward accrual
reward disbursement
slash deduction
slash redistribution
treasury allocation
reserve replenishment
reserve drawdown
governance-authorized transfer
recovery-specific financial adjustment
branch split allocation

12.3 Rule

Every material balance mutation SHOULD be explainable by allowed flow classes.

13. Financial flow record

13.1 Canonical structure

FinancialFlowRecord {
  version_major
  version_minor

  flow_id
  flow_class
  source_container_ref?
  destination_container_ref?
  obligation_ref?
  amount_hash
  authorization_ref?
  triggering_event_ref?
  effective_boundary
  status
}

13.2 status

scheduled
executed
reversed
superseded
disputed

13.3 Rule

Flow records MUST preserve both authorization and execution context where relevant.

14. Flow authorization model

14.1 Material financial flows SHOULD be authorized by:

protocol rules at runtime
active parameter set
governance act
slashing rule outcome
upgrade/recovery ratification
constitutional act in exceptional cases

14.2 Rule

No material public flow SHOULD rely only on off-ledger operator discretion.

15. Flow policy record

15.1 Canonical structure

FinancialFlowPolicyRecord {
  policy_id
  flow_class
  allowed_source_class_root
  allowed_destination_class_root
  triggering_rule_root
  limitation_root?
}

15.2 Rule

Financial flow policies SHOULD be explicit enough to validate legality of flows.

16. Treasury model

16.1 Treasury is the canonical public pool used for governance-directed or protocol-defined funding purposes.

16.2 Treasury canon SHOULD define:

sources of replenishment
authorized outflow classes
approval requirements
reserve interaction rules
branch/recovery treatment
visibility and export requirements

16.3 Rule

Treasury MUST NOT be modeled as generic “misc funds” bucket.

17. Reserve model

17.1 Reserve is the canonical pool for backstop, coverage, contingency or economically special purpose funds defined by protocol.

17.2 Reserve SHOULD define:

what it backs or stabilizes
under what triggers it can be used
whether it is fully liquid or partially locked
whether governance can directly draw it
how recovery or branch split affects it

17.3 Rule

Reserve semantics MUST be stricter and more explicit than generic treasury semantics.

18. Reward and slash pools

18.1 Reward pool semantics SHOULD define:

accrual origin
beneficiary classes
time of maturation
disbursement triggers
forfeiture rules if any

18.2 Slash pool semantics SHOULD define:

slash event source
destination logic
whether burned, redistributed or reserved
pending dispute or finality windows if applicable

18.3 Rule

Reward and slash accounting SHOULD remain deterministic and reconstructible.

19. Public financial truth root

19.1 Derivation

financial_entry_hash_i =
  H("AZ:PUBLIC_FINANCIAL_ENTRY:" || canonical_entry_i)

public_financial_truth_root = MerkleRoot(financial_entry_hash_i...)

19.2 Entries SHOULD cover:

container balances
public obligations
active material flows
legal statuses of pending/disputed items

19.3 Rule

This root SHOULD summarize public financial state for a boundary.

20. Financial reconciliation model

20.1 Need

Public financial truth SHOULD support reconciliation between:

prior state
executed flows
resulting balances
obligations opened/closed
slashing/reward side effects

20.2 Rule

Financial reconciliation MUST be deterministic and auditable.

21. Reconciliation record

21.1 Canonical structure

FinancialReconciliationRecord {
  reconciliation_id
  prior_financial_state_ref
  resulting_financial_state_ref
  applied_flow_root
  resulting_obligation_root?
  reconciliation_verdict
  timestamp_unix_ms
}

21.2 reconciliation_verdict

balanced
balanced_with_pending_obligations
disputed
inconsistent

21.3 Rule

Material financial scope SHOULD have reconciliation records for major boundaries or exported snapshots.

22. Financial event legality

22.1 A flow or state change is legitimate only if:

it is permitted by active policy/parameter/governance scope;
source and destination containers are legal;
amount and timing constraints are valid;
no higher-priority constitutional or recovery constraint is violated.

22.2 Rule

Illegitimate financial mutations SHOULD be modeled as invalid or disputed, not silently normalized.

23. Disputed financial state model

23.1 Dispute MAY arise when:

multiple candidate balances exist after incident/recovery;
authorization of a flow is contested;
branch-specific truth diverges;
reconciliation fails materially.

23.2 Canonical structure

DisputedFinancialStateRecord {
  disputed_financial_state_id
  disputed_scope_hash
  candidate_financial_truth_root
  claimant_root
  evidence_root?
  timestamp_unix_ms
}

23.3 Rule

Disputed financial truth SHOULD be explicit, not hidden behind one preferred dashboard view.

24. Financial continuity and branch splits

24.1 Compatible upgrades usually preserve same financial canon continuity.

24.2 Hard fork or exceptional recovery MAY require:

branch-specific treasury and reserve states
allocation split policies
obligation reassignment rules
branch-specific slashing/reward truth
explicit continuity or rupture classification

24.3 Rule

Financial continuity MUST follow constitutional continuity and branch lineage.

25. Branch allocation record

25.1 Canonical structure

BranchFinancialAllocationRecord {
  allocation_id
  parent_financial_state_ref
  child_branch_identity_ref
  allocation_policy_hash
  resulting_branch_financial_state_ref
  authority_ref
}

25.2 Rule

When financial truth branches, allocation and legitimacy MUST be explicit and auditable.

26. Relationship to parameter canon

26.1 Financial truth depends heavily on parameters such as:

fee schedule
rent schedule
reward formulas
slash ratios
treasury allocation thresholds
reserve drawdown conditions
governance disbursement rules

26.2 Rule

Financial state SHOULD be interpretable only relative to the active parameter set.

27. Relationship to validator canon

27.1 Validator membership affects:

reward eligibility
slash applicability
escrow/bond treatment
public obligations toward validators
branch-specific redistribution after revocation or split

27.2 Rule

Public financial truth SHOULD bind to legitimate validator membership truth when rewards or penalties are involved.

28. Relationship to governance canon

28.1 Governance MAY authorize:

treasury disbursements
reserve policy changes
program allocations
exceptional recovery-related financial actions
branch-specific financial ratification

28.2 Rule

Governance-linked financial actions MUST preserve authority lineage.

29. Relationship to threat canon and economic evaluation

29.1 Threat canon SHOULD track risks such as:

treasury abuse
reserve depletion
reward gaming
slash flow distortion
obligation opacity
branch allocation ambiguity
public financial export misrepresentation

29.2 Economic simulations SHOULD reference exact financial state and parameter scope.

29.3 Rule

Public financial canon is a protected asset class in AZ-039 and a simulation input in AZ-041.

30. Relationship to recovery canon

30.1 Severe recovery MAY require financial legitimacy review:

what balances remain legitimate?
what obligations survive?
what flows are invalidated or replayed?
how reserve or treasury continuity is preserved or split?

30.2 Rule

Recovered state legitimacy SHOULD include recovered financial truth legitimacy.

31. Financial legitimacy review object

31.1 Canonical structure

FinancialLegitimacyReviewRecord {
  review_id
  financial_scope_hash
  candidate_financial_state_ref
  legitimacy_assessment_class
  evidence_root
  findings_root?
  timestamp_unix_ms
}

31.2 legitimacy_assessment_class

sufficient
sufficient_with_pending_obligations
insufficient
disputed
requires_constitutional_review

31.3 Rule

Major recovery, upgrade split or audit findings SHOULD trigger financial legitimacy review.

32. Public financial export interface

32.1 External/public exports SHOULD support:

active financial state proof
treasury and reserve balance proof
reward/slash flow proof
obligation proof
branch-specific financial truth proof
reconciliation proof
redaction-aware audit bundle where necessary

32.2 Rule

The public financial truth export SHOULD remain claim-centered and scope-bound.

33. Financial query model

33.1 Useful queries

what were treasury and reserve balances at boundary X?
what flows changed treasury between A and B?
what obligations were pending at upgrade Y?
what slash redistributions occurred in epoch E?
how was reserve split after branch B?
what financial state is legitimate for recovery scope R?

33.2 Rule

Canon SHOULD support boundary-based and lineage-based queries.

34. Historical snapshots

34.1 Canon SHOULD preserve:

financial snapshots at genesis
launch boundary
major upgrade boundaries
hard fork boundaries
recovery boundaries
periodic audit/export boundaries

34.2 Rule

Historical public financial truth MUST remain reconstructible.

35. Financial archive model

35.1 Archive SHOULD preserve:

container identities
balance records
obligation records
material flow records
reconciliation records
legitimacy reviews
branch allocation records
export bundles
preservation verification lineage

35.2 Rule

Financial archives SHOULD be tied into long-term preservation schedule.

36. Public financial truth canon object

36.1 Canonical structure

PublicFinancialTruthCanon {
  version_major
  version_minor

  canon_id
  financial_scope_hash
  container_identity_root
  active_financial_state_ref
  historical_financial_state_root?
  legitimacy_review_root?
  timestamp_unix_ms
}

36.2 Rule

This object SHOULD be the top-level canonical entry point for public financial truth in a scope.

37. Financial anti-patterns

37.1 Systems SHOULD avoid:

treasury described only in governance prose
reserve used as catch-all fund with no strict semantics
rewards and slashes not linkable to membership truth
obligations hidden as future off-ledger expectations
balances exported with no flow or reconciliation lineage
branch split with no financial allocation record
recovery that restores state but leaves treasury legitimacy ambiguous
shadow operator spreadsheets acting as public truth source
no distinction between liquid balance and contingent obligations
deleting historical financial snapshots after supersession

38. Formal goals

AZ-047 urmărește aceste obiective:

38.1 Public financial clarity

The system can state exactly what public protocol funds, reserves and obligations exist and in what amounts.

38.2 Deterministic financial reconstruction

For any declared boundary, the legitimate public financial state can be rebuilt and audited.

38.3 Clear linkage to governance, validators, recovery and branches

Financial truth remains coherent through the hardest lifecycle transitions.

38.4 Durable and exportable financial memory

The public financial history of the network remains queryable, archivable and externally verifiable.

39. Formula documentului

Public Financial Truth Canon = stable financial container identities + balance and obligation records + authorized flow records + reconciliation + legitimacy review + historical snapshots + branch-aware continuity

40. Relația cu restul suitei

AZ-043 definește constitutional identity canon.
AZ-044 definește parameter truth canon.
AZ-045 definește recovery legitimacy.
AZ-046 definește validator legitimacy.
AZ-047 definește adevărul financiar public care leagă toate aceste domenii în plan economic și auditabil.

Pe scurt: AZ-047 este canonul prin care protocolul își poate spune adevărul financiar public fără ambiguitate.

41. Ce urmează

După AZ-047, documentul corect este:

AZ-048 — Public Network Truth Export and Verification Interface

Acolo trebuie fixate:

ce adevăruri publice pot fi exportate într-un format verificabil;
cum se unifică identity, parameters, validator set, financial state și constitutional lineage într-o interfață publică de verificare;
și cum pot terții valida starea publică a rețelei fără acces intern privilegiat.

Închidere

Un protocol nu are adevăr public complet dacă poate spune doar cine validează și ce reguli are. Trebuie să poată spune și: ce fonduri publice există, ce obligații există, cum s-au mișcat, sub ce autoritate, și ce stare financiară este legitimă după fiecare tranziție majoră.

Acolo începe canonul adevărului financiar public.