Short answer: do not send or exchange the entire ETH balance shown in your wallet. First prepare the actual transaction, note the wallet’s maximum network fee, and leave at least that amount available. If the exchange requires more than one on-chain transaction, reserve gas for every step. There is no fixed amount of ETH that is always sufficient because the required computation, current network demand, transaction route, and selected network can change.
The technical claims below are tied to Ethereum’s official documentation, final Ethereum Improvement Proposals, and the Ethereum JSON-RPC reference. Protocol rules are separated from wallet estimates and exchange-specific conditions. The gas documentation used here was updated on June 24, 2026; the JSON-RPC reference on June 28, 2026; and the transaction documentation on July 25, 2026. Those dates help establish freshness, but they do not replace a live fee estimate immediately before signing. [1]
On Ethereum, network fees are paid in ETH. This remains true when the asset being transferred is an ERC-20 token rather than ETH: the token is the transferred asset, while ETH in the same address pays for the computation. Ethereum describes the fee as the gas used multiplied by the effective price per unit of gas. Under the EIP-1559 mechanism, that price includes a protocol-defined base fee and a priority fee. [1]
The practical calculation depends on what is being exchanged:
A useful planning formula is:
ETH to reserve = total of the displayed maximum fees for all required transactions + an uncommitted buffer.
This is an operational estimate, not a protocol guarantee. No universal buffer percentage can be justified for every wallet, contract, and network condition. The safer procedure is to prepare each transaction, use its current estimate, and avoid committing the remaining balance elsewhere before all required steps are complete.
An EIP-1559 transaction can specify a gas limit, a maximum fee per gas, and a maximum priority fee per gas. The amount actually charged can be lower than the maximum: unused gas is returned, and the difference between the maximum fee and the effective base fee plus priority fee is not ultimately spent. However, the lower final charge should not be treated as spare money before execution. For planning purposes, use the maximum network cost presented on the confirmation screen, not an optimistic guess about the eventual charge. [1]
A simple ETH transfer has a well-defined minimum computational structure, but token transfers and contract interactions can require more gas because they execute contract code. Ethereum’s documentation therefore distinguishes a basic ETH payment from smart-contract transactions rather than assigning one reliable fee to every operation. [3]
| Decisive claim | Status | Primary source | Source date | Limitation | What could change the conclusion |
|---|---|---|---|---|---|
| Ethereum network gas is paid in ETH, including when a wallet sends an ERC-20 token. [1] | Confirmed | Ethereum.org, “Gas and fees”; final ERC-20 specification | Gas page updated June 24, 2026; ERC-20 created November 19, 2015 | This statement concerns Ethereum. Another network may use a different native gas asset. | A protocol change or use of a different network or sponsored-transaction system. |
| The final fee can be below the displayed maximum because unused gas and the unused portion of the maximum fee are returned. [1] | Confirmed | Ethereum.org gas and transaction documentation | Updated June 24 and July 25, 2026 | A wallet may label estimated cost, maximum cost, and gas limit differently. | Transaction type, wallet fee model, or future protocol changes. |
| A gas estimate is not an exact prediction of the amount ultimately used. [4] | Confirmed with limitation | Ethereum JSON-RPC reference, eth_estimateGas |
Updated June 28, 2026 | The reference states that an estimate may be significantly higher than actual gas usage and can be affected by EVM mechanics and node behavior. | Different transaction data, contract state, node implementation, or pending-block conditions. |
| An ERC-20 exchange may require more than one fee-paying transaction. | Dependent on conditions | Final ERC-20 and ERC-2612 specifications | Created November 19, 2015 and April 13, 2020 | An existing allowance, permit support, batching, or a different exchange flow may remove a separate approval transaction. | The token standard, current allowance, wallet features, and exchange contract design. [2] |
| The exact ETH amount that must be retained for a future exchange. | Unknown until the transaction is prepared | Ethereum gas documentation and JSON-RPC estimation method | Updated June 24 and June 28, 2026 | No static source can know the future transaction route, contract state, network demand, or wallet parameters. | The selected network, number of transactions, current fees, transaction data, and timing. |
After determining the required asset and network, you can check the currently available exchange directions and networks. This page is a practical availability check, not evidence for Ethereum’s gas rules. Verification requirements may also depend on the operation direction and the outcome of compliance checks, so review the current conditions before creating a request.
Insufficient ETH: a wallet may refuse to submit the transaction, or one completed step may leave too little ETH for the next step. A failed contract execution can also consume gas even though the intended state change is reverted. [1]
Wrong address or network: compare the full receiving address, asset, and network displayed by both services. Ethereum transactions are irreversible after confirmation; sending to an unintended address does not create a built-in recovery right. Official Ethereum security guidance recommends checking the destination before signing. [5]
Phishing: open the wallet and exchange through a known domain or saved bookmark, distrust unsolicited support messages, and never disclose a recovery phrase or private key. Review what the wallet is asking you to sign rather than approving an unexplained request. [5]
Changing service conditions: pair availability, supported networks, deposit rules, minimum or maximum amounts, and verification requirements can change. Recheck them before creating the request rather than relying on a previous operation.
The final check is therefore transaction-specific: verify the network and address, prepare every expected on-chain step, total their current maximum fees, retain additional uncommitted ETH without assuming a fixed percentage, and sign only while the displayed amounts and conditions still match the intended exchange.
