AZ-006 — Witness, Proof, and Attestation Rules v1

Status

Acest document definește stratul de memorie verificabilă al ATLAS ZERO:

• Witness Records
• Proof Bundles
• Attestation flows
• Revocation rules
• Accountability rules pentru issueri, oracles, comitete și agenți

Scopul acestui strat nu este să mute valoare direct. Scopul este să permită:

• aprobare verificabilă;
• context verificabil;
• urme verificabile pentru agenți și procese;
• legarea logicii și valorii de dovezi finite și auditable.

Acest document se bazează pe:

• AZ-002 pentru structuri de date;
• AZ-003 pentru validare și tranziții;
• AZ-004 pentru finalitate;
• AZ-005 pentru integrarea cu BVM și effect model.

Termeni:

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

1. Obiectiv

AZ-006 răspunde la 8 întrebări:

1. Ce este un Witness Record și ce semnifică normativ?
2. Ce este un Proof Bundle și cum se validează?
3. Ce tipuri de atestări există?
4. Cum se leagă witnessurile de subiecte, acțiuni și timp?
5. Cum se revocă sau expiră un witness?
6. Cum sunt trași la răspundere issuerii de atestări?
7. Cum folosesc contractele și politicile witnessurile?
8. Cum sunt jurnalizate acțiunile agenților în mod verificabil?

2. Principiul stratului Witness

2.1 Separare de Value Layer

Witness Layer MUST rămâne distinct de transferul de valoare. Un witness:

• nu mută direct fonduri;
• nu consumă direct Cell-uri doar prin existența sa;
• nu schimbă direct starea economică fără o regulă explicită în alt strat.

2.2 Rol

Witness Layer oferă:

• memorie verificabilă;
• atestare;
• aprobare;
• jurnal;
• ancorare a unor afirmații externe în protocol;
• trasabilitate pentru acțiuni automate.

2.3 Principiu de minimizare

Witnessurile SHOULD conține:

• afirmații compacte;
• hash-uri și referințe canonice;
• dovezi verificabile sau referințe la acestea;
• timp și politici clare de validitate.

Witnessurile MUST NOT deveni depozit nelimitat de date brute.

3. Obiecte fundamentale

Stratul Witness operează cu trei familii principale:

1. WitnessRecord
2. ProofBundle
3. AttestationPolicy / IssuerPolicy constraints

Acestea se combină pentru a exprima:

• o afirmație;
• dovada ei;
• dreptul cuiva de a o emite;
• perioada și condițiile în care afirmația este valabilă.

4. Witness semantics

4.1 Definiție

Un Witness Record este o afirmație protocolară semnată și contextualizată despre un subiect.

Forma abstractă:

WitnessRecord = {
  issuer,
  subject,
  statement_type,
  statement_hash,
  time,
  validity window,
  revocation semantics,
  optional proof linkage,
  optional visibility controls
}

4.2 Ce afirmă un witness

Un witness afirmă numai ceea ce statement_type și statement_hash definesc explicit. Nimic mai mult.

4.3 Interdicție semantică

Nodurile MUST NOT deduce sensuri suplimentare nedefinite de standardul statement_type.

Exemplu: un approval nu înseamnă implicit și „responsabilitate economică totală”, dacă standardul acelui tip nu o spune.

5. Witness subject model

5.1 Subject categories

subject_ref poate referi canonic:

• CELL
• MACHINE
• MACHINE_CALL
• TX
• INTENT
• POLICY
• EPOCH_NOTARIZATION
• AGENT_ACTION
• IDENTITY_ROOT
• EXTERNAL_OBJECT_COMMITMENT

5.2 Rule

Tipul real al subiectului MUST fi derivabil sau inclus în semantica statement_type.

5.3 Composite subjects

Pentru anumite statement-uri, subject-ul MAY reprezenta un tuplu hash-uit canonic:

subject_ref = H("AZ:SUBJECT_TUPLE:" || element_1 || element_2 || ...)

Acest mecanism este permis pentru:

• approval asupra unei anumite acțiuni și sume;
• attestation legată de (machine_id, state_root);
• consent asupra (intent_id, route_hash).

6. Witness statement types

6.1 Registry

