Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
Learn
Solidity at
Alchemy
University
Get started today
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Learn Solidity
REENTRANCY ATTACK OVERVIEW

What is a reentrancy attack in Solidity?

What it is, How it Works, and How to Protect Your Smart Contracts
Last Updated:
October 4, 2022
Table of Contents
Table of Contents
Table of Contents

{{learn-solidity}}

A reentrancy attack in Solidity repeatedly withdraws funds from a smart contract and transfers them to an unauthorized contract until the funds have been exhausted. The attack occurs during the execution cycle on the blockchain when bad actors find an exploitable smart contract. Reentrancy attacks have liquidated millions of dollars from DAOs and blockchain protocols.

The following article explains the mechanics of a reentrancy attack, two types of reentrancy attacks, and the preventive measures Solidity developers can take to secure a smart contract from vulnerabilities on the Ethereum and Solana blockchains. 

What is a reentrancy attack? 

Reentrancy attacks occur when a smart contract function temporarily gives up control flow of the transaction by making an external call to a contract that is sometimes written by unknown or possibly hostile actors. This permits the latter contract to make a recursive call back to the primary smart contract function to drain its funds.

The execution cycle of a smart contract on the Ethereum blockchains checks the balance, sends the funds, and then updates the balance. While the smart contract is in escrow, bad actors can make another call to withdraw funds. The cycle repeats until all funds are effectively drained.

How does a reentrancy attack work? 

A reentrancy attack creates a recursive process that transfers funds between two smart contracts, the vulnerable contract and the malicious contract. Here are the steps of a reentrancy attack:

  1. The bad actor makes a call on the vulnerable contract, "X," to transfer funds to the malicious contract, "Y."
  2. Contract X determines whether the attacker has the necessary funds, then proceeds to transfer the funds to contract Y.
  3. Once contract Y receives the funds, it executes a callback function which calls back into contract X before the balance is updated.
  4. This recursive process continues until all funds have been exhausted and transferred.

The diagram below illustrates the attack scenario:

‚Äć

Image source: CryptoMarketPool

What are the different types of reentrancy attacks?

There are two types of reentrancy attacks: a single function and cross-function reentrancy attack. 

1. Single Reentrancy Attacks

A single reentrancy attack occurs when the vulnerable function is the same function the attacker is trying to recursively call. Single reentrancy attacks are simpler and easier to prevent than cross-function reentrancy attacks. 

2. Cross-function Attacks

A cross-function reentrancy attack is feasible only when a vulnerable function shares state with another function that has a desirable effect for the attacker. Cross-function attacks are harder to detect and more difficult to prevent.

Solidity Reentrancy Attack Examples

The following prominent reentrancy attacks further illustrate how bad actors have exploited vulnerabilities in blockchain protocols: The DAO hack, Lendf.me, and Cream Finance.

1. DAO Hack (2016) 

The Ethereum DAO was hacked for approximately $60 million in Ether. Ethereum’s DAO was designed as an investment fund where network members could vote on investment decisions directly.

The DAO raised roughly $150 million, but experts and community participants expressed concerns surrounding the smart contract's security that was storing funds. The funds were locked in a smart contract vulnerable to a reentrancy attack due to a recursive call bug in the source code. Before the developer team fixed the problem, a hacker executed an attack and drained the contract. 

2. Lendf.me Protocol (2020)

In April 2020, a bad actor stole $25 million using a reentrancy attack from the Lendf.me protocol, a decentralized finance protocol for lending operations on the Ethereum network.

The protocol developers overlooked the fact that ERC-777 tokens contain a callback function that notifies users when money has been sent or received. Hackers exploited the vulnerability by instituting a malicious smart contract as the recipient and draining the Lendf.me protocol of 99.5% of its funds. 

3. Cream Finance Hack (2021)

