AZ-014 — Fraud Proof and Slashing Evidence Formats v1

Status

Acest document definește formatele normative pentru:

fraud proofs,
slashable evidence,
verdict derivation din evidență,
și legătura dintre dovadă și execuția penalității.

AZ-004 a definit fault-urile de consens. AZ-006 și AZ-007 au definit fault-urile de issuer/oracle/witness și penalitățile economice. AZ-013 a fixat formatul executabil BVM. AZ-014 le transformă într-un sistem probatoriu explicit.

Scopul lui este să răspundă la întrebarea: ce înseamnă că un fault este suficient de dovedit încât protocolul să poată aplica slashing deterministic, fără arbitraj manual în execuția normală?

Acest document se bazează pe:

AZ-002 până la AZ-013.

Termeni:

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

1. Obiectiv

AZ-014 răspunde la 10 întrebări:

Ce este un fraud proof și ce este slashing evidence?
Ce proprietăți trebuie să aibă o dovadă protocolară de fault?
Ce clase de fault-uri sunt demonstrabile strict on-chain/protocolar?
Ce formate canonice folosim pentru dovezi?
Cum derivăm verdictul din evidență?
Cum evităm duplicate, replay și slashing dublu?
Cum tratăm fault-urile de consens versus cele de witness/oracle/agent?
Cum legăm dovada de rol, policy, epocă și scope?
Cum este executat slash-ul?
Ce fault-uri rămân doar investigabile, nu auto-slashable?

2. Principii

2.1 Evidence must be canonical

Orice fraud proof sau slashing evidence MUST avea formă canonică, hash-uibilă și verificabilă independent.

2.2 Deterministic sufficiency

Protocolul MUST putea decide deterministic dacă o dovadă este:

suficientă,
insuficientă,
invalidă,
duplicată,
expirată pentru slashing.

2.3 No opinion-based slashing

În execuția normală, slash-ul MUST NOT depinde de:

interpretare umană ad-hoc,
mesaj text liber,
investigații off-chain neancorate,
autoritate arbitrară fără evidență protocolară.

2.4 Layer-specific evidence

Clase diferite de fault cer tipuri diferite de dovadă. Un format unic generic este insuficient.

2.5 Replay resistance

Evidența MUST ancora:

fault class,
offender identity/policy,
epoch/slot/time relevant,
objects involved,
domain separation.

2.6 One fault, bounded penalty path

Protocolul SHOULD evita:

slash multiplu accidental pentru exact aceeași încălcare,
și să lege clar evidența de penalty scope.

3. Definiții

3.1 Fraud proof

Fraud proof = pachet canonical care demonstrează că un anumit obiect, act sau combinație de acte încalcă regulile protocolului.

3.2 Slashing evidence

Slashing evidence = fraud proof sau altă evidență canonicală suficientă nu doar pentru a marca fault-ul, ci pentru a executa penalitatea economică relevantă.

3.3 Offender

Offender = actorul/policy/validator/issuer/operator identificat de dovadă ca fiind responsabil pentru fault.

3.4 Fault class

Fault class = categoria normativă a încălcării. Exemple:

proposer equivocation
notary double finalization
invalid verifier attestation
oracle contradiction
agent mandate bypass

3.5 Evidence window

Evidence window = intervalul protocolar în care o dovadă mai poate declanșa penalitate.

4. Classes of proof outcomes

Protocolul SHOULD distinge între:

FAULT_PROVEN
FAULT_NOT_PROVEN
EVIDENCE_INVALID
EVIDENCE_INSUFFICIENT
EVIDENCE_DUPLICATE
EVIDENCE_EXPIRED_FOR_SLASH
FAULT_PROVEN_ALREADY_SLASHED

Aceste stări sunt importante pentru audit și pentru a preveni penalizări incoerente.

5. Fraud proof families

ATLAS ZERO v1 SHOULD suporta cel puțin următoarele familii:

