# How to receive a large payment when gas is high without overpaying

When gas spikes, large multi-party payments on Ethereum carry real cost risk. Here is how settlement professionals can plan, time, and structure transactions to protect every party's proceeds.

---


There is a moment that every settlement agent, closing attorney, and OTC desk operator recognizes: a large deal is ready to close, the parties have agreed on amounts, the wire instructions are confirmed — and then someone checks the gas tracker and the number is ugly. Not catastrophically ugly, but ugly enough that a hasty decision could quietly eat hundreds of dollars out of proceeds that someone on the other end of that transaction is counting on.

This is not a theoretical problem. Ethereum processes over one million transactions daily, and during busy periods gas prices have jumped from under 20 Gwei to over 200 Gwei, even crossing 500 Gwei during events like the 2021 NFT boom. The mechanisms that drive those spikes have not gone away. As network usage climbs and smart contract interactions grow more complex, gas costs have a habit of spiking at the worst possible times. And in a deal with multiple parties and preset distribution percentages, a spike that hits mid-process — or that forces a re-send because the first attempt stalled — compounds quickly.

The good news is that this problem is solvable with preparation. The professional handling the closing does not need to become a blockchain developer. They need to understand three things: how gas pricing works, when to transact, and how to structure the payment so that one transaction does all the work. Getting all three right is what separates a clean close from an expensive re-do.

<figure class="keyfacts">
<div class="keyfacts-grid">
<div><b>3–5×</b><span>higher base fees at the weekday peak than at overnight lows</span></div>
<div><b>189,000 gas</b><span>saved when 10 transactions are batched into one</span></div>
<div><b>$60–$160</b><span>in gas for four separate ERC-20 sends at 85 Gwei</span></div>
</div>
<p class="fig-src">Figures from the timing, batching and four-party scenario sections of this article.</p>
</figure>

## Understanding What You Are Actually Paying For

Before you can optimize gas cost, you have to understand what determines it. Gas fees are the transaction costs you pay to use a blockchain network. Every time you send crypto, swap tokens, or interact with a smart contract, you pay a gas fee to compensate the network validators who process your transaction.

Ethereum's post-EIP-1559 fee model splits the price into a base fee determined by demand and a priority fee that can be set to compete for inclusion. Understanding that split matters practically. The key mental model is that gas has two knobs, and they solve different problems. The gas limit controls how many gas units the transaction is allowed to consume before halting. The fee settings control how much the sender is willing to pay per gas unit for inclusion.

A key design goal of EIP-1559 is fee predictability: the base fee is algorithmically calculated from recent block utilization. This allows wallets to anticipate costs and plan resource consumption accordingly. That predictability is the lever that professionals can use. The base fee is not random — it follows demand. And demand, it turns out, follows a very human schedule.

The distinction between the base fee and the priority fee also matters when you are handling a large institutional payment. Users seeking special treatment, such as immediate inclusion in a period of rapidly increasing demand, can supplement the base fee with a transaction tip that is transferred directly to the validator of the block that includes it. For a deal with a hard closing deadline, that tip buys certainty. For a closing that has schedule flexibility, the smarter play is to simply wait until the base fee itself drops.

<aside class="callout">
<span class="callout-label">High-value transactions</span>
<h4>Raise the gas limit 10–15% above the wallet's suggestion</h4>
<p>It costs almost nothing extra if unused, because it gets refunded, and it protects against a failed transaction and wasted fees. A failed transaction on a large payment is not just a cost problem; it is a professional embarrassment and a delay. Over-allocating the gas limit by a modest margin is cheap insurance.</p>
</aside>

## The Weekly Clock: When Gas Is Genuinely Cheaper

One of the most consistently actionable insights in Ethereum is that gas cost is not uniformly distributed across the week. It follows a predictable pattern driven by when institutional desks, DeFi traders, and automated bots are most active. Fees are consistently at their lowest during the early morning hours on Saturdays and Sundays, often falling to roughly half of typical weekday rates. Fees are consistently at their highest Tuesday through Thursday, specifically during the window when both North American and European trading desks are online simultaneously, roughly 14:00 to 18:00 UTC.

That spread is significant. Weekday peak periods can run three to five times higher than the quietest overnight weekend windows. On a $500,000 USD (approximately $760,000 AUD) settlement distributed across four parties, the difference between executing at a Tuesday afternoon peak versus a Saturday morning lull is not noise — it is a material line item.

Based on historical base fee data from 2025–2026, the pattern breaks down as follows:

| Window | When it falls | Base fees |
| --- | --- | --- |
| 02:00–06:00 UTC | Late night or early morning in the Americas, pre-dawn in Europe | Consistently the lowest of any 24-hour period |
| 14:00–18:00 UTC | Peak congestion: US and European trading sessions overlap and DeFi activity surges | Often three to five times higher than overnight lows |
| Saturday and Sunday UTC | Weekend days | Typically 30–50% lower than weekday peaks |

