Solidity Smart Contract Audit Assistant

A structured smart contract security audit workflow based on EEA EthTrust Security Levels V3 specification.

Audit Process Overview

1. Project Preparation → 2. Automated Scanning → 3. Manual Review → 4. Testing & Verification → 5. Report Generation

⚡ Quick Audit Mode (Within 30 minutes)

Suitable for emergency situations or preliminary assessment:

1. Access Control Check (5 minutes)
   - Owner permissions
   - Sensitive function modifiers
   
2. Reentrancy Risk Check (5 minutes)
   - External call positions
   - State update order
   
3. Token Security Check (10 minutes)
   - SafeERC20 usage
   - Return value checks
   
4. Critical Vulnerability Scan (10 minutes)
   - Integer overflow
   - Signature verification
   - Permission bypass

📊 Audit Capability Baseline (Based on 10 rounds of training)

| Capability Dimension | AI Audit | Professional Audit | Gap | |---------------------|----------|-------------------|-----| | Basic Vulnerabilities | 90% | 100% | -10% | | Business Logic | 75% | 95% | -20% | | Math Boundaries | 50% | 85% | -35% | | Complex Interactions | 60% | 90% | -30% |

AI Advantages: Fast coverage, pattern matching, broad knowledge AI Disadvantages: Missing toolchain, limited depth analysis, boundary conditions

Step 1: Project Scope & Preparation

Input Confirmation

Contract source code (preferably frozen version for audit)
Compiler version and optimization settings
Project documentation (architecture diagrams, functional descriptions)
Test cases (if available)

Audit Scope Definition

□ Number of logic contracts and their functions
□ Whether proxy contracts are included (upgradeability)
□ External dependencies (oracles, cross-chain bridges, etc.)
□ Deployment network (mainnet/L2/testnet)

Security Level Selection

| Level | Applicable Scenarios | Core Requirements | |-------|---------------------|-------------------| | [S] Basic | Simple token contracts, basic DeFi | No known high-risk vulnerabilities, basic protection | | [M] Intermediate | Complex DeFi, NFT markets, DAOs | External call security, access control, oracle verification | | [Q] Advanced | Cross-chain bridges, lending protocols, treasury management | Business logic verification, MEV protection, complete documentation |

Pre-Audit Checklist

[ ] Code is frozen, no modifications during audit period
[ ] Compiler version is fixed (e.g., pragma solidity 0.8.20)
[ ] All dependency versions are locked
[ ] Deployment scripts or configurations are provided
[ ] Test coverage report is available (if exists)

Step 2: Automated Tool Scanning

Static Analysis Tools

Slither (Trail of Bits)

# Installation
pip install slither-analyzer

# Basic scan
slither . --exclude-dependencies

# Output JSON format
slither . --exclude-dependencies --json output.json

# Specific detectors
slither . --detect reentrancy-eth,uninitialized-state

Aderyn (Rust-based, fast)

# Installation
cargo install aderyn

# Scan
aderyn .

# Output report
aderyn . -o report.md

Tool Output Mapping to EEA Specification

| Tool Detection | EEA Requirement | Security Level | |----------------|-----------------|----------------| | tx.origin usage | [S] No tx.origin | S | | selfdestruct | [S] No selfdestruct() | S | | CREATE2 | [S] No CREATE2 | S | | assembly blocks | [S] No assembly {} | S | | Reentrancy detection | [M] External Calls | M | | Uninitialized variables | [S] Initialize State | S | | Unchecked return values | [M] Check Return Values | M |

Compiler Version Check

# Check for known compiler bugs
slither . --check-compiler-bugs

Refer to EEA § 3.9 Source code, pragma, and compilers for compiler-related security requirements.

Step 3: Manual Review Checklist

[S] Basic Level Review

3.1 Replay Attack Protection

// Check: Does transaction hash include chainId?
// Correct example:
keccak256(abi.encodePacked(
    "\x19\x01",
    DOMAIN_SEPARATOR,  // Includes chainId
    hashStruct
))

// Dangerous: Without chainId allows cross-chain replay

3.2 Dangerous Opcodes

[ ] Check CREATE2 usage justification, whether necessary
[ ] Check selfdestruct calls, confirm legitimate reason
[ ] Verify delegatecall target address controllability

3.3 Permission Verification

// Dangerous: Using tx.origin for authorization
require(tx.origin == owner);  // Phishing attack risk