FP_PROPOSER_EQUIVOCATION
FP_VERIFIER_CONTRADICTORY_VOTES
FP_NOTARY_DOUBLE_NOTARIZATION
FP_INVALID_NOTARIZATION_SIGNATURE_SET
FP_INVALID_FRONT_REEXECUTION_CLAIM
FP_INVALID_BLOCK_CONTENT
FP_ORACLE_CONTRADICTORY_CLAIMS
FP_UNAUTHORIZED_WITNESS_EMISSION
FP_INVALID_REVOCATION
FP_AGENT_ACTION_OUTSIDE_MANDATE
FP_AGENT_LOG_FORGERY
FP_GOVERNANCE_ACTIVATION_VIOLATION
FP_DOUBLE_SLASH_ATTEMPT (defensive meta-proof)

6. Fault classes

6.1 Consensus faults

proposer equivocation in same slot
verifier contradictory vote in same scope
notary conflicting finalization for same epoch
invalid notarization support
intentionally invalid block attestation

6.2 Witness/oracle faults

contradictory claims in exclusive scope
unauthorized emission under false issuer authority
revocation without valid revoker path
stale claim misuse where standard makes freshness mandatory

6.3 Agent faults

valid-looking action outside mandate scope
execution after revoke/halt
forged or mismatched execution log
deliberate journaling bypass where normatively required

6.4 Governance faults

activation before timelock
activation with missing required review/quorum path
emergency action beyond allowed scope

6.5 VM/validation faults

Unele buguri de validare/VM nu sunt auto-slashable pentru actori individuali, ci incident classes. Acestea nu trebuie confundate cu fault-uri individual penalizabile.

7. Evidence object model

7.1 Core structure

Orice evidență slashable SHOULD deriva dintr-un obiect canonical generic:

SlashingEvidenceEnvelope {
  version_major
  version_minor

  evidence_id
  fault_family
  offender_ref
  offender_role_class
  scope_ref
  time_scope
  evidence_payload_hash
  supporting_object_refs
  reporter_policy?
  submitted_at_epoch
}

7.2 evidence_id

evidence_id = H("AZ:SLASH_EVIDENCE:" || canonical_envelope_body)

7.3 offender_role_class

Exemple:

proposer
verifier
notary
oracle_issuer
witness_issuer
agent_operator
governance_actor
committee_member

7.4 scope_ref

Poate ancora:

slot
epoch
subject_ref
mandate_id
proposal_id
committee_root
feed scope în funcție de fault family.

8. Time scope model

8.1 Structure

EvidenceTimeScope {
  epoch_index?
  round_index?
  slot_index?
  issued_at_unix_ms?
  valid_fault_window_start?
  valid_fault_window_end?
}

8.2 Rule

Fiecare family MUST define exact ce câmpuri sunt obligatorii.

8.3 Purpose

Time scope-ul permite:

replay protection
duplicate detection
expiry handling pentru penalitate

9. Supporting object references

9.1 Need

Evidența nu trebuie să includă mereu toate obiectele inline. Poate referi obiecte deja existente.

9.2 Allowed refs

block_id
tx_id
vote object id
witness_id
notarization id
machine_call id
governance outcome/activation id
proof bundle id
policy object id

9.3 Rule

Dacă supporting refs nu sunt suficiente pentru reconstruirea verificării, evidența este insuficientă.

10. Reporter model

10.1 Reporter

Un reporter MAY trimite evidență, dar adevărul fault-ului nu trebuie să depindă de identitatea reporterului.

10.2 Reporter rewards

Reporterul poate primi reward dacă:

evidența este validă;
fault-ul era nepenalizat;
raportarea cade în fereastra relevantă.

10.3 Rule

Reporter identity MUST NOT schimba verdictul de validitate al dovezii.

11. Family-specific payloads overview

Fiecare fault_family MUST defini propriul payload canonical. Envelope-ul generic doar încadrează dovada.

12. FP_PROPOSER_EQUIVOCATION

12.1 Fault definition