For closing professionals, this translates directly into a workflow consideration. If a deal is ready to move on a Wednesday afternoon US Eastern time — which sits squarely in that 14:00–18:00 UTC danger zone — and no hard deadline forces the transaction, waiting until Sunday morning UTC is not procrastination. It is competent fee management. The parties' proceeds are larger as a result.

High-fee periods are often driven by events such as popular NFT mints, busy DeFi trading windows, or other surges in Ethereum activity. This means that even within a low-cost window, a single unexpected event — a major token launch, a protocol exploit triggering liquidations — can push fees up sharply. With real-time gas estimation tools, you can time your transactions with greater precision, avoid overpaying, and reduce the risk of failed or delayed transactions. These tools provide live updates on base fees, priority levels, transaction wait times, and even projected future gas prices. Checking the gas tracker immediately before submitting — not an hour before, not the day before — is the professional standard.

## The Single Transaction Principle: Why Structure Matters More Than Timing

Timing helps. But structure is where the largest savings live, especially for complex multi-party closings. Consider the default workflow that many professionals still use: the funds arrive in one place, then are pushed out in separate transactions — one to the broker, one to the title company, one to the seller, one to the agent. Each transaction carries its own base overhead.

Every transaction requires a certain amount of gas units — simple transfers use approximately 21,000 units, and complex DeFi interactions can use 200,000 or more. Each transaction on Ethereum costs 21,000 gas as a base fee. A total gas savings of 189,000 gas can be achieved if a user batches 10 transactions at once. That is not a trivial number. At elevated gas prices, those 189,000 saved units translate directly into protected proceeds.

Transaction batching is the process of combining multiple transactions together into a single transaction to save on gas fees and improve efficiency on the blockchain. By grouping several transactions together, the overall gas fee is reduced, making transactions on networks like Ethereum more economical.

A batch transfer does not magically eliminate gas usage, but it can reduce duplicated per-transaction overhead by consolidating many payments into a single on-chain operation. If you pay the fixed cost of transaction submission many times, you should expect materially more waste than paying it once for a well-structured batch. The larger the recipient set, the more visible this difference becomes.

This is the principle that shaka.deal is built around. Rather than having a settlement professional execute four, five, or six separate outbound transactions — each of which burns its own base gas and requires its own confirmation — shaka.deal accepts one inbound payment and routes it simultaneously to every party at their preset shares. One transaction. One gas cost. All parties receive their amounts in the same block.

The math on a concrete scenario makes the value immediate. Imagine a commercial real estate close: $1,200,000 USD (approximately $1,830,000 AUD) needs to move to a selling party, a buyer's broker, a seller's agent, a title company, and a legal fund. Under the multi-transaction model, that is five separate on-chain sends, each incurring base overhead, each exposed to the gas price at the moment it is broadcast. If gas spikes between the first and fifth send — entirely possible during a busy weekday afternoon — different parties receive their funds under different fee conditions, and the total cost is unpredictable.

Under the single-routing model that shaka.deal provides, the entire distribution is encoded once in preset shares. The incoming $1,200,000 USD hits the router, and all five parties receive their amounts in one transaction with one gas cost. The settlement is simultaneous and final.

## What "Final" Means in Practice

Professionals accustomed to wire-based settlement understand that wires can be recalled, that ACH carries reversal risk, and that the business day cutoff creates time pressure. Onchain settlement operates on different rules. When a transaction is confirmed on Ethereum, the transfer is complete. There is no recall mechanism, no reversal window, no bank that can claw back funds at a counterparty's request. The transaction is either included in a block and final, or it is not yet confirmed.

Traditional cross-border bank transfers may still take several business days, as SWIFT is mainly a messaging system among participating financial institutions. By contrast, stablecoin transactions can be settled on the blockchain in seconds or minutes. For a deal with parties in multiple jurisdictions — a transaction involving a US seller, an Australian buyer's agent, and a legal representative in the UK — that difference in settlement time is not a minor operational convenience. It changes the entire closing workflow.

Finality is also the reason that gas cost matters so much at the point of submission. Unlike a wire, you cannot issue a "stop payment" on an Ethereum transaction that has been broadcast. You set your gas parameters before you submit, and those parameters determine whether your transaction is included promptly, included slowly, or stuck in the mempool while the block fills with higher-priority sends. Getting the gas settings wrong on a large closing is expensive and potentially embarrassing — not because the funds are lost, but because a stuck transaction in a live closing scenario creates coordination chaos.

