External Precondition Audit

Skill: External Precondition Audit (Soroban)

Trigger Pattern: Any env.invoke_contract() or env.try_invoke_contract() detected in contract Inject Into: Breadth agents Finding prefix: [EPA-N] Rules referenced: R1, R4, R8, R10, R16 Constraint: Interface-level inference only — no production fetch required

invoke_contract|try_invoke_contract|contractimport!|ContractClient|
external_contract|token::Client|token_contract|SorobanInterface

For every external contract the protocol invokes:

1. External Call Target Inventory and Validation

Address validation check: For each invoke_contract call, is the target contract address:

• Hardcoded as a constant or loaded from admin-controlled storage with access control? -> SAFE
• Read from user-supplied input without validation? -> CRITICAL: attacker substitutes malicious contract
• Loaded from contract storage but settable by an unauthorized caller? -> HIGH: arbitrary external call

Upgradeability assessment: Soroban contracts can be upgraded via update_current_contract_wasm() if the contract has an upgrade entry point. Is the external contract upgradeable?

• If YES: its behavior can change after audit. Apply Rule 4 (adversarial assumption on future behavior).
• If NO (no upgrade entry point or upgrade authority revoked): behavior is fixed, trust boundary is clear.

contractimport! macro risk: Contracts imported via contractimport! bind the caller to the interface of the external contract at compile time. If the external contract upgrades and changes its interface, calls will fail. More critically, if the imported interface definition does not match the deployed contract's actual interface, calls may succeed with incorrect semantics (wrong argument order, wrong return type interpretation).

2. invoke_contract vs try_invoke_contract — Error Handling

Soroban provides two call modes with fundamentally different error semantics:

invoke_contract (trap mode): If the external call fails (panic, host error), the ENTIRE transaction reverts. This is safe against partial state corruption but means any external contract can DoS the protocol by reverting.

try_invoke_contract (Result mode): Returns Ok(val) or Err(...). The calling contract's state changes are NOT automatically reverted on error — the calling contract must handle the error explicitly and decide whether to revert or continue.

Critical check for try_invoke_contract:

• Is the Err branch handled explicitly?
• Does the calling contract revert (panic) on external error, or continue with partial state?
• If it continues: what state was already written before the external call? Is that state now inconsistent?

Attack pattern (partial state corruption):

1. Protocol calls try_invoke_contract to external token
2. External call fails (returns Err)
3. Protocol writes partial state without reverting (e.g., records a deposit but token transfer failed)
4. User's accounting shows balance but tokens were never transferred

3. Return Value Consumption

For each return value:

• What happens if the external call returns 0? (division by zero, incorrect accounting)
• What happens if it returns an unexpected type? (Soroban SDK will trap on deserialization mismatch)
• What happens if try_invoke_contract returns Err? Does the protocol handle this case explicitly?
• Are return values deserialized with a type assertion that could trap on malformed data from an upgraded contract?
• 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)?

4. State Dependency Mapping

For each dependency: model what happens when the external contract state changes between our contract's read and use.

Soroban-specific concerns:

• Soroban contracts within the SAME transaction can call the same external contract before and after our contract — state may differ between our calls
• Storage TTL: if an external contract's data entry has expired (TTL exhausted), reading it returns the default value, not the last written value. This can silently return zero or empty data.
• A contract call that reads external state, then performs computation, then re-reads external state may see inconsistent state if another contract in the same transaction modified the external state between reads.