Același proposer produce două blocuri incompatibile pentru același slot și aceeași autoritate de rol.

12.2 Payload

ProposerEquivocationPayload {
  proposer_id
  epoch_index
  slot_index
  block_a_id
  block_b_id
  block_a_header_hash
  block_b_header_hash
  proposer_signature_a
  proposer_signature_b
}

12.3 Sufficient proof conditions

Fault-ul este dovedit dacă:

ambele blocuri sunt semnate valid de același proposer role key;
ambele declară același epoch/slot relevant;
blocurile sunt distincte;
blocurile sunt incompatibile după regula protocolului.

12.4 Notes

Incompatibilitatea poate fi:

parent divergence relevantă,
content divergence,
front incompatibility în același slot scope.

13. FP_VERIFIER_CONTRADICTORY_VOTES

13.1 Fault definition

Același verifier semnează două voturi incompatibile în același scope normativ.

13.2 Payload

VerifierContradictoryVotesPayload {
  verifier_id
  vote_a_id
  vote_b_id
  vote_a_scope_hash
  vote_b_scope_hash
  vote_a_signature
  vote_b_signature
}

13.3 Proof conditions

Trebuie demonstrat:

ambele voturi sunt autentice;
aparțin aceluiași verifier;
scope-ul exclusiv relevant este același;
verdicturile sunt incompatibile (VALID vs INVALID, sau două FRONT_VALID incompatibile).

14. FP_NOTARY_DOUBLE_NOTARIZATION

14.1 Fault definition

Același notary semnează două notarizări incompatibile pentru aceeași epocă.

14.2 Payload

NotaryDoubleNotarizationPayload {
  notary_id
  epoch_index
  notarization_a_id
  notarization_b_id
  front_commitment_hash_a
  front_commitment_hash_b
  signature_a
  signature_b
}

14.3 Proof conditions

Trebuie demonstrat:

același notary a semnat ambele obiecte;
aceeași epocă;
fronturi incompatibile;
ambele semnături sunt valide.

15. FP_INVALID_NOTARIZATION_SIGNATURE_SET

15.1 Fault definition

O notarizare pretinde threshold atins, dar setul de semnături este invalid.

15.2 Payload

InvalidNotarizationSignatureSetPayload {
  notarization_id
  claimed_committee_root
  signature_bundle_ref
  invalid_member_refs?
  missing_threshold_proof?
}

15.3 Important distinction

Acest fault poate dovedi că notarizarea este invalidă. Nu întotdeauna identifică singur toți actorii slashabili. Poate necesita derivare suplimentară:

semnături false,
membri neeligibili,
threshold miscount.

15.4 Outcome

Poate produce:

invalidare notarizare,
eventual slash pentru semnatarii frauduloși sau assembler-ul relevant dacă regula o prevede.

16. FP_INVALID_FRONT_REEXECUTION_CLAIM

16.1 Fault definition

Un front/notarizare pretinde anumite rădăcini finale care nu rezultă din reexecutare.

16.2 Payload

InvalidFrontReexecutionPayload {
  notarization_id
  front_commitment_hash
  expected_state_root_claimed
  reproduced_state_root
  divergence_proof_hash
}

16.3 Rule

Pentru consens normal, astfel de dovadă SHOULD fi derivabilă din:

front objects,
state checkpoint anterior,
parameter state activ,
deterministic replay.

16.4 Slashability

Dacă se demonstrează că un notary a semnat o notarizare nereexecutabilă, aceasta poate susține slash.

17. FP_INVALID_BLOCK_CONTENT

17.1 Fault definition

Un actor a validat sau a produs bloc cu conținut demonstrabil invalid.

17.2 Payload

InvalidBlockContentPayload {
  block_id
  invalid_object_ref
  invalidity_class
  invalidity_proof_hash
  related_signer_ref?
}

17.3 Slashability nuance

Simpla existență a unui bloc invalid nu înseamnă automat slash pentru toți cei care l-au propagat. Trebuie identificat actorul slashabil:

