External Precondition Audit

Skill: External Precondition Audit (Solana)

Trigger Pattern: Any CPI (Cross-Program Invocation) detected in program Inject Into: Breadth agents (merged via M5 hierarchy) Finding prefix: [EPA-N] Rules referenced: S1, S3, S5, S9, R1, R4 Constraint: IDL/interface-level inference only -- no production fetch required

invoke|invoke_signed|CpiContext|cpi::|anchor_spl|spl_token|system_program|
associated_token|token_2022|program::invoke

For every CPI target program the protocol invokes:

1. CPI Target Inventory and Validation

Rule S3 check: For each CPI call, is the target program ID:

• Hardcoded as a constant (spl_token::ID, known program address)? -> SAFE
• Read from an account field without validation? -> CRITICAL: attacker substitutes malicious program
• Passed as an AccountInfo and checked via constraint = program.key() == expected_id? -> SAFE if constraint present

Upgradeability assessment: Is the CPI target program upgradeable?

• If YES: its behavior can change after audit. Apply Rule 4 (adversarial assumption).
• If NO (immutable / upgrade authority revoked): behavior is fixed, trust boundary is clear.

2. Signer Privilege Propagation

For each invoke_signed / CPI call, trace signer propagation:

Checks:

• Does the CPI forward signer privileges that should NOT be forwarded? (e.g., forwarding user signer to an external program that can drain their accounts)
• Are PDA signer seeds constructed correctly? (wrong seeds = wrong PDA = different authority)
• Can an attacker control any of the PDA seed components to derive a different PDA?
• Does invoke_signed pass accounts the CPI target can mutate that should not be mutated?

3. Account Reload After CPI (Rule S5 -- CRITICAL)

For each CPI call that modifies accounts used by subsequent logic:

Rule S5: After a CPI call, any account that the CPI target may have modified MUST be reloaded before the calling program reads it again. Anchor's reload() method handles this. Without reload, the program reads cached (pre-CPI) data.

Attack pattern:

1. Program reads account balance (cached)
2. CPI transfers tokens out of account
3. Program reads account balance again -- gets STALE pre-CPI value
4. Program makes decisions based on stale balance

Check for each CPI:

• All mutable accounts passed to CPI are reloaded after return
• Lamport balances are re-read after CPI (lamports can change via CPI)
• Token account balances are re-read after SPL Token CPI
• If NOT reloaded: trace what stale data is used for and compute impact

4. Return Data Consumption

For each return value:

• What happens if CPI returns 0? (division by zero, incorrect accounting)
• What happens if CPI returns MAX_U64? (overflow in subsequent arithmetic)
• What happens if CPI does NOT set return data? (Solana's get_return_data() returns None)
• What happens if the CPI reverts? Does the calling program handle the error or propagate it?

Solana-specific: sol_get_return_data returns the program ID that set the data. Verify the caller checks that the return data comes from the expected program, not a previously-invoked program's stale return data.

• For each external data structure received (Vec, array, Map, list): (a) What ordering/uniqueness does the consuming code assume? (b) Does the external contract's spec guarantee that ordering? (c) What happens if the assumption is violated (unsorted, duplicates, gaps)?