Toate statement_type folosite normativ MUST proveni dintr-un registry standardizat sau dintr-un spațiu de extensie controlat.

6.2 Statement types de bază v1

Set minim recomandat:

• approval
• rejection
• execution_log
• risk_ack
• oracle_claim
• committee_vote
• delegation_grant
• delegation_revoke
• settlement_confirmation
• compliance_flag
• halt_justification
• migration_ack
• audit_observation

6.3 Statement type semantics

Fiecare statement type MUST defini:

1. semantica exactă;
2. forma canonicală a payload-ului hash-uit;
3. condițiile minime de validitate;
4. dacă poate expira;
5. dacă poate fi revocat;
6. dacă este single-use sau reusable;
7. dacă are consecințe normative directe în politici/contracte.

7. Witness payload model

7.1 Statement hash

statement_hash MUST fi hash-ul payload-ului canonical pentru acel statement type:

statement_hash = H("AZ:STATEMENT:" || statement_type || canonical_statement_payload)

7.2 Payload canonicality

Payload-ul MUST:

• aibă schemă fixă per type/version;
• fie serializat canonic;
• nu aibă câmpuri duplicate;
• nu aibă sensuri alternative pentru aceeași reprezentare.

7.3 No free-form normative text

Text liber MAY exista în metadate off-chain, dar efectele normative MUST depinde numai de payload canonical.

8. Witness validity states

Un witness poate fi în una dintre următoarele stări logice:

• ACTIVE
• EXPIRED
• REVOKED
• SUPERSEDED
• INVALID

8.1 ACTIVE

Witnessul:

• există;
• a fost emis valid;
• nu a expirat;
• nu a fost revocat;
• nu a fost înlocuit normativ unde standardul o cere.

8.2 EXPIRED

TTL-ul sau perioada de validitate a trecut.

8.3 REVOKED

Există o revocare validă care îi anulează utilizarea normativă.

8.4 SUPERSEDED

Un witness mai nou, din aceeași familie semantică, l-a înlocuit conform standardului.

8.5 INVALID

A fost emis greșit, are proof invalid, sau nu respectă schema / policy.

9. TTL and temporal model

9.1 Validity window

Un witness MAY avea:

• issued_at_unix_ms
• valid_from_unix_ms?
• ttl_unix_ms?

Dacă valid_from nu există, witnessul este valid din momentul emiterii.

9.2 Temporal rule

Un witness poate satisface o condiție numai dacă, la punctul temporal relevant:

• este emis;
• este activ;
• nu este expirat;
• nu este revocat.

9.3 Protocol time

Validitatea temporală MUST fi evaluată folosind timpul protocolar relevant, nu interpretări locale arbitrare.

10. Revocation model

10.1 Principiu

Revocarea este separată de emitere. Un witness revocabil MUST defini cum se revocă.

10.2 Tipuri de revocare

V1 SHOULD suporta:

• issuer_revoke
• committee_revoke
• policy_revoke
• supersession_revoke
• expiry_only (non-revocable except expiration)

10.3 Revocation object

Revocarea SHOULD fi reprezentată printr-un witness special sau obiect standardizat:

WitnessRevocation {
  target_witness_id
  revoker_policy
  reason_code
  reason_hash?
  issued_at_unix_ms
}

10.4 Reguli

1. Revocarea MUST referi exact witnessul țintă.
2. revoker_policy MUST fi compatibilă cu revocation_policy al witnessului.
3. Revocarea MUST fi validată canonic.
4. O revocare invalidă MUST NOT afecta witnessul original.
5. Revocarea MAY fi ea însăși contestabilă numai dacă standardul o permite explicit.

11. Supersession model

11.1 Necesitate

Pentru anumite tipuri, un witness nou trebuie să înlocuiască unul vechi fără a-l „anula moral”.

Exemple:

• rotație de delegare;
• status mai nou;
• atestare reîmprospătată.

11.2 Regula

Dacă un statement type suportă supersession, trebuie să definească:

• cheia de supersession;
• regula de ordonare;
• cum se decide care e cel activ;
• dacă vechiul witness rămâne istoric dar neutilizabil normativ.

11.3 Exemplu

