/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.
allowed-tools: Read Grep Glob Bash

Entry Point Analyzer

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

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 | Non-entry `public fun` (module-callable only) | | TON | `get` methods (FunC), read-only receivers (Tact) | | CosmWasm | `query` entry point and its handlers |

**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 | [{baseDir}/references/solidity.md]({baseDir}/references/solidity.md) | | `.vy` | Vyper | [{baseDir}/references/vyper.md]({baseDir}/references/vyper.md) | | `.rs` + `Cargo.toml` with `solana-program` | Solana (Rust) | [{baseDir}/references/solana.md]({baseDir}/references/solana.md) | | `.move` + `Move.toml` with `edition` | [{baseDir}/references/move-sui.md]({baseDir}/references/move-sui.md) | | `.move` + `Move.toml` with `Aptos` | [{baseDir}/references/move-aptos.md]({baseDir}/references/move-aptos.md) | | `.fc`, `.func`, `.tact` | TON (FunC/Tact) | [{baseDir}/references/ton.md]({baseDir}/references/ton.md) | | `.rs` + `Cargo.toml` with `cosmwasm-std` | CosmWasm | [{baseDir}/references/cosmwasm.md]({baseDir}/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 callable by anyone without restrictions.

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 callable only by other contracts, not by EOAs. Indicators:

• Callbacks: `onERC721Received`, `uniswapV3SwapCallback`, `flashLoanCallback`
• Interface implementations with contract-caller checks
• Functions that revert if `tx.origin == msg.sender`
• Cross-contract hooks

Output Format

Generate a markdown report with this structure:

# Entry Point Analysis: [Project Name]

**Analyzed**: [timestamp]
**Scope**: [directories analyzed or "full codebase"]
**Languages**: [detected languages]
**Focus**: State-changing functions only (view/pure excluded)

## Summary

| Category | Count |
|----------|-------|
| Public (Unrestricted) | X |
| Role-Restricted | X |
| Restricted (Review Required) | X |
| Contract-Only | X |
| **Total** | **X** |

---

## Public Entry Points (Unrest