In October 2021, a bad actor stole over $130 million worth of ERC-20 and CREAM liquidity protocol (LP) tokens by using a reentrancy attack on the protocol‚Äôs ‚Äėflash loan‚Äô feature. The root cause of the exploit was the erroneous integration of AMP into the CREAM finance protocol.¬†

How to Prevent a Reentrancy Attack

Developing a rigorous blockchain security framework is critical to prevent and mitigate potential damage from a reentrancy attack. The following anti-reentrancy best practices will help developers and the broader web3 community secure their funds: checks, effects and interactions (CEI), reentrancy guards, pull payments, and gas limits.

1. Checks, Effects, and Interactions (CEI)

The CEI process is a rudimentary method to prevent reentrancy. Checks refer to the truthfulness of the condition, effects refer to state modifications that result from interaction, and interactions refer to transactions between functions or contracts.

Potential security risks and loopholes associated with placing executive effects before interactions are an important consideration for developers. 

Reentrancy Guard or Mutex

A reentrancy guard or mutex can be created as a function or function modifier. A boolean lock is placed around the function call that is vulnerable to reentrancy. This implies that the initial state of ‚Äėlocked‚Äô is false, however, it is set to true immediately before the vulnerable function execution begins and is then quickly set back to false after termination.¬†

Pull Payment

A more secure end-to-end transaction is by using the pull payment methodology. The pull payment process mandates using an intermediary escrow to send funds and avoids direct contact with a potentially hostile contact.

By sending funds via an intermediary escrow, the smart contract's funds are protected from a reentrancy attack. The escrow could be subject to reentrancy if it manages funds for multiple accounts. The CEI pattern and reentrancy guard should be implemented where appropriate. 

Gas limit

Gas limits are not an optimal method to avert an attacker since gas costs depend on Ethereum’s opcodes, which are subject to change. On the other hand, smart contract code is immutable.

Understanding the difference between the send, transfer, and call functions is important. Send and transfer are effectively the same, but the transfer will revert if the transaction fails and send will not.

Unlike send and transfer, the call function does not have a gas limit and will forward its gas to execute multi-contract transactions. Unfortunately, this also means that reentrancy attacks are possible. 

Learn More About Reentrancy Attacks with Alchemy University

The execution cycle of a smart contract on Ethereum is not a foolproof process. Bad actors exploit the blockchain by implementing reentrancy attacks to transfer and drain funds from vulnerable smart contracts. Taking preventive measures will ensure Soldiity developers safer execution cycles and the protection of their blockchain protocols.

To learn about Solidity smart contract development best practices, join Alchemy's free, 7-week Ethereum Developer Bootcamp. Originally a $3,000 certification course taught by ChainShot, Alchemy University's bootcamp is the premier place to learn Solidity for free.

If developers are new to development in general, Alchemy's 3-week JavaScript crash course is a great prerequisite before starting an Ethereum bootcamp.

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Learn Solidity
REENTRANCY ATTACK OVERVIEW

Learn Solidity: What is a reentrancy attack?

What it is, How it Works, and How to Protect Your Smart Contracts
Last Updated:
October 4, 2022
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Table of Contents
Table of Contents

{{learn-solidity}}

A reentrancy attack in Solidity repeatedly withdraws funds from a smart contract and transfers them to an unauthorized contract until the funds have been exhausted. The attack occurs during the execution cycle on the blockchain when bad actors find an exploitable smart contract. Reentrancy attacks have liquidated millions of dollars from DAOs and blockchain protocols.

The following article explains the mechanics of a reentrancy attack, two types of reentrancy attacks, and the preventive measures Solidity developers can take to secure a smart contract from vulnerabilities on the Ethereum and Solana blockchains. 

What is a reentrancy attack? 

Reentrancy attacks occur when a smart contract function temporarily gives up control flow of the transaction by making an external call to a contract that is sometimes written by unknown or possibly hostile actors. This permits the latter contract to make a recursive call back to the primary smart contract function to drain its funds.

