Question

In a Solidity smart contract, which specific low-level call type must be avoided to prevent re-entrancy vulnerabilities, and what is the standard recommended practice to replace it?

Accepted Answer

To prevent re-entrancy vulnerabilities, you must avoid using the low-level call function when sending Ether to an external address. A re-entrancy vulnerability occurs when an attacker contract calls back into your contract before the first function execution is finished, allowing the attacker to manipulate the contract state repeatedly. The call function is dangerous because it forwards all remaining gas to the recipient, which provides enough energy for the attacker contract to execute complex logic and initiate further calls. The standard recommended practice to replace this is to use the transfer or send functions, or more ideally, the Checks-Effects-Interactions pattern. The transfer function is safer because it automatically forwards only a fixed amount of 2300 gas, which is sufficient for simple logging but not for executing complex malicious code. However, the best defense is the Checks-Effects-Interactions pattern, which dictates that a function must first validate input requirements, then update the internal state, and only perform external interactions like sending Ether as the final step. By updating your contract&#x27;s state before sending money, any recursive call from an attacker will encounter an updated state that prevents additional withdrawals or unauthorized actions.

Home → All Courses → Engineering and Technology Courses → FinTech Engineering → Flashcard

In a Solidity smart contract, which specific low-level call type must be avoided to prevent re-entrancy vulnerabilities, and what is the standard recommended practice to replace it?