blockchain-securityUse this skill when asked about blockchain security, smart contract auditing, DeFi threat modeling, blockchain incident response, bug bounty programs, economic security, formal verification of smart contracts, and blockchain-specific security analysis. Languages: Solidity, Python, Rust, Haskell. Covers threat modeling for DeFi protocols (STRIDE for blockcha…
Independent GitHub snapshot · Automated classification · Original documentation governs
Guide blockchain-specific security analysis covering smart contract auditing, DeFi threat modeling, economic security, incident response, formal verification, and bug bounty programs. Combines traditional security engineering with blockchain-specific risks like economic attack vectors, flash loans, oracle manipulation, and MEV.
"blockchain security", "smart contract audit", "DeFi security", "DeFi threat model", "blockchain threat modeling", "audit methodology", "blockchain incident response", "emergency pause", "fork coordination", "bug bounty", "Immunefi", "Code4rena", "economic security", "game theory blockchain", "incentive analysis", "MEV security", "certora", "formal verification blockchain", "Halmos", "Scribble", "solidity security", "smart contract vulnerability", "blockchain exploit", "flash loan attack", "oracle manipulation", "reentrancy", "access control blockchain", "cross-chain security", "bridge security"
Security analysis including: threat model, vulnerability findings, economic analysis, verification approach, and remediation recommendations.
5000 tokens
Security need:
├── Pre-deployment audit?
│ ├── Early stage → Threat modeling + architecture review
│ │ ├── Identify trust assumptions
│ │ ├── Map attack surface
│ │ └── Design security controls
│ ├── Mid-development → Full audit (automated + manual + fuzz)
│ │ ├── Slither + Mythril static analysis (first pass)
│ │ ├── Manual line-by-line review (second pass)
│ │ ├── Foundry fuzz + invariant tests (third pass)
│ │ ├── Echidna/Medusa property-based fuzzing (fourth pass)
│ │ └── Certora/Halmos formal verification (fifth pass)
│ └── Pre-launch → Final audit + bug bounty launch
│ ├── Re-audit after fixes
│ ├── Immunefi or Code4rena bounty program
│ └── Emergency response plan
├── Incident response?
│ ├── Ongoing exploit → Emergency pause + communication
│ ├── Post-exploit → Damage assessment + recovery plan
│ └── Post-mortem → Root cause analysis + fix implementation
└── Ongoing security?
├── Continuous monitoring → Forta, Tenderly alerts
├── Bug bounty management → VRT, severity classification
└── Periodic review → Quarterly parameter review, annual deep audit
| Severity | Impact | Payout Range |
|---|---|---|
| Critical | Direct loss of funds, permanent DoS | Up to $10M+ |
| High | Theft of unclaimed yield, temporary DoS | $50K-$500K |
| Medium | Contract fails to deliver expected return, temporarily frozen funds | $5K-$50K |
| Low | Griefing (no direct financial loss) | $1K-$5K |
| None | Informational | No payout |
| Threat | Blockchain Equivalent | Example |
|---|---|---|
| Spoofing | Fake event log emission, counterfeit token | Impostor token impersonation |
| Tampering | State manipulation, reorg, flash loan price | Manipulating oracle price |
| Repudiation | Unauthorized proposal, fake governance | Flash loan governance attack |
| Information disclosure | Mempool snooping, frontrunning | MEV extraction from public tx pool |
| Denial of Service | Gas griefing, block stuffing | Low-cost DoS via state bloat |
| Elevation of Privilege | Unauthorized role assignment, proxy admin | OpenZeppelin UUPS unauthorized upgrade |
Reentrancy Attack Tree
├── External call before state update
│ ├── ETH transfer via .call{value}() (forward all gas)
│ ├── ERC-777 callback (tokensToSend hook)
│ └── ERC-1155 callback (onERC1155Received)
├── Recipient is malicious contract
│ └── Malicious fallback re-enters victim function
└── Mitigations:
├── Checks-effects-interactions pattern
├── ReentrancyGuard (OpenZeppelin)
└── Pull-over-push for payments
Oracle Manipulation Attack Tree
├── Single oracle price source
│ ├── Flash loan to manipulate AMM price
│ ├── Sandwich attack on oracle update
│ └── Frontrun oracle transaction
├── TWAP manipulation
│ └── Multi-block TWAP manipulation (expensive but possible)
└── Mitigations:
├── Redundant oracles (minimum 3 independent sources)
├── TWAP with sufficient window (30 min+)
├── Stale price checks (max age < 1 hour)
└── Circuit breakers on price deviation
Flash Loan Attack Tree
├── Borrow large capital from flash loan provider
├── Manipulate price (AMM swap → oracle price change)
├── Exploit protocol with manipulated price
│ ├── Mint undercollateralized position
│ ├── Drain pool via mispriced asset
│ └── Trigger false liquidations
└── Repay flash loan + profit
// VULNERABLE
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount);
(bool ok, ) = msg.sender.call{value: amount}(""); // external call BEFORE state
require(ok);
balances[msg.sender] -= amount; // state update AFTER
}
// FIXED: CEI pattern
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount);
balances[msg.sender] -= amount; // state update FIRST
(bool ok, ) = msg.sender.call{value: amount}(""); // then external call
require(ok);
}
// VULNERABLE: init function unprotected
function initialize(address _owner) external {
owner = _owner; // anyone can call this
}
// FIXED
function initialize(address _owner) external initializer {
__Ownable_init(_owner);
}
// VULNERABLE: tx.origin for auth
function adminOnly() external {
require(tx.origin == owner); // tx.origin can be phished
}
// FIXED: msg.sender for auth
function adminOnly() external {
require(msg.sender == owner);
}
// VULNERABLE: uses spot price for liquidation
function getLiquidationValue(address user) external view returns (uint256) {
return collateral[user] * getSpotPrice(); // Can be manipulated
}
// FIXED: uses TWAP
function getLiquidationValue(address user) external view returns (uint256) {
return collateral[user] * getTWAP(30 minutes); // Manipulation resistant
}
// VULNERABLE: first depositor manipulates share price
// Attacker mints 1 wei shares, then donates large amount to vault
// share price becomes very high → subsequent depositors get 0 shares
// FIXED: virtual shares + assets
uint256 internal constant VIRTUAL_SHARES = 1e6;
uint256 internal constant VIRTUAL_ASSETS = 1e6;
function convertToShares(uint256 assets) public view returns (uint256) {
uint256 supply = totalSupply + VIRTUAL_SHARES;
return assets * supply / (totalAssets() + VIRTUAL_ASSETS);
}
| Tool | Type | Best For | Limitations |
|---|---|---|---|
| Slither | Static analysis | First-pass vulnerability detection, inheritance analysis | False positives, limited deep logic |
| Mythril | Symbolic execution | Complex state-exploration bugs | Slow, state explosion |
| Echidna | Property-based fuzzing | Invariant testing with custom properties | Requires writing properties |
| Foundry fuzz | Parameterized fuzzing | Input-range fuzzing, stateful tests | Less directed than Echidna |
| Certora | Formal verification | Critical invariants, solvency proofs | Expensive, requires CVL DSL |
| Halmos | Symbolic testing | Bounded verification of assertions | Not fully automated |
| Aderyn | Static analysis | Solidity spec compliance | Limited depth |
// Certora Verification Language: define invariants
rule total_supply_invariant() {
// totalSupply must equal sum of all balances
uint256 total = totalSupply();
uint256 sum = 0;
address user;
// Quantified assertion over all users (handled by Certora)
assert total == currentContract.balance + sumOfAllUserBalances();
}
rule no_double_withdrawal(address user) {
uint256 balance_before = balanceOf(user);
uint256 amount = balance_before / 2;
withdraw(amount);
withdraw(amount);
uint256 balance_after = balanceOf(user);
assert balance_after == 0;
}
Protocol economic security:
├── Nash equilibrium analysis
│ ├── Does a rational user have incentive to act honestly?
│ └── Is there a profitable deviation path?
├── Attack cost vs. profit
│ ├── How much capital required for exploit?
│ └── What is the expected profit from exploit?
├── MEV analysis
│ ├── What MEV opportunities exist?
│ └── Can MEV disrupt protocol equilibrium?
└── Composability risk
├── What other protocols does this interact with?
└── Can a failure cascade through the system?
// Emergency pause pattern
contract Pausable {
bool public paused;
address public guardian;
modifier whenNotPaused() {
require(!paused, "PAUSED");
_;
}
function pause() external {
require(msg.sender == guardian, "NOT_GUARDIAN");
paused = true;
emit EmergencyPaused(msg.sender);
}
function unpause() external {
require(msg.sender == guardian, "NOT_GUARDIAN");
paused = false;
emit EmergencyUnpaused(msg.sender);
}
}
1. DETECT: Monitoring alert, community report, or security partner notification
- Forta bot detects anomalous activity
- Tenderly alert on unexpected state changes
- Community report via Discord/Immunefi
2. ASSESS: Guardian multi-sig evaluates severity (15-30 min)
- Is there an active exploit?
- What is compromised? (contract, key, oracle, bridge?)
- What is the damage scope? (TVL at risk)
3. PAUSE: Guardian pauses affected contracts
- Emergency pause kill switch (guardian only)
- Stop deposits, withdraws, liquidations as needed
- Can't pause critical owner functions (timelock bypass)
4. COMMUNICATE: Pre-prepared message template
- "We are aware of an issue with [contract]. All funds are safe. Paused while investigating."
- Twitter/Discord/Governance forum within 30 min
- Regular updates every 2 hours
5. MITIGATE: Emergency proposal with fix
- Upgrade contract (if upgradeable) or deploy new version
- Requires timelock delay (unless emergency bypass)
6. RESUME: Governance vote to unpause + validate fix
- Multi-sig unpause after fix confirmed
- Bug bounty payout for reporter
7. POST-MORTEM: Public incident report within 7 days
- Root cause analysis
- Timeline of events
- Fix details
- Lessons learned
contract ProtectedVault {
using SafeERC20 for IERC20;
uint256 private _status = 1; // 1=unlocked 2=locked
modifier nonReentrant() {
require(_status == 1, "Reentrant call");
_status = 2; _;
_status = 1;
}
function withdraw(uint256 amount) external nonReentrant {
uint256 bal = balances[msg.sender];
require(bal >= amount, "Insufficient");
balances[msg.sender] = bal - amount; // Effects first
token.safeTransfer(msg.sender, amount); // Interaction last
}
}
methods {
function totalAssets() external returns (uint256);
function totalSupply() external returns (uint256);
}
invariant solvency()
totalAssets() >= totalSupply()
filtered on f { f.contract != currentContract }
Blockchain Security Approach
├── Audit phase?
│ ├── Pre-development → Threat model + formal spec
│ ├── Post-development → Smart contract audit + fuzzing
│ ├── Pre-deployment → Comprehensive security review + bug bounty
│ └── Post-deployment → Continuous monitoring + incident response
├── Vulnerability type?
│ ├── Reentrancy → ReentrancyGuard, checks-effects-interactions
│ ├── Access control → OpenZeppelin AccessControl, multisig
│ ├── Oracle manipulation → TWAP, multiple sources, circuit breaker
│ └── Math errors → SafeMath (pre-0.8), overflow checks (0.8+)
├── Formal verification needed?
│ ├── Yes (high-value) → Certora / Halmos (rule-based verification)
│ ├── Yes (ZK circuits) → Circom compiler checks, zkVerify
│ └── No → Standard audit + fuzz testing
└── Bug bounty program?
├── Yes → Immunefi / HackerOne (up to 10% of TVL)
└── No → Internal audits only (higher residual risk)
Decision criteria: Evaluate TVL at risk, regulatory requirements, team security maturity, and budget.
// blockchain-security/contracts/ReentrancyGuard.sol
pragma solidity ^0.8.20;
abstract contract ReentrancyGuard {
uint256 private constant _NOT_ENTERED = 1;
uint256 private constant _ENTERED = 2;
uint256 private _status;
modifier nonReentrant() {
require(_status != _ENTERED, "ReentrancyGuard: reentrant call");
_status = _ENTERED;
_;
_status = _NOT_ENTERED;
}
}
// blockchain-security/contracts/TimelockController.sol
contract TimelockController {
uint256 public constant MIN_DELAY = 2 days;
uint256 public constant GRACE_PERIOD = 14 days;
mapping(bytes32 => bool) public queuedTransactions;
event Queued(bytes32 indexed txHash, address target, uint256 value, bytes data, uint256 executeTime);
event Executed(bytes32 indexed txHash);
function queue(address target, uint256 value, bytes calldata data) external onlyRole(PROPOSER_ROLE) {
bytes32 txHash = keccak256(abi.encode(target, value, data, block.timestamp + MIN_DELAY));
queuedTransactions[txHash] = true;
emit Queued(txHash, target, value, data, block.timestamp + MIN_DELAY);
}
function execute(address target, uint256 value, bytes calldata data) external onlyRole(EXECUTOR_ROLE) {
bytes32 txHash = keccak256(abi.encode(target, value, data, block.timestamp));
require(queuedTransactions[txHash], "Not queued");
delete queuedTransactions[txHash];
(bool success,) = target.call{value: value}(data);
require(success, "Execution failed");
emit Executed(txHash);
}
}
| Anti-Pattern | Consequence | Solution |
|---|---|---|
| Skipping threat model | Miss architecture-level vulnerabilities | Mandatory threat model before code |
| Only automated audits | Miss logic bugs | Manual review + automated + fuzzing |
| No timelock on upgrades | Compromised owner upgrades malicious code | Enforce minimum 48h timelock |
| Fixing bugs without re-audit | New bugs introduced | Re-audit > 20% code changes |
| No pause mechanism | Can't stop exploit in progress | Implement pausable + emergency stop |
onlyOwner.blockchain → blockchain-security