Gas Management

KeeperHub handles gas configuration automatically for all blockchain transactions. This page explains how gas limits are calculated and how to override the defaults when needed.

How Gas Limit Estimation Works

Every transaction goes through three stages:

1. Estimate - KeeperHub calls eth_estimateGas on the network to get the minimum gas units required
2. Multiply - The estimate is multiplied by a safety factor (the gas limit multiplier) to account for on-chain state changes between estimation and execution
3. Submit - The final gas limit is set on the transaction

Final Gas Limit = Estimated Gas x Multiplier

The multiplier exists because gas estimates are point-in-time snapshots. Between estimation and on-chain execution, contract state can change (other transactions may execute first), which can increase the actual gas required. Without a buffer, transactions risk running out of gas and reverting — wasting the gas fee while accomplishing nothing.

Default Multipliers

Defaults vary by chain type. L2 networks use lower multipliers because their gas estimates tend to be more accurate.

The same multiplier applies however the workflow was triggered. A manual run, a scheduled run, a webhook, and an event trigger hitting the same contract on the same network all receive the same gas limit.

These defaults are resolved in order: database chain config > hardcoded chain overrides > global default (2.0x).

Gas Limit Override

You can set an absolute gas limit per action node:

1. Open the action node configuration (Transfer Native Token, Transfer ERC20 Token, Approve ERC20 Token, or Write Contract)
2. Expand the Advanced section
3. Set the Gas Limit field to an absolute gas unit value (e.g. 500000)

Field Behavior

• When empty: The chain’s default multiplier (see Default Multipliers) is applied to the gas estimate at execution time
• When set: Your absolute value is used directly as the transaction gas limit, bypassing the multiplier

The field also shows a live gas estimate when enough configuration is filled in (network, contract address, function, etc.). This helps you choose an appropriate gas limit. If your value is below the current estimate, a warning is shown.

Example

If the network estimates 100,000 gas for your transaction and the network’s default multiplier is 2.0x:

Setting a gas limit below the estimate will cause the transaction to revert with an out-of-gas error. Setting it close to the estimate risks failure if on-chain state changes between estimation and execution.

Gas Sponsorship

On supported networks, KeeperHub can sponsor the gas fee of a workflow transaction through Turnkey’s Gas Station, so a workflow can run even when the sending wallet holds no native gas token. Sponsorship is enabled per organization and metered against a monthly gas credit allowance shown on your billing page.

Sponsorship also changes how the transaction appears on a block explorer. See What Your Transaction Looks Like On-Chain.

What sponsorship covers

Sponsorship pays the transaction fee only. It does not provide the assets your transaction moves. The native value a transaction sends (for example, the ETH amount in a Transfer Native Token action) is always debited from your own wallet.

To send 0.1 ETH to another address, your wallet must hold at least 0.1 ETH; sponsorship only means it does not also need extra ETH to cover the gas fee. A token transfer (USDC and similar) likewise requires the token balance in your wallet. Only the gas is sponsored.

When a transaction is sponsored

A transaction is sponsored only when all of the following are true. Otherwise it falls back to paying gas from your wallet, and it fails if that wallet has no native balance.

• Supported network: Ethereum, Base, Polygon, and Arbitrum, plus their testnets (Sepolia, Base Sepolia, Polygon Amoy, Arbitrum Sepolia).
• Direct wallet sender (no Safe): the active Sender is the wallet itself.
• Public mempool: transactions routed through a private mempool are not sponsored.
• Gas credits available: your organization still has gas credits for the current period.

Safe wallets

Workflows that route through a Safe (Sender ON) are not gas sponsored. The sponsored transaction is built as a direct call from your wallet, so applying it to a Safe write would change msg.sender away from the Safe. Safe writes pay gas from the wallet that signs the outer transaction; direct wallet sends remain eligible for sponsorship.

Gas credits

Sponsored gas is metered in USD against your plan’s monthly gas credit cap (shown on the billing page). Mainnet usage counts against the cap; testnet usage is not charged. When the cap is reached, sponsorship pauses for the rest of the period and transactions pay gas from the wallet.

When sponsorship falls back

Sponsorship is attempted first and falls back to direct signing (your wallet pays the gas) whenever any eligibility condition above is not met. Sponsorship can also be unavailable for a specific organization or wallet even when all of them hold: Turnkey can reject an activity at submission time, and the step then falls back the same way.

The Runs panel shows a Gas sponsored badge on each sponsored step; a step that fell back has no badge. The badge is per step, so a run with one sponsored step and one fallback step still shows it on the sponsored step. The run-level Sponsored filter (under Used gas) lists runs that drew on gas credits. The run output does not say why sponsorship was skipped.

What the fallback does next depends on the wallet balance:

• Wallet holds native gas: the run completes, paid from your wallet.

• Wallet has no native gas: the gas preflight runs before the transaction is broadcast and fails the step with:

  Insufficient ETH balance. Have: 0.0, Need: 0.000000231. Fund
  0x...orgWallet with at least 0.000000231 ETH on this chain and retry.

  Nothing was broadcast at this point, so there is no transaction hash to look up. Fund the address named in the message and retry. The preflight caches the balance and the gas price for about ten seconds, so a retry started right after the funds land can repeat the same error; give it a few seconds.

The preflight runs in the Web3 plugin’s EVM write actions and in the protocol actions built on them. Actions on chains with their own transaction path, such as Tempo, do not run it. Reaching the preflight means the wallet is paying gas itself — either the step was never eligible for sponsorship, or a sponsored attempt fell back — and funding the address fixes the run either way. For a write that sends no native value, restoring the eligibility conditions above can also fix it without funding. A write that sends native value always needs that value in the wallet, because sponsorship covers the fee only (see What sponsorship covers).

FAQ

What happens if I leave the gas limit empty?

The chain’s default multiplier is applied to the gas estimate at execution time: 2.0x on most networks, 1.5x on the L2s listed under Default Multipliers. The trigger type has no effect on it.

What happens if my gas limit is too low?

The transaction is mined but reverts with an “out of gas” error, and you still pay for the gas consumed up to the limit. KeeperHub does not retry it: the run fails and reports the revert, including the transaction hash. Raise or clear the gas limit and run the workflow again.

What happens if my gas limit is too high?

The transaction reserves more gas but only consumes what it needs. Unused gas is refunded. There is no direct cost penalty, but very high limits may cause the transaction to be deprioritized by some networks.

Does the gas limit affect gas price/fees?

No. The gas limit only sets the maximum gas units. Gas pricing (base fee, priority fee) is handled separately by KeeperHub’s adaptive fee strategy and is not configurable through this field.

Solana Fees

Solana transactions do not use EVM-style gas limits or multipliers. Instead, fees are paid in lamports from your SOL balance.

Every confirmed transaction includes a base signature fee of 5,000 lamports. If the transaction sets a compute-unit price, KeeperHub also reports the priority component derived from consumed compute units and the effective micro-lamport price.

In workflow outputs for Solana transfers:

• gasUsed is the total lamport fee paid
• gasUsedUnits is the compute units consumed
• effectiveGasPrice is the micro-lamports-per-compute-unit price used for the priority component

There is no gas limit multiplier on Solana write actions. Ensure the wallet holds enough SOL to cover both the transfer amount (for native SOL sends) and the transaction fee, plus any rent required when creating a recipient associated token account during SPL transfers.

Wallet Funding

Ensure your Turnkey wallet has sufficient ETH to cover:

• Transaction gas costs
• Retry attempts
• Potential gas price spikes during network congestion

See Turnkey Integration for wallet funding details.