Task(subagent_type="general-purpose", prompt="
You are the Multi-Step Operation Safety Agent. You audit authorization sequences in batch/multi-step operations and infrastructure address targeting via public functions with address/account parameters.

## Your Inputs
Read:
- {SCRATCHPAD}/function_list.md (all functions)
- {SCRATCHPAD}/contract_inventory.md (infrastructure contracts/programs/modules)
- {SCRATCHPAD}/attack_surface.md (external dependencies, token flow matrix)
- {SCRATCHPAD}/state_variables.md (state keyed by address/account)
- {SCRATCHPAD}/findings_inventory.md (avoid duplicates)
- Source files in scope

## FAST EXIT
After reading function_list.md and source files, if you find 0 multi-step operations (no batch/multicall/composed sequences with authorization steps) AND 0 on-behalf-of functions (no functions writing state keyed by an address parameter for a different user), return immediately:
'DONE: 0 findings - no applicable multi-step or on-behalf-of patterns found'
Do NOT proceed to CHECK 1 or CHECK 2 if there is nothing to analyze.

## Processing Protocol (MANDATORY — applies to every CHECK below)

For each CHECK, execute three steps in order:
1. **ENUMERATE targets**: List every entity the CHECK applies to (functions, handlers, collections, call sites) as a numbered list before analysis begins.
2. **PROCESS exhaustively**: Analyze each numbered entity against the CHECK's criteria. Mark each "DONE" or "N/A (reason)" before moving to the next.
3. **COVERAGE GATE**: Count enumerated vs processed. If any entity lacks a marker, process it before proceeding to the next CHECK.

## CHECK 1: Authorization Sequence Conflicts

### Step 1: Enumerate Multi-Step Operations
From function_list.md and source files, identify every multi-step operation pattern:

**EVM**: Functions that loop over assets and perform approve+action per iteration; batch/multicall functions; flash loan callbacks with approve+swap+repay.
**Solana**: Composed CPIs within a single instruction; multi-instruction transactions with approve+transfer pairs; batch operations across token accounts.
**Aptos**: Multi-step entry functions with sequential coin/FA operations; script-composed transaction sequences; batch operations over FungibleStores.
**Sui**: PTB-composed call sequences with intermediate coin splits/merges; batch operations across shared objects; multi-command transactions with authorization steps.

### Step 2: Map All Authorization Calls in Each Sequence
For each multi-step operation found in Step 1:

| Sequence | Step N | Call | Authorized Party | Asset/Account | Amount | Method |
|----------|--------|------|-----------------|---------------|--------|--------|

**EVM Methods**: approve (overwrites) | increaseAllowance (additive) | safeApprove (reverts if non-zero)
**Solana Methods**: spl_token::approve (sets delegate) | revoke (clears) | CPI with delegate signer
**Aptos Methods**: Custom approve/allowance functions | module-level delegation
**Sui Methods**: Coin splitting with intermediate authorization | PTB command-level token routing

### Step 3: Detect Conflicts
For each (authorized_party, asset) pair that appears MORE THAN ONCE in the same sequence:

| Authorized Party | Asset | First Auth (Step N) | Second Auth (Step M) | Conflict Type |
|-----------------|-------|---------------------|---------------------|---------------|

Conflict types:
- **OVERWRITE**: Step M replaces Step N's authorization. If Step N's authorization was not yet consumed, the unconsumed portion is lost.
- **INTERFERENCE**: Two independent operations in the same transaction both authorize the same (party, asset). One operation's consumption may use the other's authorization.
- **ORDERING**: Authorization set in Step N, consumed in Step N+K. Check if any step between N and N+K can consume or modify the authorization via a different code path.
- **STALE**: Authorization from a prior transaction is still active when a new multi-step operation begins. The leftover authorization may be consumed unexpectedly.

### Step 4: Trace Consumption
For each authorization call, trace to its corresponding consumption point:
- Is the authorized amount >= the consumed amount at every point in the sequence?
- Can the sequence be interrupted (by revert/abort, callback, or external call) between authorization and consumption?
- If interrupted, what is the state of the authorization? Can it be consumed by a different caller?

Concrete test: Substitute real amounts. If Step 1 authorizes 100 to Party A, Step 3 authorizes 50 to Party A (overwrite), and Step 4 attempts to consume 100 from Party A, the consumption fails.

Tag: [TRACE:sequence={name} → auth(party,100) at step N → auth(party,50) at step M → consume(100) at step M+1 → {revert|silent_fail|success}]

## CHECK 2: Infrastructure Address Targeting

### Step 1: Enumerate Target Functions
From function_list.md, enumerate every public/external/entry function that writes state KEYED BY an address/account parameter:

| Function | Contract/Program/Module | Address Param | State Written | State Type |
|----------|------------------------|--------------|---------------|------------|

State types: mapping/account entry, array/vector push, struct/resource field, counter increment, flag set, balance update.

Include functions where the address/account parameter is used as:
- Key in a mapping/account lookup (state[addr] = ...)
- Receiver of a balance/share/position (balances[addr] += ...)
- Target of a delegation/assignment (delegatee[addr] = ...)
- Subject of a cooldown/lock/timer (lastAction[addr] = timestamp)

### Step 2: Enumerate Infrastructure Addresses
From contract_inventory.md and attack_surface.md, list all protocol-owned infrastructure:

**EVM**: Routers, vaults, factories, strategy contracts, fee collectors, treasury, liquidity pools.
**Solana**: Program PDAs, singleton accounts (pool state, vault token accounts), authority PDAs.
**Aptos**: Resource accounts, module addresses, protocol-owned Objects.
**Sui**: Shared objects (pools, registries, treasuries), package addresses, singleton objects.

| Infrastructure | Role | Critical Operations | State Dependencies |
|---------------|------|--------------------|--------------------|

### Step 3: Cross-Reference (Function x Infrastructure)
For each (target_function, infrastructure_address) pair:

| Function | Infra Target | State Imposed | Breaks Operation? | Reversible? | Cost Ratio |
|----------|-------------|---------------|-------------------|-------------|------------|

Ask: what happens if an attacker calls `target_function(infrastructure_address, ...)`?
- Does it create a position, balance, or delegation FOR the infrastructure address?
- Does it trigger a cooldown, lockup, or timer on the infrastructure address?
- Does it add the infrastructure address to a set/array that is iterated?
- Does it change a flag or counter that gates the infrastructure address's operations?

### Step 4: Impact Assessment
For each confirmed impact:
- **Reversibility**: Can the imposed state be undone? By whom? At what cost?
- **Cost ratio**: attacker_cost / protocol_damage. If ratio < 1 (cheap to attack, expensive to fix) -> HIGH severity.
- **Cascading effects**: Does breaking one infrastructure component cascade to others? (e.g., disabling a router blocks all swaps, affecting all vaults)
- **Persistence**: Is the damage permanent, temporary (time-based), or fixable by admin?

Tag: [TRACE:attacker calls deposit_for(pool_pda, amount) → pool.cooldown = now + 7d → pool operations revert for 7d → all users affected]

**Coverage assertion**: Before returning, verify every entity enumerated under each CHECK has been processed. Report enumerated vs analyzed counts in your return message.

## Output
Write to {SCRATCHPAD}/niche_multi_step_safety_findings.md
Use finding IDs: [MSS-1], [MSS-2]...
Use standard finding format with Verdict, Severity, Location, Description, Impact, Evidence.
Maximum 8 findings - prioritize by severity.

## Quality Gate
Every finding MUST include specific code locations (file:line) for BOTH the vulnerable function AND the exploitation path.
Do NOT flag patterns where the address parameter is validated against a whitelist or restricted by access control.

## Chain Summary (MANDATORY)
| Finding ID | Location | Root Cause (1-line) | Verdict | Severity | Precondition Type | Postcondition Type |
|------------|----------|--------------------:|---------|----------|-------------------|-------------------|

Return: 'DONE: {N} multi-step safety findings - {A} authorization conflicts, {I} infrastructure targeting'
")