A disciplined workflow uses suggested fees as a baseline, raises the max fee to protect eligibility, and reserves high priority fees for truly time-sensitive actions. For a closing professional, this means: always set the max fee generously enough that the transaction will be included even if the base fee ticks up between submission and confirmation. The actual fee paid will be no higher than the base fee plus your priority tip — the max fee is a ceiling, not what you pay. In times of increased network congestion, the base fee rises and users who paid tips will have their transactions processed first.

## Concrete Scenario: A Four-Party Commercial Close at Peak Gas

Walk through this in detail.

A property transaction closes for $850,000 USD (approximately $1,296,000 AUD). The agreed distribution is:

| Party | Share | Amount |
| --- | --- | --- |
| Seller | 72% | $612,000 |
| Buyer's broker | 12% | $102,000 |
| Seller's agent | 10% | $85,000 |
| Settlement reserve account, controlled by the closing attorney | 6% | $51,000 |
| **Total** | **100%** | **$850,000** |

The deal is scheduled to close on a Thursday afternoon, US Eastern — 17:00 UTC. That is inside the peak congestion window. The closing attorney checks the gas tracker and sees base fees running at 85 Gwei. At that gas price, a standard ERC-20 transfer costs roughly $15–$40 depending on the token contract complexity. Four separate sends would cost $60–$160 USD in gas alone — and that assumes all four go through cleanly on the first attempt.

Option A: Execute four individual transactions at 85 Gwei. Total gas cost: high, unpredictable, and borne as an overhead against the deal. If one transaction is sent with a priority fee that is slightly too low and it stalls, the closing is incomplete and the attorney has to rebroadcast with higher fees.

Option B: Wait thirty-seven hours. The same close is executed Saturday morning at 06:00 UTC, when base fees are running at 12 Gwei. The lowest-fee window is typically 02:00–06:00 UTC, when transactions can be 50–70% cheaper than midday. The gas cost drops dramatically.

Option C: Use shaka.deal to route the entire $850,000 USD through a single transaction, with the preset split encoded in advance. The closing attorney submits one transaction Saturday morning. All four parties receive their amounts simultaneously in the same block. One confirmation, one gas cost at the low-congestion rate, simultaneous and final distribution.

Option C is obviously the right answer — but it is only available if the infrastructure is in place before the close, not assembled under pressure on the day. The preset shares have to be configured. The parties have to agree on their wallet addresses in advance. The payment asset has to be the agreed stablecoin. None of that is complicated, but it requires the professional to run the onchain workflow the same way they run wire instructions: methodically, verified in advance, tested with a small amount if the parties are new to the process.

## The Asset Question: Which Stablecoin to Accept

For large professional payments, the choice of stablecoin matters. Ethereum retained dominance in tokenized asset settlement and large-ticket institutional flows. For most B2B treasury use cases, USDC's regulatory standing and CCTP-based chain mobility make it the default choice. USDT remains dominant in emerging-market settlement and offshore exchange flows because of its liquidity and Tron deployment costs.

For a settlement professional routing on Ethereum mainnet, USDC carries the strongest combination of regulatory transparency, institutional acceptance, and liquidity depth. The paying party will generally have no difficulty sourcing USDC for a large transaction, and the receiving parties in all major markets — US, Australia, UK, and EU — have clear pathways to convert to fiat after receipt.

USDC and USDT are the most popular stablecoins for global payroll and are preferred due to faster settlement and cost efficiency compared to banking infrastructure. That preference increasingly extends to complex B2B settlements: the professional certainty of a confirmed onchain transaction, with the price stability of a dollar-pegged asset, is a genuinely different product from a SWIFT wire — not a replacement for it, but a complementary tool that solves problems SWIFT cannot.

## Practical Protocol for Any Large Onchain Close

Pull these steps into a standard pre-closing checklist.

**Two to three days before closing:**
- Confirm all parties' wallet addresses and verify each one by sending a test amount (a few dollars USD is sufficient) and confirming receipt.
- Agree on the stablecoin asset. If using USDC on Ethereum, confirm all parties can receive ERC-20 tokens.
- Configure the preset distribution shares in shaka.deal. Have the closing attorney or escrow officer review the percentages before submission. Treat this review the same way you would review a wire instruction.
- Identify the closing window. If the scheduled close falls in the 14:00–18:00 UTC window on a weekday, surface this with the parties and discuss whether a Saturday morning UTC submission is operationally feasible. In most non-time-critical deals, it is.

**On the day of closing:**
- Check the gas tracker immediately before submitting — Etherscan's gas tracker is the standard reference. In 2026, a good gas price for Ethereum mainnet is 8–20 Gwei for standard transactions. Below 10 Gwei is excellent — typically seen on weekends and late-night UTC hours. 20–50 Gwei is moderate and acceptable for urgent transactions. Above 50 Gwei is expensive — consider waiting for lower congestion.
- Set the max fee ceiling generously. The amount you actually pay will be no more than base fee plus tip, but the ceiling protects against a stall if the base fee ticks up between broadcast and confirmation.
- Submit the single routing transaction through shaka.deal. All parties receive their preset shares in the same transaction.
- Share the transaction hash with all parties immediately. The hash is the permanent, auditable record of the settlement.