La delegation_grant, un nou grant cu același delegation_scope_key MAY supersede grantul anterior.

12. ProofBundle semantics

12.1 Definiție

Un Proof Bundle este un container standardizat pentru dovezi auxiliare validate de protocol sau de logică standardizată.

12.2 Funcții

ProofBundle poate reprezenta:

• Merkle inclusion proof;
• committee signature aggregation proof;
• oracle package proof;
• external system commitment proof;
• zero-knowledge proof;
• execution proof;
• storage proof.

12.3 Regula

Protocolul MUST ști pentru fiecare proof_type:

• schema payload-ului;
• algoritmul de verificare;
• precondițiile de validitate;
• condițiile de expirare;
• ce obiecte poate susține normativ.

13. Proof type registry

13.1 Tipuri minime v1

Set minim recomandat:

• merkle_inclusion
• committee_signature_bundle
• oracle_data_package
• state_commitment_inclusion
• external_event_commitment
• zk_claim_proof
• attestation_chain_proof

13.2 Requirements

Fiecare proof_type MUST defini:

1. verificatorul canonical;
2. schemele hash/crypto permise;
3. payload schema;
4. mărimea maximă;
5. reguli de expirare și replay protection;
6. dacă dovada e self-contained sau dependentă de blob_ref.

14. Proof validation

14.1 Regula generală

Un ProofBundle este valid numai dacă:

• schema sa e corectă;
• hash-ul payload-ului corespunde;
• verificatorul pentru tipul său returnează succes;
• orice obiect referit există și este compatibil;
• nu este expirat;
• nu este replay-uit ilegal în alt context dacă standardul interzice asta.

14.2 Replay protection

Proof-urile care sunt context-sensitive MUST ancora:

• subject;
• statement type;
• epoch/time window;
• chain/protocol domain;
• eventual machine / tx / intent id.

14.3 Invalidity

Un proof invalid face invalid:

• witnessul care îl cere;
• policy satisfaction-ul dependent de el;
• contract path-ul dependent de el.

15. Issuer model

15.1 Issuer

Un issuer este entitatea protocolară care emite witnessul. Poate fi:

• cheie singulară;
• multisig;
• committee;
• machine-authorized emitter;
• oracle set;
• delegated agent;
• governance-controlled authority.

15.2 Issuer accountability

Orice issuer normativ important MUST fi:

• identificabil prin policy;
• auditable;
• slashable sau penalizabil economic, unde aplicabil;
• capabil de revocare sau supersession conform regulilor.

15.3 Issuer classes

Clase recomandate:

• human_controlled
• committee_controlled
• machine_controlled
• oracle_controlled
• agent_controlled
• governance_controlled

16. Attestation classes

16.1 Approval attestation

Semnifică acord pentru o acțiune, obiect sau tranziție.

16.2 Fact attestation

Semnifică afirmația că un fapt este adevărat în anumite condiții. Exemplu:

• „datele sursă X la timpul T au valoarea V”.

16.3 Process attestation

Semnifică faptul că un anumit pas procedural a avut loc. Exemplu:

• KYC done, audit step completed, committee quorum reached.

16.4 Execution attestation

Semnifică faptul că un agent sau sistem a făcut o acțiune. Exemplu:

• agent executed order route Y.

16.5 Risk attestation

Semnifică asumare/confirmare de risc. Exemplu:

• user acknowledged risk limit;
• manager approved exposure cap.

17. Approval semantics

17.1 Canonical approval payload

Un approval SHOULD ancora explicit:

• cine aprobă;
• ce subiect aprobă;
• ce variantă exactă aprobă;
• ce limită aprobă;
• până când este valabilă;
• dacă este single-use sau reusable.

Exemplu conceptual:

ApprovalPayload {
  subject_ref
  scope_hash
  max_value_by_asset?
  max_loss_by_asset?
  valid_until_unix_ms?
  usage_mode
}

17.2 Usage modes

• single_use
• bounded_reuse
• until_revoked
• until_expiry

17.3 Regula

O politică care cere approval MUST specifica exact:

• issuer class acceptată;
• scope-ul;
• dacă approval-ul poate fi refolosit;
• dacă trebuie consumat logic la prima utilizare.

