Skip to content
Back to skills

External Precondition Audit

ASecurity

Trigger Pattern Any external module interaction detected in attack_surface.md - Inject Into Breadth agents (merged via M5 hierarchy)

  • 281 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added May 27, 2026
blockchaingo

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add PlamenTSV/plamen --skill external-precondition-audit --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of External Precondition Audit?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for External Precondition Audit
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/plamentsv-external-precondition-audit/badge)](https://www.skillsdirectory.com/skills/plamentsv-external-precondition-audit)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: "external-precondition-audit"
description: "Trigger Pattern Any external module interaction detected in attack_surface.md - Inject Into Breadth agents (merged via M5 hierarchy)"
---

# EXTERNAL_PRECONDITION_AUDIT Skill

> **Trigger Pattern**: Any external module interaction detected in attack_surface.md
> **Inject Into**: Breadth agents (merged via M5 hierarchy)
> **Constraint**: Interface-level inference only -- no production fetch required

For every external module the protocol interacts with:

## 1. Interface-Level Requirement Inference

From the `use` imports and function calls to external modules, infer what the external module requires:

| External Function Called | Module::Function | Parameters Passed | Likely Preconditions (from signature + abort codes) | Our Protocol Validates? |
|--------------------------|-----------------|-------------------|-----------------------------------------------------|------------------------|

**Inference method**: Read the function signature, type parameters, ability constraints, and abort conditions. Example: `coin::withdraw<CoinType>(account: &signer, amount: u64)` -> infer that `account` must have sufficient balance, `CoinType` must be initialized, amount must be > 0. Check abort codes in framework source if available.

**Aptos-specific patterns**:
- `&signer` parameters: does external module require the signer to own a specific resource?
- Generic type parameters `<T>`: does external module require `T` to be registered/initialized?
- `Object<T>` parameters: does external module validate object ownership or type?
- Abort conditions: enumerate all `assert!` / `abort` in external function that could revert our call

## 2. Return Value Consumption

| External Call | Return Type | How Protocol Uses Return | Failure Mode if Return Unexpected |
|--------------|-------------|-------------------------|----------------------------------|

For each return value:
- What happens if it returns 0? What happens if it returns `MAX_U64`?
- What happens if the external call aborts?
- For `Option<T>` returns: does our protocol handle `none` correctly?
- For `FungibleAsset` returns: is metadata validated after receiving?
- For `Object<T>` returns: is the object type verified before use?
- 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)?

## 3. State Dependency Mapping

| Protocol State | Depends on External State | External Module Upgradeable? | State Can Change Without Our Knowledge? |
|---------------|--------------------------|-----------------------------|-----------------------------------------|

For each dependency:
- **Upgrade risk**: Aptos modules are upgradeable by default (`compatible` policy). Can the external module add new abort conditions to a function we call? Can it change return value semantics within compatible upgrade bounds?
- **Immutability check**: Is the external module published as `immutable`? If so, behavior is frozen.
- **State mutation timing**: Can external module state change between our module's read and use within the same transaction? (e.g., another instruction in a multi-instruction transaction modifies external state)
- **Framework dependency**: If depending on `aptos_framework` modules, are there governance-controlled parameters that could change? (e.g., `transaction_fee`, `staking_config`)

## Instantiation Parameters

```
{CONTRACTS}           -- List of modules to analyze
{EXTERNAL_MODULES}    -- External modules identified during recon
{FRAMEWORK_DEPS}      -- aptos_framework / aptos_std / aptos_token dependencies
```

## Output Schema

For each finding:

```markdown
## Finding [EP-N]: Title

**Verdict**: CONFIRMED / PARTIAL / REFUTED / CONTESTED
**Step Execution**: S1,S2,S3 | X(reasons) | ?(uncertain)
**Rules Applied**: [R1:Y, R4:Y, R8:Y]
**Severity**: Critical/High/Medium/Low/Info
**Location**: module::function (source_file.move:LineN)

**External Dependency**: {module::function}
**Failure Mode**: {what breaks}

**Description**: What's wrong
**Impact**: What can happen (abort DoS, wrong state, fund loss)
**Evidence**: Code showing dependency and missing validation
```

## Step Execution Checklist

| Section | Required | Completed? |
|---------|----------|------------|
| 1. Interface-Level Requirement Inference | YES | Y/N/? |
| 2. Return Value Consumption | YES | Y/N/? |
| 3. State Dependency Mapping | YES | Y/N/? |

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.