// Correct: Use msg.sender
require(msg.sender == owner);

3.4 Encoding Security

// Dangerous: Hash collision with consecutive variable-length parameters
keccak256(abi.encodePacked(str1, str2));  // str1="ab", str2="c" == str1="a", str2="bc"

// Safe: Use encode or fixed length
keccak256(abi.encode(str1, str2));

3.5 Inline Assembly

[ ] List all assembly blocks
[ ] Check if detailed comments explain the reason
[ ] Focus on memory operations and storage operations

[M] Intermediate Level Review

3.6 External Calls & Reentrancy

// CEI Pattern Check (Checks-Effects-Interactions)
function withdraw() external {
    // 1. Checks
    require(balances[msg.sender] > 0, "No balance");
    
    // 2. Effects (update state first)
    balances[msg.sender] = 0;
    
    // 3. Interactions (external calls last)
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
}

// Read-only reentrancy check: Are view functions called externally before state updates?

3.7 Oracle Dependencies

[ ] Is the price data source trustworthy?
[ ] Is there a TWAP time window?
[ ] Is there a data staleness detection mechanism?
[ ] Is there a failover plan?

// Check: Is there price deviation detection?
uint256 price = oracle.getPrice();
require(price > 0 && price < MAX_PRICE, "Invalid price");

// Check: Is there timestamp validation?
require(block.timestamp - oracle.lastUpdate() < HEARTBEAT, "Stale data");

3.8 Access Control

[ ] Check permission modifiers on critical functions
[ ] Is role management correctly implemented
[ ] Can initialization functions be called repeatedly

// Dangerous: Unprotected initialization function
function initialize() external {
    owner = msg.sender;  // Anyone can call!
}

// Safe: Use OpenZeppelin Initializable
function initialize() external initializer {
    owner = msg.sender;
}

3.9 Integer Overflow

// Solidity 0.8+ checks overflow by default
// But need to check unchecked blocks:
unchecked {
    // Overflow here will not be detected!
    uint256 result = a + b;  // Dangerous
}

// Special case: Loop counters can safely use unchecked
for (uint256 i; i < n; ) {
    // ...
    unchecked { i++; }
}

[Q] Advanced Level Review

3.10 Logic & Documentation Consistency

[ ] Compare code implementation with whitepaper/documentation
[ ] Check for undocumented "hidden features"
[ ] Verify mathematical formula implementation correctness

3.11 MEV Attack Surface

[ ] Sandwich attack risk (AMM pricing)
[ ] Front-running risk (public mempool)
[ ] Liquidation mechanism exploitable

// AMM sandwich attack example
// User transaction: A -> B
// Attacker: Buy B before user transaction, sell B after
// Protection: Use TWAP, slippage protection

3.12 Upgradeable Contract Security

// Check items:
// 1. Is the proxy contract implementation correct?
// 2. Is the initialization function protected against reentry?
// 3. Are upgrade permissions reasonable?
// 4. Is there storage layout conflict?

// Dangerous: Storage layout conflict
// V1: uint256 a; uint256 b;
// V2: uint256 a; address c; uint256 b;  // c overwrites b's slot!

Special Focus: Governance Module

Governance contract vulnerabilities are often more subtle but have greater impact, requiring specialized review.

3.13 Voting Power & Stake Synchronization

// Dangerous example: State sync uses wrong account balance
function notifyFor(address account) external {
    _notifyFor(account, balanceOf(msg.sender));  // Wrong!
    // Should be balanceOf(account)
}

// Check points:
// 1. Is governance module synchronized with main contract state
// 2. Does notify function use correct account address
// 3. Is stake increase/decrease order correct

3.14 Voting Mechanism Security

[ ] Can users manipulate results through extreme voting
[ ] Is voting weight calculation correct
[ ] Is voting cooldown period reasonable

3.15 Copy-Paste Error Detection

// High-risk pattern: Similar code blocks
function _beforeTokenTransfer(address from, address to, uint256 amount) {
    uint256 balanceFrom = (from != address(0)) ? balanceOf(from) : 0;
    uint256 balanceTo = (from != address(0)) ? balanceOf(to) : 0;  // Copy-paste error!
    // Should be: (to != address(0)) ? balanceOf(to) : 0
}

// Detection method:
// 1. Find code blocks with > 80% similarity
// 2. Compare each difference character by character
// 3. Verify each difference is intentional

Special Focus: System Architecture

3.16 Contract Dependency Analysis