proposer,
verifier care l-a validat explicit,
notary care l-a folosit fraudulos.

18. FP_ORACLE_CONTRADICTORY_CLAIMS

18.1 Fault definition

Același oracle issuer emite două oracle_claim incompatibile pentru același scope exclusiv.

18.2 Payload

OracleContradictoryClaimsPayload {
  issuer_policy_ref
  witness_a_id
  witness_b_id
  claim_scope_hash
  claim_a_value_hash
  claim_b_value_hash
}

18.3 Conditions

Trebuie demonstrat:

același issuer;
același scope exclusiv;
claim-uri incompatibile;
ambele active/legitimate enough to conflict.

18.4 Scope examples

same feed key
same observation time bucket
same asset pair
same source class

19. FP_UNAUTHORIZED_WITNESS_EMISSION

19.1 Fault definition

Un witness a fost emis fără issuer authority validă.

19.2 Payload

UnauthorizedWitnessEmissionPayload {
  witness_id
  issuer_policy_ref
  missing_or_invalid_authorization_hash
}

19.3 Outcome

Poate duce la:

witness invalidation,
slash pentru issuer/operator dacă rolul era bonded și fault-ul este culpabil.

20. FP_INVALID_REVOCATION

20.1 Fault definition

O revocare încearcă să anuleze un witness fără revocation authority validă.

20.2 Payload

InvalidRevocationPayload {
  revocation_object_ref
  target_witness_id
  claimed_revoker_policy
  revocation_mismatch_hash
}

20.3 Outcome

revocarea este invalidă;
actorul poate fi slashat dacă rolul și politica o permit.

21. FP_AGENT_ACTION_OUTSIDE_MANDATE

21.1 Fault definition

Un agent/operator a emis o acțiune care depășește mandatul activ.

21.2 Payload

AgentActionOutsideMandatePayload {
  mandate_id
  agent_policy_ref
  action_ref
  violated_constraint_class
  mandate_snapshot_hash
  action_projection_hash
}

21.3 Constraint classes

action outside scope
notional cap exceeded
exposure cap exceeded
action while suspended/revoked/halted
forbidden counterparty/domain
missing required approval witness

21.4 Conditions

Trebuie demonstrat:

mandatul relevant;
acțiunea exactă;
regula încălcată;
faptul că încălcarea e determinist verificabilă.

22. FP_AGENT_LOG_FORGERY

22.1 Fault definition

Execution log sau decision record falsificat, contradictoriu cu acțiunea sau cu obiectele reale.

22.2 Payload

AgentLogForgeryPayload {
  log_witness_id
  referenced_action_id
  action_ref
  mismatch_class
  mismatch_hash
}

22.3 Mismatch examples

log says action A, tx shows action B
log says within cap, actual route exceeds cap
log says mandate X, actual action bound to mandate Y or none

23. FP_GOVERNANCE_ACTIVATION_VIOLATION

23.1 Fault definition

O activare de guvernanță este aplicată deși:

timelock nu a expirat,
challenge valid a blocat-o,
review obligatoriu lipsește,
quorum profile nu este satisfăcut.

23.2 Payload

GovernanceActivationViolationPayload {
  activation_id
  proposal_id
  violated_rule_class
  expected_activation_boundary
  observed_activation_boundary
  governance_state_hash
}

23.3 Outcome

Poate invalida activarea și, unde rolul bonded o justifică, susține penalizare pentru actorii responsabili.

24. FP_DOUBLE_SLASH_ATTEMPT

24.1 Purpose

Meta-fault defensiv. Dovedește că aceeași evidență sau același fault semantic este folosit pentru o penalizare duplicată nepermisă.

24.2 Payload

DoubleSlashAttemptPayload {
  evidence_id
  prior_slash_record_id
  new_slash_attempt_ref
  duplication_scope_hash
}

24.3 Outcome

Trebuie prevenită dublă penalizare pentru exact aceeași încălcare, dacă politica de penalizare nu permite multiplicitate.