The execution cycle of a smart contract on the Ethereum blockchains checks the balance, sends the funds, and then updates the balance. While the smart contract is in escrow, bad actors can make another call to withdraw funds. The cycle repeats until all funds are effectively drained.

How does a reentrancy attack work? 

A reentrancy attack creates a recursive process that transfers funds between two smart contracts, the vulnerable contract and the malicious contract. Here are the steps of a reentrancy attack:

  1. The bad actor makes a call on the vulnerable contract, "X," to transfer funds to the malicious contract, "Y."
  2. Contract X determines whether the attacker has the necessary funds, then proceeds to transfer the funds to contract Y.
  3. Once contract Y receives the funds, it executes a callback function which calls back into contract X before the balance is updated.
  4. This recursive process continues until all funds have been exhausted and transferred.

The diagram below illustrates the attack scenario:

‚Äć

Image source: CryptoMarketPool

What are the different types of reentrancy attacks?

There are two types of reentrancy attacks: a single function and cross-function reentrancy attack. 

1. Single Reentrancy Attacks

A single reentrancy attack occurs when the vulnerable function is the same function the attacker is trying to recursively call. Single reentrancy attacks are simpler and easier to prevent than cross-function reentrancy attacks. 

2. Cross-function Attacks

A cross-function reentrancy attack is feasible only when a vulnerable function shares state with another function that has a desirable effect for the attacker. Cross-function attacks are harder to detect and more difficult to prevent.

Solidity Reentrancy Attack Examples

The following prominent reentrancy attacks further illustrate how bad actors have exploited vulnerabilities in blockchain protocols: The DAO hack, Lendf.me, and Cream Finance.

1. DAO Hack (2016) 

The Ethereum DAO was hacked for approximately $60 million in Ether. Ethereum’s DAO was designed as an investment fund where network members could vote on investment decisions directly.

The DAO raised roughly $150 million, but experts and community participants expressed concerns surrounding the smart contract's security that was storing funds. The funds were locked in a smart contract vulnerable to a reentrancy attack due to a recursive call bug in the source code. Before the developer team fixed the problem, a hacker executed an attack and drained the contract. 

2. Lendf.me Protocol (2020)

In April 2020, a bad actor stole $25 million using a reentrancy attack from the Lendf.me protocol, a decentralized finance protocol for lending operations on the Ethereum network.

The protocol developers overlooked the fact that ERC-777 tokens contain a callback function that notifies users when money has been sent or received. Hackers exploited the vulnerability by instituting a malicious smart contract as the recipient and draining the Lendf.me protocol of 99.5% of its funds. 

3. Cream Finance Hack (2021)

In October 2021, a bad actor stole over $130 million worth of ERC-20 and CREAM liquidity protocol (LP) tokens by using a reentrancy attack on the protocol‚Äôs ‚Äėflash loan‚Äô feature. The root cause of the exploit was the erroneous integration of AMP into the CREAM finance protocol.¬†

How to Prevent a Reentrancy Attack

Developing a rigorous blockchain security framework is critical to prevent and mitigate potential damage from a reentrancy attack. The following anti-reentrancy best practices will help developers and the broader web3 community secure their funds: checks, effects and interactions (CEI), reentrancy guards, pull payments, and gas limits.

1. Checks, Effects, and Interactions (CEI)

The CEI process is a rudimentary method to prevent reentrancy. Checks refer to the truthfulness of the condition, effects refer to state modifications that result from interaction, and interactions refer to transactions between functions or contracts.

Potential security risks and loopholes associated with placing executive effects before interactions are an important consideration for developers. 

Reentrancy Guard or Mutex

A reentrancy guard or mutex can be created as a function or function modifier. A boolean lock is placed around the function call that is vulnerable to reentrancy. This implies that the initial state of ‚Äėlocked‚Äô is false, however, it is set to true immediately before the vulnerable function execution begins and is then quickly set back to false after termination.¬†

Pull Payment