Must Complete:

Draw contract dependency graph
Mark external call directions
Identify trust boundaries

Example dependency graph:
┌─────────────────┐
│ GovernanceMothership │
│ (Master)        │
└────────┬────────┘
         │ notify
         ▼
┌─────────────────┐    ┌─────────────────┐
│ FactoryGovernance │    │ RewardsGovernance │
│ (Slave 1)       │    │ (Slave 2)       │
└─────────────────┘    └─────────────────┘

Check Points:

[ ] Do Slave contracts trust Master
[ ] Can external contract addresses be replaced
[ ] Is state synchronization safe

3.17 Trust Assumption Verification

[ ] "Only contracts deployed by factory are trusted" → Is there verification?
[ ] "Governance tokens have no callbacks" → Is there checking?
[ ] "Price oracle returns real price" → Is there boundary checking?

Special Focus: Permission Model

3.18 Admin Permission Scope

// List all onlyOwner/onlyAdmin functions
// Analyze impact scope of each function

// Dangerous pattern: Admin can lock user funds
function emergencyPause() external onlyOwner {
    paused = true;  // Users cannot withdraw funds!
}

// Dangerous pattern: Parameter modification without timelock
function setFeeReceiver(address newReceiver) external onlyOwner {
    feeReceiver = newReceiver;  // Can immediately set malicious contract
}

3.19 Permission Bypass Check

[ ] Can removeMarket + addMarket bypass time restrictions
[ ] Does adding/removing sub-modules affect fund safety
[ ] Does modifying contract addresses bypass security checks

3.20 Timelock Integrity

[ ] Do all critical parameter changes have timelock
[ ] Does timelock cover all bypass paths
[ ] Do users have enough time to respond

Special Focus: Flash Loans & Oracles

3.21 Flash Loan Attack Surface

// Check point: State validation after flash loan callback
// Dangerous example: Only check balance, not mapping
function flashLoan(uint256 amount) external {
    uint256 balanceBefore = address(this).balance;
    IFlashLoanReceiver(msg.sender).execute{value: amount}();
    // ⚠️ Only check balance, not balances mapping!
    if (address(this).balance < balanceBefore) revert RepayFailed();
}

// Correct approach: Check all relevant states
function flashLoan(uint256 amount) external {
    uint256 balanceBefore = address(this).balance;
    uint256 depositsBefore = totalDeposits;  // Record mapping state
    IFlashLoanReceiver(msg.sender).execute{value: amount}();
    require(address(this).balance >= balanceBefore, "Balance not restored");
    require(totalDeposits == depositsBefore, "Deposits changed");  // Verify mapping
}

3.22 Oracle Manipulation Protection

// Dangerous: Using current reserves as price
function _computePrice() private view returns (uint256) {
    return uniswapPair.balance * 1e18 / token.balanceOf(uniswapPair);
    // ⚠️ Reserves can be manipulated by large trades!
}

// Safe: Use TWAP or Chainlink
function _computePrice() private view returns (uint256) {
    (uint256 price0Cumulative, uint256 price1Cumulative,) = 
        UniswapV2OracleLibrary.currentCumulativePrices(pair);
    // Use time-weighted average price
}

// Safe Chainlink usage
function getPrice() public view returns (uint256) {
    (, int256 price,, uint256 timestamp,) = oracle.latestRoundData();
    require(price > 0, "Invalid price");
    require(block.timestamp - timestamp < HEARTBEAT, "Stale data");
    return uint256(price);
}

3.23 Governance Voting Power Persistence

// Dangerous: Only check current voting power
function queueAction(...) external returns (uint256) {
    if (!_hasEnoughVotes(msg.sender)) revert NotEnoughVotes();
    // ⚠️ Attacker can temporarily gain voting power via flash loan!
}

// Safe: Require voting power holding time
function queueAction(...) external returns (uint256) {
    if (!_hasHeldVotesFor(msg.sender, VOTING_DELAY)) revert NotEnoughVotes();
    // Check voting power for past N blocks
}

function _hasHeldVotesFor(address who, uint256 blocks) private view returns (bool) {
    for (uint256 i = 0; i < blocks; i++) {
        if (getVotesAtBlock(who, block.number - i) <= threshold) return false;
    }
    return true;
}

SecureUM Quick Checklist

See references/secureum-knowledge.md for details

Top 30 Must-Check Items