18. Oracle claims

18.1 Definiție

oracle_claim este o atestare despre un fapt extern sau derivat.

18.2 Payload minim

SHOULD include:

• source class
• observation time
• claim key
• claim value commitment
• freshness bound
• confidence metadata hash?
• feed sequence / nonce

18.3 Normative use

Contractele și politicile MUST fie foarte restrictive cu oracle_claim. Trebuie să definească:

• sursele acceptate;
• quorum-ul dacă sunt mai multe;
• toleranța de divergență;
• TTL-ul maxim;
• fallback behavior.

18.4 Accountability

Oracle issuerii SHOULD avea:

• bond economic;
• slashing / penalty path;
• feed ordering discipline;
• replay protection.

19. Committee votes as witness

19.1 Model

Un committee_vote witness reprezintă votul unui membru asupra unui subiect.

19.2 Aggregation

Sistemul MAY folosi:

• witnessuri individuale per vot;
• un witness agregat susținut de committee_signature_bundle.

19.3 Regula

Dacă se folosește agregare, protocolul MUST putea reconstrui:

• cine a votat;
• în ce comitet;
• pentru ce subiect;
• dacă pragul a fost atins.

20. Delegation witnesses

20.1 Delegation grant

delegation_grant exprimă că un issuer acordă unui agent sau unei politici un anumit scope.

Payload minimal:

• delegate policy root
• scope key
• allowed actions
• value caps
• time window
• journaling requirement
• halt conditions
• replay domain

20.2 Delegation revoke

delegation_revoke anulează grantul sau îl supersedează.

20.3 Rule

Un agent MAY acționa doar dacă grantul relevant este activ, neexpirat și nerevocat.

21. Execution logs for agents

21.1 Rol

execution_log este witnessul central pentru auditul agenților.

21.2 Ce trebuie să conțină

Payload-ul SHOULD ancora:

• agent_policy_ref
• action_id
• action_type
• subject_ref
• intent_ref?
• decision_hash
• input_commitment_hash
• risk_context_hash
• result_commitment_hash
• timestamp_or_epoch
• operator_scope_key

21.3 Scop

Acest log permite:

• audit post-factum;
• verificarea dacă agentul a acționat în limite;
• corelarea dintre intent, decizie, execuție și rezultat;
• dispute analysis.

21.4 Regula

Pentru clase sensibile de agenți, politicile SHOULD cere witness logging obligatoriu înainte sau după acțiune, după modelul standardizat.

22. Risk acknowledgment witnesses

22.1 Definiție

risk_ack dovedește că o parte a înțeles și a acceptat anumite limite sau expuneri.

22.2 Folosire

Poate fi cerut pentru:

• activare de strategii riscante;
• ridicare de limite;
• operațiuni cu leverage;
• actualizare de delegare.

22.3 Payload minimal

• ack_subject_ref
• risk_terms_hash
• validity window
• acknowledgment scope
• issuer identity/policy

22.4 Limită

risk_ack nu poate forța singur o acțiune economică. Doar satisface condiții necesare unde politica o cere.

23. Settlement confirmation witnesses

23.1 Definiție

settlement_confirmation afirmă că o stare de settlement extern sau intern a fost atinsă.

23.2 Utilizare

Poate fi folosit pentru:

• release de escrow;
• finalizare de livrare;
• closing de process;
• reconciliere cross-system.

23.3 Rule

Dacă settlement-ul este critic, politica SHOULD cere:

• issuer autorizat;
• proof bundle valid;
• TTL scurt;
• unicitate per subject.

24. Halt justification witnesses

24.1 Rol

halt_justification susține o acțiune de oprire de urgență.

24.2 Utilizare

Poate ancora:

• anomaly detected;
• fraud proof exists;
• oracle divergence severe;
• risk bound breached;
• compliance stop triggered.

24.3 Regula

Dacă un TX_GUARD_HALT cere justificare, witnessul de tip halt_justification MUST fi activ și compatibil cu politica de halt.

25. Audit observation witnesses

25.1 Rol

audit_observation nu implică neapărat aprobare sau respingere. El ancorează o constatare verificabilă.

25.2 Exemple

