AZ-041 — Economic Attack Simulation and Red-Team Evaluation Protocol v1

Status

Acest document definește protocolul pentru:

• simularea atacurilor economice;
• evaluarea adversarială de tip red-team;
• metricile de impact economic și protocolar;
• transformarea rezultatelor în update-uri de risk canon, conformance, rollout și guvernanță.

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

• specificația protocolului și a subsistemelor;
• economia, witness/proof, guvernanța și controlul agenților;
• launch discipline, monitoring, archive și audit export;
• threat model canon și formal conformance claim framework.

AZ-041 răspunde la întrebarea: cum evaluăm adversarial reziliența economică și comportamentul sistemului sub presiune strategică, astfel încât să distingem între modele de atac teoretice, atacuri plauzibile și atacuri suficient de ieftine sau profitabile încât să devină blocker pentru launch, upgrade sau parametri activi?

Scopul documentului este să fixeze:

• taxonomia atacurilor economice relevante;
• scenariile și mediile de simulare;
• obiectivele red-team;
• metricile de succes și eșec;
• modelele de raportare și triage;
• și cum se traduc rezultatele în residual risk updates, conformance additions, restricții de rollout sau modificări de parametri.

Acest document se bazează pe:

• AZ-002 până la AZ-040, cu accent direct pe AZ-006, AZ-007, AZ-008, AZ-009, AZ-011, AZ-017, AZ-027, AZ-039 și AZ-040.

Termeni:

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

1. Obiectiv

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

1. Ce este un atac economic în ATLAS ZERO?
2. Ce clase de atac merită simulate sistematic?
3. Ce înseamnă red-team evaluation în context protocolar și economic?
4. Ce metrici măsoară succesul sau eșecul unui atac?
5. Cum diferențiem presiune normală de piață, spam, griefing și exploit economic?
6. Cum construim scenarii reproductibile și comparabile?
7. Ce rezultate schimbă threat canon-ul și residual risk canon-ul?
8. Când un rezultat devine blocker pentru launch, upgrade sau activare de parametri?
9. Cum legăm simulările de corpusul de conformitate și de policy?
10. Cum evităm atât complacerea teoretică, cât și teatralizarea red-team fără valoare măsurabilă?

2. Principii

2.1 Economic safety must be tested as adversarial behavior, not only reasoned statically

Siguranța economică MUST fi testată sub comportamente strategice, nu doar argumentată intuitiv.

2.2 Profitability and damage are distinct

Un atac poate fi:

• profitabil pentru adversar;
• neprofitabil, dar devastator;
• ieftin, dar cu impact operațional mare;
• scump, dar realist pentru anumite adversary classes. Toate aceste variante contează.

2.3 Simulation is evidence, not truth by itself

Simulările produc dovezi utile, dar nu echivalează singure cu garanție absolută. Ele trebuie integrate în threat canon și residual risk canon.

2.4 Red-team must be scope-bound and explicit

Evaluările red-team MUST spune:

• ce atac încearcă;
• ce active vizează;
• ce presupuneri fac;
• ce capabilități au;
• și ce înseamnă succesul.

2.5 Failure to break is not proof of safety

Faptul că un scenariu nu a produs atac reușit nu dovedește automat siguranța completă. Poate însemna și:

• model incomplet;
• capabilitate insuficientă;
• metrici greșite;
• sau acoperire limitată.

2.6 Results must feed decisions

Rezultatele serioase SHOULD actualiza:

• threat model;
• residual risks;
• parametri economici;
• rollout restrictions;
• conformance corpus;
• operator guidance;
• și eventual policy sau governance.

3. Evaluation scope

3.1 The protocol SHOULD evaluate at minimum:

• spam and congestion attacks
• fee-market manipulation
• rent evasion or griefing
• validator incentive manipulation
• witness/proof incentive abuse
• MEV-like ordering or extraction surfaces if relevant
• governance incentive distortion
• upgrade or launch-time economic abuse
• liquidity or treasury pressure scenarios if protocol-relevant

