Gas Fees Explained: How They Work and What They Mean for Crypto Payments

A gas fee is the price you pay a blockchain network to execute and permanently record a transaction. Every operation a network performs — moving a token, updating a balance, running a smart contract — consumes computational resources, and validators or miners are compensated for that work. "Gas" is simply the unit that measures how much work a given transaction requires, and the fee is what you pay for that work at the going rate.

Crucially, gas is not a percentage of the amount you send. Sending $10 or $10,000 of the same token over the same network costs roughly the same in gas, because both transactions consume similar computational resources. This is the opposite of card processing, where fees scale with ticket size. It also means gas can feel trivial on a large payment and painfully large on a small one — a $2 gas fee is a rounding error on a $5,000 invoice but ruinous on a $3 coffee.

The fee is always denominated in the network's native asset. On Ethereum, Base, Arbitrum, and Optimism you pay gas in ETH; on Solana in SOL; on Polygon in POL; on BNB Chain in BNB; on Avalanche in AVAX; on Tron in TRX; and on Bitcoin the equivalent fee is paid in BTC. Because those assets have different prices and each network has different capacity, the same logical action costs very different amounts depending on where it runs.

On most networks, the total fee is a product of two numbers: how much gas a transaction uses, and the price per unit of gas at that moment. A simple token transfer consumes a small, fixed amount of gas; a complex smart-contract interaction consumes more. The price per unit floats with demand — when many people want their transactions confirmed at once, they bid the price up, and the network prioritises whoever pays more.

Ethereum and EVM-compatible chains use a two-part model introduced with EIP-1559: a base fee that the protocol sets algorithmically and burns, plus a priority fee (a "tip") that goes to the validator to speed up inclusion. The base fee rises and falls block by block according to how full recent blocks have been, which is why gas can spike during a popular token launch and settle minutes later. You can also set a maximum you're willing to pay so a transaction never confirms at a price you didn't expect.

Other networks price differently. Solana charges a small base fee per signature plus optional priority fees, keeping costs consistently low because its throughput is high. Bitcoin prices by transaction size in virtual bytes multiplied by a sat-per-byte rate rather than by computation. Tron uses a bandwidth-and-energy model where accounts can effectively transact for very little. The common thread is straightforward: fee equals resources consumed times the current rate, and both halves of that equation vary constantly.

Gas prices are set by supply and demand for block space. Every block can hold a limited number of transactions, so when demand exceeds that capacity, users compete by offering higher fees, and the market rate climbs. When the network is quiet, fees fall back toward the protocol minimum. This is why the identical transaction can cost pennies at one hour and several dollars a few hours later.

The biggest driver is congestion. NFT mints, token launches, airdrops, liquidations during volatile markets, and general trading activity all flood networks with transactions and push fees up. Ethereum mainnet is especially sensitive because its base layer has limited throughput and hosts an enormous amount of activity. Layer-2 networks like Base, Arbitrum, and Optimism inherit Ethereum's security but batch transactions off-chain, so their fees are typically a small fraction of mainnet's.

Token price matters too. Because gas is paid in the native asset, a rising ETH price raises the dollar cost of the same gas amount even if network demand is flat. That interaction is why merchants who settle on high-fee chains can see their effective processing cost drift over time without changing anything on their end. The practical takeaway: the network you transact on, and the moment you transact, together determine what you pay — not the size of the payment itself.

Apa supports payments across Bitcoin, Ethereum, Base, Arbitrum, Optimism, Solana, Polygon, Avalanche, BNB Chain, and Tron. Those networks span the full cost spectrum, and understanding where each sits is the single most useful thing a merchant can learn about gas.

Ethereum mainnet is the reference point for "expensive" — a simple transfer there can cost meaningfully more than the same transfer elsewhere, and complex interactions cost more still. Layer-2s built on Ethereum — Base, Arbitrum, and Optimism — deliver the same asset support at a small fraction of mainnet fees, because they post compressed proofs back to Ethereum rather than settling every transaction there directly. For most payment flows, an L2 or an alternative L1 is dramatically cheaper than mainnet with no meaningful downside.

The non-EVM and alternative networks round out the low-cost end. Solana is engineered for high throughput and consistently low, predictable fees, which makes it well suited to small-ticket and high-volume payments. Polygon, Avalanche, and BNB Chain offer fast, inexpensive EVM transactions. Tron is widely used for stablecoin transfers precisely because its fee model keeps costs extremely low. Bitcoin fees depend on network congestion and transaction size and can rise sharply during busy periods. The point isn't that one chain is always best — it's that the right chain for a given payment can be tens or hundreds of times cheaper than the wrong one.

