Skip to content

Scenario Tables

Requested Scenarios

Scenario Observation / receipt context Expected model effect
Healthy full balance actual >= 32 CTN, effective = 32 CTN, no conflict risk healthy, dust healthy, running claims can be fully enabled
Healthy with dust effective healthy, actual slightly below principal within dust threshold dust-neutral or covered-dust path; may remain claim-enabled with limits by mode
Reduced effective balance / recovery effective below target or recovery conditions met claim mode shifts to recovery or debt-first behavior
Slashing slashed or ejection/threshold conditions risk stop-loss, running rewards fail closed
Exit pending exit requested or accepted running claims move to repair-only/disabled path
Receipt arrives before safe claim epoch unsafe snapshot or epoch constraints not met receipt routed to holdback or repair bucket, not immediate reward
Consensus reward observed, no physical receipt observation can affect risk/smoothing exposure only user claimability does not increase solely from observation
Physical receipt after prior consensus recognition receipt processed with source uniqueness checks recoup and reward buckets updated without double counting prior source
Claim consumes bucket finalize claim consumes reward bucket amount does not reappear unless new economic input arrives

Interpretation Notes

  • Reserve-backed advances can temporarily enable claimability but create recoup debt tracked in dust accounting.
  • Exiting and settlement phases subordinate reward payout to principal resolution.
  • Oracle conflict or stale data should fail closed, not degrade silently.

Illustrative Numeric Scenarios

These examples are explanatory only. They use 32 CTN as the Phase-1 principal target because DepositContractCTN requires exactly 32_000_000_000 gwei. Other numbers are scenario values, not production constants, unless source or an approved economic paper proves them.

Scenario Example inputs Expected accounting interpretation Claim implication Evidence required before production claim
Healthy validator Principal target 32 CTN, effective balance 32 CTN, no deficit, fresh oracle Principal remains covered and reward accounting can be considered normally Reward path may be available if claim mode, trigger, reserve, and caps allow Fresh risk observation, reserve coverage, gatekeeper state
Healthy with dust Actual balance 31.9999 CTN, effective balance still safe, dust below configured threshold Dust is tracked; it does not automatically become claimable reward Claim mode may remain limited or available depending on dust policy Dust thresholds and current controller state
Reduced effective balance Actual 32 CTN, effective 31 CTN Economic safety treats this as reduced validator effectiveness, not a reward Claims should fail closed or reduce advance until policy allows Risk observation and claim-state derivation
Recovery Prior deficit 0.5 CTN, later receipt or balance repair 0.5 CTN Recovery repairs principal before creating reward No reward appears until deficit bucket is cleared Receipt classification and ledger readback
Slashing Slashing flag true with actual 30 CTN Validator moves to unsafe/incident handling Routine claims should stop; settlement or reserve response begins Slashing proof and controller observation
Exit pending Exit requested, no final receipt yet Validator lifecycle is no longer routine-running Claims depend on exit/settlement state and pending delays Exit request and accepted-exit evidence
Stale oracle Last observation older than freshness window State is not trustworthy enough for normal claims Claims and deposits depending on readiness fail closed New finalized observation
Receipt before safe claim epoch Receipt at epoch 100, cleared safe epoch 98 Receipt must not be treated as safely claimable yet Claim waits or is classified conservatively Safe-epoch proof
Consensus reward without physical receipt Consensus delta shows 0.1 CTN, vault receipt absent Consensus recognition alone does not prove spendable vault funds Advance may be capped or unavailable depending on reserve/smoothing policy Vault receipt or reserve-backed policy evidence
Physical receipt after consensus recognition Receipt 0.1 CTN arrives after prior consensus recognition Receipt reconciles physical funds against prior recognition Avoid double count by consuming the relevant bucket once Receipt id/source uniqueness
Claim consumes reward bucket Reward bucket 0.1 CTN, claim 0.04 CTN Remaining bucket becomes 0.06 CTN Same 0.04 CTN cannot be claimed again Post-claim ledger readback
No value reappears without input Bucket after claim 0, no new receipt or consensus delta No new claimable value should appear Claim remains unavailable New economic input, not time alone