01The short answer
Gas is what you pay to have the whole network execute and record an operation for you. It does not go to the wallet software and it does not go to an exchange; it goes to the nodes that package transactions on that chain.
Think of the chain as a road with a fixed number of lanes. Each block can carry only so much, so getting in means bidding. Higher bids go first, lower bids queue, and bids that are too low may never get in at all.
02Who actually receives it
The validators or miners maintaining the chain. They run the hardware that executes your transaction and writes it into a block, and gas is the compensation. Some chains additionally destroy part of it.
Two consequences follow:
- Why a wallet cannot waive it. A wallet is a client. It has no authority over whether the network charges.
- Why it is not refunded. Even when your transaction fails — a contract condition was not met, say — the network already spent the computation, so the fee still applies.
On Ethereum today the fee splits in two: a base component that adjusts automatically with congestion and is burned, and a priority component you add on top for whoever includes it. The official write-up is on ethereum.org's gas documentation.
03Why the same transfer costs different amounts
Because it is not a price list, it is an auction. When many people want in at the same moment the price rises; when few do it falls. The complexity of your operation matters too — a plain transfer is cheaper than a contract call.
Three things drive the final number:
- How busy the network is. The most volatile input, capable of several times' difference.
- How complex your operation is. A plain transfer is cheapest; contract interaction and multi-token operations consume more.
- How long you are willing to wait. Most wallets offer fast, normal and slow — slow is cheaper and may take a while.
Our experience is that for anything not urgent, avoiding the obviously busy hours makes a noticeable difference. Exact figures move constantly, so this site does not print any — check a block explorer for the current level when it matters.
04Tokens in the wallet, and it says insufficient balance
The number one beginner wall. Gas has to be paid in that chain's native token, and what you are holding is a different token. If your address holds only stablecoins and none of the chain's native token, you cannot send anything at all.
Concretely: you withdrew some stablecoins from an exchange to your own wallet. The wallet displays them plainly. You try to send some to a friend and the wallet says insufficient balance. You check again; the stablecoins are right there.
The problem is that the chain will not accept stablecoins as a toll. It only accepts its own native token, and that row in your wallet reads zero. So no matter how large the other balance is, no transaction can be sent.
- Withdraw a small amount of that chain's native token from an exchange to the same address. Enough for a few operations is plenty.
- Or have someone you know send a little native token to that address.
- Then make it a habit: whenever you move assets to an address on a new chain, top it up with a little native token at the same time.
How much native token to keep
There is no universal figure, because chains differ enormously and prices move daily. A workable way to size it is by "how many operations":
- Start composing a transfer in the wallet, without confirming, and read the estimated fee.
- Keep five to ten times that amount in native token, so that a busy network still leaves you a few operations.
- Top up whenever you move assets onto that chain.
Why the headroom? Because the moment you most need to send is often the moment the network is busiest — for instance, when you want to move funds out quickly. A balance sized for exactly one transaction is no margin at all.
In this state people go looking for a "gas sponsorship" service or someone offering to move the funds out for them. This is one of the densest scam environments there is, and the request always ends at your seed phrase. Never hand it over; the reasoning is in seed phrases and private keys.
Reading the fee estimate your wallet shows you
Most wallets present three things before you confirm, and they are commonly confused with each other:
- The price per unit — what you are bidding. This is the number that swings with congestion.
- The limit — the maximum amount of computation this operation is permitted to consume. Not a price; a ceiling. A plain transfer needs very little, while a contract call needs considerably more.
- The estimated total — roughly the price multiplied by the expected consumption, which is what actually leaves your balance.
Two practical consequences follow. First, raising the limit does not make you pay more by itself: unused allowance is not charged, so a limit set generously is a safeguard rather than a cost. Second, setting the limit too low is a way to lose money for nothing — execution stops partway, the transaction fails, and the computation already spent is still billed.
Which is why "the transaction failed and I was charged anyway" is more often a limit problem than a price problem. If a wallet suggests a limit and you have no specific reason to lower it, leave it where it is.
One more thing worth noticing: the estimate is an estimate. Between you reading it and the transaction being included, the network can move, and what you finally pay may differ from the figure on screen. On chains with mechanisms that adjust the base fee automatically, you are usually charged the prevailing rate rather than your maximum bid — so the number shown is closer to a ceiling than a quote.
05How much chains differ
Enormously — the same transfer can differ by one or two orders of magnitude between chains. Which is exactly why people switch chains to save fees and then come unstuck on whether the recipient supports that chain.
Without printing numbers, the structural differences:
- Block cadence. Bitcoin produces a block roughly every ten minutes, Ethereum mainnet runs on roughly twelve-second slots, Tron produces a block roughly every three seconds. Faster and larger generally means less price pressure from congestion.
- Network design. Layer-two networks and high-throughput chains are typically far cheaper than Ethereum mainnet.
- The unit of account. Each chain prices in its own native token, so the figure in your own currency also depends on that token's price.
Fees are only one input when choosing. The more important one is whether the receiving side supports that chain — see what a chain is, and for the withdrawal mechanics, moving coins from an exchange into your wallet.
06When a transaction gets stuck
If your bid was below the going rate the transaction can sit pending for a long time. Most wallets offer speed up or cancel, both of which work by re-sending at a higher fee to replace it.
"It failed and still charged me"
The most irritating outcome, and consistent with everything above: the network executed your transaction, the result was failure, the computation was already spent. Common causes:
- Slippage set too tight. The price moved beyond your tolerance during an on-chain swap and the transaction reverted.
- Gas limit too low. Not the price but the allowance for how much the operation may consume; it ran out partway.
- A contract condition was not met. The event ended, the allocation ran out, your address was not eligible.
- An earlier transaction with the same sequence number is still pending.
Look up the failure reason on a block explorer — most give you a message — then decide whether to adjust and retry or abandon it. Do not simply tap send several times; that only pays repeatedly.
If it is stuck rather than failed
- First confirm which it is. Paste the transaction hash into a block explorer rather than trusting the wallet's display.
- Speed up: rebroadcast with the same sequence number and a higher fee; the network takes the later one.
- Cancel: send an empty transaction to yourself with the same sequence number to displace the original. This also costs a fee.
- Do not repeatedly press send. You may end up with several queued transactions that all eventually execute.
One more piece of experience: when something is stuck, doing nothing is often correct. Networks quiet down, and the original transaction frequently goes through on its own. Rushing to speed up mostly just costs more.