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

```bash
which slither
```

### 2. If Slither is Detected, Run Entry Points Printer

```bash
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:

```markdown
# 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

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

| 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:
1. Note it in the report under "Analysis Warnings"
2. Continue with remaining files
3. Suggest manual review for unparsable files


---

## Companion Files

The following reference files are included for convenience:

### references/vyper.md

# Vyper Entry Point Detection

## Entry Point Identification (State-Changing Only)

### Include: State-Changing Functions
```vyper
@external                    # State-changing entry point
def function_name():
    pass

@external
@payable                     # State-changing, receives ETH
def payable_function():
    pass

@external
@nonreentrant("lock")        # State-changing with reentrancy protection
def protected():
    pass
```

### Exclude: Read-Only Functions
```vyper
@external
@view                        # EXCLUDE - cannot modify state
def read_only():
    pass

@external
@pure                        # EXCLUDE - no state access
def pure_function():
    pass
```

### Decorator Matrix
| Decorators | Include? | Notes |
|------------|----------|-------|
| `@external` | **Yes** | State-changing entry point |
| `@external @payable` | **Yes** | State-changing, receives ETH |
| `@external @nonreentrant` | **Yes** | State-changing with protection |
| `@external @view` | No | Read-only, exclude |
| `@external @pure` | No | No state access, exclude |
| `@internal` | No | Not externally callable |
| `@deploy` | No | Constructor (Vyper 0.4+) |

### Special Entry Points
```vyper
@external
@payable
def __default__():           # Fallback function (receives ETH + unmatched calls)
    pass
```

## Access Control Patterns

### Owner Pattern
```vyper
owner: public(address)

@external
def restricted_function():
    assert msg.sender == self.owner, "Not owner"
    # ...
```

### Role-Based Patterns
```vyper
# Common patterns
admin: public(address)
governance: public(address)
guardian: public(address)
operator: public(address)

# Mapping-based roles
authorized: public(HashMap[address, bool])
minters: public(HashMap[address, bool])

@external
def mint(to: address, amount: uint256):
    assert self.minters[msg.sender], "Not minter"
    # ...
```

### Access Control Classification
| Pattern | Classification |
|---------|----------------|
| `assert msg.sender == self.owner` | Admin/Owner |
| `assert msg.sender == self.admin` | Admin |
| `assert msg.sender == self.governance` | Governance |
| `assert msg.sender == self.guardian` | Guardian |
| `assert self.authorized[msg.sender]` | Review Required |
| `assert self.whitelist[msg.sender]` | Review Required |

## Contract-Only Detection

### Callback Functions
```vyper
@external
def onERC721Received(...) -> bytes4:
    return method_id("onERC721Received(address,address,uint256,bytes)")

@external
def uniswapV3SwapCallback(amount0: int256, amount1: int256, data: Bytes[...]):
    # Must verify caller is the pool
    pass
```

### Contract-Caller Checks
```vyper
assert msg.sender == self.pool, "Only pool"
assert msg.sender != tx.origin, "No EOA"  # Vyper 0.3.7+
```

## Extraction Strategy

1. Parse all `.vy` files
2. For each function:
   - Check for `@external` decorator
   - **Skip** functions with `@view` or `@pure` decorators
   - Record function name and parameters
   - Record line number
   - Check for access control assertions in function body
3. Classify:
   - No access assertions → Public (Unrestricted)
   - `msg.sender == self.X` → Check what X is
   - `self.mapping[msg.sender]` → Review Required
   - Known callback name → Contract-Only

## Vyper-Specific Considerations

1. **No Modifiers**: Vyper doesn't have modifiers—access control is inline `assert` statements
2. **No Inheritance**: Each contract is standalone (interfaces only)
3. **Explicit is Better**: All visibility must be declared explicitly
4. **Default Internal**: Functions without decorators are internal

## Common Gotchas

