Sending Ether in Solidity: transfer, send, and call

Solidity gives you three ways to send Ether from a contract: transfer, send, and call. They look similar on the surface, but they behave very differently when it comes to gas, error handling, and security. Choosing the wrong one can break your contract or open it to attacks.

This post covers how each method works, where they differ, and which one to use today.

The Three Methods

transfer

transfer forwards a fixed 2300 gas to the recipient and automatically reverts the entire transaction if the transfer fails. No return value. No manual error checking required.

1function sendViaTransfer(address payable _to) public payable {
2    _to.transfer(msg.value);
3}

The 2300 gas stipend is intentionally small. It is enough for the recipient to emit an event, but not enough to make external calls or run complex logic. This was designed as a security feature to block reentrancy attacks.

After the Istanbul hard fork (EIP-1884, 2019), the gas cost of SLOAD increased from 200 to 800. This means some recipient contracts that used to work fine with 2300 gas now run out of gas and cause transfer to fail. Contracts you did not write might break without any code change on your end.

send

send also forwards 2300 gas, but instead of reverting on failure, it returns a bool. You are responsible for checking it.

1function sendViaSend(address payable _to) public payable {
2    bool sent = _to.send(msg.value);
3    require(sent, "Failed to send Ether");
4}

If you forget to check the return value, your contract continues executing as if the transfer succeeded, even when it did not. This is a real bug pattern. The Solidity compiler will warn you, but it will not stop you.

send has the same gas-related problems as transfer. There is almost no reason to use it over transfer (if you want automatic revert) or call (if you want flexibility).

call

call is a low-level function. It forwards all remaining gas by default and returns two values: a success boolean and any returned bytes.

1function sendViaCall(address payable _to) public payable {
2    (bool sent, bytes memory data) = _to.call{value: msg.value}("");
3    require(sent, "Failed to send Ether");
4}

The {value: msg.value} syntax sets how much Ether to send. The empty string "" means you are not calling a specific function on the recipient, just sending Ether.

You can also specify a custom gas limit:

1(bool sent, ) = _to.call{value: msg.value, gas: 10000}("");

Because call forwards all gas, the recipient can run complex logic. This makes it flexible, but it also means reentrancy attacks become possible if you are not careful.

Comparison at a Glance

Which Method to Use

Use call.

After EIP-1884, the 2300 gas limit is no longer a reliable safety net. transfer and send can silently break when interacting with contracts that have non-trivial fallback logic. call avoids this by not capping gas, and it gives you full control over error handling.

The tradeoff is that call requires you to handle reentrancy yourself. The standard approach is the checks-effects-interactions pattern: update all state before making any external call.

 1contract SafeSender {
 2    mapping(address => uint) public balances;
 3
 4    function withdraw() public {
 5        uint amount = balances[msg.sender];
 6
 7        // Check
 8        require(amount > 0, "Nothing to withdraw");
 9
10        // Effect: update state before external call
11        balances[msg.sender] = 0;
12
13        // Interaction: send Ether last
14        (bool success, ) = msg.sender.call{value: amount}("");
15        require(success, "Transfer failed");
16    }
17}

The balance is set to zero before calling call. Even if the recipient re-enters withdraw, their balance is already zero, so they get nothing on the second call.

If your withdrawal logic is more complex, consider a reentrancy guard instead of relying solely on ordering:

 1contract SafeSenderWithGuard {
 2    mapping(address => uint) public balances;
 3    bool private locked;
 4
 5    modifier noReentrant() {
 6        require(!locked, "No reentrancy");
 7        locked = true;
 8        _;
 9        locked = false;
10    }
11
12    function withdraw() public noReentrant {
13        uint amount = balances[msg.sender];
14        require(amount > 0, "Nothing to withdraw");
15
16        balances[msg.sender] = 0;
17
18        (bool success, ) = msg.sender.call{value: amount}("");
19        require(success, "Transfer failed");
20    }
21}

Receiving Ether in a Contract

For a contract to receive Ether sent via call, it needs at least one of these functions:

 1contract EtherReceiver {
 2    event Received(address sender, uint amount);
 3
 4    // Called when msg.data is empty (plain Ether transfer)
 5    receive() external payable {
 6        emit Received(msg.sender, msg.value);
 7    }
 8
 9    // Called when no other function matches
10    fallback() external payable {}
11}

receive handles plain Ether transfers with no calldata. fallback catches everything else. If neither exists, the contract will reject incoming Ether and cause your call to fail.

Full Working Example

 1// SPDX-License-Identifier: MIT
 2pragma solidity ^0.8.0;
 3
 4contract EtherSender {
 5    function sendViaTransfer(address payable _to) public payable {
 6        _to.transfer(msg.value);
 7    }
 8
 9    function sendViaSend(address payable _to) public payable {
10        bool sent = _to.send(msg.value);
11        require(sent, "Send failed");
12    }
13
14    function sendViaCall(address payable _to) public payable {
15        (bool sent, ) = _to.call{value: msg.value}("");
16        require(sent, "Call failed");
17    }
18}
19
20contract EtherReceiver {
21    event Received(address sender, uint amount);
22
23    receive() external payable {
24        emit Received(msg.sender, msg.value);
25    }
26}

When you call sendViaCall with 1 Ether and pass an EtherReceiver address, the Ether is forwarded and the Received event is emitted. The other two methods will also work with this receiver, but they carry the gas-limit risk described above.

Conclusion

Use call for sending Ether in any contract you write today. Always check the boolean return value. Always update contract state before the external call.

transfer and send exist in older contracts and tutorials, so you will see them. But the gas assumptions they rely on are no longer safe after Istanbul. call with the checks-effects-interactions pattern (or a reentrancy guard) is the right approach.