3.2 Rule

Economic evaluation MUST be tied to actual active or planned protocol surfaces, not fantasy-only attack catalogs.

4. Attack taxonomy

4.1 Recommended economic attack classes

ATLAS ZERO SHOULD support at least:

• EAT_SPAM_DOS
• EAT_FEE_MARKET_MANIPULATION
• EAT_RENT_EVASION
• EAT_STORAGE_BLOAT_GRIEFING
• EAT_VALIDATOR_INCENTIVE_DISTORTION
• EAT_SLASHING_EVASION_OR_GRIEFING
• EAT_WITNESS_REWARD_ABUSE
• EAT_PROOF_VERIFICATION_COST_ASYMMETRY
• EAT_GOVERNANCE_BRIBE_OR_CAPTURE
• EAT_TREASURY_OR_ALLOCATION_ABUSE
• EAT_AGENT_MANDATE_ECONOMIC_BYPASS
• EAT_UPGRADE_WINDOW_ARBITRAGE
• EAT_LAUNCH_WINDOW_ECONOMIC_DISRUPTION

4.2 Rule

Attack class MUST be explicit in simulation and red-team records.

5. Economic adversary classes

5.1 Recommended adversary classes

• EADV_LOW_CAPITAL_SPAMMER
• EADV_RATIONAL_PROFIT_MAXIMIZER
• EADV_GRIEFER
• EADV_WELL_CAPITALIZED_VALIDATOR
• EADV_COLLUDING_VALIDATOR_GROUP
• EADV_EXTERNAL_MARKET_ACTOR
• EADV_BRIBE_COORDINATOR
• EADV_PROTOCOL_INSIDER_WITH_TIMING_EDGE
• EADV_WITNESS_ISSUER_ABUSER
• EADV_AGENT_OPERATOR_ABUSER

5.2 Rule

Economic scenarios SHOULD declare adversary class and available budget/capabilities.

6. Asset classes under economic attack

6.1 Economic evaluation SHOULD tie attacks to affected assets such as:

• finality and liveness
• execution throughput
• fee predictability
• state growth and storage cost integrity
• validator incentive health
• witness/proof market integrity
• treasury and reserve safety
• governance legitimacy
• operator cost sustainability
• upgrade/launch operational stability

6.2 Rule

Attack records MUST identify targeted assets explicitly.

7. Simulation environment classes

7.1 Recommended environment classes

• SIM_ANALYTIC_MODEL
• SIM_AGENT_BASED
• SIM_DISCRETE_EVENT
• SIM_PROTOCOL_REPLAY_PLUS_ATTACKER
• SIM_TESTNET_EXERCISE
• SIM_HYBRID_MODEL

7.2 Meaning

SIM_ANALYTIC_MODEL

Closed-form or reduced model.

SIM_AGENT_BASED

Strategic agents with policies and budgets.

SIM_DISCRETE_EVENT

Event-based system simulation over time.

SIM_PROTOCOL_REPLAY_PLUS_ATTACKER

Replay of realistic system traces with injected attacker actions.

SIM_TESTNET_EXERCISE

Live but controlled execution in public/internal testnet.

SIM_HYBRID_MODEL

Combination of the above.

7.3 Rule

Serious claims SHOULD prefer more than one environment class where feasible.

8. Red-team evaluation classes

8.1 Recommended classes

• RT_DESIGN_REVIEW_ATTACK
• RT_SIMULATED_STRATEGY_ATTACK
• RT_OPERATOR_PLAYBOOK_ATTACK
• RT_TESTNET_STRESS_CAMPAIGN
• RT_UPGRADE_ROLLOUT_ATTACK
• RT_GOVERNANCE_GAME_THEORY_ATTACK
• RT_POST_INCIDENT_COUNTERFACTUAL

8.2 Rule

Red-team exercises MUST be typed and scoped, not vague “try to break it” exercises.

9. Scenario object model

