/multi-step-operation-safety

name: "multi-step-operation-safety"
description: "Niche agent for multi-step operation safety: authorization sequence conflicts in batch/multi-step operations, and infrastructure address targeting via public on-behalf-of functions"

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

| Language | Authorization Patterns | On-Behalf-Of Patterns | |----------|----------------------|----------------------| | **EVM** | `approve\|safeApprove\|increaseAllowance\|permit` | `depositFor\|stakeFor\|delegateTo\|mintFor\|withdrawFor\|OnBehalf\|claimFor` | | **Solana** | `approve\|delegate\|authorized_amount` | `deposit_for\|stake_for\|delegate_to\|_on_behalf\|_for_user` + public instructions with target pubkey | | **Aptos** | `approve\|delegate\|allowance` | `deposit_for\|stake_for\|delegate_to\|_on_behalf\|_for(.*address` | | **Sui** | `approve\|delegate\|allowance` | `deposit_for\|stake_for\|delegate_to\|_on_behalf\|_for_user` | | **Soroban** | `approve\|allowance\|require_auth\|require_auth_for_args` | `deposit_for\|stake_for\|transfer_from\|_on_behalf\|_for_user` + functions with Address param + require_auth on different Address |

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