• „contract state invariant check found deviation”
• „oracle feed X diverged by Y”
• „agent exceeded non-critical threshold”

25.3 Efect normativ

Acest tip MAY avea efect doar dacă o politică sau mașină îl interpretează explicit. Altfel rămâne context verificabil.

26. Witness indexing and lookup

26.1 Indexing model

Nodurile SHOULD indexa witnessuri după:

• witness_id
• subject_ref
• issuer_policy
• statement_type
• temporal validity
• active/revoked/expired status

26.2 Lookup constraints

Contractele și politicile MUST citească witnessuri prin referințe sau query-uri bounded standardizate. V1 SHOULD evita scanarea globală nebounded.

26.3 Subject-bound lookups

Permis conceptual:

• „read witness W”
• „read active witness of type T for subject S from issuer class I within bounded candidate set”

Acest tip de query MUST fi bounded și standardizat.

27. Normative use in spend policies

27.1 Model

O spend policy MAY cere un witness. Exemplu:

• Cell poate fi cheltuit doar dacă există approval activ pentru acel subject_ref.

27.2 Requirements

Spend policy-ul MUST defini:

• statement type cerut;
• issuer/policy acceptată;
• scope matching;
• active state requirement;
• single-use or reusable semantics.

27.3 Single-use semantics

Dacă witnessul este single-use, regula de „consumare logică” MUST fi reprezentată explicit în protocol sau în maşina/politica ce îl utilizează.

28. Normative use in BVM

28.1 Model

Un contract poate:

• citi witnessuri;
• verifica statement_type și payload commitments;
• condiționa tranziția de ele;
• emite noi witnessuri.

28.2 Restrictions

Contractul MUST NOT:

• interpreta liber tipuri necunoscute;
• ignora revocation/expiry semantics dacă tipul le are;
• folosi witnessuri în afara scope-ului lor declarat.

28.3 Determinism

Orice verificare de witness în contract MUST fi derivabilă numai din obiectele canonical accesibile.

29. Chains of attestation

29.1 Necesitate

Uneori un witness este susținut de alte witnessuri sau proof-uri.

Exemplu:

• un settlement_confirmation se bazează pe oracle_claim + committee_vote.

29.2 Rule

Lanțurile de atestare sunt permise numai dacă standardul tipului definește:

• graful de dependențe;
• profunzimea maximă;
• tipurile admise;
• regula de validitate compusă.

29.3 Bound

Validation depth MUST fi bounded.

30. External object commitments

30.1 Model

Protocolul poate ancora obiecte externe prin commitment hash, fără a le importa complet în stare.

Exemple:

• document hash;
• invoice hash;
• off-chain report hash;
• storage object root.

30.2 Rule

Când un witness se referă la obiect extern, efectul normativ MUST depinde de:

• commitment-ul canonical;
• proof-ul de proveniență / integritate dacă cerut;
• issuerul și policy-ul relevante.

30.3 Interdicție

Nodul MUST NOT depinde de conținutul brut extern dacă acesta nu este ancorat prin hash/proof standardizat.

31. Visibility model

31.1 Visibility classes

• PUBLIC
• HASH_ONLY
• RESTRICTED

31.2 PUBLIC

Tot payload-ul sau forma lui relevantă este disponibilă pentru validare publică.

31.3 HASH_ONLY

Protocolul vede doar commitment-ul; efecte normative limitate. Acest tip SHOULD fi folosit numai când hash-ul și dovada externă sunt suficiente.

31.4 RESTRICTED

Conținutul poate fi accesibil numai prin mecanism controlat. V1 SHOULD limita sever utilizarea normativă a witnessurilor RESTRICTED pentru consens public.

32. Privacy constraints

32.1 Principiu

Witness Layer poate reduce expunerea, dar v1 MUST favoriza verificabilitatea.

32.2 Rules

• afirmațiile normative SHOULD fi commitment-based;
• datele sensibile SHOULD sta off-chain sau în proof-uri compacte;
• subiectele și scope-ul SHOULD rămâne suficient de precise pentru audit.

32.3 Zero-knowledge integration

zk_claim_proof MAY permite:

• verificarea unei afirmații fără dezvăluirea întregului payload;
• dar verificatorul și semantica MUST fi standardizate.