9.1 Canonical structure

EconomicAttackScenario {
  version_major
  version_minor

  scenario_id
  attack_class
  adversary_class
  target_asset_root
  environment_class
  protocol_scope_hash
  parameter_profile_hash
  capability_profile_hash
  success_metric_root
  failure_metric_root?
  notes_hash?
}

9.2 Rule

Scenario MUST be deterministic enough to rerun or compare.

10. Protocol scope hash

10.1 Protocol scope SHOULD bind:

• protocol version
• feature profile
• economics profile
• validator set assumptions
• witness/proof families active
• governance mode assumptions
• release or upgrade scope if relevant

10.2 Rule

An economic result without protocol scope is weak and not portable.

11. Capability profile

11.1 Canonical structure

EconomicCapabilityProfile {
  capability_profile_id
  budget_class
  liquidity_profile_hash?
  validator_influence_class?
  network_timing_advantage_class?
  key_access_class?
  collusion_size_class?
  external_market_leverage_class?
}

11.2 Rule

Economic attacks SHOULD model not only raw capital but also timing, coordination and privilege edges.

12. Metric families

12.1 Recommended metric families

• attacker_profit
• attacker_cost
• victim_cost
• network_latency_impact
• finality_delay
• state_growth_delta
• fee_distortion
• validator_reward_distortion
• slash_exposure_shift
• governance_outcome_bias
• treasury_drain_or_exposure
• operator_overhead_delta
• recovery_cost_delta

12.2 Rule

Each scenario SHOULD define which metrics are primary and which are secondary.

13. Success and failure metrics

13.1 Attack success SHOULD be typed, e.g.:

• profit_positive
• liveness_broken
• finality materially delayed
• operator costs materially inflated
• governance outcome biased
• treasury or reserves exposed
• spam costs below acceptable deterrence threshold
• witness rewards extracted illegitimately
• slash deterrence neutralized

13.2 Rule

“Attack succeeded” MUST map to explicit metric thresholds, not intuition.

14. Metric threshold object

14.1 Canonical structure

EconomicMetricThreshold {
  threshold_id
  metric_name_hash
  threshold_class
  value_hash
  comparison_mode
  observation_window_hash
}

14.2 threshold_class examples

• success
• warning
• blocker
• residual_risk_update
• monitoring_followup

14.3 comparison_mode examples

• greater_than
• less_than
• between
• ratio_over
• percentile_over

14.4 Rule

Thresholds MUST be declared before scenario result classification.

15. Simulation run object

15.1 Canonical structure

EconomicSimulationRun {
  run_id
  scenario_id
  run_class
  environment_version_hash
  input_seed_hash?
  started_at_unix_ms
  completed_at_unix_ms?
  result_root
  result_class
  notes_hash?
}

15.2 run_class

• baseline
• adversarial
• sensitivity_sweep
• stress
• regression_retest
• calibration

15.3 result_class

• inconclusive
• benign
• degraded
• attack_viable
• attack_profitable
• blocker

15.4 Rule

Baseline and adversarial runs SHOULD be comparable, not isolated anecdotes.

16. Result object

16.1 Canonical structure

EconomicSimulationResult {
  result_id
  scenario_id
  primary_metric_root
  secondary_metric_root?
  verdict_class
  evidence_root?
}

16.2 verdict_class

• no_material_issue
• issue_bounded
• exploit_path_plausible
• exploit_path_viable
• exploit_path_blocker
• needs_more_modeling

16.3 Rule

Results SHOULD separate “plausible” from “profitable” and from “blocker”.

17. Sensitivity analysis

17.1 Need

Economic attacks depend heavily on parameter ranges.

17.2 The framework SHOULD support sensitivity sweeps across:

• fee parameters
• rent parameters
• reward ratios
• slash ratios
• validator concentration assumptions
• message load assumptions
• witness reward sizes
• governance quorum assumptions
• market liquidity assumptions

17.3 Rule

A single-point result SHOULD NOT dominate policy if sensitivity is high and unexplored.

