/entry-point-analyzer

name: entry-point-analyzer
description: Analyzes smart contract codebases to identify state-changing entry points for security auditing. Detects externally callable functions that modify state, categorizes them by access level (public, admin, role-restricted, contract-only), and generates structured audit reports. Excludes view/pure/read-only functions. Use when auditing smart contracts (Solidity, Vyper, Solana/Rust, Move, TON, CosmWasm) or when asked to find entry points, audit flows, external functions, access control patterns, or privileged operations.

Entry Point Analyzer

Systematically identify all **state-changing** entry points in a smart contract codebase to guide security audits.

Execution in Codex

Use the available file-reading, search, and shell tools. Resolve bundled reference links relative to this SKILL.md, not the audited repository. Slither is optional; use manual inspection if it is unavailable or fails. Report unreadable source or reference files as coverage gaps. Runtime permissions come from the workspace.

When to Use

Use this skill when:

• Starting a smart contract security audit to map the attack surface
• Asked to find entry points, external functions, or audit flows
• Analyzing access control patterns across a codebase
• Identifying privileged operations and role-restricted functions
• Building an understanding of which functions can modify contract state

When NOT to Use

Do NOT use this skill for:

• Vulnerability detection (use audit-context-building or domain-specific-audits)
• Writing exploit POCs (use solidity-poc-builder)
• Code quality or gas optimization analysis
• Non-smart-contract codebases
• Analyzing read-only functions (this skill excludes them)

Scope: State-Changing Functions Only

This skill focuses exclusively on functions that can modify state. **Excluded:**

| Language | Excluded Patterns | |----------|-------------------| | Solidity | `view`, `pure` functions | | Vyper | `@view`, `@pure` functions | | Solana | Functions without `mut` account references | | Move | Read-only function bodies; visibility alone does not establish mutability | | TON | `get` methods (FunC), read-only receivers (Tact) | | CosmWasm | `query` entry point and its handlers |

Include state-changing Move `public fun` even without `entry`: Aptos transaction scripts and Sui programmable transaction blocks can reach them. Trace callees when needed to determine state effects, and record signer, capability, and object ownership requirements separately from visibility.

**Why exclude read-only functions?** They cannot directly cause loss of funds or state corruption. While they may leak information, the primary audit focus is on functions that can change state.

Workflow

1. **Detect Language** - Identify contract language(s) from file extensions and syntax 2. **Use Tooling (if available)** - For Solidity, check if Slither is available and use it 3. **Locate Contracts** - Find all contract/module files (apply directory filter if specified) 4. **Extract Entry Points** - Parse each file for externally callable, state-changing functions 5. **Classify Access** - Categorize each function by access level 6. **Generate Report** - Output structured markdown report

Slither Integration (Solidity)

For Solidity codebases, Slither can automatically extract entry points. Before manual analysis:

1. Check if Slither is Available

which slither

2. If Slither is Detected, Run Entry Points Printer

slither . --print entry-points

This outputs a table of all state-changing entry points with:

• Contract name
• Function name
• Visibility
• Modifiers applied

3. Use Slither Output as Foundation

• Parse the Slither output table to populate your analysis
• Cross-reference with manual inspection for access control classification
• Slither may miss some patterns (callbacks, dynamic access control)—supplement with manual review
• If Slither fails (compilation errors, unsupported features), fall back to manual analysis

4. When Slither is NOT Available

If `which slither` returns nothing, proceed with manual analysis using the language-specific reference files.

Language Detection

| Extension | Language | Reference | |-----------|----------|-----------| | `.sol` | Solidity | [references/solidity.md](references/solidity.md) | | `.vy` | Vyper | [references/vyper.md](references/vyper.md) | | `.rs` + `Cargo.toml` with `solana-program` | Solana (Rust) | [references/solana.md](references/solana.md) | | `.move` + `Move.toml` with `edition` | Move (Sui) | [references/move-sui.md](references/move-sui.md) | | `.move` + `Move.toml` with `Aptos` | Move (Aptos) | [references/move-aptos.md](references/move-aptos.md) | | `.fc`, `.func`, `.tact` | TON (FunC/Tact) | [references/ton.md](references/ton.md) | | `.rs` + `Cargo.toml` with `cosmwasm-std` | CosmWasm | [references/cosmwasm.md](references/cosmwasm.md) |

Load the appropriate reference file(s) based on detected language before analysis.

Access Classification

Classify each state-changing entry point into one of these categories:

1. Public (Unrestricted)

Functions with no caller-identity or role restriction. Record state conditions such as pause flags separately; they do not make a function privileged.

2. Role-Restricted

Functions limited to specific roles. Common patterns to detect:

• Explicit role names: `admin`, `owner`, `governance`, `guardian`, `operator`, `manager`, `minter`, `pauser`, `keeper`, `relayer`, `lender`, `borrower`
• Role-checking patterns: `onlyRole`, `hasRole`, `require(msg.sender == X)`, `assert_owner`, `#[access_control]`
• When role is ambiguous, flag as **"Restricted (review required)"** with the restriction pattern noted

3. Contract-Only (Internal Integration Points)

Functions whose enforced caller restrictions limit them to other contracts. Cite the actual check and the identity or provenance of the permitted caller. A callback name, implemen