/outcome-determinism

name: "outcome-determinism"
description: "Protocol Type Trigger outcome_determinism - detected when EITHER of these code patterns are present - - Selection from finite depletable pool with fallback behavior (while(full)..."

Injectable Skill: Outcome Determinism - Selection Fairness & Strategic Timing

> **Protocol Type Trigger**: `outcome_determinism` - detected when EITHER of these code patterns are present: > - Selection from finite depletable pool with fallback behavior (`while(full) next`, `modulo` with shrinking domain, category/slot/validator selection) > - Time-gated actions with observable default/fallback outcomes (`deadline`, `claimPeriod`, `defaultSelection`, `expiry` + fallback path that computes from predictable state) > **Inject Into**: Breadth agents, depth-edge-case > **Language**: All (rational actor patterns are chain-agnostic) > **Finding prefix**: `[OD-N]` > **Added in**: v1.1 > > **NOTE**: Callback selective revert (Section 1a of the original skill) and RNG consumption enumeration (Section 1b) are now ALWAYS-ON checks in the depth agent template - they do not require this injectable to trigger.

What This Injectable Adds (beyond always-on checks)

The always-on depth template already covers:

• **Callback selective revert**: Full taxonomy of external execution transfers (ERC-721/1155/777/1363, flash loans, hooks, low-level calls, ETH transfers) - see depth-templates.md "CALLBACK SELECTIVE REVERT ANALYSIS"
• **Tainted source consumption enumeration**: RNG/oracle consumed by multiple functions → rate severity by worst consumer - see depth-templates.md PART 1 item 6

This injectable adds analysis that only applies when SPECIFIC structural patterns exist:

---

1. Selection Fairness Under Constraint Changes

For every selection algorithm operating on a set that can shrink, grow, or be modified between selections:

1a. Probability Redistribution on Depletion

| Selection Function | Pool Size | Depletion Mechanism | Fallback Behavior | Redistribution Fair? | |-------------------|-----------|--------------------|--------------------|---------------------|

**Fairness test**: When element X is removed from a pool of N:

• **Fair**: Each remaining element gets probability 1/(N-1) - uniform redistribution
• **Biased**: Sequential fallback (`index++`, `next slot`) - adjacent element gets doubled probability
• **Broken**: Infinite loop (no exit when all depleted) or unreachable elements

**Common biased patterns across protocol types**:

• `while (slot_full) { index++ }` - next-in-line gets 2/N probability (NFT categories, validator slots, LP positions)
• `if (depleted) skip` - skipped element's share goes entirely to next check, not distributed
• `modulo(N)` where N decreases - specific indices get boosted as N shrinks

**Quantify**: At each depletion level (1-of-N, N/2-of-N, N-1-of-N), what is the maximum probability deviation from uniform? Is it exploitable (can the actor influence which elements deplete first)?

Tag: `[VARIATION:pool N→N-K → element X probability 1/N→{new_prob} → bias={factor}x]`

1b. Admin Parameter Regression on Selection Algorithms

For bounded parameters (caps, limits, quotas) where the bound can be LOWERED below already-accumulated state and the bound is used by a selection/iteration algorithm:

| Parameter | Setter | Current Accumulated | Can Set Below Accumulated? | Selection Algorithm Affected | What Breaks? | |-----------|--------|--------------------|--------------------------|-------|--------------|

**This extends Rule 14** (Setter Regression) specifically for selection/allocation algorithms: when a cap is lowered below the current count, does the selection algorithm's termination condition still hold? (e.g., `while (count == max)` becomes unreachable when count > max)

---

2. Strategic Timing - Delay, Front-Run, Sequence

**Core question**: For each user-facing action, is the TIMING of the action exploitable by a rational self-interested actor?

2a. Delay-vs-Act Rationality

For every time-gated action with a default or fallback:

| Action | Active Path | Default/Fallback Path | Default Predictable? | Default Sometimes Better? | Delay Cost | |--------|-----------|----------------------|---------------------|--------------------------|-----------|

**A rational actor will delay when ALL THREE hold**: 1. The default outcome is **predictable** (computed from observable on-chain state, not future unknowns) 2. The default is **sometimes better** than the active choice (different formula, different prices, different parameters) 3. The **cost of waiting** (opportunity cost, gas, penalty) is lower than the expected value gain

**Cross-protocol examples**:

• DeFi: Defer unstaking claim when penalty decreases over time and rate may improve
• NFT: Defer coin/trait claiming when default allocation uses more favorable prices than current
• Governance: Defer vote to observe other votes and vote strategically
• Staking: Defer withdrawal when accrued rewards during delay exceed the withdrawal amount
• Auctions: Defer bid to last block to prevent counter-bidding (sniping)

**Methodology**: 1. Identify the active path (user calls function before deadline) 2. Identify the default path (what happens if user doesn't act - system assigns default, claim expires, fallback triggers) 3. Is the default outcome computable from CURRENT on-chain state? (If it depends on future block hash or unresolved oracle → not predictable → no strategic edge) 4. Compare: under what market/state conditions is default > active? How often do those conditions occur? 5. What does delay cost? (forfeiture, penalty, opportunity cost, gas savings)

Tag: `[TRACE:action={fn} deadline={T} → default={fallback_fn} → computed_from={state_vars} → predictable={YES/NO} → default_better_when={condition}]`

2b. Admin Action Information Asymmetry

For every admin-settable parameter that affects pending or future user operations:

| Parameter | Setter | Timelock? | Event