18. Red-team objective model

18.1 Canonical structure

RedTeamObjective {
  objective_id
  target_asset_root
  target_metric_root
  desired_outcome_class
  stop_condition_root
}

18.2 desired_outcome_class examples

• profitable_spam
• cheap_finality_disruption
• governance_bias
• slash_deterrence_bypass
• treasury_exposure
• witness_reward_abuse
• upgrade_disruption

18.3 Rule

Red-team objectives MUST be explicit and measurable.

19. Red-team exercise object

19.1 Canonical structure

RedTeamEvaluationRecord {
  evaluation_id
  evaluation_class
  objective_root
  scenario_root
  operator_or_team_scope_hash
  time_window_hash
  result_root
  findings_root?
  timestamp_unix_ms
}

19.2 Rule

Red-team outputs SHOULD be archivable and linked to threat canon.

20. Economic blocker criteria

20.1 A scenario or red-team result SHOULD be blocker-worthy when:

• attack is cheap enough relative to plausible adversary budget and impact is high;
• attack breaks liveness or finality under realistic assumptions;
• attacker profit remains positive across meaningful sensitivity range;
• deterrence assumptions fail materially;
• governance capture or bribery becomes too cheap;
• launch/upgrade window disruption is plausible and severe.

20.2 Rule

Blocker classification SHOULD be explicit and not delayed by rhetorical minimization.

21. Non-blocker but important findings

21.1 Some results may not block launch but SHOULD still trigger:

• residual risk updates
• monitoring threshold updates
• parameter tuning proposals
• operator guidance changes
• conformance additions
• public testnet campaigns

21.2 Rule

Important economic weaknesses SHOULD not vanish merely because they are not immediate blockers.

22. Relationship to threat canon

22.1 Every serious simulation or red-team result SHOULD map to:

• one or more threat classes
• one or more control records
• one or more residual risk records
• one or more risk review triggers

22.2 Rule

Economic evaluation without risk-canon integration is incomplete.

23. Relationship to residual risk canon

23.1 Results SHOULD be able to:

• create new residual risks
• lower confidence in previously accepted risks
• retire residual risks if evidence strongly supports mitigation
• convert open_unknown into bounded_known_gap

23.2 Rule

Residual risk canon MUST be updated when economic findings materially change posture.

24. Relationship to conformance corpus

24.1 Some economic attack findings SHOULD create:

• regression cases
• parameter-boundary cases
• anti-spam validation cases
• upgrade or governance boundary cases
• operator checklist updates

24.2 Rule

Even though many economic attacks are system-level, parts of them SHOULD still feed conformance and regression protection where possible.

25. Relationship to launch readiness

25.1 Before launch, serious economic evaluation SHOULD test:

• spam deterrence sufficiency
• validator incentive health
• witness/proof reward abuse surfaces
• governance capture cost assumptions
• treasury exposure under launch configuration
• early-mainnet disruption scenarios

25.2 Rule

Launch readiness SHOULD consume economic evaluation evidence explicitly, not as background intuition.

26. Relationship to upgrade rollout

26.1 Before upgrade activation, evaluation SHOULD test:

• upgrade-window arbitrage or griefing
• mixed-fleet economic manipulation
• parameter changes that change profitability thresholds
• reward/slash distortions under rollout
• governance bribery around activation decision

26.2 Rule

Major upgrades SHOULD have upgrade-specific economic evaluation, not only reuse old results.

27. Relationship to public testnet

27.1 Public/internal testnets MAY be used for:

• stress campaigns
• spam experiments within permitted scope
• operator cost studies
• witness reward abuse probes
• governance bribery games under safe simulation assumptions

27.2 Rule

Public testnet exercises MUST remain explicitly bounded and ethical within program policy.

28. Baseline economic profile

28.1 Need

Attack viability depends on baseline state.

28.2 Each scenario SHOULD define:

