Entry Point Analyzer Agent Skill

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