Understand crypto network fees: gas, fee estimation and why costs change

Why this matters

Network fees pay for blockspace and computation. Ethereum measures work in gas and uses a protocol base fee plus a tip (post‑EIP‑1559); Bitcoin fees are an auction on vbytes × sat/vbyte. Both change with demand, transaction complexity and network events.

Key definitions: gas, base fee, priority fee, sat/vbyte

Ethereum uses gas as the unit of computational work. Each transaction consumes gas units; the sender pays for gas units multiplied by a per‑unit price. After EIP‑1559 (London upgrade), transactions specify maxFeePerGas and maxPriorityFeePerGas; the protocol computes a baseFee per block (which is burned) and a priority fee (tip) paid to the validator.

Bitcoin fees work differently: there is no gas. Bitcoin transactions pay a fee equal to the difference between inputs and outputs. Miners prioritize transactions by fee rate, commonly expressed in satoshis per virtual byte (sat/vB). Larger or more complex transactions (more inputs/outputs) have larger vbyte sizes and therefore higher fees at the same sat/vB rate.

• gas (Ethereum): unit of computation
• baseFee (Ethereum): protocol‑set per block; burned
• priorityFee (tip): incentive paid to the validator
• sat/vB (Bitcoin): fee rate = satoshis per virtual byte

Why transaction costs change

Both chains’ fees move with supply and demand. On Ethereum, EIP‑1559’s baseFee adjusts algorithmically depending on recent block fullness: sustained demand pushes baseFee up, lower activity pushes it down. Users also adjust priority fees to compete for inclusion when congestion is high.

On Bitcoin, fees are determined by an open market: mempool congestion and competing transactions set the sat/vB buyers must offer to be included within their desired time window. External events—DeFi activity, NFT drops, network upgrades, bridge congestion—can produce sudden fee spikes on either chain.

• Ethereum baseFee adapts based on block gas used vs target (EIP‑1559)
• Transaction complexity increases gas used (smart contracts > simple transfers)
• User tip behaviour affects how quickly validators include transactions
• Mempool congestion and external events can rapidly change required fees

How wallets and nodes estimate fees

Ethereum nodes expose RPC methods like eth_estimateGas (for gas units) and eth_feeHistory / eth_gasPrice for price guidance. Wallets combine RPC outputs with historical block data and UI heuristics to set gasLimit, maxFeePerGas and maxPriorityFeePerGas. Implementations and client defaults can vary.

Bitcoin wallets inspect recent blocks and the mempool to recommend a sat/vB target for a desired confirmation time. Estimation is inherently probabilistic: sudden changes in network demand or incorrect heuristics can leave transactions underpriced or delayed.

• Ethereum RPC: eth_estimateGas, eth_feeHistory (see ethereum.org JSON‑RPC docs)
• Wallets provide recommended maxFeePerGas / maxPriorityFeePerGas values
• Bitcoin wallets use recent blocks/mempool to propose sat/vB rates
• Estimators are heuristics — not guarantees; rerun checks during fast changes

Worked examples (illustrative only)

Ethereum simple transfer (illustrative math): use 21,000 gas units. If baseFee = 20 gwei and priorityFee = 2 gwei then effective price = 22 gwei. Multiply: 21,000 × 22 gwei = 462,000 gwei = 0.000462 ETH. BaseFee portion is burned; priorityFee goes to the validator. Always treat these inputs as hypothetical and check live values before transacting.

Bitcoin simple payment (illustrative math): if a transaction is 250 vbytes and you choose 50 sat/vB, total fee = 250 × 50 = 12,500 sats = 0.000125 BTC. Transaction size depends on inputs and outputs; wallets can optimize input selection and consolidation during low‑fee periods to save costs.

• Ethereum example: 21,000 gas × (20 gwei + 2 gwei) = 462,000 gwei = 0.000462 ETH
• Bitcoin example: 250 vB × 50 sat/vB = 12,500 sats = 0.000125 BTC
• Unused gas (if gasLimit > gasUsed) is refunded
• Replace example numbers with live tracker values at time of publishing

Practical checklist

• Check live fee trackers (Ethereum baseFee and priorityFee; Bitcoin mempool sat/vB) before sending.
• For Ethereum: set a realistic gasLimit (use eth_estimateGas) and choose sensible maxFeePerGas and maxPriorityFeePerGas; increase tip only when you need faster inclusion.
• For Bitcoin: choose a sat/vB coherent with your confirmation speed preference; use RBF if available to bump a low‑fee tx.
• Test with small amounts if you’re using a new wallet or sending to a new address; never share private keys.
• Consider batching payments and consolidating inputs during low‑fee periods to reduce long‑term costs.
• Remember: estimators are heuristics — transactions can fail (out‑of‑gas) or remain unconfirmed if fees are too low.