1. **Initializer Pattern**: Look for `initialized: bool` flag with one-time setup
2. **Raw Calls**: `raw_call()` can delegate to other contracts
3. **Create Functions**: `create_minimal_proxy_to()`, `create_copy_of()` are factory patterns
4. **Reentrancy**: `@nonreentrant` protects against reentrancy but function is still entry point

### references/solana.md

# Solana Entry Point Detection

## Entry Point Identification (State-Changing Only)

In Solana, most program instructions modify state. **Exclude** view-only patterns:
- Instructions that only read account data without `mut` references
- Pure computation functions that don't write to accounts

### Native Solana Programs
```rust
// Single entrypoint macro
entrypoint!(process_instruction);

pub fn process_instruction(
    program_id: &Pubkey,
    accounts: &[AccountInfo],
    instruction_data: &[u8],
) -> ProgramResult {
    // Dispatch to handlers based on instruction_data
}
```

### Anchor Framework
```rust
#[program]
mod my_program {
    use super::*;

    // Each pub fn is an entry point
    pub fn initialize(ctx: Context<Initialize>) -> Result<()> { }
    pub fn transfer(ctx: Context<Transfer>, amount: u64) -> Result<()> { }
}
```

### Entry Point Detection Rules
| Pattern | Include? | Notes |
|---------|----------|-------|
| `entrypoint!(fn_name)` | **Yes** | Native program entry |
| `pub fn` inside `#[program]` mod with `mut` accounts | **Yes** | Anchor state-changing |
| `pub fn` inside `#[program]` mod (view-only) | No | Exclude if no `mut` accounts |
| Functions in `processor.rs` matching instruction enum | **Yes** | Native pattern |
| Internal helper functions | No | Not externally callable |

## Access Control Patterns

### Anchor Constraints
```rust
#[derive(Accounts)]
pub struct AdminOnly<'info> {
    #[account(mut)]
    pub admin: Signer<'info>,

    #[account(
        constraint = config.admin == admin.key() @ ErrorCode::Unauthorized
    )]
    pub config: Account<'info, Config>,
}
```

### Common Access Control Patterns
| Pattern | Classification |
|---------|----------------|
| `constraint = X.admin == signer.key()` | Admin |
| `constraint = X.owner == signer.key()` | Owner |
| `constraint = X.authority == signer.key()` | Authority (Admin-level) |
| `constraint = X.governance == signer.key()` | Governance |
| `constraint = X.guardian == signer.key()` | Guardian |
| `has_one = admin` | Admin |
| `has_one = owner` | Owner |
| `has_one = authority` | Authority |
| `Signer` account with no constraints | Review Required |

### Native Access Control
```rust
// Check signer
if !accounts[0].is_signer {
    return Err(ProgramError::MissingRequiredSignature);
}

// Check specific authority
if accounts[0].key != &expected_authority {
    return Err(ProgramError::InvalidAccountData);
}
```

### Access Control Macros (Anchor)
```rust
#[access_control(is_admin(&ctx))]
pub fn admin_function(ctx: Context<AdminAction>) -> Result<()> { }

fn is_admin(ctx: &Context<AdminAction>) -> Result<()> {
    require!(ctx.accounts.admin.key() == ADMIN_PUBKEY, Unauthorized);
    Ok(())
}
```

## Contract-Only Detection (CPI Patterns)

### Cross-Program Invocation Sources
```rust
// Functions expected to be called via CPI
pub fn on_token_transfer(ctx: Context<TokenCallback>, amount: u64) -> Result<()> {
    // Should verify calling program
    require!(
        ctx.accounts.calling_program.key() == expected_program::ID,
        ErrorCode::InvalidCaller
    );
}
```

### CPI Verification Patterns
```rust
// Verify CPI caller
let calling_program = ctx.accounts.calling_program.key();
require!(calling_program == &spl_token::ID, InvalidCaller);

// Check instruction sysvar for CPI
let ix = load_current_index_checked(&ctx.accounts.instruction_sysvar)?;
```

## Extraction Strategy

1. **Detect Framework**:
   - Check `Cargo.toml` for `anchor-lang` → Anchor
   - Check for `entrypoint!` macro → Native

