Master the fundamentals of blockchain security through hands-on modules, real-world examples, and knowledge checks. Complete each module to track your progress.
A seed phrase (also called a mnemonic phrase or recovery phrase) is a human-readable representation of your wallet's master private key. Defined by BIP-39, it consists of 12 or 24 words drawn from a standardized list of 2,048 English words. From this single phrase, all of your private keys, public keys, and addresses are mathematically derived.
The seed phrase is the single most critical piece of security in your entire crypto setup. Anyone who obtains your seed phrase has complete, irreversible control over every account derived from it -- across every chain, every token, every NFT.
No legitimate service, wallet, or support team will ever ask for your seed phrase. If someone asks for it, it is a scam -- 100% of the time, with zero exceptions. Do not type it into any website, do not store it in a cloud document, and do not photograph it with your phone.
A hardware wallet is a specialized physical device that stores your private keys in a secure element -- an isolated chip that never exposes the keys to your computer or the internet. When you sign a transaction, the data is sent to the device, signed inside the secure element, and only the signed result is sent back. The private key never leaves the device.
Uses a certified Secure Element (SE) chip (ST33/ST31). Supports Ledger Live and third-party wallets. Models: Nano S Plus, Nano X, Stax.
Open-source firmware and hardware. Uses a general-purpose MCU (not SE). Models: Trezor Model One, Model T, Safe 3 (adds SE chip).
Always purchase hardware wallets directly from the manufacturer. Tampered devices sold through third-party resellers have been used to steal funds. When your device arrives, verify the tamper-evident packaging is intact and run the manufacturer's genuineness check.
Hierarchical Deterministic (HD) wallets, defined by BIP-32 and BIP-44, generate an entire tree of key pairs from a single seed. Each "branch" follows a derivation path that looks like this:
This means a single seed phrase can control addresses across every blockchain. It also means losing that seed phrase compromises everything.
ERC-4337 brings smart contract wallet functionality to Ethereum without requiring protocol changes. It enables gas sponsorship (so users do not need ETH for gas), batched transactions, session keys, and custom validation logic. This is the future direction for all wallet security.
Every Ethereum transaction must be cryptographically signed with the sender's private key before it can be broadcast to the network. The signing process uses the Elliptic Curve Digital Signature Algorithm (ECDSA) with the secp256k1 curve. Here is what happens step by step:
The nonce is a sequential counter that prevents replay attacks. Each transaction from an address must use the next nonce in sequence. If you submit a transaction with nonce 5, nonce 4 must have already been mined. This is also why "stuck" transactions happen -- a pending transaction with a lower nonce blocks all subsequent ones.
Before a smart contract (like a DEX or lending protocol) can move your ERC-20 tokens, you must first call the approve() function on the token contract. This grants the spender address permission to transfer up to the approved amount of your tokens.
The problem: most dApps request unlimited approval (the maximum uint256 value: ~1.15 x 10^77). This means the approved contract can drain your entire token balance at any time, even long after you have finished using the dApp.
Use revoke.cash or Etherscan's Token Approval Checker to regularly audit and revoke stale approvals. Only approve the exact amount you need when possible. Infinite approvals on compromised or malicious contracts have led to hundreds of millions in losses.
Attackers compromised Badger's Cloudflare API key and injected malicious scripts into the front-end that prompted users to sign approval transactions to an attacker-controlled address. Users who approved the malicious requests had their tokens drained. The approvals looked like normal dApp interactions.
Before signing any transaction, you should understand exactly what it does. Every contract interaction encodes its function call as hexadecimal calldata. The first 4 bytes are the function selector -- the Keccak-256 hash of the function signature, truncated to 4 bytes.
When your hardware wallet shows you raw hex data that you cannot decode, do not sign it. Use tools like Etherscan's input data decoder, the 4byte.directory, or Tenderly's transaction simulator to understand what you are approving.
EIP-712 defines a standard for signing typed, structured data off-chain. Unlike raw message signing (eth_sign), EIP-712 presents the data in a human-readable format so you can see exactly what you are signing. This is used by protocols like OpenSea (Seaport orders), Uniswap (Permit2), and many governance systems.
The eth_sign method signs an arbitrary hash with no context about what the data represents. This is extremely dangerous because an attacker can present a transaction hash for signing, and the signed result can be broadcast as a valid transaction. MetaMask now displays a red warning when a dApp requests eth_sign. Never approve an eth_sign request unless you have verified the exact hash being signed.
Since EIP-1559 (London upgrade), Ethereum uses a dual-fee model:
The formula is: Total cost = gas units used * (base fee + priority fee). A standard ETH transfer costs 21,000 gas units. Complex contract interactions can consume hundreds of thousands or even millions of gas units.
Reentrancy is one of the most infamous smart contract vulnerabilities. It occurs when a contract makes an external call to another contract before updating its own state. The receiving contract can then "re-enter" the calling function and repeat the action (e.g., withdraw funds) before the state update occurs.
This is the vulnerability behind the 2016 DAO hack that led to Ethereum's hard fork and the creation of Ethereum Classic.
Always follow the Checks-Effects-Interactions (CEI) pattern: first validate conditions (Checks), then update state (Effects), then make external calls (Interactions). Additionally, use OpenZeppelin's ReentrancyGuard as a defense-in-depth measure with the nonReentrant modifier.
Before Solidity 0.8.0, arithmetic operations did not check for overflow or underflow. A uint256 holding the maximum value (2^256 - 1) would silently wrap around to 0 when incremented. An attacker could exploit this to mint tokens, bypass balance checks, or manipulate accounting logic.
Since Solidity 0.8.0, the compiler includes built-in overflow and underflow checks that automatically revert the transaction. However, developers can bypass these checks using unchecked { } blocks for gas optimization -- which reintroduces the risk if used carelessly.
Access control bugs occur when critical functions lack proper authorization checks, allowing unauthorized users to call admin-only functions like mint(), pause(), setFeeRecipient(), or upgradeProxy().
A developer accidentally triggered the initWallet() function on the Parity library contract, making themselves the owner. They then called kill(), which self-destructed the library. This permanently froze approximately $150 million in ETH held across 587 wallets that depended on that library contract.
Flash loans allow anyone to borrow an unlimited amount of assets with zero collateral, as long as the loan is repaid within the same transaction. While designed for legitimate arbitrage and liquidation, they dramatically amplify attack vectors:
Never use spot AMM prices as price oracles. Use time-weighted average prices (TWAPs), Chainlink price feeds, or other decentralized oracle networks that are resistant to single-transaction manipulation. Protocols like Compound and Aave use Chainlink oracles specifically to prevent flash loan-based price manipulation.
One of the most effective social engineering attacks in web3 targets trust between colleagues and contacts. Attackers compromise Telegram accounts or email inboxes -- often through SIM swaps, session hijacking, or credential stuffing -- and then use those accounts to send fake Zoom or Google Meet invitations to the victim's contacts. Because the message comes from a known, trusted person, recipients rarely question it.
Multiple crypto founders and investors have lost significant funds to this exact attack. The malware installed through these fake call links often targets MetaMask, Phantom, and other browser-extension wallets, extracting private keys before the victim even realizes their contact's account was compromised.
zoom.us. Real Google Meet links come from meet.google.com. Any variation (zoom-us.app, meet.google-web.co, us06-zoom.us) is a phishing domain.Attackers create pixel-perfect replicas of popular DeFi protocols and wallet interfaces. These phishing sites are promoted through Google Ads, social media, and SEO manipulation to appear above legitimate results. When users connect their wallets, the fake dApp prompts them to sign malicious transactions -- typically unlimited token approvals or direct transfers to attacker addresses.
A user searches "Uniswap" on Google. The top result is a Google Ad pointing to uniswapp.org (note the extra "p"). The site looks identical to real Uniswap. When the user connects their wallet and attempts a swap, the site instead sends an approve() transaction giving the attacker unlimited access to their USDC. The user sees "Swap" in the UI but is actually signing a blank check.
Discord is the primary communication hub for most crypto projects, making it a high-value target for attackers. Common attack vectors include:
Attackers exploit vulnerable bots or compromise admin accounts to post fake "mint" or "airdrop" announcements in official channels, sending users to phishing sites.
Scammers impersonate team members or support staff, DMing users who post questions. They direct victims to "verify their wallet" or "sync" by entering their seed phrase on a fake site.
Attackers compromise Discord webhooks to inject phishing messages that appear to come from official bot accounts, bypassing user suspicion of human-sent messages.
Fake "exclusive" Discord servers require users to "connect their wallet to verify holdings." The verification site is actually a phishing page that requests malicious signatures.
Attackers compromised the Discord account of a BAYC community manager. They used the account to post a fake "exclusive airdrop" link in the official BAYC Discord server. Users who clicked the link and interacted with the phishing site lost approximately $360,000 in NFTs. The announcement appeared in the official channel from a known moderator, making it highly convincing.
Unlike traditional phishing that steals credentials, "ice phishing" (a term coined by Microsoft) tricks users into signing blockchain transactions that grant the attacker permission to move their assets. The attacker never needs your private key or seed phrase -- they just need you to sign one transaction.
The most common forms:
approve(attacker_address, MAX_UINT) on your token contract.ERC-2612 Permit signatures are particularly dangerous because they are off-chain. The victim signs a message (no gas cost, no on-chain trace), and the attacker submits the permit on-chain later to drain tokens. The victim may not realize anything happened until they check their balance. Always scrutinize any signature request, even if it does not cost gas.
eth_sign instead of a structured data request.A multi-signature (multi-sig) wallet requires M-of-N signatures to approve any transaction. For example, a 3-of-5 setup means any 3 of the 5 designated signers must approve before a transaction can execute. This eliminates single points of failure and protects against compromised keys, rogue insiders, and coercion.
Recommended configurations by treasury size:
| Treasury Size | Configuration | Reasoning |
|---|---|---|
| < $100K | 2-of-3 | Basic protection while maintaining operational speed |
| $100K - $1M | 3-of-5 | Balances security with availability; can tolerate 2 unavailable signers |
| $1M - $10M | 4-of-7 | Higher threshold for larger amounts; geographic distribution of signers |
| > $10M | 5-of-9 + Timelock | Maximum security with mandatory time delay on execution |
Safe is the industry standard for multi-sig wallets, securing over $100 billion in digital assets. It supports EVM-compatible chains, transaction batching, spending policies, and integration with governance frameworks like Snapshot and Zodiac. Always deploy Safe through the official app at app.safe.global.
Every organization handling digital assets needs a formal key management policy. This document should cover the full lifecycle of cryptographic keys from generation through destruction.
Generate keys on air-gapped devices. Use hardware wallet secure elements. Never generate keys on internet-connected computers or through web interfaces.
Primary key in hardware wallet. Seed phrase backup on steel plates in geographically separate fireproof safes. No digital copies, no cloud storage, no photographs.
Rotate signer keys quarterly or when any signer departs. Update multi-sig configurations promptly. Old signers should never retain access to active wallets.
When keys are decommissioned: reset hardware wallets to factory settings, destroy steel plate backups physically. Document the destruction with witnesses.
Ask yourself: "How many people could be unavailable (quit, get sick, lose their device) before we can no longer access our funds?" This is your "bus factor." If the answer is 1, you have a critical single point of failure. Your multi-sig threshold must always be lower than the total number of signers by at least 2.
Written, enforced security policies are the backbone of organizational security. They transform ad-hoc decisions into consistent, auditable processes. The following policies should be documented, reviewed quarterly, and signed by all team members:
When a security incident occurs -- a compromised key, a detected exploit, or suspicious activity -- every second counts. A well-rehearsed incident response plan can mean the difference between a minor scare and a catastrophic loss.
Set up on-chain monitoring (Tenderly, Forta, OpenZeppelin Defender) to detect unusual transactions. Define alert thresholds: any transaction above $X, any interaction with non-whitelisted contracts, any owner change. All alerts go to a dedicated Slack/Signal channel that team members actively monitor.
Immediately pause affected contracts if possible (if you have a pause() function). Revoke compromised key access from multi-sig. Move assets from compromised wallets to secure backup wallets. Disable affected API keys and access tokens.
Determine the scope: What was compromised? How? What is the potential financial impact? Preserve all evidence: logs, transaction hashes, screenshots, timeline. Do not modify or clean up systems before evidence is collected.
Deploy new keys and wallets. Migrate assets through verified secure channels. Update all dependent systems with new addresses and configurations. Perform full security audit of all related systems before resuming normal operations.
Conduct a blameless post-mortem. Document the full timeline, root cause, impact, and response effectiveness. Identify policy gaps and implement improvements. Share findings with the broader team. Update the incident response plan based on lessons learned.
Run incident response drills at least quarterly. Simulate scenarios like "Signer 2's hardware wallet is compromised" or "Our hot wallet is draining." Time the response. Identify bottlenecks. An untested plan is barely better than no plan.
Deepen your knowledge with our in-depth guides covering multi-sig wallet setup, smart contract auditing best practices, and real-world phishing case studies.