25. Slash record model

25.1 Need

După fault proven, protocolul trebuie să păstreze dovada că penalitatea a fost aplicată.

25.2 Structure

SlashRecord {
  slash_record_id
  evidence_id
  offender_ref
  offender_role_class
  fault_family
  penalty_class
  slash_amounts_by_asset
  reward_to_reporter_by_asset?
  burn_amounts_by_asset?
  reserve_amounts_by_asset?
  applied_at_epoch
}

25.3 slash_record_id

slash_record_id = H("AZ:SLASH_RECORD:" || canonical_slash_record)

25.4 Rule

SlashRecord MUST fi canonical, replayable și indexabil pentru duplicate prevention.

26. Penalty classes

26.1 Classes

ATLAS ZERO SHOULD standardiza:

PENALTY_MINOR
PENALTY_MAJOR
PENALTY_BYZANTINE
PENALTY_ADMINISTRATIVE_INVALIDATION_ONLY

26.2 Mapping

Fiecare fault_family MUST avea:

penalty class implicită,
sau regulă clară de derivare din context/severity.

26.3 Rule

Penalty mapping MUST fi deterministic.

27. Evidence sufficiency rules

27.1 Every family MUST define:

minimum objects required
minimum signatures/proofs required
exact contradiction/exclusivity condition
time window requirements
offender identity binding rule
slashability rule
invalidation-only vs slashable distinction

27.2 Rule

Dacă oricare componentă critică lipsește, verdictul este EVIDENCE_INSUFFICIENT, nu FAULT_NOT_PROVEN.

28. Evidence validation pipeline

28.1 Canonical pipeline

Orice evidență SHOULD fi validată în această ordine:

canonical decode
evidence_id derivation
fault_family known
offender binding check
time scope validation
supporting object existence check
per-family structural validation
cryptographic/signature verification
exclusivity/contradiction/reexecution test
duplicate/slash-history check
evidence window check
verdict derivation

28.2 Rule

Această ordine SHOULD fi urmată consistent între implementări.

29. Duplicate detection

29.1 Need

Același fault poate fi raportat de mai mulți reporteri.

29.2 Duplicate classes

exact same evidence object
semantically same fault with reordered payload
same underlying contradiction represented through different wrapper objects

29.3 Rule

Protocolul SHOULD defini un fault_fingerprint per family:

fault_fingerprint = H("AZ:FAULT_FP:" || canonical_family_specific_core)

29.4 Purpose

fault_fingerprint ajută la:

duplicate suppression
single reward grant
avoiding double slash

30. Evidence windows

30.1 Need

Nu orice fault trebuie slashable la infinit.

30.2 Rules

Fiecare family MUST defini:

evidence admissibility window
slashing eligibility window
archival relevance window

30.3 Examples

consensus double-signing: lung, dar bounded
oracle contradiction: mediu, în funcție de feed freshness
mandate violation: suficient pentru audit și bond slash
governance activation violation: până la stabilizarea regimului activ relevant

31. Invalidation-only vs slashable evidence

31.1 Important distinction

Unele dovezi arată că un obiect este invalid, dar nu identifică suficient de clar un actor slashabil.

31.2 Examples

malformed notarization object may invalidate finalization candidate
malformed block may invalidate block, but not always prove malicious verifier fault

31.3 Rule

Protocolul MUST distinge:

OBJECT_INVALIDATED
ACTOR_FAULT_PROVEN

Doar al doilea poate duce direct la slashing.

32. Reexecution-based proofs

32.1 Need

Anumite fault-uri se dovedesc prin replay determinist.

32.2 Conditions

Un reexecution-based proof este suficient doar dacă:

pre-state este canonical cunoscută;
parameter state este cunoscută;
object set este complet;
reproducerea este deterministică.

32.3 Uses

invalid front reexecution claim
governance activation boundary mismatch
agent action constraint breach if derived from canonical state

