Entry Point Analyzer

When to Use

• 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

• 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

view

pure

@view

@pure

mut

public fun

get

query

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)

1. Check if Slither is Available

which slither

2. If Slither is Detected, Run Entry Points Printer

slither . --print entry-points

• 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

which slither

Language Detection

.sol

.vy

.rs

Cargo.toml

solana-program

.move

Move.toml

edition

.move

Move.toml

Aptos

.fc

.func

.tact

.rs

Cargo.toml

cosmwasm-std

Access Classification

1. Public (Unrestricted)

2. Role-Restricted

• 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)

• Callbacks:

  onERC721Received

  ,

  uniswapV3SwapCallback

  ,

  flashLoanCallback

• Interface implementations with contract-caller checks
• Functions that revert if

  tx.origin == msg.sender

• Cross-contract hooks

Output Format

# 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

• Only analyze files within that path
• Note the filter in the report header
• Example: "Analyze only

  src/core/

  " → scope =

  src/core/

Analysis Guidelines

1. Be thorough: Don't skip files. Every state-changing externally callable function matters.
2. Be conservative: When uncertain about access level, flag for review rather than miscategorize.
3. Skip read-only: Exclude

   view

   ,

   pure

   , and equivalent read-only functions.
4. Note inheritance: If a function's access control comes from a parent contract, note this.
5. Track modifiers: List all access-related modifiers/decorators applied to each function.
6. 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

owner

feeManager

pairCreator

admin

guardian

liquidator

oracle

proposer

executor

canceller

timelock

minter

admin

royaltyReceiver

relayer

guardian

validator

operator

strategist

keeper

harvester

manager

Rationalizations to Reject

• "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

1. Note it in the report under "Analysis Warnings"
2. Continue with remaining files
3. Suggest manual review for unparsable files