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

Public Entry Points (Unrestricted)

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

Role-Restricted Entry Points

Admin / Owner

Governance

Guardian / Pauser

Other Roles

Restricted (Review Required)

Functions with access control patterns that need manual verification.

Contract-Only (Internal Integration Points)

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

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