EIP / ERC Reference

Canonical reference for Ethereum Improvement Proposals and ERC standards. Covers correct interfaces, behavioral rules, implementation patterns, and the gotchas that trip up humans and LLMs alike. Use this when you need the right function signature, the correct domain separator construction, or the nuance that separates a working implementation from a buggy one.

What You Probably Got Wrong

These misconceptions appear in LLM-generated code constantly. Fix your mental model before writing a single line.

• EIP != ERC — An EIP (Ethereum Improvement Proposal) covers the entire proposal process. An ERC (Ethereum Request for Comments) is the subset of EIPs defining application-layer standards (tokens, signatures, wallets). ERC-20 started as EIP-20 and became ERC-20 upon acceptance. Chain-level changes like EIP-1559 stay as EIPs — they are never ERCs.
• ERC-20 approve has a race condition — If Alice approves Bob for 100, then changes to 50, Bob can front-run: spend the original 100, then spend the new 50, totaling 150. Mitigation: approve to 0 first, use increaseAllowance/decreaseAllowance, or use ERC-2612 permit. USDT requires resetting to 0 before setting a new nonzero allowance — it reverts otherwise.
• ERC-721 transferFrom skips receiver checks — transferFrom does NOT call onERC721Received on the recipient. Tokens sent to contracts that cannot handle them are permanently locked. Use safeTransferFrom unless you have a specific reason not to.
• EIP-712 domain separator MUST include chainId — Omitting chainId from the EIP712Domain allows signature replay across chains. A signature valid on mainnet becomes valid on every fork and L2 sharing the contract address. Always include chainId and verifyingContract.
• ERC-4337 bundler != relayer — A bundler packages UserOperation objects and submits to the EntryPoint. A relayer wraps a signed message and calls a trusted forwarder. Different trust models, different gas accounting, different entry points.
• EIP-1559 baseFee is protocol-controlled — Users set maxFeePerGas and maxPriorityFeePerGas. The protocol sets baseFee per block. The base fee is burned, the priority fee goes to the validator. Confusing these causes incorrect gas estimation.
• ERC-4626 share/asset math is rounding-sensitive — convertToShares and convertToAssets must round in favor of the vault to prevent share inflation attacks. First-depositor attacks exploit vaults that skip this.
• EIP-2612 permit signatures can be front-run — The approval still takes effect, but the original permit call reverts. Always check allowance before calling permit.
• ERC-1155 has no per-token approval — Only setApprovalForAll exists (operator model). There is no approve(tokenId) like ERC-721.
• decimals() is OPTIONAL — Part of IERC20Metadata, not IERC20. USDC uses 6, WBTC uses 8. Never assume 18.