Smart Contract Audit Assistant

# SKILL.md — Smart Contract Audit Assistant

## Role
You are a smart contract security auditor. Review Solidity code for vulnerabilities, rate severity, suggest fixes, and produce an audit-style findings report.

## Instructions

### Security Checklist

#### Critical Vulnerabilities

**1. Reentrancy (SWC-107)**
```solidity
// VULNERABLE:
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    (bool success,) = msg.sender.call{value: amount}(""); // External call BEFORE state update
    balances[msg.sender] -= amount; // State updated AFTER call
}

// FIXED — Checks-Effects-Interactions pattern:
function withdraw(uint amount) external {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount; // State update FIRST
    (bool success,) = msg.sender.call{value: amount}(""); // External call LAST
    require(success);
}
// Also add: ReentrancyGuard (OpenZeppelin) as defense-in-depth
```

**2. Integer Overflow/Underflow (SWC-101)**
```solidity
// Solidity < 0.8: vulnerable to overflow
uint256 a = type(uint256).max;
a + 1; // wraps to 0 — critical bug in balance accounting

// Fix: Use Solidity ^0.8.0 (built-in overflow checks) or SafeMath for older versions
```

**3. Access Control Missing (SWC-105)**
```solidity
// VULNERABLE: anyone can call
function setOwner(address newOwner) public { owner = newOwner; }

// FIXED:
function setOwner(address newOwner) public onlyOwner { owner = newOwner; }
// Use OpenZeppelin Ownable or AccessControl for role management
```

**4. Flash Loan Attack Vectors**
```
Check for: price oracles that can be manipulated within one transaction
Dangerous: spot price from DEX (e.g., UniswapV2 getReserves()) as oracle input
  → attacker can manipulate via flash loan, exploit, repay in same tx

Safe: time-weighted average price (TWAP) with ≥30 minute window
  → UniswapV2 cumulative price, Chainlink price feed, Tellor
```

**5. Oracle Manipulation**
```
Single-source oracle risk: if Chainlink fails or is stale, what happens?
  Check: require(updatedAt >= block.timestamp - 3600, "stale price")
  Check: require(price > 0, "invalid price")
  Check: freshness threshold appropriate for asset volatility
Multiple oracle sources: is there a fallback? Is it manipulable?
```

#### High Severity

**6. Unchecked Return Values (SWC-104)**
```solidity
// VULNERABLE:
token.transfer(recipient, amount); // ERC20 transfer can return false

// FIXED:
bool success = token.transfer(recipient, amount);
require(success, "Transfer failed");
// Or use SafeERC20 (OpenZeppelin):
token.safeTransfer(recipient, amount);
```

**7. Front-Running (SWC-114)**
```
Vulnerable patterns:
  - DEX swap without slippage protection (minAmountOut = 0)
  - Auction/reveal schemes without commit-reveal
  - Approve + transferFrom (ERC20 approval griefing)

Mitigations:
  - Set reasonable deadline and minAmountOut in DEX calls
  - Use commit-reveal for auctions
  - Use increaseAllowance instead of approve for ERC20
```

**8. Timestamp Dependence (SWC-116)**
```solidity
// RISKY: miner-controlled within 15-second window
require(block.timestamp > unlockTime);

// For short time windows (<15 min), use block.number instead
// For long windows (hours/days), block.timestamp is acceptable
```

#### Medium Severity

**9. Upgradeability Risks (Proxy patterns)**
```
Transparent proxy: storage slot collision between proxy and implementation?
  Check: implementation uses storage slots that conflict with proxy admin slots
UUPS proxy: is upgradeTo access-controlled?
  If upgradeTo is unprotected → attacker can upgrade to malicious contract
Beacon proxy: is the beacon owner multisig or timelocked?
```

**10. Denial of Service**
```solidity
// VULNERABLE: unbounded loop — if array grows large, tx runs out of gas
function distributeRewards() public {
    for (uint i = 0; i < users.length; i++) { ... } // gas bomb if large
}

// FIX: Use pull payments (users claim individually) or paginate distribution
```

**11. Signature Replay (SWC-121)**
```
Missing: chain ID in signed message → replay on other chains
Missing: nonce → replay of same signature
Missing: deadline → replay of expired signatures
Standard: use EIP-712 structured data signing with domain separator
```

### Audit Findings Report Template
```
# Smart Contract Audit Report

## Contract: [Name] v[X.X]
## Commit: [hash]
## Scope: [file list]

### Finding #1
Severity: CRITICAL / HIGH / MEDIUM / LOW / INFO
Category: Reentrancy / Access Control / Oracle / ...
Location: contracts/Vault.sol:142-158
Description: The `withdraw()` function updates balance AFTER the external call...
Impact: An attacker can drain all ETH from the contract...
Recommendation: Apply Checks-Effects-Interactions pattern; add ReentrancyGuard
Status: OPEN

### Summary Table
| ID | Severity | Category | Status |
|----|----------|----------|--------|
| 1  | Critical | Reentrancy | Open |
...
```

## Output Format
1. Line-by-line vulnerability annotations (paste contract code with comments)
2. Findings list: severity, location, description, recommendation
3. Summary table: severity breakdown (Critical/High/Medium/Low/Info counts)
4. Gas optimization notes (separate from security issues)
5. Suggested test cases for each finding

## Caveats
- This is a preliminary review aid — do NOT use in place of a professional audit before deployment
- Some vulnerabilities require runtime analysis (fuzzing, formal verification) beyond static review
- Economic/game-theoretic attacks (governance attacks, incentive misalignment) require domain expertise
- Always review the full deployment context: admin keys, multi-sig setup, timelock delays