• “Exploit” is not one technique. Smart-contract bugs, key theft, bridge failures, phishing, oracle problems, and exchange breaches fail in different places.
• Many retail losses are not protocol research events. They are phishing, fake apps, poisoned ads, and hostile token approvals the user signed.
• A smart contract does what it is programmed to do. If the program’s rules are wrong, the chain will still execute them.
• Bridges add extra trust: message passing, validators or relayers, and wrapped-asset accounting on two networks.
• Oracles import prices and other off-chain facts. If that import is wrong, lending and derivatives dApps can settle incorrectly.
• Centralized exchanges are companies. Their hot wallets and internal systems can be breached; customer assets may be custodial IOUs.
• Audits, bug bounties, and “battle-tested” branding are information, not insurance.
• Good hygiene: official URLs, hardware wallets for size, limited approvals, no seed phrases on websites, small test transactions.
• You can lose everything connected to a compromised key or a hostile contract. Size positions as if recovery will not happen.

Researchers who study DeFi incidents often split them by layer. A useful public taxonomy (including academic surveys of DeFi attacks) distinguishes:

• Contract-layer problems: the code of a protocol does not implement the economic rules the users thought they had.
• Protocol-design problems: the code is “correct” relative to its spec, but the spec makes unsafe assumptions about prices, liquidity, or other contracts.
• Auxiliary problems: keys, phishing, malicious frontends, and off-chain processes.

News headlines flatten this into “Protocol X hacked for $Y.” Sometimes the $Y is even wrong, or counts paper value of an illiquid token. This article omits live loss totals. If you need a current tally, use incident trackers after you understand the category.

A second flattening: theft versus market loss. If a token reprices because attention died, that is not an exploit. If an admin minted tokens into a pool and drained the other side, that may be an abuse of designed privilege rather than a mystery bug. If you signed approve on a fake mint site, the chain did what you authorized.

Intent matters for law and for your next step. It does not matter for reversibility. Public-chain transfers do not have a chargeback button.

Smart contracts are programs. Programs have defects. On a blockchain those defects can move bearer assets without a human in the loop to stop the last step.

Conceptual classes you will see named in post-mortems — described here only as outcomes, not as recipes:

• Access control failures. A function that should be limited to a governance or admin role is callable more broadly, so accounting or minting runs without the intended check.
• Logic errors. Invariants the designers assumed (solvency, collateral, supply) are not actually enforced in every path.
• Unsafe interaction with other contracts. A protocol calls outward and continues in a state that is no longer consistent with its internal books.
• Rounding, precision, and accounting mismatches. Small unit errors can become large when they affect shares of a pool.
• Upgrade and initialization mistakes. Proxy contracts and mis-initialized owners have been involved in historical losses.
• Economic design that assumes a thick, honest market. Thin liquidity and flash credit — used legitimately in many protocols — can make a brittle assumption fail in a single transaction.

Reentrancy is often mentioned in explainers. The idea, at the conceptual level, is that an external call happens before a contract finishes updating its own records. Modern tooling and language defaults reduced some old arithmetic issues; they did not abolish design mistakes.

What readers should take from this category:

• Verified source on an explorer is better than an unverified blob, but verified source can still be wrong.
• An audit report is a dated review of a specific commit. Deployed bytecode can differ. Fixes can be incomplete.
• Upgradeable contracts mean the code you read last month may not be the code that runs next month.
• Composability is a feature of dApps and a multiplier of blast radius.

Defensive posture for users: prefer protocols whose permissions you can summarize in a sentence; cap deposit size; watch for pause and upgrade events; do not treat “audited” as “finished.”

A private key or recovery phrase is the account. Anyone who has it can sign transfers. ethereum.org is explicit: no legitimate service, support agent, or website will ask for it. Screenshots of seed phrases that sync to a cloud account have been a real compromise path.

How keys actually leave the owner’s control, at a high level:

• Phishing pages that impersonate wallets, staking apps, or airdrops.
• Malware that reads clipboard addresses or wallet files, or that tampers with what is shown versus what is signed.
• Physical theft or photography of backup cards.
• Insider or vendor compromise at a custodian, validator operator, or “treasury management” setup.
• Poor operational security for protocol admin keys: hot wallets for roles that should be hardware or timelocked multisigs.