33. Accountability and penalties

33.1 Principiu

Issuerii de witnessuri critice trebuie să poată fi sancționați pentru comportament rău.

33.2 Slashable / punishable events

Exemple:

• emitere de atestări contradictorii pentru același scope exclusiv;
• emitere de oracle claims frauduloase;
• emitere de committee attestations false;
• emitere de execution logs falsificate;
• revocări neautorizate.

33.3 Consequences

Consecințele MAY include:

• slash de bond;
• revocare de rol;
• blacklist protocolară;
• downgrade de trust tier;
• audit escalation.

34. Trust tiers

34.1 Motivation

Nu toate witnessurile au aceeași greutate.

34.2 Suggested tiers

• tier_0_untrusted_context
• tier_1_signed_claim
• tier_2_bonded_issuer
• tier_3_committee_backed
• tier_4_protocol_native

34.3 Rule

Politicile și contractele SHOULD specifica tier-ul minim acceptat pentru un anumit path de decizie.

35. Multi-source corroboration

35.1 Need

Pentru afirmații sensibile, un singur issuer poate fi insuficient.

35.2 Model

O politică MAY cere:

• N witnessuri independente;
• mai multe oracle_claims;
• committee quorum;
• combinație witness + proof.

35.3 Rule

Standardul MUST defini:

• independența surselor;
• agregarea;
• toleranța de divergență;
• conflict resolution.

36. Contradiction handling

36.1 Contradictory witness

Două witnessuri pot intra în contradicție:

• approval și rejection pe același subiect/scope;
• două oracle_claims incompatibile;
• două execution logs care afirmă rezultate incompatibile.

36.2 Rule

Protocolul MUST NOT rezolva implicit contradicțiile fără regulă standardizată. Trebuie una din:

• priority by issuer class
• latest-valid supersession
• quorum aggregation
• explicit invalidation path
• conflict state requiring halt/manual governance

36.3 Security

Dacă un path critic întâlnește contradicții nerezolvate, contractele și politicile SHOULD fail closed.

37. Witness replay protection

37.1 Need

Un witness valid într-un context nu trebuie refolosit fraudulos în altul.

37.2 Anchoring

Witnessurile context-sensitive SHOULD ancora:

• subject_ref
• scope_hash
• domain separator
• chain_id / protocol_id
• time window
• usage mode
• eventual nonce

37.3 Rule

Un witness context-limited MUST NOT satisface o condiție într-un alt context.

38. Agent memory model

38.1 Role

Stratul witness permite agenților să lase urme protocolare finite și verificabile.

38.2 What can be recorded

Agenții pot ancora:

• decizia luată;
• inputurile de risc;
• contextul de piață hash-uit;
• parametrii de execuție;
• rezultatul;
• justificarea unei opriri;
• schimbarea de delegare;
• încălcarea sau near-miss a unui bound.

38.3 Why this matters

Astfel, un agent:

• nu mai este cutie neagră completă;
• poate fi auditat;
• poate fi oprit;
• poate fi comparat cu mandatul primit;
• poate lăsa traseu pentru dispute și recuperare.

39. Agent decision witness standard

39.1 Standard propus

V1 SHOULD defini un standard agent_decision_record, fie ca subtype al execution_log, fie separat.

Payload minimal:

AgentDecisionRecord {
  agent_policy_ref
  mandate_scope_hash
  decision_id
  decision_class
  input_context_hash
  candidate_actions_hash
  chosen_action_hash
  risk_snapshot_hash
  precondition_hash
  expected_outcome_hash?
  decision_epoch
}

39.2 Rule

Acest tip de witness nu obligă rețeaua să „creadă” decizia. Doar o face verificabilă și legabilă de execuția ulterioară.

40. Minimal canonical validation pipeline for witnesses

Nodul MUST valida un witness în această ordine:

1. decode canonical;
2. verify witness_id derivation;
3. verify schema for statement_type;
4. verify issuer policy existence;
5. verify issuer authorization/signature;
6. verify subject form;
7. verify proof bundle if required;
8. verify temporal validity fields;
9. verify revocation semantics fields;
10. verify replay/domain protections;
11. derive status = ACTIVE or other.