33. Signature-based contradiction proofs

33.1 Pattern

Cele mai curate fault-uri slashable sunt contradicțiile semnate.

33.2 Generic condition

Trebuie demonstrate:

aceeași role key/policy
același exclusivity scope
două mesaje incompatibile
semnături valide

33.3 Families

proposer equivocation
verifier contradictory votes
notary double notarization
oracle contradictory claims
possibly committee contradictory attestations

34. Scope exclusivity model

34.1 Need

Nu orice două mesaje diferite sunt incompatibile. Trebuie definit scope-ul exclusiv.

34.2 Generic structure

ExclusivityScope {
  domain_class
  scope_hash
}

34.3 Examples

same slot for proposer
same epoch for notary finalization
same feed key + time bucket for oracle
same proposal/chamber/ballot scope for governance vote if exclusive
same mandate + action_id for agent log

34.4 Rule

Fără exclusivity scope bine definit, fault-ul contradictoriu nu este suficient demonstrat.

35. Evidence serialization and hashing

35.1 Canonical encoding

Toate payload-urile MUST folosi encoding canonical protocolar.

35.2 Family-specific hashes

Se recomandă:

family_payload_hash = H("AZ:FP:<FAMILY_NAME>:" || canonical_payload)

35.3 Envelope hash

evidence_id MUST hash-ui doar envelope-ul canonic. fault_fingerprint MUST hash-ui contradicția semantică de bază.

36. Slashing execution model

36.1 Abstract function