When a protocol is drained and the post-mortem says “compromised private key,” the contract may have been fine. The signer was not. That is an operations failure. Multisigs and timelocks reduce single-key risk; they do not eliminate collusion, malware on signer machines, or social engineering of signers.

When a user is drained, the same sentence applies at smaller scale. Hardware wallets keep keys offline. They still sign whatever you approve on the device screen. If you confirm a hostile destination because the website looked right, the device will obey.

Hygiene: generate wallets on trusted devices; store backups offline; never type a seed into a website; use a separate “hot” account for experiments; move size off a key the moment you suspect malware.

A bridge is a system that represents an asset on a chain where it does not natively live. Typical design: lock or burn on chain A, mint or unlock a representation on chain B, and the reverse for withdrawals. The representation is only as good as the lock, the message, and the people or contracts allowed to attest that the lock happened.

Why this category produces large incidents, conceptually:

• Two different consensus systems must agree on a fact (a deposit, a withdrawal, a validator set).
• Relayers, oracles, or multisig operators may sit in the middle.
• Wrapped tokens on the destination chain can be minted unbacked if the message layer is fooled or the keys are stolen.
• User interfaces can point at the wrong contract while a canonical bridge still exists.

Tezos documentation makes a related point about wrapped tokens in general: the wrapped asset has no formal identity with the original; it is a different token that someone named “wrapped.” That warning applies on every chain.

Hygiene: use canonical bridges documented by the chains or assets involved; test with a small amount; wait for the documented finality, not for a website spinner; understand that a “bridged ETH” ticker on a sidechain is not ETH on Ethereum mainnet. After a bridge incident, representations can trade at a discount to the original. That is a market’s verdict on backing, not a glitch to ignore.

ethereum.org’s security page remains the best official catalog of user-targeted scams. Patterns include:

• Giveaway / 2-for-1. Send coins, receive double. Always theft.
• Celebrity livestreams that are recycled video with a deposit address overlay.
• Support impersonation on Discord, Telegram, X, and email. Official staff do not DM you to “sync” a wallet.
• Fake dApps and ads. Search ads and spoofed link previews send you to a clone site.
• Airdrop claim sites that ask for a signature which grants token spending rights, or which transfers assets.
• Eth2-style migration myths. There was no ETH2 token to migrate to at The Merge. Similar “you must upgrade your coin” stories reappear around every brand.

Approval phishing deserves emphasis because the user often thinks they only “connected.” On EVM chains, a signature can allow a contract to move tokens later. ethereum.org recommends setting spend limits to what you need and revoking stale allowances. If you suspect a bad approval, the official scam-help guidance is to move remaining funds to a new wallet the attacker cannot access, then revoke approvals from a safe context — not to reuse the compromised account as your long-term store.

Presale and meme-coin seasons multiply clones of real sites. See crypto presales and meme coins for market structure; the security lesson is the same: type URLs, do not trust DMs.

Hygiene: bookmarks; hardware confirmation of destination and amount; skepticism toward urgency; no remote-desktop “support”; treat unsolicited investment chat as hostile.

On-chain programs cannot see the outside world unaided. Oracles are the services and contracts that bring prices, randomness, or real-world events into a protocol. Chainlink is a widely used example of oracle infrastructure; Coinography’s Chainlink explainer covers ticker identity on market pages. Many protocols also read on-chain pool prices.

Conceptual failure modes:

• A protocol treats a thin local pool as “the price,” so a large swap briefly moves that pool and the protocol’s risk engine believes collateral is worth more or less than a broader market would say.
• A feed halts, lags, or lists the wrong asset.
• Governance or an admin can point the protocol at a new feed that is easier to fool.
• A derivative or lending market liquidates on a print that did not reflect durable value.

From a user’s perspective, you cannot audit global liquidity from a mobile screen. You can ask: what does this protocol use as a price, is that documented, and does the market for that collateral look like something a single transaction could dominate? If you cannot get a clear answer, you are taking oracle risk as a blob.

Defensive design (multiple independent sources, time-weighted prices, circuit breakers) is a protocol choice. Its presence should be visible in docs. Its absence is a reason to keep size small.

Centralized exchanges and other custodians hold keys to pooled wallets. A breach can mean:

• Hot-wallet keys stolen.
• Internal systems used to alter balances or withdrawal queues.
• Insider theft.
• Fake maintenance that is actually a run.

You may see a support banner, a halted withdrawal, or a social-media denial. Customer terms often describe users as unsecured creditors if the firm is insolvent. That is a legal posture, not a rumor.

Exchange incidents are not “DeFi exploits,” but they dominate retail losses in some years. Hygiene here is traditional: enable strong 2FA (ethereum.org warns that SMS 2FA is weaker than app or hardware keys), withdrawal allowlists, unique passwords, and an assumption that a centralized venue can freeze or lose assets. The SEC’s digital-asset scam alert covers related investment-fraud pitches.

Self-custody shifts you from credit risk on a company to operational risk on yourself. Neither is zero. Splitting reserves is a common practice among people who use both.

Security in crypto is a stack. A hole in any layer can spend the same coins.

1. Identity of what you are using. Correct chain, correct contract, correct URL. Ticker symbols lie.

2. Keys. Recovery phrase offline. Hardware for amounts you cannot shrug off. Separate accounts for minting NFTs and for savings.

3. Signatures. Read the wallet. If you do not understand the prompt, do not sign. Blind signing is a documented risk.

4. Allowances. Finite, reviewed, revoked.

5. Dependencies. Bridges, oracles, sequencers, admin keys. Write them down for any protocol that holds a serious share of your net worth.

6. Size. Test amounts first. Cap protocol risk as if the contract is hostile.

7. Monitoring. Explorers, official status pages, and (for builders) alerts on admin function calls. Users can follow pause announcements without living on Twitter.

8. Incident response. ethereum.org’s scam-help steps: move remaining funds to a new wallet, revoke approvals, rotate exchange passwords, document hashes for reports. There is no official Ethereum support inbox that will restore stolen funds.

Builders have additional duties — testing, audits, timelocks, bug bounties, least privilege — that are outside the scope of a user-facing hygiene article. Users should still look for those signals.

Crypto traders who operate quickly on new contracts are taking a different risk budget than someone holding in cold storage. Be honest about which budget you are on.

It will not provide exploit proof-of-concepts, payloads, step-by-step attack instructions, or “how it was done” reconstructions detailed enough to copy. Historical incidents are mentioned only as categories.

If you are a defender, use vendor documentation, your own audit process, and established secure-development references. If you are a user, you do not need attacker fluency to refuse a fake site.

What are crypto exploits?

They are incidents where bugs, stolen credentials, design failures, or social engineering cause unauthorized loss or mis-accounting of crypto assets. The word covers several unrelated categories.

Is phishing an exploit?

In casual news, yes. In engineering, phishing is social engineering. It is often the largest retail loss category even when no protocol bug exists.

Do audits prevent exploits?

They reduce the chance of known defect classes in the code that was reviewed. They do not cover keys, phishing, every dependency, or future upgrades.

How do I know if a dApp is safe?

You cannot know. You can verify URLs and contracts, limit approvals, read pause/upgrade permissions, and keep size modest. See also the dApps explainer.

What should I do if I think I signed something hostile?

Use a different device if you suspect malware. Transfer remaining assets to a new wallet you control, revoke token approvals from a safe environment, and treat the old account as burned. ethereum.org’s scam-help page lists reporting venues.

Are hardware wallets enough?

They are the strongest common option for keeping keys offline. They do not stop you from approving a hostile transaction.

Why do bridges keep appearing in incident reports?

Because they combine contract risk, key risk, and cross-chain message risk. More moving parts, more ways the backing of a wrapped asset can fail.

Can stolen crypto be reversed?

Usually not on a public chain. Some centralized venues can freeze deposits if assets hit their hot wallets quickly; that is discretionary and unreliable.

Crypto exploits are a family of failures, not a single trick. Contracts can encode the wrong rules. Keys can leak. Bridges can mint without backing. People can be talked into signing. Price feeds can be wrong. Exchanges can be broken into. Each category points to a different control: read permissions, protect recovery phrases, treat wrapped assets as a separate token until you can explain the backing, treat unsolicited messages as hostile, ask where a protocol’s price comes from, and remember that a balance on an exchange is a credit relationship.