Această ordine SHOULD fi consistentă între noduri.

41. Minimal canonical validation pipeline for proof bundles

Nodul MUST valida un proof bundle în această ordine:

1. decode canonical;
2. verify payload hash;
3. verify proof_type known;
4. verify schema for proof_type;
5. verify referenced objects exist;
6. verify cryptographic proof;
7. verify expiry / freshness;
8. verify replay/domain anchoring;
9. expose proof validity result.

42. Storage and retention

42.1 Witness retention

Nodurile MAY arhiva witnessuri vechi, dar SHOULD păstra suficient pentru:

• validare a referințelor active;
• audit relevant;
• dispute windows;
• light verification.

42.2 Pruning

Witnessurile expirate și fără relevanță normativă activă MAY fi prunate din starea activă, dar SHOULD rămâne accesibile istoric dacă politica de retenție o cere.

42.3 Proof retention

Proof bundles mari MAY fi păstrate off-chain cu commitment on-chain, dacă standardul tipului o permite și verificarea rămâne posibilă.

43. Light client verification

43.1 Goal

Un light client SHOULD putea verifica:

• existența unui witness;
• emiterea sa validă;
• includerea/finalizarea sa;
• revocarea sau lipsa revocării, în limita dovezilor disponibile.

43.2 Required pieces

• witness object
• inclusion proof
• notarized epoch reference
• issuer membership/policy proof dacă necesar
• revocation status proof dacă necesar

44. Witness classes by normative strength

44.1 Informational

Fără efect direct; doar context.

44.2 Conditional

Poate satisface o precondiție în policy/contract.

44.3 Authoritative

Poate schimba o decizie normativă semnificativă prin simpla sa validitate. Exemplu:

• committee-backed approval pentru treasury release.

44.4 Critical

Folosit în procese sensibile:

• halt
• settlement release
• oracle-driven liquidation
• major delegation changes

Aceste clase SHOULD cere trust tier mai mare și dovadă mai strictă.

45. Failure modes to prevent

Stratul Witness trebuie să prevină sau să reducă:

1. atestări ambigue;
2. payload-uri necanonice;
3. replay cross-context;
4. revocări neautorizate;
5. oracle claims stale;
6. contradicții nerezolvate;
7. agent logs fără legătură cu acțiunea reală;
8. proofs opace pe care nodurile nu le pot valida;
9. folosirea hash-only ca și cum ar fi dovadă completă;
10. supraîncărcarea stării cu date brute inutile.

46. Security consequences

46.1 Dacă stratul Witness este bine definit:

• contractele pot cere dovezi finite și clare;
• agenții pot fi controlați prin jurnalizare verificabilă;
• procesele externe pot fi ancorate fără a distruge determinismul;
• contradicțiile pot fi detectate și pedepsite.

46.2 Dacă stratul Witness este vag:

• tot sistemul devine interpretabil și disputabil;
• auditul devine slab;
• agenții redevin cutii negre;
• politicile devin imposibil de verificat consistent.

47. Formula stratului Witness

Witness Layer = signed statement + canonical subject + proof linkage + validity window + revocation semantics + issuer accountability

48. Relația cu restul protocolului

• Value Layer mută valoare.
• Logic Layer schimbă stare bounded.
• Witness Layer spune ce a fost aprobat, observat, executat sau dovedit.

Pe scurt: Witness Layer este memoria verificabilă care face cooperarea dintre oameni, mașini, comitete și agenți auditable în același protocol.

49. Ce urmează

După AZ-006, documentul corect este:

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

Acolo trebuie fixate:

• tokenomics funcțional;
• fee curves;
• rent pentru stare;
• bonds pentru issueri / executori / oracles;
• recovery reserve;
• reward and penalty schedules.

Închidere

ATLAS ZERO nu tratează memoria ca pe o anexă neimportantă. O tratează ca pe un strat normativ distinct în care afirmațiile trebuie să fie:

• finite,
• semnate,
• dovedite,
• temporale,
• revocabile când este cazul,
• și suficient de clare încât o mașină și un auditor uman să ajungă la aceeași concluzie.

Acolo începe memoria verificabilă reală.