What is a reentrancy attack and why is it so dangerous?
Reentrancy is one of the most classic and dangerous smart contract vulnerabilities. Imagine a contract's 'withdraw' function: user calls withdraw → contract transfers funds → then updates balance. An attacker can call withdraw again in the window after the transfer but before the balance update, draining the contract repeatedly while the ledger still shows full balance. The most famous example: the 2016 DAO hack via reentrancy stole ~3.6M ETH, directly causing Ethereum to hard-fork into ETH and ETC. Modern audits prioritize checking reentrancy, but new protocols still fall victim — Euler Finance's 2023 $197M exploit involved similar logic vulnerabilities.
How do I assess whether a DeFi protocol's smart contracts are safe? What specific indicators?
Several publicly checkable metrics. First, audit count and quality: look for independent audits from OpenZeppelin, Trail of Bits, Certik, or Sherlock — how many, how recent, and whether post-upgrade audits exist. Multiple audits far outperform a single one. Second, TVL and history: sustained high TVL (hundreds of millions+) with no exploits is the best time-pressure test — hackers have looked many times and found no entry. Third, admin control: does the protocol have a timelock (upgrades need 24-72h before taking effect, giving community reaction time) and multisig (at least 3/5 or 4/7)? Fourth, bug bounty: a large Immunefi bounty signals the protocol takes security seriously.
If an audit says 'no critical vulnerabilities,' why do hacks still happen?
Several reasons why 'audited' doesn't mean 'definitely safe.' First, audits are static snapshots — after a protocol upgrades, the prior audit is invalid if the new version wasn't audited. Second, auditors are human; complex business logic vulnerabilities can be subtle even for top firms. Third, composability creates new attack surfaces: individually audited contracts may be fine, but their combined behavior can introduce vulnerabilities — flash loan attacks exploit unexpected behaviors across multiple protocols. Audits are necessary, not sufficient. The hardest protection is time-tested live history without exploits, plus a substantial Bug Bounty that makes it more profitable for whitehats to report than to steal.
Advanced: is formal verification a stricter security measure than auditing?
Yes, but with limitations. Formal verification uses mathematical methods to rigorously prove that code logic behaves as specified under all possible inputs — not 'I tested some cases and found nothing' but 'I mathematically proved it can't misbehave in any case.' Stricter and more comprehensive than traditional code audits. Downsides: extremely costly (only top DeFi protocols can afford it), requires properties to be formally specified precisely (getting the specification right is hard), and can only guarantee the specification's correctness — if the spec itself is wrong, verification doesn't help. DAI/USDS core contracts and some Aave components use formal verification, but it remains a complementary tool, not a replacement for human audits and Bug Bounties.
Euler Finance March 2023: ~$197M drained via a logic bug in the donate-to-reserve function combined with flash loans. Euler had reputable audits. The specific edge case wasn't fully covered. After lengthy negotiations, the attacker returned ~95% of funds, but users couldn't access assets for weeks. Even a blue-chip protocol with audits can be exploited. Only put into DeFi what you can afford to lose — a more fundamental principle than 'pick a good protocol.'
DeFi's core advantage is removing the bank intermediary: your money interacts directly with code, and no one can proactively misappropriate your deposit or block withdrawals (if the contract runs normally). The cost: when the code is wrong, there's also no one accountable to fix it — no deposit insurance, no legal compensation obligation, no customer service. Smart contract risk is the other face of this trade-off. The more decentralized and auto-executing a protocol, the harder it is to patch afterward; the more conservative and well-governed a protocol, the faster it can respond to security incidents.