solidity-audit

---

name: solidity-audit description: > Solidity smart contract security audit assistant following EEA EthTrust V3 specification. Performs structured audit workflow: vulnerability scanning, security analysis, audit reports. Detects reentrancy, integer overflow, access control issues, and more. Supports Slither/Aderyn static analysis and Foundry testing. Triggers: smart contract audit, solidity audit, security review, vulnerability assessment.

---

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: 1. Draw contract dependency graph 2. Mark external call directions 3. 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

1. Least Privilege - Grant only necessary permissions 2. Separation of Privilege | Critical operations require multiple authorizations 3. Fail-safe Defaults - Default to deny, not allow 4. Complete Mediation - Check permissions on every access 5. 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

Vulnerability Checklist: See references/vulnerability-checklist.md

Testing Guide: See references/testing-guide.md

SecureUM Knowledge Base: See 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:
1. Project Preparation
   - Please provide contract source code
   - Target security level: [S] Basic
   
2. Execute Scanning
   - Running Slither static analysis...
   - Detected the following issues...
3. 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:

## 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: 1. withdraw/transfer/claim 2. liquidate/absorb/seize 3. setOwner/setConfig 4. 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