What are gas fees and who pays them in a payment
Every professional who touches an onchain payment eventually runs into the same question: where did that fraction of a token go, and who actually owes it? Gas fees are not a surcharge buried in fine print or a platform’s revenue line. They are the cost the network charges to perform any operation — including moving money from one wallet to another, or splitting funds across multiple recipients at once. If you are structuring a deal that closes onchain, understanding what gas is, how it is calculated, and who bears it is not academic. It determines whether the money lands exactly as agreed or whether someone’s proceeds come up short by an amount nobody planned for.
What a gas fee actually is
The term “gas” originates from Ethereum, but the concept applies across virtually every programmable blockchain. Gas is the unit that measures the computational effort required for executing different types of actions while interacting with a blockchain. Think of it as the network’s internal unit of work — not a dollar figure itself, but a count of how much processing a given transaction demands.
Interacting with blockchain networks requires computational resources to process data, verify signatures, and update the shared ledger. Because these networks operate without a central authority, they rely on a distributed network of participants to provide this computing power. Those participants — called validators — do real work. Network validators, a distributed group of individuals that run a specialized computer program to authenticate blockchain transactions, provide this computing power. Validators purchase, run, and maintain their own equipment as they work to ensure the security and accuracy of a blockchain network.
Gas fees are the mechanism that compensates them. Gas fees are the transaction costs users pay to execute operations on a blockchain network. They compensate validators for computing resources and secure the network by preventing spam and malicious attacks.
The fee is always paid in the network’s native token. Gas fees are usually paid by the network’s native token. For Ethereum, the ETH token is used to pay gas fees; for Cronos, CRO is used to pay for gas fees. On Solana, it’s SOL. On Polygon, it’s MATIC. This matters practically: if you are sending a stablecoin — USDC, USDT, or any other — you still need a reserve of the network’s native token in the sending wallet to cover gas. The stablecoin amount and the gas fee are two separate things drawn from two separate balances.
How gas is calculated
The calculation of gas fees involves two key components: the gas limit and the gas price. The gas limit is the maximum amount of work a user estimates a validator will do for a particular transaction. The gas price, on the other hand, is the price per unit of work done.
The gas limit functions as a ceiling. The gas limit is the maximum number of units of gas you are willing to pay for in order to carry out a transaction or EVM operation. Different operations demand different quantities of gas units. The network only charges for what it actually uses; if the transaction completes before hitting the limit, the unused gas is returned. If the transaction runs out of gas before completing — because the limit was set too low — it fails, and the gas already consumed is still spent. The transaction does not go through, but the fee is gone.
For a simple transfer of a native token from one wallet to another, the computation required is small and standardized. A normal transaction sending ETH or a token normally costs 21,000 gas. That 21,000 gas figure has become a benchmark in the industry. Everything more complex costs more.
The total cost in the network’s native token is then a function of how many gas units the transaction uses multiplied by the prevailing gas price at the moment the transaction is submitted. The cost of gas fees is influenced by supply and demand dynamics. If the network experiences high traffic, gas prices may increase. On the other hand, they could decrease if there is not much traffic.
The modern fee structure: base fee and priority fee
Ethereum’s upgrade known as EIP-1559 changed how the gas price component is structured, and most EVM-compatible chains have adopted the same model. Under EIP-1559, the total transaction fee consists of the base fee and the priority fee. The base fee is determined by the network and burned, while the priority fee is set by the user and goes to the miners.
The base fee is not negotiable. The base fee is a mandatory minimum fee required for including a transaction in a block. The base fee is determined algorithmically by the Ethereum network based on demand and adjusts dynamically to ensure efficient use of block space. Specifically, when network usage exceeds 50% of block capacity, the base fee increases, while it decreases slightly when usage falls below 50%. The base fee is burned after payment, permanently removing it from circulation. Burned means it goes to no one — it is destroyed to reduce total supply.
The priority fee — sometimes called the “tip” — is what actually reaches the validator. The priority fee, or “tip,” is an optional extra amount paid directly to the block validator to incentivize them to include the transaction quickly. A higher tip means validators are more likely to pick your transaction out of the queue and include it in the next block. In practical terms: if you are closing a deal and speed matters, a slightly higher priority fee gets your transaction confirmed faster. Most wallets set a reasonable default automatically.
To make this concrete: consider a scenario where Alice sends Bob 1 ETH. Imagine the base fee is 100 gwei and Alice includes a tip of 10 gwei. Using the standard formula, we can calculate this as 21,000 × (100 + 10) = 2,310,000 gwei or 0.00231 ETH. When Alice sends the money, 1.00231 ETH will be deducted from Alice’s account. Bob will be credited 1.0000 ETH. The validator will receive the tip of 0.00021 ETH and the base fee of 0.0021 ETH is burned.
That example illustrates the core logic cleanly: the recipient gets exactly the amount sent, and the sender’s wallet is debited the amount plus the gas fee. The gas never touches the recipient’s balance.
Who pays the gas fee in a payment
The short, unambiguous answer is: the sender pays. The wallet initiating the transaction signs it, and the gas comes out of that wallet’s native token balance at the moment of confirmation. You pay gas fees when making onchain transactions initiated in your crypto wallet or via decentralized applications. Your gas fee won’t be paid unless you confirm your transaction. After confirming, the amount of ETH required to cover your gas fee will be automatically deducted from your ETH balance.
The recipient does not pay gas. The recipient does not need to have native tokens in their wallet to receive funds. Nothing is withheld from the receiving end. The amount sent lands in the recipient’s wallet in full.
This has a practical consequence that is easy to miss in a deal setting. If the sending party’s wallet has enough stablecoin to cover the payment amount but not enough native token to cover the gas, the transaction won’t go through. The payment fails silently, the deal appears to have closed, but nothing has actually moved. Every wallet initiating an onchain settlement needs a native token reserve — this is not optional and not trivial to communicate to counterparties who are new to onchain transactions.
The other side of this: when a professional sets up a payment that disburses to multiple wallets simultaneously — broker commission, agent fee, closing attorney, whatever the structure calls for — the gas is still a single charge on the initiating wallet. The recipients do not each pay separately. The complexity of the transaction changes the gas cost, but it does not split the gas obligation across the parties being paid.
How transaction complexity affects gas cost
Not all payments cost the same to process. The gas units consumed scale with what the transaction actually asks the network to do.
Simple token transfers require minimal gas, while complex smart contracts or multi-step transactions consume more computational resources, driving up gas costs. The gap can be significant. Simple transfers require less work — about 21,000 gas units. Smart contracts with multiple steps can consume over a million gas units depending on their logic.
The complexity of a transaction or smart contract also influences the amount of gas required. Easy transactions like transferring tokens use less gas than complex transactions like the deployment of smart contracts.
For a payment router that splits funds across multiple recipients in a single transaction — rather than sending four or five separate transfers — the smart contract logic does more work than a bare token send. It reads the split percentages, performs arithmetic, executes multiple internal transfers, updates multiple state entries, and emits the corresponding on-chain records. Each of those steps costs gas units. The tradeoff is real, but it is favorable: one smart contract execution that routes to five wallets costs meaningfully less in total gas than five independent transactions submitted one after another, because the fixed overhead of submitting and validating a transaction is paid only once.
A smart contract that is more complex in terms of the actions to be performed will cost more gas to execute. This is why well-optimized contract code matters in a payment context. The design and efficiency of smart contracts also impact gas fees. Smart contracts that are well-optimized require less gas to execute, while inefficient contracts are expensive.
Why gas prices swing — and what that means for closing a deal
Gas fees are not fixed. They fluctuate with demand on the network, sometimes dramatically. When many users compete for space in the next block, gas prices surge. Congested periods can raise costs sharply, especially during token launches or market volatility.
Fees increase as users raise their bids to get included sooner, while low-fee transactions can be pushed to the back of the queue or dropped if demand stays high. You’ll see this during popular NFT mints, sharp market moves that trigger liquidations and panic selling, and major token launches or airdrops that attract a surge of activity. On these busy days, even a simple transfer can cost several times more than it would during quiet periods purely because of congestion.
For a professional closing a deal, this is a real operational consideration. If you are routing payment at the close of a significant commercial transaction, you want confirmation — not a pending transaction sitting in a queue because gas was set too low. The cost difference between a standard gas fee and a fast-confirmation fee is almost always negligible relative to the transaction value. Pay the priority fee. Get the confirmation. The deal is done.
Understanding network congestion and timing transactions accordingly can help users manage their gas costs effectively. Most wallets and payment tools display a live estimate before you confirm. That estimate reflects current network conditions and gives you a clear picture of what the send will actually cost before anything is committed.
The native token requirement: what professionals need to have ready
Because gas is always paid in the network’s native token, anyone initiating an onchain payment needs to hold that token in the sending wallet. This is the practical friction point that catches professionals who are comfortable with the payment logic but new to the onchain mechanics.
Consider a title company or closing attorney routing the disbursements from a commercial real estate closing onchain. The funds might all be in USDC — a stablecoin pegged to the dollar, stable and appropriate for a transaction of that nature. But to push those USDC payments out to the listing broker, the buyer’s agent, and the attorney’s own account, the sending wallet also needs a small ETH balance (if operating on Ethereum or an EVM-compatible chain). The gas comes out of that ETH, not the USDC. The USDC balance is untouched except for the disbursement amounts themselves.
How much ETH? On Ethereum mainnet, a smart contract interaction that routes to multiple wallets might cost anywhere from a few dollars to tens of dollars in gas, depending on network conditions at the time. On Layer 2 networks — chains like Base, Arbitrum, or Optimism that settle to Ethereum but process transactions more cheaply — the same operation can cost a fraction of a cent. Layer 2 networks like Unichain, Base, and Arbitrum are designed to execute transactions faster and at lower cost than Ethereum’s mainnet. Professionals who are doing routine deal settlements do not need to be on Ethereum mainnet; the economics of Layer 2 make much more sense for high-frequency or time-sensitive closing scenarios.
The practical checklist before initiating any onchain payment: confirm the sending wallet holds both the payment token in the correct amount and the native gas token in sufficient reserve. Both have to be there. Missing either one means the transaction fails.
Who bears the gas when a payment link is shared
In a deal structure where one party sets up the payment routing and another party initiates the transaction — a buyer triggering the release of funds, for example — the question of who physically pays the gas follows the same rule: whoever signs and submits the transaction pays the gas.
If the buyer’s wallet is initiating the payment, the gas comes from the buyer’s wallet. If the professional’s system is the one executing the final routing transaction after receiving funds, the gas on that execution comes from the routing wallet. The mechanics do not change based on the deal’s legal structure or who agreed commercially to bear costs — they are determined by which wallet broadcasts the transaction to the network.
This distinction matters when you are explaining the settlement to parties who have not done this before. The buyer, the seller, the lender, the agent — whichever of them is actually pushing the onchain transaction needs to have native tokens ready. The others simply receive. Clear pre-close communication about who initiates, and which wallets need native token balances before close, prevents last-minute delays.
When Shaka handles a deal, the routing logic — which wallets receive what percentage — is embedded in the payment structure the professional configures in advance. When the transaction executes, the split happens in that single onchain operation. The gas cost for that entire multi-wallet disbursement is paid once, by the initiating wallet, and every recipient gets their exact allocation without any deduction.
Gas fees versus other payment costs
It is worth being precise about what a gas fee is and is not, because the term sometimes gets conflated with other costs in the payment stack.
A gas fee is paid to the network — to the validators who process the block. It is not revenue for any platform or application built on the blockchain. Gas fees are transaction fees paid to blockchain validators, not to OpenSea — and the same principle applies universally. The network gets the gas; the application does not.
Crypto fees don’t go to a centralized company. Instead, the transaction fees on a blockchain go to the node operators that secure the network. This is a fundamental difference from traditional payment processing, where the fee goes to an intermediary that built and runs the infrastructure. Onchain, the infrastructure is the network itself, and the fee sustains it.
Applications and platforms that run on top of blockchains may charge their own separate fees — that is a distinct matter, sitting at the application layer, not the network layer. Gas is exclusively the network’s charge for computation. Any other fee is something else entirely, and should be identified and disclosed separately.
What to account for when structuring a deal with onchain settlement
Gas is a cost of execution. Like wire transfer fees in a traditional closing, it needs to be anticipated and assigned before the close, not discovered after. The difference is that gas is variable, not fixed — it moves with network demand.
For any deal closing onchain, the relevant parties should agree on three things before settlement day. First, which wallet initiates the disbursement transaction and therefore bears the gas. Second, that the initiating wallet has a sufficient native token balance — not just the payment funds, but the gas reserve. Third, approximately when the transaction will be submitted, because timing relative to network congestion affects cost. A settlement executed at a high-congestion moment costs more gas than one timed for a quieter period, and on high-value deals, even that variable cost can be worth managing deliberately.
The actual gas amount, in dollar terms, is almost always minor relative to the deal size. A commercial closing routed onchain through a smart contract might pay a few dollars in gas on a Layer 2 network, or somewhat more on mainnet during a busy period. That cost needs to be anticipated, not treated as a surprise. The parties who have done this before budget for it automatically. The ones who haven’t are the ones who call to ask why the initiating wallet needs ETH when the deal is denominated in USDC.
What gas fees ultimately represent is the price of certainty. When the transaction confirms, it is final. There is no reversal window, no clearinghouse holding the funds overnight, no counterparty risk on the settlement leg. The computational work that validators did — and that the gas fee paid for — is what made the payment permanent and verifiable on a public ledger. For a professional whose job depends on deals closing cleanly and proceeds landing where they belong, that certainty is exactly what gas is buying.
