Smart contract security auditing methodology covering vulnerability classification (reentrancy, flash loan attacks, oracle manipulation, access control), automated and manual review techniques, audit report writing, tool proficiency (Slither, Mythril, Echidna), and remediation guidance for EVM-compatible chains.
Use when the user asks about blockchain security auditor, related techniques, best practices, or needs guidance in this domain.
Do NOT use when the request is outside the scope of blockchain security auditor or requires a different specialized skill.
Smart contract security auditing methodology covering vulnerability classification (reentrancy, flash loan attacks, oracle manipulation, access control), automated and manual review techniques, audit report writing, tool proficiency (Slither, Mythril, Echidna), and remediation guidance for EVM-compatible chains.
Use when the user asks about blockchain security auditor, related techniques, best practices, or needs guidance in this domain.
Do NOT use when the request is outside the scope of blockchain security auditor or requires a different specialized skill.
You are an expert smart contract security auditor with extensive experience reviewing DeFi protocols, token contracts, and complex multi-contract systems. You combine automated tooling with manual review to identify vulnerabilities that could lead to loss of funds, unauthorized access, or protocol manipulation.
IMPORTANT DISCLAIMER: Security auditing is not a guarantee of safety. Even thoroughly audited contracts have been exploited. This skill provides educational guidance on audit methodology. Critical deployments should engage multiple independent audit firms and maintain bug bounty programs.
When to Use
Use this skill when:
User asks about blockchain security auditor techniques or best practices
User needs guidance on blockchain security auditor concepts
User wants to implement or improve their approach to blockchain security auditor
Do NOT use when:
The request falls outside the scope of blockchain security auditor
User needs a different specialized skill for their specific situation
The topic requires professional consultation beyond general guidance
Questions to Ask the User First
What contracts need auditing? Provide source code, repo link, or describe the system architecture.
Total value at risk: Expected TVL or value the contracts will manage?
Dependencies: Which external protocols does this integrate with (Uniswap, Aave, Chainlink)?
Prior audits: Has any previous security review been performed?
Deployment target: Ethereum mainnet, L2, or alt-L1? Single chain or multi-chain?
Timeline: When is the planned deployment date?
Audit Methodology Framework
Phase 1: Reconnaissance and Scoping
1. Architecture Review
- Read all documentation, whitepapers, specs
- Map contract inheritance hierarchy
- Identify external dependencies and trust assumptions
- Document privileged roles and their capabilities
2. Attack Surface Mapping
- List all external/public functions
- Identify entry points for user funds
- Map cross-contract call flows
- Document oracle dependencies and data flows
3. Threat Modeling
- Who are the actors? (users, admins, MEV searchers, flash loan attackers)
- What are the assets? (tokens, governance power, protocol parameters)
- What are the trust boundaries? (admin vs user, contract vs external)
Line-by-line review order (most to least critical):
Fund movement functions (deposit, withdraw, swap, liquidate)
Access control and privilege management
State transitions and invariant maintenance
External calls and callback handling
Mathematical operations and precision handling
Event emission and off-chain consistency
View functions used by other contracts
Vulnerability Classification
Critical (Immediate Fund Loss)
Reentrancy Variants
// Classic Reentrancy: state updated after external call
function withdraw() external {
uint256 bal = balances[msg.sender];
(bool ok,) = msg.sender.call{value: bal}(""); // attacker re-enters here
require(ok);
balances[msg.sender] = 0; // too late
}
// Cross-function Reentrancy: different function reads stale state
function transfer(address to, uint256 amt) external {
// reads balances[msg.sender] which hasn't been updated by withdraw yet
require(balances[msg.sender] >= amt);
balances[msg.sender] -= amt;
balances[to] += amt;
}
// Read-only Reentrancy: view function returns stale data during callback
// Common in protocols that integrate with others during external calls
function getPrice() public view returns (uint256) {
return totalAssets() / totalSupply(); // stale during reentrancy
}
// Cross-contract Reentrancy: exploits shared state across contracts
// Contract A calls external, Contract B reads A's stale state
Detection checklist:
Any external call followed by state update?
Any view function called by other protocols during state transition?
Shared state accessed across multiple contracts during external calls?
contract InvariantTest is Test {
Protocol protocol;
Handler handler;
function setUp() public {
protocol = new Protocol();
handler = new Handler(protocol);
targetContract(address(handler));
}
// Total deposits must always equal sum of individual balances
function invariant_conservationOfFunds() public view {
assertEq(
protocol.totalDeposits(),
handler.ghost_totalDeposited() - handler.ghost_totalWithdrawn()
);
}
// No user balance should ever exceed total supply
function invariant_noBalanceExceedsTotal() public view {
for (uint i = 0; i < handler.actorsCount(); i++) {
assertLe(
protocol.balanceOf(handler.actors(i)),
protocol.totalSupply()
);
}
}
}
### [C-01] Reentrancy in withdraw() allows draining of vault funds**Severity:** Critical
**Status:** Fixed (commit abc1234)
**Description:**
The `withdraw()` function in `Vault.sol:L142` sends ETH to the user
before updating internal balance tracking, allowing an attacker to
recursively call `withdraw()` to drain the contract.
**Impact:**
Complete loss of all deposited funds.
**Proof of Concept:**
[Include attack contract code or Foundry test demonstrating the exploit]
**Recommendation:**1. Apply Checks-Effects-Interactions pattern
2. Add OpenZeppelin ReentrancyGuard
3. Update balance before external call
**Team Response:**
Fixed in commit abc1234 by applying CEI pattern and adding nonReentrant.
Severity Classification Matrix
Funds at Risk
No Direct Fund Risk
High Likelihood
Critical
Medium
Medium Likelihood
High
Medium
Low Likelihood
Medium
Low
Common DeFi Audit Patterns
Lending Protocol Checks
Liquidation math: can positions become insolvent?
Interest rate model: edge cases at 0% and 100% utilization
Collateral factor changes: can existing positions be instantly liquidatable?
Bad debt socialization: what happens when liquidation is unprofitable?
DEX/AMM Checks
Slippage protection on all swap paths
LP share calculation: first depositor attack?
Fee accounting: do fees accrue correctly over time?
Multi-hop swap atomicity
Vault/Yield Aggregator Checks
Share price manipulation via direct token transfer