A more secure end-to-end transaction is by using the pull payment methodology. The pull payment process mandates using an intermediary escrow to send funds and avoids direct contact with a potentially hostile contact.

By sending funds via an intermediary escrow, the smart contract's funds are protected from a reentrancy attack. The escrow could be subject to reentrancy if it manages funds for multiple accounts. The CEI pattern and reentrancy guard should be implemented where appropriate. 

Gas limit

Gas limits are not an optimal method to avert an attacker since gas costs depend on Ethereum’s opcodes, which are subject to change. On the other hand, smart contract code is immutable.

Understanding the difference between the send, transfer, and call functions is important. Send and transfer are effectively the same, but the transfer will revert if the transaction fails and send will not.

Unlike send and transfer, the call function does not have a gas limit and will forward its gas to execute multi-contract transactions. Unfortunately, this also means that reentrancy attacks are possible. 

Learn More About Reentrancy Attacks with Alchemy University

The execution cycle of a smart contract on Ethereum is not a foolproof process. Bad actors exploit the blockchain by implementing reentrancy attacks to transfer and drain funds from vulnerable smart contracts. Taking preventive measures will ensure Soldiity developers safer execution cycles and the protection of their blockchain protocols.

To learn about Solidity smart contract development best practices, join Alchemy's free, 7-week Ethereum Developer Bootcamp. Originally a $3,000 certification course taught by ChainShot, Alchemy University's bootcamp is the premier place to learn Solidity for free.

If developers are new to development in general, Alchemy's 3-week JavaScript crash course is a great prerequisite before starting an Ethereum bootcamp.

A reentrancy attack in Solidity repeatedly withdraws funds from a smart contract and transfers them to an unauthorized contract until the funds have been exhausted. The attack occurs during the execution cycle on the blockchain when bad actors find an exploitable smart contract. Reentrancy attacks have liquidated millions of dollars from DAOs and blockchain protocols.

The following article explains the mechanics of a reentrancy attack, two types of reentrancy attacks, and the preventive measures Solidity developers can take to secure a smart contract from vulnerabilities on the Ethereum and Solana blockchains. 

What is a reentrancy attack? 

Reentrancy attacks occur when a smart contract function temporarily gives up control flow of the transaction by making an external call to a contract that is sometimes written by unknown or possibly hostile actors. This permits the latter contract to make a recursive call back to the primary smart contract function to drain its funds.

The execution cycle of a smart contract on the Ethereum blockchains checks the balance, sends the funds, and then updates the balance. While the smart contract is in escrow, bad actors can make another call to withdraw funds. The cycle repeats until all funds are effectively drained.

How does a reentrancy attack work? 

A reentrancy attack creates a recursive process that transfers funds between two smart contracts, the vulnerable contract and the malicious contract. Here are the steps of a reentrancy attack:

  1. The bad actor makes a call on the vulnerable contract, "X," to transfer funds to the malicious contract, "Y."
  2. Contract X determines whether the attacker has the necessary funds, then proceeds to transfer the funds to contract Y.
  3. Once contract Y receives the funds, it executes a callback function which calls back into contract X before the balance is updated.
  4. This recursive process continues until all funds have been exhausted and transferred.

The diagram below illustrates the attack scenario:

‚Äć

Image source: CryptoMarketPool

What are the different types of reentrancy attacks?

There are two types of reentrancy attacks: a single function and cross-function reentrancy attack. 

1. Single Reentrancy Attacks

A single reentrancy attack occurs when the vulnerable function is the same function the attacker is trying to recursively call. Single reentrancy attacks are simpler and easier to prevent than cross-function reentrancy attacks. 

2. Cross-function Attacks

A cross-function reentrancy attack is feasible only when a vulnerable function shares state with another function that has a desirable effect for the attacker. Cross-function attacks are harder to detect and more difficult to prevent.

Solidity Reentrancy Attack Examples

The following prominent reentrancy attacks further illustrate how bad actors have exploited vulnerabilities in blockchain protocols: The DAO hack, Lendf.me, and Cream Finance.