2. **For Anchor**:
   - Find `#[program]` module
   - Extract all `pub fn` within it
   - Parse `#[derive(Accounts)]` structs for constraints

3. **For Native**:
   - Find instruction enum (usually in `instruction.rs`)
   - Map variants to handler functions in `processor.rs`
   - Check each handler for signer/authority checks

4. **Classify**:
   - No authority constraints → Public (Unrestricted)
   - `has_one`, `constraint` with authority → Role-based
   - CPI-only patterns → Contract-Only

## Solana-Specific Considerations

1. **Account Validation**: Access control often via account constraints, not function-level
2. **PDA Authority**: Program Derived Addresses can act as authorities
3. **Signer vs Authority**: `Signer` alone doesn't mean admin—check what the signer controls
4. **Instruction Data**: Native programs dispatch based on instruction discriminator

## Common Gotchas

1. **Initialize Patterns**: `is_initialized` checks—first caller may set authority
2. **Upgrade Authority**: Programs can be upgraded—check upgrade authority
3. **Multisig**: Some operations require multiple signers
4. **CPI Safety**: Functions callable via CPI should verify calling program
5. **Freeze Authority**: Token accounts may have freeze authority

### references/move-sui.md

# Move Entry Point Detection (Sui)

## Entry Point Identification (State-Changing Only)

In Move, `public` functions can be invoked from programmable transaction blocks (Sui) or transaction scripts (Aptos) and typically modify state. In addition, private `entry` functions are entrypoints. Package-protected (`public(package) fun`) and private (`fun`) functions should be excluded.

```move
// Public functions
public fun compute(obj: &mut Object): u64 { }

// Entry functions in Sui
public entry fun transfer(ctx: &mut TxContext) { }
```

### Visibility Rules
| Visibility | Include? | Notes |
|------------|----------|-------|
| `public entry fun` | **Yes** | Callable from transactions and modules |
| `public fun` | **Yes** | Callable from transactions and modules |
| `entry fun` | **Yes** | Callable from transactions, but not other modules |
| `fun` (private) | No | Not externally callable |
| `public(package) fun` | No | Only callable by other modules in the same package |

## Access Control Patterns

```move
// Object types have the key ability
public struct MyObject has key { id: ID, ... }

// Capability objects typically have names that end with "Cap"
public struct AdminCap has key { id: ID, ... }

// Shared objects are created via `public_share
public struct Pool has key { id: ID, ... }

// Object ownership provides access control
public fun use_owned_object(obj: &mut MyObject) {
    // Only owner of obj can call this
}

// Shared object - anyone can access
public fun use_shared(pool: &mut Pool) { }

// Shared Pool object gated by capability - only owner of AdminCap can call
public fun capability_gate(_cap: &AdminCap, pool: &mut Pool) {}
```

### Access Control Classification
| Pattern | Classification |
|---------|----------------|
| Owned object parameter | Owner of object |
| Shared object | Public (Unrestricted) |

## Contract-Only Detection

### Package-protected Functions
```move
// Only callable by other modules in the same Move package
public(protected) fun internal_fun() { }
```

## Extraction Strategy

1. Parse all `.move` files
2. Find `module` declarations
3. Extract `public`, `public entry`, and `entry` functions
4. Extract object type declarations (`struct`'s that have the `key` ability)
5. Determine whether each object type is **owned** (passed as parameter to `transfer` or `public_transfer` functions) or **shared** (passed as parameter to `share` or `public_share` functions)
6. Analyze parameters:
   - Owned object type with "XCap" in name -> X role (e.g., AdminCap = Admin role, GuardianCap = Guardian role)
   - Owned object type without "Cap" in name -> Owner role
   - Shared object type -> Public

## Move-Specific Considerations

1. **Object Model**: Access control typically through object ownership (rather than runtime assertions)
2. **Capabilities**: `Cap` suffix typically indicates capability pattern
4. **Generic Types**: Type parameters may carry capability constraints
5. **Package Visibility**: `public(pacakge)` limits callers to modules in the same package

## Common Gotchas

1. **Module Initializers**: `init` functions often create singletone shared objects and initial capabilities
2. **Object Wrapping**: Wrapped objects transfer ownership
3. **Shared vs Owned**: Shared objects can be accessed by anyone, owned objects only by a transaction sent by the owner
4. **Package Upgrades**: Upgrades can introduce new types and functions and change old ones in type-compatible ways
5. **Phantom Types**: Type parameters with `phantom` don't affect runtime

### references/move-aptos.md

# Move Entry Point Detection (Aptos)

## Entry Point Identification (State-Changing Only)

In Move, `public` functions can be invoked from transaction scripts (Aptos) and typically modify state. In addition, all `entry` functions are entrypoints. Package-protected (`public package`) and friend (`friend` or `public friend`) functions should be excluded.

### Aptos Move
```move
// Public entry functions are entry points
public entry fun transfer(from: &signer, to: address, amount: u64) { }