| # | Check Item | Description | Reference | |---|------------|-------------|-----------| | 1 | pragma version locked | pragma solidity 0.8.20; not ^0.8.0 | #2 | | 2 | Access control completeness | All sensitive functions have permission modifiers | #4-8 | | 3 | delegatecall target verification | Target address must be trusted | #12 | | 4 | Reentrancy protection | CEI pattern or ReentrancyGuard | #13-15 | | 5 | Random number safety | Don't use block.timestamp/blockhash as random source | #17 | | 6 | Integer overflow | Check unchecked blocks | #19 | | 7 | Multiply before divide | Avoid precision loss | #20 | | 8 | ERC20 approve race | approve(0) then approve(new) | #22, #105 | | 9 | Signature malleability | Verify signature format before ecrecover | #23 | | 10 | ERC20 return values | Use SafeERC20 | #24 | | 11 | Unexpected ETH | selfdestruct can force send ETH | #26 | | 12 | tx.origin authorization | Prohibit for authorization checks | #30 | | 13 | mapping deletion | Deleting struct doesn't clear internal mapping | #32 | | 14 | Low-level call return values | Check call/send/delegatecall return values | #37 | | 15 | External calls in loops | May cause DoS | #43 | | 16 | Unbounded loops | May cause out of gas | #44 | | 17 | Event emission | Emit events for critical state changes | #45 | | 18 | Zero address validation | Check address parameters | #49 | | 19 | require vs assert | require for conditions, assert for invariants | #52 | | 20 | Deprecated keywords | Avoid throw/callcode/suicide | #53 | | 21 | Function visibility | Must be explicitly declared | #54 | | 22 | Inheritance order | Affects initialization order | #55 | | 23 | Hash collision | abi.encodePacked with multiple variable parameters | #60 | | 24 | Assembly code | Needs detailed comments and review | #63 | | 25 | Uninitialized variables | Especially storage pointers | #67-68 | | 26 | Proxy initialization protection | initializer modifier | #95-96 | | 27 | Proxy storage layout | Maintain consistency during upgrades | #99 | | 28 | ERC777 hooks | May trigger reentrancy | #106 | | 29 | Deflationary/inflationary tokens | Transfer amounts may not match | #107-108 | | 30 | Two-step permission change | Critical operations need timelock or two-step verification | #162-163 |

Audit Process

1. Read specification docs → 2. Run static analyzers → 3. Manual code review
4. Run deep tools → 5. Discuss with team → 6. Write report

Manual Review Approaches

| Method | Starting Point | |--------|----------------| | Access Control | Start with permission checks | | Asset Flow | Start with asset flow | | Control Flow | Evaluate control flow | | Data Flow | Evaluate data flow | | Constraints | Infer constraint conditions | | Dependencies | Understand dependencies | | Assumptions | Evaluate assumptions | | Checklists | Use checklists |

Security Design Principles

Least Privilege - Grant only necessary permissions
Separation of Privilege | Critical operations require multiple authorizations
Fail-safe Defaults - Default to deny, not allow
Complete Mediation - Check permissions on every access
Open Design - Security doesn't depend on secrecy

Step 4: Testing & Verification

Foundry Test Framework

# Installation
curl -L https://foundry.paradigm.xyz | bash
foundryup

# Initialize
forge init my-test

# Run tests
forge test -vvv

# Fuzz testing
forge test --fuzz-runs 10000

# Gas report
forge test --gas-report

Vulnerability PoC Template

// test/ReentrancyPoC.t.sol
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import "forge-std/Test.sol";
import "../src/VulnerableContract.sol";

contract ReentrancyPoC is Test {
    VulnerableContract target;
    Attacker attacker;
    
    function setUp() public {
        target = new VulnerableContract();
        attacker = new Attacker(address(target));
        vm.deal(address(target), 10 ether);
        vm.deal(address(attacker), 1 ether);
    }
    
    function test_Reentrancy() public {
        uint256 initialBalance = address(attacker).balance;
        
        // Execute attack
        attacker.attack{value: 1 ether}();
        
        // Verify: Attacker balance should be greater than initial
        assertGt(address(attacker).balance, initialBalance);
        console.log("Stolen:", address(attacker).balance - initialBalance);
    }
}

contract Attacker {
    VulnerableContract target;
    
    constructor(address _target) {
        target = VulnerableContract(_target);
    }
    
    function attack() external payable {
        target.deposit{value: msg.value}();
        target.withdraw();
    }
    
    receive() external payable {
        if (address(target).balance > 0) {
            target.withdraw();
        }
    }
}