1. DAO Hack (2016) 

The Ethereum DAO was hacked for approximately $60 million in Ether. Ethereum’s DAO was designed as an investment fund where network members could vote on investment decisions directly.

The DAO raised roughly $150 million, but experts and community participants expressed concerns surrounding the smart contract's security that was storing funds. The funds were locked in a smart contract vulnerable to a reentrancy attack due to a recursive call bug in the source code. Before the developer team fixed the problem, a hacker executed an attack and drained the contract. 

2. Lendf.me Protocol (2020)

In April 2020, a bad actor stole $25 million using a reentrancy attack from the Lendf.me protocol, a decentralized finance protocol for lending operations on the Ethereum network.

The protocol developers overlooked the fact that ERC-777 tokens contain a callback function that notifies users when money has been sent or received. Hackers exploited the vulnerability by instituting a malicious smart contract as the recipient and draining the Lendf.me protocol of 99.5% of its funds. 

3. Cream Finance Hack (2021)

In October 2021, a bad actor stole over $130 million worth of ERC-20 and CREAM liquidity protocol (LP) tokens by using a reentrancy attack on the protocol‚Äôs ‚Äėflash loan‚Äô feature. The root cause of the exploit was the erroneous integration of AMP into the CREAM finance protocol.¬†

How to Prevent a Reentrancy Attack

Developing a rigorous blockchain security framework is critical to prevent and mitigate potential damage from a reentrancy attack. The following anti-reentrancy best practices will help developers and the broader web3 community secure their funds: checks, effects and interactions (CEI), reentrancy guards, pull payments, and gas limits.

1. Checks, Effects, and Interactions (CEI)

The CEI process is a rudimentary method to prevent reentrancy. Checks refer to the truthfulness of the condition, effects refer to state modifications that result from interaction, and interactions refer to transactions between functions or contracts.

Potential security risks and loopholes associated with placing executive effects before interactions are an important consideration for developers. 

Reentrancy Guard or Mutex

A reentrancy guard or mutex can be created as a function or function modifier. A boolean lock is placed around the function call that is vulnerable to reentrancy. This implies that the initial state of ‚Äėlocked‚Äô is false, however, it is set to true immediately before the vulnerable function execution begins and is then quickly set back to false after termination.¬†

Pull Payment

A more secure end-to-end transaction is by using the pull payment methodology. The pull payment process mandates using an intermediary escrow to send funds and avoids direct contact with a potentially hostile contact.

By sending funds via an intermediary escrow, the smart contract's funds are protected from a reentrancy attack. The escrow could be subject to reentrancy if it manages funds for multiple accounts. The CEI pattern and reentrancy guard should be implemented where appropriate. 

Gas limit

Gas limits are not an optimal method to avert an attacker since gas costs depend on Ethereum’s opcodes, which are subject to change. On the other hand, smart contract code is immutable.

Understanding the difference between the send, transfer, and call functions is important. Send and transfer are effectively the same, but the transfer will revert if the transaction fails and send will not.

Unlike send and transfer, the call function does not have a gas limit and will forward its gas to execute multi-contract transactions. Unfortunately, this also means that reentrancy attacks are possible. 

Learn More About Reentrancy Attacks with Alchemy University

The execution cycle of a smart contract on Ethereum is not a foolproof process. Bad actors exploit the blockchain by implementing reentrancy attacks to transfer and drain funds from vulnerable smart contracts. Taking preventive measures will ensure Soldiity developers safer execution cycles and the protection of their blockchain protocols.

To learn about Solidity smart contract development best practices, join Alchemy's free, 7-week Ethereum Developer Bootcamp. Originally a $3,000 certification course taught by ChainShot, Alchemy University's bootcamp is the premier place to learn Solidity for free.

If developers are new to development in general, Alchemy's 3-week JavaScript crash course is a great prerequisite before starting an Ethereum bootcamp.

Build web3 with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free