// Public functions callable by other modules
public fun helper(): u64 { }

// Entry-only functions (can't be called by other modules)
entry fun private_entry(account: &signer) { }
```

### Visibility Rules
| Visibility | Include? | Notes |
|------------|----------|-------|
| `public entry fun` | **Yes** | Transaction entry point (state-changing) |
| `entry fun` | **Yes** | Transaction-only entry point |
| `public fun` | No | Module-callable only, not direct entry |
| `fun` (private) | No | Not externally callable |
| `public(friend) fun` | No | Friend modules only |

## Access Control Patterns

### Signer-Based Control (Aptos)
```move
// Admin check via signer
public entry fun admin_action(admin: &signer) {
    assert!(signer::address_of(admin) == @admin_address, E_NOT_ADMIN);
}

// Owner check via resource
public entry fun owner_action(owner: &signer) acquires Config {
    let config = borrow_global<Config>(@module_addr);
    assert!(signer::address_of(owner) == config.owner, E_NOT_OWNER);
}
```

### Capability Pattern (Aptos)
```move
// Capability resource
struct AdminCap has key, store {}

// Requires capability
public entry fun admin_action(admin: &signer) acquires AdminCap {
    assert!(exists<AdminCap>(signer::address_of(admin)), E_NO_CAP);
}
```

### Access Control Classification
| Pattern | Classification |
|---------|----------------|
| `signer::address_of(s) == @admin` | Admin |
| `signer::address_of(s) == config.owner` | Owner |
| `exists<AdminCap>(addr)` | Admin (capability) |
| `exists<GovernanceCap>(addr)` | Governance |
| `exists<GuardianCap>(addr)` | Guardian |
| `&signer` with no checks | Review Required |

## Contract-Only Detection

### Friend Functions
```move
// Only callable by friend modules
public(friend) fun internal_callback() { }

// Friend declaration
friend other_module;
```

### Module-to-Module Patterns
```move
// Functions designed for other modules
public fun on_transfer_hook(amount: u64): bool {
    // Called by token module
}
```

## Extraction Strategy

### Aptos
1. Parse all `.move` files
2. Find `module` declarations
3. Extract functions with `public entry` or `entry` visibility
4. Check function body for:
   - `signer::address_of` comparisons → Role-based
   - `exists<*Cap>` checks → Capability-based
   - No access checks → Public (Unrestricted)

## Move-Specific Considerations

1. **Resource Model**: Access control often through resource ownership
2. **Capabilities**: `Cap` suffix typically indicates capability pattern
3. **Acquires**: `acquires Resource` shows what global resources are accessed
4. **Generic Types**: Type parameters may carry capability constraints
5. **Friend Visibility**: `public(friend)` limits callers to declared friends

## Common Gotchas

1. **Init Functions**: `init` or `initialize` often create initial capabilities
2. **Module Upgrades**: Check upgrade capability ownership
3. **Phantom Types**: Type parameters with `phantom` don't affect runtime