**After confirmation:**
- Record the block number and transaction hash in the deal file. This is your settlement receipt. It is immutable, timestamped, and publicly verifiable by any party at any time without requiring a bank statement.

## Why One Transaction Changes the Professional's Exposure

There is a subtler risk management dimension to the single-transaction structure that goes beyond gas cost. When a closing professional executes multiple individual outbound transactions, each one is a discrete event with its own failure mode. One stalls. One is sent to a slightly wrong address because of a copy-paste error on the fifth repetition of the same workflow. One is broadcast at a different fee level than the others and takes longer to confirm, creating an asymmetric settlement: some parties have their funds and some do not.

What begins as a straightforward payout quickly turns into a repetitive, high-friction workflow: copy an address, enter an amount, confirm the transaction, wait for inclusion, repeat the entire process again and again. For teams running partner settlements, this manual process introduces delays, gas inefficiencies, and a surprisingly large surface area for mistakes.

The bigger improvement is reducing human error and making the transfer process easier to validate before funds move. When recipients and amounts are assembled in a single batch view, the sender can review the entire distribution at once.

Shaka.deal addresses this directly. The distribution logic is preset and reviewed once, not re-entered transaction by transaction under closing-day pressure. The routing is simultaneous — not sequential — which means no party is in a position where their funds have moved but another party's have not. The settlement professional can confirm the transaction hash to all parties at once, with everyone having received their amounts in the same block. That simultaneity is a qualitative change in the closing experience, not merely a cost reduction.

## When Gas Is High and the Deal Cannot Wait

Sometimes the calendar does not cooperate. A deal has a hard closing date. The parties are ready. The gas tracker is showing 120 Gwei at 3:00 PM UTC on a Tuesday. What then?

Accepting slower inclusion can reduce cost, especially during moderate congestion — lowering the priority fee if you can tolerate a wait time of a few blocks. If the deal can absorb a 10–20 minute delay, setting a modest priority fee and letting the transaction sit in the mempool until the next quieter block can reduce cost without meaningfully delaying the settlement.

If the deal truly cannot wait and gas is genuinely high, the single-transaction structure of shaka.deal still protects the parties relative to the alternative. One high-gas transaction is materially less expensive than four or five high-gas transactions. The routing overhead of distributing to multiple parties simultaneously through a smart contract costs less in aggregate than executing the same distributions sequentially as individual sends. The batch overhead is amortized across all recipients.

A batch blockchain transaction may have lower overall fees and gas costs than implementing each of the requests individually in its own dedicated blockchain transaction. Moreover, by collating requests into a batch transaction, the transaction may have a higher overall fee that will ensure the batch is mined expeditiously — whereas if the requests were in individual blockchain transactions, the individual fee in each may be too low for validators to include those individual transactions.

This last point is underappreciated. A single well-configured routing transaction with a proper priority fee gets included reliably. Five individual transactions with individually modest priority fees may not all clear in the same block — some may wait, creating exactly the partial-settlement scenario that professionals want to avoid.

## The Closing Professional as the Architect of Good Settlement

The professionals who handle large payments — settlement agents, closing attorneys, escrow officers, OTC desks — already understand that settlement quality is their core product. The speed, accuracy, and finality of the distribution is not a background technical function; it is the value they deliver to every party at the table.

Onchain routing tools do not change that professional's role. They expand their toolkit. The closing attorney still sets the distribution percentages. The escrow officer still reviews every address. The settlement agent still manages the relationship between all parties and communicates the results. What changes is the mechanism: instead of initiating multiple wires and managing the confirmations one by one, the professional submits a single transaction that handles the entire distribution atomically.

Stablecoins give you the programmability and speed of crypto without the price swings. That simple combination has turned them into plumbing for DeFi, cross-border payments, remittances, treasury management, and on-chain settlement.

For a professional who handles multiple large transactions per month, internalizing gas timing and single-transaction routing as standard practice — the way they internalized wire cut-off times and confirmation call protocols years ago — changes the economics of every close in their pipeline. Not dramatically on any single deal, but persistently and compoundingly across a book of business.

High gas is not an emergency. It is a predictable variable with documented patterns and concrete mitigation strategies. Time the transaction to the low-congestion window. Structure it as a single routing transaction that distributes to all parties simultaneously. Set the fee parameters correctly. Verify addresses before the day of closing. Use shaka.deal to handle the routing so that the distribution logic is locked in before the moment of execution, not assembled under pressure at the desk.

That is the workflow. It is not complicated. It is competent.