• normal throughput/load assumption
• normal validator participation
• normal witness emission profile
• normal fee market behavior
• normal governance participation
• normal operator cost assumptions

28.3 Rule

Without baseline, attack deltas are hard to interpret.

29. Environment calibration

29.1 Simulation environments SHOULD be calibrated against:

• replay traces
• testnet observations
• live metrics where safe
• launch or upgrade monitoring baselines
• operator cost reports if relevant

29.2 Rule

Economic simulation divorced from real operating data SHOULD be marked with lower confidence.

30. Confidence classes

30.1 Recommended confidence classes

• CONF_LOW
• CONF_MEDIUM
• CONF_HIGH
• CONF_HIGH_WITH_LIVE_CORROBORATION

30.2 Rule

Scenario results SHOULD carry confidence class reflecting model fidelity and data quality.

31. Report object

31.1 Canonical structure

EconomicAttackEvaluationReport {
  report_id
  scope_hash
  scenario_root
  simulation_run_root
  red_team_root?
  findings_root
  blocker_root?
  residual_risk_update_root?
  recommended_action_root?
  timestamp_unix_ms
}

31.2 Rule

Serious evaluation SHOULD end in structured report, not only notebooks or chats.

32. Recommended action classes

32.1 Recommended action classes

• parameter_change_required
• launch_blocker
• upgrade_blocker
• monitoring_update_required
• operator_guidance_update_required
• conformance_case_required
• residual_risk_acceptance_review_required
• governance_review_required
• further_modeling_required

32.2 Rule

Reports SHOULD propose explicit action classes, not just observations.

33. Simulation anti-patterns

33.1 Systems SHOULD avoid:

1. only modeling honest traffic and calling it stress
2. one adversary budget only
3. no sensitivity sweeps on fee/rent/reward parameters
4. no distinction between griefing and profitable attack
5. no baseline-to-adversarial comparison
6. red-team exercise with no explicit objectives
7. blocker discussions with no metric thresholds
8. ignoring operator cost explosions because state remains “correct”
9. reusing pre-launch results after major upgrade with no reevaluation
10. treating inability to exploit as proof of impossibility

34. Formal goals

AZ-041 urmărește aceste obiective:

34.1 Adversarial economic realism

The system evaluates attacks under explicit budgets, incentives and strategic behavior.

34.2 Measurable blocker discipline

Results can become blockers through declared thresholds rather than intuition alone.

34.3 Tight linkage to security memory

Economic evaluation updates threat and residual risk canon instead of living in isolation.

34.4 Operational usefulness

Findings translate into parameter changes, monitoring changes, rollout restrictions or launch decisions.

35. Formula documentului

Economic Attack Evaluation = typed attack taxonomy + explicit adversary capabilities + reproducible scenarios + metric thresholds + red-team objectives + risk canon updates + actionable outputs

36. Relația cu restul suitei

• AZ-039 definește threat model și residual risk canon.
• AZ-040 definește claims de conformitate.
• AZ-041 furnizează dovada adversarială economică ce poate întări, slăbi sau invalida aceste claims și riscuri asumate.

Pe scurt: AZ-041 este puntea dintre economia teoretică a protocolului și realitatea adversarială măsurabilă.

37. Ce urmează

După AZ-041, documentul corect este:

AZ-042 — Incident Postmortem Canon and Lessons Registry

Acolo trebuie fixate:

• forma canonicală a postmortem-urilor;
• taxonomia lecțiilor învățate;
• mapping-ul dintre incident, control failure, remediation și registry-ul de lessons;
• și cum asigurăm că incidentele schimbă efectiv threat canon, runbooks, checklists și conformance corpus.

Închidere

Un model economic devine serios abia când îl supui unor adversari care încearcă efectiv să-l învingă. Nu doar când pare elegant pe hârtie.

Acolo începe evaluarea reală: când poți spune cât costă atacul, ce câștig produce, ce degradează, cât de des reușește, și ce trebuie schimbat dacă rezultatul este prea bun pentru atacator.