In a direct on-chain payment, gas is paid by whoever initiates a transaction. When a customer sends crypto to a merchant, the customer pays the gas to broadcast that transfer, and it's deducted from their wallet on top of the amount they send. So the headline cost of accepting a payment isn't necessarily the merchant's to bear — the send is push-based and funded by the payer.

The subtlety is on the settlement side. If a merchant wants to consolidate incoming funds, swap a received asset into their preferred payout token, or move funds across chains, those actions are themselves transactions that incur gas. This is exactly where routing decisions add up: a naive setup that settles everything on an expensive chain, or that performs unnecessary on-chain conversions, quietly leaks value on every payment.

Apa's model keeps this clean. Because settlement goes directly to the merchant's own wallet in the asset and on the chain they choose, there's no custodial middle layer adding hops. The cheapest-route settlement engine evaluates the available paths and selects the lowest-cost way to get the merchant the payout they specified, so gas is minimised structurally rather than left to chance. Combined with a per-payment fee that sits well below the roughly 2.9% plus a fixed fee typical of card networks, the total cost of acceptance stays predictable.

Apa positions itself as a non-custodial checkout — think "Stripe for crypto" — and the cheapest-route settlement engine is the part of that story most directly tied to gas. Rather than forcing every payment down a single network, the engine looks across Apa's supported chains and assets and automatically selects the lowest-cost path to deliver the payout you asked for. You don't have to monitor gas prices or manually choose networks; the routing is handled for you on each transaction.

This matters because pay-in and payout are independent in Apa. A customer can pay in BTC while you receive USDC; someone can pay in ETH while you settle in USDT on a low-fee chain. That separation gives the engine room to optimise — it can accept whatever the customer wants to send and still route your settlement over the cheapest viable path, instead of being locked into an expensive chain just because that's what the customer happened to use.

The result is that gas stops being a variable you have to manage and becomes a cost the system minimises by default. Paired with direct-to-wallet, non-custodial settlement, it means the value that reaches you is close to the value the customer paid, minus a transparent fee that is materially lower than card-network economics. For merchants running thin margins or high transaction counts, that difference compounds quickly.

Two costs get conflated in crypto payments: the gas fee to move funds, and the price risk of holding a volatile asset between when you're paid and when you convert. They're separate problems, and both are solvable. Gas is addressed by routing over low-fee chains; volatility is addressed by choosing a stable payout asset.

Because Apa lets you choose your payout asset and chain, you can accept BTC, ETH, SOL, or any supported token from the customer and receive USDC or USDT — settled on a low-gas network like Base, Polygon, Solana, or Tron. That means you're not exposed to price swings on the asset the customer chose, and you're not overpaying to receive it. A merchant who prices in dollars can effectively take any crypto and land dollar-pegged value in their own wallet.

This is a meaningful advantage over setups that force you to hold whatever the customer sent. Settling to a stablecoin on a cheap chain gives you predictable value and predictable cost at the same time. And because settlement is final once confirmed on-chain, there's no multi-day pending window where the amount you'll ultimately receive is still in question.

Gas doesn't just pay for processing — it pays for the network to reach agreement that your payment happened and to make that record permanent. Once a transaction has enough confirmations, it is final: it can't be silently reversed, and the funds are irrevocably in the recipient's wallet. This is the mechanical reason crypto payments don't suffer chargebacks.

Crypto payments are push, not pull. A card charge is a pull — the merchant requests funds from the customer's account, which can later be disputed and clawed back, sometimes months afterward. A crypto payment is a push — the customer proactively sends funds, and once the network confirms the transfer, it's done. There's no issuer sitting in the middle who can reverse the transaction, so the fraudulent-chargeback risk that plagues card acceptance simply doesn't exist.

That finality shapes how refunds work. Because a settled payment can't be pulled back, refunds are handled as a new, separate payment from the merchant to the customer — which incurs its own gas. The upshot is that merchants trade the unpredictability of chargebacks for a clear, deterministic model: money in is final, and money out is an intentional, explicit transaction you control.

You don't need to become a gas-optimisation expert to keep costs low — most of the leverage comes from a few structural choices, and Apa automates the hardest one. The goal is to accept whatever your customers want to pay while settling over the cheapest sensible path in the asset you actually want to hold.

Start by deciding your payout asset and chain based on what you want to end up with, not on what customers send. If you price in dollars, settling to USDC or USDT on a low-fee network gives you stable value and low gas. Then let the cheapest-route engine handle path selection per payment rather than pinning everything to an expensive chain. Finally, choose the integration that fits your stack — Apa offers hosted checkout, shareable payment links, and a developer API, and is self-hostable if you want full control.