Fuzz Testing Example

// test/FuzzTest.t.sol
function testFuzz_Transfer(address to, uint256 amount) public {
    vm.assume(to != address(0));
    vm.assume(to != address(this));
    vm.assume(amount <= token.balanceOf(address(this)));
    
    uint256 balanceBefore = token.balanceOf(to);
    token.transfer(to, amount);
    uint256 balanceAfter = token.balanceOf(to);
    
    assertEq(balanceAfter - balanceBefore, amount);
}

Test Coverage Requirements

| Vulnerability Type | Test Method | Coverage Target | |-------------------|-------------|-----------------| | Reentrancy attacks | Unit tests + PoC | All external call points | | Integer overflow | Fuzz testing | unchecked blocks | | Access control | Unit tests | All permission functions | | Business logic | Integration tests | Core functionality paths |

Step 5: Report Generation

Report Structure Template

# [Project Name] Smart Contract Security Audit Report

## 1. Summary
- **Audit Period**: YYYY-MM-DD to YYYY-MM-DD
- **Audit Scope**: Contract list and versions
- **Security Level Target**: [S]/[M]/[Q]
- **Total Findings**: High X / Medium Y / Low Z / Informational W

## 2. Audit Scope
| File | Lines | Description |
|------|-------|-------------|
| ContractA.sol | 123 | Core logic |
| ContractB.sol | 456 | Proxy contract |

## 3. Findings Details

### [High] R-01: Reentrancy Vulnerability
**Location**: `Vault.sol#withdraw()` line 42  
**EEA Spec**: Violates [M] External Calls  
**Description**: External call before state update, attacker can reenter to drain funds  
**Impact**: Funds can be completely stolen  

**Reproduction Steps**:
1. Deploy attacker contract
2. Call deposit to deposit 1 ETH
3. Call withdraw to trigger reentrancy
4. Verify contract balance is zero

**Recommendation**:
```solidity
// Use ReentrancyGuard or CEI pattern
function withdraw() external nonReentrant {
    // ...
}

4. Test Coverage

Static analysis: Slither 4.12.0
Dynamic testing: Foundry fuzz + unit tests
Coverage: XX%

5. EEA Compliance Statement

| Requirement | Status | Notes | |-------------|--------|-------| | [S] No tx.origin | ✅ Pass | - | | [S] No selfdestruct | ✅ Pass | - | | [M] External Calls | ❌ Fail | R-01 | | [Q] Documentation | ⚠️ Partial | Missing architecture diagram |

6. Appendix

Compiler version: solc 0.8.20
Optimization settings: enabled, runs=200
Deployment network: Ethereum Mainnet


## References

### Detailed Reference Documents
- **EEA Specification Details**: See [references/eea-requirements.md](references/eea-requirements.md)
- **Vulnerability Checklist**: See [references/vulnerability-checklist.md](references/vulnerability-checklist.md)
- **Testing Guide**: See [references/testing-guide.md](references/testing-guide.md)
- **SecureUM Knowledge Base**: See [references/secureum-knowledge.md](references/secureum-knowledge.md) - 200+ audit knowledge points

### External Resources
- EEA EthTrust V3 Specification: https://entethalliance.org/specs/ethtrust-sl/v3/
- Secureum Knowledge Graph: https://github.com/x676f64/secureum-mind_map
- OpenZeppelin Contracts: https://docs.openzeppelin.com/contracts
- EIP Standards List: https://eips.ethereum.org/all
- Mastering Ethereum: https://masteringethereum.xyz/

### Common Tools
| Tool | Purpose | Link |
|------|---------|------|
| Slither | Static analysis | https://github.com/crytic/slither |
| Aderyn | Fast scanning | https://github.com/Cyfrin/aderyn |
| Foundry | Test framework | https://github.com/foundry-rs/foundry |
| Echidna | Fuzz testing | https://github.com/crytic/echidna |
| Mythril | Symbolic execution | https://github.com/ConsenSys/mythril |

## Usage Example

User: Help me audit this ERC20 contract for security

AI: I will perform a basic audit following EEA EthTrust specification:

Project Preparation
- Please provide contract source code
- Target security level: [S] Basic
Execute Scanning
- Running Slither static analysis...
- Detected the following issues...
Manual Review
- Checking access control...
- Checking reentrancy risks...


## Audit Capability Assessment Framework

### Audit Quality Self-Assessment

After completing an audit, use this framework for self-evaluation:

| Dimension | Check Item | Assessment Method |
|-----------|------------|-------------------|
| Coverage | Did you review all core contracts | Contract checklist |
| Depth | Did you discover complex logic vulnerabilities | PoC verification |
| Tools | Did you use automated tools | Slither/Aderyn reports |
| Comparison | Compare with professional reports | Gap analysis |

### Capability Level Classification

| Level | Standard | Typical Performance |
|-------|----------|---------------------|
| Junior | Can find basic vulnerabilities | Reentrancy, permission issues, overflow |
| Intermediate | Can find business logic issues | Price manipulation, liquidation issues |
| Senior | Can find complex interaction vulnerabilities | Cross-chain, composability attacks |
| Expert | Can design security architecture | Formal verification, zero-knowledge proofs |

### Audit Time Reference

| Contract Size | Junior | Intermediate | Senior |
|---------------|--------|--------------|--------|
| <500 lines | 2 hours | 1 hour | 30 minutes |
| 500-2000 lines | 8 hours | 4 hours | 2 hours |
| 2000-10000 lines | 40 hours | 20 hours | 10 hours |
| >10000 lines | 2 weeks+ | 1 week+ | 3 days+ |

### Common Missed Checks

After completing an audit, check if you missed:

- [ ] Callback function security
- [ ] Multi-signature/timelock configuration
- [ ] Special token compatibility (rebasing, fee-on-transfer)
- [ ] Cross-chain message verification
- [ ] Price precision issues
- [ ] Gas limit boundary conditions
- [ ] Upgrade pattern security
- [ ] Signature verification security

### 🎯 Professional Audit Comparison Template

After completing an audit, compare using this format:

```markdown
## My Findings vs Professional Audit