ApplySlashingEvidence(State S, Evidence E) ->
  (State S', SlashRecord R) | EvidenceVerdict

36.2 Preconditions

evidence proven
evidence within slashing window
no prior slash for same fault_fingerprint unless multiplicity allowed
offender has slashable stake/bond/reward available or recoverable path

36.3 Effects

May include:

reduce stake
reduce role-specific bond
seize pending rewards
mark offender suspended/quarantined
emit slash record
reward reporter
update slash history index

37. Slash history index

37.1 Need

Trebuie prevenită reaplicarea aceleiași penalități.

37.2 Structure

SlashHistoryIndexEntry {
  fault_fingerprint
  offender_ref
  slash_record_id
  penalty_class
  applied_at_epoch
}

37.3 Rule

Slash execution MUST consult slash history before applying new penalty.

38. Reward-to-reporter rules

38.1 Conditions

Reporter reward MAY fi acordat dacă:

evidence verdict = FAULT_PROVEN
no prior accepted equivalent reporter reward
reporter not same as offender in disallowed self-report scenarios unless constitution allows
reward window active

38.2 Anti-farming

Protocolul SHOULD prevent:

duplicate reward claims
trivial rewrapping of same evidence
reward races that create inconsistent state

39. Partial evidence and escalation

39.1 Need

Uneori există suspiciune puternică, dar nu suficientă dovadă pentru auto-slash.

39.2 Outcome

Protocolul MAY emit:

invalidation,
quarantine hint,
audit_observation,
emergency review trigger, fără slashing imediat.

39.3 Rule

Insuficiența probatorie MUST NOT fi „rotunjită” la slash.

40. Evidence against committees

40.1 Committee-level contradiction

Unele fault-uri implică grupuri:

invalid committee signature bundle
threshold claimed with invalid members
committee contradictory attestation set

40.2 Rule

Dovada SHOULD permite derivarea responsabilității individuale acolo unde posibil. Slashing colectiv opac SHOULD fi evitat dacă identitatea membrilor poate fi determinată.

41. Governance-related slashing evidence nuances

41.1 Caution

Nu toate erorile de guvernanță sunt auto-slashable. Unele sunt:

procedural invalidations,
constitutional inadmissibility,
review failures, fără offender singular clar.

41.2 Slashable subset

Slash should apply only where:

actorul a semnat explicit o activare/vot/review incompatibilă sau frauduloasă;
rolul este bonded/slashable;
încălcarea este determinist probată.

42. Evidence windows by family (recommended)

42.1 Long window

proposer equivocation
verifier contradictory votes
notary double notarization

42.2 Medium window

oracle contradictory claims
unauthorized witness emission
invalid revocation

42.3 Medium/short depending on mandate lifecycle

agent action outside mandate
agent log forgery

42.4 Structural/governance window

governance activation violation poate necesita fereastră suficientă până la stabilizarea regimului activ și audit.

43. Canonical evidence examples

43.1 EX-FP-001

Two proposer-signed blocks with same slot and different block ids.

43.2 EX-FP-002

Same verifier signs BLOCK_VALID and BLOCK_INVALID for same block.

43.3 EX-FP-003

Same notary signs two notarizations for same epoch with different front commitments.

43.4 EX-FP-004

Oracle issuer emits two active conflicting claims for same feed scope.

43.5 EX-FP-005

Agent submits action under revoked mandate; evidence includes mandate status and action ref.

43.6 EX-FP-006

Slash duplication attempt against already consumed fault_fingerprint.

44. Integration with AZ-011 vectors

44.1 Conformance suites MUST include:

valid fraud proof accepted
malformed evidence rejected
insufficient evidence classified correctly
duplicate evidence identified
slash record produced exactly once
reporter reward logic deterministic
expired evidence no-slash but auditable
invalidation-only proof not over-slashing

44.2 Cross-implementation requirement

Implementări conforme MUST agree on:

evidence verdict
fault_fingerprint
slash applicability
slash amount inputs
slash record hash

45. Security considerations

45.1 Dangerous anti-patterns

Implementers SHOULD avoid:

using text explanations as primary evidence
slashing on object invalidity without offender binding
not anchoring exclusivity scope
treating stale evidence as timeless
allowing multiple slash records for one fault without rule
rewarding duplicate reporters repeatedly
accepting reexecution proofs without full context
conflating node-local suspicion with protocol proof
allowing governance body to slash without evidence path in normal flow
making evidence hashing depend on noncanonical serialization

45.2 Principle

Fraud proofs should be boringly precise. If a proof is dramatic but not canonical, it is not protocol evidence.

46. Formal goals

AZ-014 urmărește aceste obiective:

46.1 Proof soundness

Dacă verdictul este FAULT_PROVEN, evidența este suficientă pentru a demonstra încălcarea conform specificației.

46.2 Proof completeness for supported families

Pentru familiile suportate, fault-urile relevante SHOULD fi reprezentabile prin evidență canonicală.

46.3 Single-application penalty safety

Același fault semantic nu produce penalitate multiplă accidentală.

46.4 Role-attributed accountability

Penalitatea poate fi legată de actorul slashabil corect.

47. Formula documentului

Fraud/Slashing Layer = canonical evidence + offender binding + exclusivity scope + deterministic verdict + bounded penalty execution

48. Relația cu restul suitei

AZ-004 a spus ce fault-uri de consens sunt relevante.
AZ-006 și AZ-008 au spus ce fault-uri de witness/oracle/agent sunt relevante.
AZ-007 a spus cum se calculează penalitatea.
AZ-014 spune ce dovadă exactă pornește penalitatea și cum evităm arbitrarul.

Pe scurt: fără AZ-014, slashing-ul rămâne idee. Cu AZ-014, devine procedură protocolară.

49. Ce urmează

După AZ-014, documentul corect este:

AZ-015 — Incident Response and Recovery Runbooks

Acolo trebuie fixate:

clasele de incidente,
pașii operaționali,
când se intră în safe mode,
când se cere emergency action,
cum se reconstruiește starea și serviciul după incident.

Închidere

Un protocol cu slashing, dar fără format exact de dovadă, este încă la nivel de intenție. Un protocol matur spune exact: ce trebuie prezentat, cum se verifică, când este suficient, cui i se aplică penalitatea și de ce aceeași încălcare nu poate fi pedepsită la infinit prin ambiguitate.

Acolo începe răspunderea protocolară reală.