Reentrancy
Published Last updated
Key Takeaway
A smart contract vulnerability where external contract calls can recursively re-enter the calling function before initial execution completes, potentially enabling attackers to drain funds or manipulate state.
Learn These First
What Is Reentrancy?
A smart contract vulnerability where external contract calls can recursively re-enter the calling function before initial execution completes, potentially enabling attackers to drain funds or manipulate state.
How Reentrancy Works
Frequently Asked Questions
How can I tell if a smart contract is vulnerable to reentrancy attacks?
Identifying reentrancy vulnerabilities requires technical analysis but users can look for indicators: Check if contracts have professional security audits explicitly mentioning reentrancy testing—reputable auditors like Trail of Bits, ConsenSys Diligence, or OpenZeppelin test for this. Review verified source code for ReentrancyGuard modifiers from OpenZeppelin or similar protection mechanisms. Look for checks-effects-interactions patterns where state updates occur before external calls. Evaluate developer experience with secure coding—projects from security-conscious teams are less likely to have basic vulnerabilities. Use automated security scanners like Slither or MythX that flag potential reentrancy issues. However, complex interactions can create subtle vulnerabilities even expert auditors miss, so no evaluation provides absolute certainty. Prioritize contracts with multiple independent audits, established track records, and significant time-in-production without exploits for maximum confidence.
What was the DAO hack and how did reentrancy cause it?
The DAO hack in 2016 represents cryptocurrency's most famous reentrancy exploit, where attackers drained approximately $60 million worth of ETH from The DAO smart contract. The DAO was an investment vehicle allowing members to vote on funding proposals. Its withdrawal function sent ETH to users before updating their balance to prevent double-withdrawals. Attackers exploited this by creating malicious contracts that, when receiving ETH, immediately called the withdrawal function again before the balance update completed. This recursive calling drained funds repeatedly until substantial ETH was stolen. The attack's severity and The DAO's prominence prompted Ethereum's controversial hard fork that reversed the theft, creating a chain split into Ethereum (reversed) and Ethereum Classic (original). This incident established reentrancy as a critical smart contract vulnerability and drove adoption of defensive programming patterns now considered standard security practice.
Are reentrancy attacks still possible in modern DeFi protocols?
Yes, though less common due to improved awareness and standardized protections. Modern contracts increasingly use defensive patterns (checks-effects-interactions, ReentrancyGuard) making basic reentrancy attacks rare. However, sophisticated vulnerabilities emerge in complex DeFi scenarios involving multiple contract interactions, cross-contract reentrancy (reentering through different functions or contracts), and read-only reentrancy (manipulating view functions during execution). Recent examples include Cream Finance 2021 ($130M loss) and various smaller incidents showing that complex protocols still face reentrancy risks despite best practices. The threat persists especially in: novel DeFi mechanisms without extensive security review, contracts with complex inter-protocol interactions, projects by less experienced teams, and rapidly deployed protocols prioritizing speed over security. Always verify audit quality, prefer battle-tested codebases, and exercise caution with innovative protocols lacking production time.
Common Misconceptions About Reentrancy
If a smart contract has been audited, it's definitely safe from reentrancy attacks.
Audits significantly reduce but don't eliminate reentrancy risks. Even reputable auditors occasionally miss vulnerabilities in complex scenarios, particularly: cross-contract reentrancy vectors spanning multiple protocols, read-only reentrancy manipulating view functions, novel attack patterns not covered by standard testing, and subtle logic issues in intricate DeFi mechanisms. Additionally, audit quality varies dramatically—some 'audits' provide minimal value while thorough reviews from established firms offer much stronger assurance. Contracts can also add vulnerabilities in post-audit updates without new security reviews. Multiple independent audits from reputable firms provide stronger confidence than single audits. Prefer protocols with bug bounty programs, extensive production time without incidents, formal verification where possible, and ongoing security monitoring. Audits are critical but represent one layer of security, not absolute guarantees.
Reentrancy is an old vulnerability that modern smart contracts don't need to worry about anymore.
While awareness has improved and basic reentrancy is less common, the vulnerability remains relevant through evolution into sophisticated variants. Modern threats include: cross-contract reentrancy (reentering through different contracts), cross-function reentrancy (reentering via different functions), read-only reentrancy (manipulating view functions during execution), and complex interaction scenarios creating subtle vectors. Recent major losses (Cream Finance 2021 $130M, various 2022-2023 incidents) demonstrate continued relevance. DeFi's increasing complexity creates new reentrancy opportunities as protocols interact in novel ways. Rapid development cycles and innovative mechanisms mean new patterns emerge faster than best practices evolve. Developers cannot assume basic protections suffice—they need comprehensive security analysis covering advanced reentrancy variants. Users should treat reentrancy as ongoing threat requiring verified protection through audits, established security patterns, and cautious evaluation of novel mechanisms.
Only developers need to understand reentrancy—users can't protect themselves from these attacks.
While users can't directly prevent reentrancy vulnerabilities in contracts they use, understanding reentrancy informs critical risk assessment decisions: Prioritize contracts with multiple independent professional audits explicitly testing reentrancy. Favor protocols using established security libraries (OpenZeppelin) over custom implementations. Prefer mature protocols with significant production time over rapidly deployed experimental ones. Evaluate developer experience and security consciousness through past project history. Consider bug bounty program existence indicating ongoing security focus. Limit exposure to unaudited or minimally-tested contracts regardless of promised returns. Understanding reentrancy helps identify warning signs: complex novel mechanisms without thorough security review, inexperienced teams, absence of standard protections, or aggressive timelines suggesting inadequate testing. Users make daily decisions about which protocols to trust with funds—reentrancy awareness informs these decisions by highlighting what security measures to verify before committing capital.