Multi Step Operation Safety

Niche Agent: Multi-Step Operation Safety

Trigger: MULTI_STEP_OPS flag detected (recon finds authorization/delegation patterns or on-behalf-of function patterns) Agent Type: general-purpose (standalone niche agent, NOT injected into another agent) Budget: 1 depth budget slot in Phase 4b iteration 1 Finding prefix: [MSS-N] Added in: v1.1.0

Why This Agent Exists

Scanner sub-checks for these patterns (Scanner A CHECK 2e, 2f) are positionally buried in a multi-check scanner prompt. Research on LLM attention ("Lost in the Middle", Liu et al. 2023) shows that checks in the middle of long prompts are systematically skipped. This agent gives these critical checks their own context window with full attention.

When This Agent Spawns

Recon Agent 3 (Patterns + Surface + Templates) greps for multi-step operation patterns during TASK 6. If any are found, recon sets MULTI_STEP_OPS flag in the BINDING MANIFEST under ## Niche Agents.

Language-Specific Trigger Patterns

Agent Prompt Template

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'
")

Integration Point

This agent's output (niche_multi_step_safety_findings.md) is read by:

• Phase 4a inventory merge (after Phase 4b iteration 1)
• Phase 4c chain analysis (authorization conflicts can enable token theft chains; infrastructure targeting can enable DoS chains)
• Phase 6 report writers