Introduction
A recent incident involving the Gemholic project on zkSync Era highlights a critical development pitfall. The project raised approximately 921 ETH through a token sale but encountered a major issue: the funds became locked within their smart contract. This problem stemmed from the use of Solidity's transfer() function, which behaved unexpectedly on the zkSync Era network due to differences in gas calculation and Ethereum Virtual Machine (EVM) compatibility.
This article explores the technical reasons behind this failure, compares common Ether transfer methods, and provides best practices to avoid similar issues in your projects.
What Caused the 921 ETH to Be Locked?
The primary cause was the use of the transfer() function in the project's smart contract. In standard EVM-compatible environments, transfer() limits gas to 2300 units. This is typically sufficient for simple transfers but restricts the complexity of the fallback() or receive() functions in the recipient contract. If the transfer fails, the transaction reverts automatically.
However, zkSync Era is not fully compatible with the Ethereum Virtual Machine. It uses a dynamic gas measurement system that often requires more than 2300 gas for operations that would suffice on Ethereum. When the transfer() function was executed, it exceeded this gas limit, causing the transaction to revert and leaving the funds inaccessible.
Ether Transfer Methods in Solidity
Developers have several options for transferring native tokens like ETH in Solidity. Understanding the differences between these methods is crucial for writing robust and chain-agnostic code.
The transfer() Function
The transfer() function is a straightforward method for sending Ether. It forwards a specified amount of ETH to a given address but imposes a strict gas limit of 2300 units. This limitation ensures that the recipient's fallback function cannot execute complex logic, which is a security feature to prevent reentrancy attacks.
Example code:
payable(_address).transfer(1 ether);A key characteristic of transfer() is that it automatically reverts the entire transaction if the transfer fails. This can be desirable for safety but problematic in environments where gas costs differ.
The send() Function
Similar to transfer(), the send() function also restricts gas to 2300 units. However, it does not automatically revert the transaction upon failure. Instead, it returns a boolean value indicating success or failure, allowing the calling contract to handle the outcome manually.
Example code:
bool success = payable(_address).send(1 ether);The lack of automatic reversion and the gas limit make send() less convenient and secure compared to modern alternatives.
The call() Function
The call() function provides the most flexibility. It forwards all available gas by default (though you can set a limit) and returns a boolean success value along with any data from the call. This allows the recipient contract to execute more complex logic in its fallback function.
Example code:
(bool success, ) = payable(_address).call{value: 1 ether}("");Unlike transfer() and send(), call() does not impose a gas limit, making it adaptable to various network conditions, including layer-2 solutions like zkSync Era. For this reason, it is the currently recommended method for Ether transfers.
Why call() is the Preferred Method
Most contemporary development guides recommend using call() for Ether transfers. Its flexibility in handling gas and failure conditions makes it more suitable across different blockchain environments. The ability to manually handle successes and failures provides developers with greater control, reducing the risk of locked funds or failed transactions on non-standard EVM chains.
In contrast, transfer() and send() are increasingly seen as legacy functions. Their rigid gas limits can cause incompatibilities on emerging networks, as demonstrated by the zkSync Era incident.
How to Avoid Similar Smart Contract Issues
Preventing such issues requires a thorough approach to development and testing.
Conduct Comprehensive Testing: Always test smart contracts on a testnet that mirrors the production environment. This helps identify chain-specific behaviors, like gas differences, before deployment.
Seek Professional Audits: Engage with smart contract auditing services to review your code. Auditors can spot potential vulnerabilities and environment-specific pitfalls that internal teams might overlook.
Understand Chain Compatibility: Research the specific characteristics of the blockchain you are building on. Layer-2 solutions and sidechains often have unique features that deviate from standard Ethereum behavior.
Use Modern Development Practices: Favor the call() function for ETH transfers unless you have a specific need to limit gas. Stay updated with best practices from the developer community.
👉 Explore advanced smart contract strategies
Frequently Asked Questions
What is the main difference between transfer() and call()?
The transfer() function limits gas to 2300 units and reverts on failure, while call() forwards all available gas and returns a boolean for success, allowing manual handling.
Why did transfer() fail on zkSync Era but work on Ethereum?
zkSync Era uses a different gas calculation system that often requires more than 2300 gas for basic operations, causing transfer() to exceed its limit and revert.
Can the locked ETH in the Gemholic contract be recovered?
Since smart contracts are immutable after deployment, recovery is typically impossible unless the contract includes specific emergency functions designed for this purpose.
Is send() ever recommended over call()?
Due to its gas limit and lack of automatic reversion, send() is generally not recommended. call() offers better flexibility and control in most scenarios.
How important is a smart contract audit?
Extremely important. Audits help identify critical vulnerabilities and environmental mismatches that can lead to significant financial losses, as seen in this case.
What should I do if I encounter a similar issue?
If you are developing on a non-standard EVM chain, consult the chain's documentation, use call() for transfers, and conduct extensive testing on their testnet before mainnet deployment.
Conclusion
The incident where 921 ETH was locked on zkSync Era serves as a cautionary tale for smart contract developers. The root cause was a mismatch between the development assumptions (based on Ethereum) and the actual execution environment (zkSync Era). By understanding the differences between transfer functions, conducting rigorous testing, and seeking professional audits, developers can mitigate such risks and build more resilient applications.
Always remember: smart contract deployments are immutable. Prior diligence is the only way to ensure security and functionality.