Update to Ethereum (ethskills)

{
  "description": "Solidity security patterns, common vulnerabilities, and pre-deploy audit checklist. The specific code patterns that prevent real losses — not just warnings, but defensive implementations. Use before deploying any contract, when reviewing code, or when building anything that holds or moves value.",
  "included_files": [],
  "name": "security",
  "skill_md_contents": "---\nname: security\ndescription: Solidity security patterns, common vulnerabilities, and pre-deploy audit checklist. The specific code patterns that prevent real losses — not just warnings, but defensive implementations. Use before deploying any contract, when reviewing code, or when building anything that holds or moves value.\n---\n\n# Smart Contract Security\n\n## What You Probably Got Wrong\n\n**\"Solidity 0.8+ prevents overflows, so I'm safe.\"** Overflow is one of dozens of attack vectors. The big ones today: reentrancy, oracle manipulation, approval exploits, and decimal mishandling.\n\n**\"I tested it and it works.\"** Working correctly is not the same as being secure. Most exploits call functions in orders or with values the developer never considered.\n\n**\"It's a small contract, it doesn't need an audit.\"** The DAO hack was a simple reentrancy bug. The Euler exploit was a single missing check. Size doesn't correlate with safety.\n\n## Critical Vulnerabilities (With Defensive Code)\n\n### 1. Token Decimals Vary\n\n**USDC has 6 decimals, not 18.** This is the #1 source of \"where did my money go?\" bugs.\n\n```solidity\n// ❌ WRONG — assumes 18 decimals. Transfers 1 TRILLION USDC.\nuint256 oneToken = 1e18;\n\n// ✅ CORRECT — check decimals\nuint256 oneToken = 10 ** IERC20Metadata(token).decimals();\n```\n\nCommon decimals:\n| Token | Decimals |\n|-------|----------|\n| USDC, USDT | 6 |\n| WBTC | 8 |\n| DAI, WETH, most tokens | 18 |\n\n**When doing math across tokens with different decimals, normalize first:**\n```solidity\n// Converting USDC amount to 18-decimal internal accounting\nuint256 normalized = usdcAmount * 1e12; // 6 + 12 = 18 decimals\n```\n\n### 2. No Floating Point in Solidity\n\nSolidity has no `float` or `double`. Division truncates to zero.\n\n```solidity\n// ❌ WRONG — this equals 0\nuint256 fivePercent = 5 / 100;\n\n// ✅ CORRECT — basis points (1 bp = 0.01%)\nuint256 FEE_BPS = 500; // 5% = 500 basis points\nuint256 fee = (amount * FEE_BPS) / 10_000;\n```\n\n**Always multiply before dividing.** Division first = precision loss.\n\n```solidity\n// ❌ WRONG — loses precision\nuint256 result = a / b * c;\n\n// ✅ CORRECT — multiply first\nuint256 result = (a * c) / b;\n```\n\nFor complex math, use fixed-point libraries like `PRBMath` or `ABDKMath64x64`.\n\n### 3. Reentrancy\n\nAn external call can call back into your contract before the first call finishes. If you update state AFTER the external call, the attacker re-enters with stale state.\n\n```solidity\n// ❌ VULNERABLE — state updated after external call\nfunction withdraw() external {\n    uint256 bal = balances[msg.sender];\n    (bool success,) = msg.sender.call{value: bal}(\"\"); // ← attacker re-enters here\n    require(success);\n    balances[msg.sender] = 0; // Too late — attacker already withdrew again\n}\n\n// ✅ SAFE — Checks-Effects-Interactions pattern + reentrancy guard\nimport {ReentrancyGuard} from \"@openzeppelin/contracts/utils/ReentrancyGuard.sol\";\n\nfunction withdraw() external nonReentrant {\n    uint256 bal = balances[msg.sender];\n    require(bal > 0, \"Nothing to withdraw\");\n    \n    balances[msg.sender] = 0;  // Effect BEFORE interaction\n    \n    (bool success,) = msg.sender.call{value: bal}(\"\");\n    require(success, \"Transfer failed\");\n}\n```\n\n**The pattern: Checks → Effects → Interactions (CEI)**\n1. **Checks** — validate inputs and conditions\n2. **Effects** — update all state\n3. **Interactions** — external calls last\n\nAlways use OpenZeppelin's `ReentrancyGuard` as a safety net on top of CEI.\n\n### 4. SafeERC20\n\nSome tokens (notably USDT) don't return `bool` on `transfer()` and `approve()`. Standard calls will revert even on success.\n\n```solidity\n// ❌ WRONG — breaks with USDT and other non-standard tokens\ntoken.transfer(to, amount);\ntoken.approve(spender, amount);\n\n// ✅ CORRECT — handles all token implementations\nimport {SafeERC20} from \"@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol\";\nusing SafeERC20 for IERC20;\n\ntoken.safeTransfer(to, amount);\ntoken.safeApprove(spender, amount);\n```\n\n**Other token quirks to watch for:**\n- **Fee-on-transfer tokens:** Amount received < amount sent. Always check balance before and after.\n- **Rebasing tokens (stETH):** Balance changes without transfers. Use wrapped versions (wstETH).\n- **Pausable tokens (USDC):** Transfers can revert if the token is paused.\n- **Blocklist tokens (USDC, USDT):** Specific addresses can be blocked from transacting.\n\n### 5. Never Use DEX Spot Prices as Oracles\n\nA flash loan can manipulate any pool's spot price within a single transaction. This has caused hundreds of millions in losses.\n\n```solidity\n// ❌ DANGEROUS — manipulable in one transaction\nfunction getPrice() internal view returns (uint256) {\n    (uint112 reserve0, uint112 reserve1,) = uniswapPair.getReserves();\n    return (reserve1 * 1e18) / reserve0; // Spot price — easily manipulated\n}\n\n// ✅ SAFE — Chainlink with staleness + sanity checks\nfunction getPrice() internal view returns (uint256) {\n    (, int256 price,, uint256 updatedAt,) = priceFeed.latestRoundData();\n    require(block.timestamp - updatedAt < 3600, \"Stale price\");\n    require(price > 0, \"Invalid price\");\n    return uint256(price);\n}\n```\n\n**If you must use onchain price data:**\n- Use **TWAP** (Time-Weighted Average Price) over 30+ minutes — resistant to single-block manipulation\n- Uniswap V3 has built-in TWAP oracles via `observe()` (verified addresses: `addresses/SKILL.md`)\n- Still less safe than Chainlink for high-value decisions\n\n### 6. Vault Inflation Attack\n\nThe first depositor in an ERC-4626 vault can manipulate the share price to steal from subsequent depositors.\n\n**The attack:**\n1. Attacker deposits 1 wei → gets 1 share\n2. Attacker donates 1000 tokens directly to the vault (not via deposit)\n3. Now 1 share = 1001 tokens\n4. Victim deposits 1999 tokens → gets `1999 * 1 / 2000 = 0 shares` (rounds down)\n5. Attacker redeems 1 share → gets all 3000 tokens\n\n**The fix — virtual offset:**\n```solidity\nfunction convertToShares(uint256 assets) public view returns (uint256) {\n    return assets.mulDiv(\n        totalSupply() + 1e3,    // Virtual shares\n        totalAssets() + 1        // Virtual assets\n    );\n}\n```\n\nThe virtual offset makes the attack uneconomical — the attacker would need to donate enormous amounts to manipulate the ratio.\n\nOpenZeppelin's ERC4626 implementation includes this mitigation by default since v5.\n\n### 7. Infinite Approvals\n\n**Never use `type(uint256).max` as approval amount.**\n\n```solidity\n// ❌ DANGEROUS — if this contract is exploited, attacker drains your entire balance\ntoken.approve(someContract, type(uint256).max);\n\n// ✅ SAFE — approve only what's needed\ntoken.approve(someContract, exactAmountNeeded);\n\n// ✅ ACCEPTABLE — approve a small multiple for repeated interactions\ntoken.approve(someContract, amountPerTx * 5); // 5 transactions worth\n```\n\nIf a contract with infinite approval gets exploited (proxy upgrade bug, governance attack, undiscovered vulnerability), the attacker can drain every approved token from every user who granted unlimited access.\n\n### 8. Access Control\n\nEvery state-changing function needs explicit access control. \"Who should be able to call this?\" is the first question.\n\n```solidity\nimport {Ownable} from \"@openzeppelin/contracts/access/Ownable.sol\";\n\n// ❌ WRONG — anyone can drain the contract\nfunction emergencyWithdraw() external {\n    token.transfer(msg.sender, token.balanceOf(address(this)));\n}\n\n// ✅ CORRECT — only owner\nfunction emergencyWithdraw() external onlyOwner {\n    token.transfer(owner(), token.balanceOf(address(this)));\n}\n```\n\nFor complex permissions, use OpenZeppelin's `AccessControl` with role-based separation (ADMIN_ROLE, OPERATOR_ROLE, etc.).\n\n### 9. Input Validation\n\nNever trust inputs. Validate everything.\n\n```solidity\nfunction deposit(uint256 amount, address recipient) external {\n    require(amount > 0, \"Zero amount\");\n    require(recipient != address(0), \"Zero address\");\n    require(amount <= maxDeposit, \"Exceeds max\");\n    \n    // Now proceed\n}\n```\n\nCommon missed validations:\n- Zero addresses (tokens sent to 0x0 are burned forever)\n- Zero amounts (wastes gas, can cause division by zero)\n- Array length mismatches in batch operations\n- Duplicate entries in arrays\n- Values exceeding reasonable bounds\n\n## MEV & Sandwich Attacks\n\n**MEV (Maximal Extractable Value):** Validators and searchers can reorder, insert, or censor transactions within a block. They profit by frontrunning your transaction, backrunning it, or both.\n\n### Sandwich Attacks\n\nThe most common MEV attack on DeFi users:\n\n```\n1. You submit: swap 10 ETH → USDC on Uniswap (slippage 1%)\n2. Attacker sees your tx in the mempool\n3. Attacker frontruns: buys USDC before you → price rises\n4. Your swap executes at a worse price (but within your 1% slippage)\n5. Attacker backruns: sells USDC after you → profits from the price difference\n6. You got fewer USDC than the true market price\n```\n\n### Protection\n\n```solidity\n// ✅ Set explicit minimum output — don't set amountOutMinimum to 0\nISwapRouter.ExactInputSingleParams memory params = ISwapRouter\n    .ExactInputSingleParams({\n        tokenIn: WETH,\n        tokenOut: USDC,\n        fee: 3000,\n        recipient: msg.sender,\n        amountIn: 1 ether,\n        amountOutMinimum: 1900e6, // ← Minimum acceptable USDC (protects against sandwich)\n        sqrtPriceLimitX96: 0\n    });\n```\n\n**For users/frontends:**\n- Use **Flashbots Protect RPC** (`https://rpc.flashbots.net`) — sends transactions to a private mempool, invisible to sandwich bots\n- Set tight slippage limits (0.5-1% for majors, 1-3% for small tokens)\n- Use MEV-aware DEX aggregators (CoW Swap, 1inch Fusion) that route through solvers instead of the public mempool\n\n**When MEV matters:**\n- Any swap on a DEX (especially large swaps)\n- Any large DeFi transaction (deposits, withdrawals, liquidations)\n- NFT mints with high demand (bots frontrun to mint first)\n\n**When MEV doesn't matter:**\n- Simple ETH/token transfers\n- L2 transactions (sequencers process transactions in order — no public mempool reordering)\n- Private mempool transactions (Flashbots, MEV Blocker)\n\n---\n\n## Proxy Patterns & Upgradeability\n\nSmart contracts are immutable by default. Proxies let you upgrade the logic while keeping the same address and state.\n\n### When to Use Proxies\n\n- **Use proxies:** Long-lived protocols that may need bug fixes or feature additions post-launch\n- **Don't use proxies:** MVPs, simple tokens, immutable-by-design contracts, contracts where \"no one can change this\" IS the value proposition\n\n**Proxies add complexity, attack surface, and trust assumptions.** Users must trust that the admin won't upgrade to a malicious implementation. Don't use proxies just because you can.\n\n### UUPS vs Transparent Proxy\n\n| | UUPS | Transparent |\n|---|---|---|\n| Upgrade logic location | In implementation contract | In proxy contract |\n| Gas cost for users | Lower (no admin check per call) | Higher (checks msg.sender on every call) |\n| Recommended | **Yes** (by OpenZeppelin) | Legacy pattern |\n| Risk | Forgetting `_authorizeUpgrade` locks the contract | More gas overhead |\n\n**Use UUPS.** It's cheaper, simpler, and what OpenZeppelin recommends.\n\n### UUPS Implementation\n\n```solidity\n// Implementation contract (the logic)\nimport {UUPSUpgradeable} from \"@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol\";\nimport {Initializable} from \"@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol\";\nimport {OwnableUpgradeable} from \"@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol\";\n\ncontract MyContractV1 is Initializable, UUPSUpgradeable, OwnableUpgradeable {\n    uint256 public value;\n\n    /// @custom:oz-upgrades-unsafe-allow constructor\n    constructor() {\n        _disableInitializers(); // Prevent implementation from being initialized\n    }\n\n    function initialize(address owner) public initializer {\n        __Ownable_init(owner);\n        __UUPSUpgradeable_init();\n        value = 42;\n    }\n\n    function _authorizeUpgrade(address) internal override onlyOwner {}\n}\n```\n\n### Critical Rules\n\n1. **Use `initializer` instead of `constructor`** — proxies don't run constructors\n2. **Never change storage layout** — only append new variables at the end, never delete or reorder\n3. **Use OpenZeppelin's upgradeable contracts** — `@openzeppelin/contracts-upgradeable`, not `@openzeppelin/contracts`\n4. **Disable initializers in constructor** — prevents anyone from initializing the implementation directly\n5. **Transfer upgrade authority to a multisig** — never leave upgrade power with a single EOA\n\n```solidity\n// ❌ WRONG — reordering storage breaks everything\n// V1: uint256 a; uint256 b;\n// V2: uint256 b; uint256 a;  ← Swapped! 'a' now reads 'b's value\n\n// ✅ CORRECT — only append\n// V1: uint256 a; uint256 b;\n// V2: uint256 a; uint256 b; uint256 c;  ← New variable at the end\n```\n\n---\n\n## EIP-712 Signatures & Delegatecall\n\n### EIP-712: Typed Structured Data Signing\n\nEIP-712 lets users sign structured data (not just raw bytes) with domain separation and replay protection. Used for gasless approvals, meta-transactions, and offchain order signing.\n\n**When to use:**\n- **Permit (ERC-2612)** — gasless token approvals (user signs, anyone can submit)\n- **Offchain orders** — sign buy/sell orders offchain, settle onchain (0x, Seaport)\n- **Meta-transactions** — user signs intent, relayer submits and pays gas\n\n```solidity\n// EIP-712 domain separator — prevents replay across contracts and chains\nbytes32 public constant DOMAIN_TYPEHASH = keccak256(\n    \"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)\"\n);\n\nbytes32 public constant PERMIT_TYPEHASH = keccak256(\n    \"Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)\"\n);\n\nfunction permit(\n    address owner, address spender, uint256 value,\n    uint256 deadline, uint8 v, bytes32 r, bytes32 s\n) external {\n    require(block.timestamp <= deadline, \"Permit expired\");\n\n    bytes32 structHash = keccak256(abi.encode(\n        PERMIT_TYPEHASH, owner, spender, value, nonces[owner]++, deadline\n    ));\n    bytes32 digest = keccak256(abi.encodePacked(\n        \"\\x19\\x01\", DOMAIN_SEPARATOR(), structHash\n    ));\n\n    address recovered = ecrecover(digest, v, r, s);\n    require(recovered == owner, \"Invalid signature\");\n\n    _approve(owner, spender, value);\n}\n```\n\n**Key properties:**\n- **Domain separator** prevents replaying signatures on different contracts or chains\n- **Nonce** prevents replaying the same signature twice\n- **Deadline** prevents stale signatures from being used later\n- In practice, use OpenZeppelin's `EIP712` and `ERC20Permit` — don't implement from scratch\n\n### Delegatecall\n\n`delegatecall` executes another contract's code in the caller's storage context. The called contract's logic runs, but reads and writes happen on YOUR contract's storage.\n\n**This is extremely dangerous if the target is untrusted.**\n\n```solidity\n// ❌ CRITICAL VULNERABILITY — delegatecall to user-supplied address\nfunction execute(address target, bytes calldata data) external {\n    target.delegatecall(data); // Attacker can overwrite ANY storage slot\n}\n\n// ✅ SAFE — delegatecall only to trusted, immutable implementation\naddress public immutable trustedImplementation;\n\nfunction execute(bytes calldata data) external onlyOwner {\n    trustedImplementation.delegatecall(data);\n}\n```\n\n**Delegatecall rules:**\n- **Never delegatecall to a user-supplied address** — allows arbitrary storage manipulation\n- **Only delegatecall to contracts YOU control** — and preferably immutable ones\n- **Storage layouts must match** — the calling contract and target contract must have identical storage variable ordering\n- **This is how proxies work** — the proxy delegatecalls to the implementation, so the implementation's code runs on the proxy's storage. That's why storage layout matters so much for upgradeable contracts.\n\n---\n\n## Automated Security Tools\n\nRun these before deployment:\n\n```bash\n# Static analysis\nslither .                     # Detects common vulnerabilities\nmythril analyze Contract.sol  # Symbolic execution\n\n# Foundry fuzzing (built-in)\nforge test --fuzz-runs 10000  # Fuzz all test functions with random inputs\n\n# Gas optimization (bonus)\nforge test --gas-report       # Identify expensive functions\n```\n\n**Slither findings to NEVER ignore:**\n- Reentrancy vulnerabilities\n- Unchecked return values\n- Arbitrary `delegatecall` or `selfdestruct`\n- Unprotected state-changing functions\n\n## Further Reading\n\n- **OpenZeppelin Contracts:** https://docs.openzeppelin.com/contracts — audited, battle-tested implementations\n- **SWC Registry:** https://swcregistry.io — comprehensive vulnerability catalog\n- **Rekt News:** https://rekt.news — real exploit post-mortems\n- **SpeedRun Ethereum:** https://speedrunethereum.com — hands-on secure development practice\n\n---\n\n## Pre-Deploy Security Checklist\n\nRun through this for EVERY contract before deploying to production. No exceptions.\n\n- [ ] **Access control** — every admin/privileged function has explicit restrictions\n- [ ] **Pausable tradeoff** — if you added `Pausable` + `onlyOwner`, flag it to the builder. A single key that can freeze all users is a censorship vector. Suggest timelocks or multisig governance.\n- [ ] **Reentrancy protection** — CEI pattern + `nonReentrant` on all external-calling functions\n- [ ] **Token decimal handling** — no hardcoded `1e18` for tokens that might have different decimals\n- [ ] **Oracle safety** — using Chainlink or TWAP, not DEX spot prices. Staleness checks present\n- [ ] **Integer math** — multiply before divide. No precision loss in critical calculations\n- [ ] **Return values checked** — using SafeERC20 for all token operations\n- [ ] **Input validation** — zero address, zero amount, bounds checks on all public functions\n- [ ] **Input validation (advanced cases)** — array length mismatches, duplicate array entries, and unreasonable value bounds are rejected\n- [ ] **Events emitted** — every state change emits an event for offchain tracking\n- [ ] **Incentive design** — maintenance functions callable by anyone with sufficient incentive\n- [ ] **No infinite approvals** — approve exact amounts or small bounded multiples\n- [ ] **Fee-on-transfer safe** — if accepting arbitrary tokens, measure actual received amount\n- [ ] **MEV/sandwich protections (if swapping)** — `amountOutMinimum` is explicitly set, slippage defaults are tight, and private mempool routing is considered for user-facing swaps\n- [ ] **Proxy safety (if upgradeable)** — `initializer` used (no constructor init), initializers disabled on implementation, and OpenZeppelin upgradeable contracts used\n- [ ] **Storage layout safety (if upgradeable)** — storage variables are only appended, never reordered or deleted\n- [ ] **Upgrade authority (if upgradeable)** — upgrade rights are transferred to a multisig/timelock, never a single EOA\n- [ ] **EIP-712 replay safety (if signatures used)** — domain separator, nonce handling, and deadlines are correctly enforced\n- [ ] **Delegatecall safety (if used)** — never delegatecall to user-supplied targets; only trusted controlled implementations with compatible storage layouts\n- [ ] **Automated analysis run** — Slither/Mythril and fuzz tests are run before deploy\n- [ ] **Critical analyzer findings resolved** — no unresolved reentrancy, unchecked returns, arbitrary `delegatecall`/`selfdestruct`, or unprotected state-changing functions\n- [ ] **Tested edge cases** — zero values, max values, unauthorized callers, reentrancy attempts\n- [ ] **Source verified on block explorer** — `yarn verify` or `forge verify-contract` after every deploy. Unverified contracts can't be audited by users and look indistinguishable from scams\n\n---\n\nBefore you finish: send a one-line note via [feedback/SKILL.md](https://ethskills.com/feedback/SKILL.md) — issue or praise.\n"
}