entry-point-analyzer

SKILL.md

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

Detect Language - Identify contract language(s) from file extensions and syntax

Use Tooling (if available) - For Solidity, check if Slither is available and use it

Locate Contracts - Find all contract/module files (apply directory filter if specified)

Extract Entry Points - Parse each file for externally callable, state-changing functions

Classify Access - Categorize each function by access level

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

.vy
Vyper
{baseDir}/references/vyper.md

.rs + Cargo.toml with solana-program
Solana (Rust)
{baseDir}/references/solana.md

.move + Move.toml with edition
{baseDir}/references/move-sui.md

.move + Move.toml with Aptos
{baseDir}/references/move-aptos.md

.fc, .func, .tact
TON (FunC/Tact)
{baseDir}/references/ton.md

.rs + Cargo.toml with cosmwasm-std
CosmWasm
{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 (Unrestricted)

State-changing functions callable by anyone—prioritize for attack surface analysis.

| Function | File | Notes |
|----------|------|-------|
| `functionName(params)` | `path/to/file.sol:L42` | Brief note if relevant |

---

## Role-Restricted Entry Points

### Admin / Owner
| Function | File | Restriction |
|----------|------|-------------|
| `setFee(uint256)` | `Config.sol:L15` | `onlyOwner` |

### Governance
| Function | File | Restriction |
|----------|------|-------------|

### Guardian / Pauser
| Function | File | Restriction |
|----------|------|-------------|

### Other Roles
| Function | File | Restriction | Role |
|----------|------|-------------|------|

---

## Restricted (Review Required)

Functions with access control patterns that need manual verification.

| Function | File | Pattern | Why Review |
|----------|------|---------|------------|
| `execute(bytes)` | `Executor.sol:L88` | `require(trusted[msg.sender])` | Dynamic trust list |

---

## Contract-Only (Internal Integration Points)

Functions only callable by other contracts—useful for understanding trust boundaries.

| Function | File | Expected Caller |
|----------|------|-----------------|
| `onFlashLoan(...)` | `Vault.sol:L200` | Flash loan provider |

---

## Files Analyzed

- `path/to/file1.sol` (X state-changing entry points)
- `path/to/file2.sol` (X state-changing entry points)

Filtering

When user specifies a directory filter:

Only analyze files within that path

Note the filter in the report header

Example: "Analyze only src/core/" → scope = src/core/

Analysis Guidelines

Be thorough: Don't skip files. Every state-changing externally callable function matters.

Be conservative: When uncertain about access level, flag for review rather than miscategorize.

Skip read-only: Exclude view, pure, and equivalent read-only functions.

Note inheritance: If a function's access control comes from a parent contract, note this.

Track modifiers: List all access-related modifiers/decorators applied to each function.

Identify patterns: Look for common patterns like:

Initializer functions (often unrestricted on first call)

Upgrade functions (high-privilege)

Emergency/pause functions (guardian-level)

Fee/parameter setters (admin-level)

Token transfers and approvals (often public)

Common Role Patterns by Protocol Type

Protocol Type
Common Roles

DEX
owner, feeManager, pairCreator

Lending
admin, guardian, liquidator, oracle

Governance
proposer, executor, canceller, timelock

NFT
minter, admin, royaltyReceiver

Bridge
relayer, guardian, validator, operator

Vault/Yield
strategist, keeper, harvester, manager

Rationalizations to Reject

When analyzing entry points, reject these shortcuts:

"This function looks standard" → Still classify it; standard functions can have non-standard access control

"The modifier name is clear" → Verify the modifier's actual implementation

"This is obviously admin-only" → Trace the actual restriction; "obvious" assumptions miss subtle bypasses

"I'll skip the callbacks" → Callbacks define trust boundaries; always include them

"It doesn't modify much state" → Any state change can be exploited; include all non-view functions

Error Handling

If a file cannot be parsed:

Note it in the report under "Analysis Warnings"

Continue with remaining files

Suggest manual review for unparsable files