### Matched Items
| My Finding | Professional Audit Finding | Match Level |
|------------|---------------------------|-------------|
| Reentrancy risk | ✅ Usually found | High |
| Permission issues | ✅ Usually found | High |

### Missed Items
| Professional Finding | Why I Missed It |
|---------------------|-----------------|
| Math boundaries | Need fuzz testing |
| Interaction vulnerabilities | Need symbolic execution |

### Capability Score
- This round score: X/100
- Cumulative average: Y/100

📈 Audit Capability Improvement Path

| Stage | Target | Method | |-------|--------|--------| | Junior→Intermediate | 78→85 points | More practice cases, learn vulnerability patterns | | Intermediate→Senior | 85→92 points | Use toolchain, deep protocol research | | Senior→Expert | 92→98 points | Formal verification, innovative attack vectors |

🔧 Toolchain Gap Solution (Addressing 60% gap)

Problem: AI cannot directly run Slither/Foundry

Solution: Request user to run tools, AI analyzes results

Please provide tool scan results for audit:

# Slither quick scan
slither . --exclude-dependencies --json slither.json

# Or Aderyn scan
aderyn . -o report.md

Provide the output to me, and I will combine tool findings with deep analysis.

Tool Output Mapping:

| Slither Detector | AI Analysis Focus | |------------------|-------------------| | reentrancy-eth | Verify reentrancy protection | | uninitialized-state | Check initialization | | arbitrary-send | Verify sending logic | | controlled-delegatecall | Verify target address |

⏱️ Time Optimization Solution (Addressing 25% gap)

Problem: Limited audit time

Solution: Focus on high-risk modules

35-minute Allocation:

Access Control (5 minutes): owner/governor/permission modifiers
Reentrancy Check (5 minutes): external calls + state update order
Token Security (10 minutes): SafeERC20/return value checks
Critical Vulnerabilities (10 minutes): liquidation/price/permission bypass
Report Output (5 minutes): formatted output

High-Risk Function Priority:

withdraw/transfer/claim
liquidate/absorb/seize
setOwner/setConfig
getPrice/updatePrice

📚 Knowledge Gap Solution (Addressing 15% gap)

Problem: Unfamiliar with new protocol features

Solution: Protocol type knowledge base

| Protocol Type | Core Check Points | |---------------|-------------------| | AMM | Price calculation, liquidity, slippage | | Lending | Liquidation factors, interest rates, oracles | | Cross-chain | Signature verification, message replay | | Aggregator | Interaction order, composability risks | | NFT | Transfers, royalties, authorization |

See: references/toolchain-guide.md for details