Shibarium Gas: Estimated and Actual Transaction Fees
Updated:
Shibarium transaction fees use BONE, and the final gas charge comes from the transaction receipt. An estimate combines predicted gas use with a gas-price quote. After execution, gasUsed and effectiveGasPrice show the actual fee inputs. Comparing those values explains why a wallet’s estimate can differ from the BONE amount spent on gas.
The useful comparison keeps transaction details and network context aligned. Gas units, gas limits, and prices describe different things. A pending transaction hash, a failed receipt, and an Ethereum-side bridge charge also need different treatment when assessing the cost.
The short version: The gas limit sets an execution allowance; the receipt’s gasUsed determines how many units enter the actual fee calculation.
Bor Execution and the BONE Fee Balance
Bor is the EVM-compatible execution layer that processes transactions and runs smart contracts on the network. The Ethereum Virtual Machine, or EVM, measures execution work in gas units. Native BONE supplies the currency for paying that charge. Together, those components explain the distinction between work and price: the transaction consumes gas units, and its paid price converts those units into a BONE fee. A contract call’s computational demands matter even when the amount of the token transfer stays unchanged.
The native BONE balance funds gas. A balance of another token doesn’t substitute for the currency that the network charges for ordinary transaction execution.
What Does a Gas Estimate Actually Measure?
A gas estimate predicts the execution units that a proposed transaction needs, using the call details supplied to the node. The
eth_estimateGas
method performs that estimation without adding the transaction to the blockchain. Its result describes simulated execution, so it doesn’t establish a completed transfer or a final charge. Sender, recipient, native value, and encoded contract input define the call that the node estimates.
The gas limit sets an execution allowance, while the estimate helps choose that allowance. Neither value reports the units that the transaction eventually consumes. Estimates can exceed actual usage because of EVM mechanics and node performance. Changing the proposed call also changes the basis of the estimate. A limit that falls short of the required execution work can cause failure; extra allowance doesn’t establish that execution will consume every permitted unit.
Price Quotes and Fee Settings
A gas-price quote supplies a price per execution unit, which combines with estimated units to produce an estimated gas cost. The
eth_gasPrice
method returns the network’s gas-price estimate. Where the node and fee format support EIP-1559,
eth_feeHistory
supplies historical fee information that can inform fee settings. These queries don’t promise the price that a later receipt will report. Congestion can change network price quotes, while contract complexity can change the required gas quantity. An executed legacy transaction pays its specified gasPrice per gas unit. Where EIP-1559 transactions are supported, the effective price is the inclusion block’s base fee plus the tip, bounded by the transaction’s fee caps.
Three RPC Views of One Fee
A fee comparison joins a gas-unit prediction and a price quote with the execution data in a receipt. These RPC methods answer different parts of the same question. Their outputs become comparable only when the estimate concerns the transaction whose receipt supplies the actual cost.
| RPC Method | Fee Information | Confirmation Limit |
|---|---|---|
eth_estimateGas
|
Estimated execution units | Doesn’t submit or complete the transaction |
eth_gasPrice
|
Quoted price per gas unit | Doesn’t establish the eventual paid price |
eth_getTransactionReceipt
|
Actual gas use and effective price | A pending transaction has no execution receipt |
| Comparison Basis | Matching transaction details and network | Receipt fields establish the executed gas charge |
For a transaction with an estimate and a later receipt, compare the estimated units with
gasUsed
. Then compare the quoted unit price with
effectiveGasPrice
. Lower actual usage explains a quantity difference, while a different effective price explains a pricing difference. Both inputs can change the total. The transferred asset amount alone doesn’t reveal which input accounts for a gap.
This comparison requires matching call details. A changed sender, recipient, value, or encoded input can make the earlier estimate an unsuitable baseline.
How Do You Calculate a Transaction’s Actual Gas Fee?
A transaction’s gas charge in base units equals its receipt’s
gasUsed
multiplied by
effectiveGasPrice
.
The first field measures the gas that this transaction consumed. The second gives the price that it paid per unit. Transferred native value and ERC-20 quantities belong outside this gas calculation.
BONE uses 18 decimal places, so dividing the base-unit product by
10^18
expresses the charge in BONE. Preserve the integer values during multiplication and conversion to avoid rounding away small fees. A wallet or explorer may round its displayed total. A displayed difference therefore warrants checking units and display precision before attributing the entire gap to a change in execution.
The receipt’s block number identifies the execution context for comparing its fee with an earlier quote.
Can a Pending Transaction Have an Actual Fee?
A pending transaction doesn’t yet have the execution receipt needed to calculate its actual gas charge. A transaction hash identifies the transaction, while a receipt supplies its inclusion and execution details. The receipt query returns
null
when it finds no receipt, including for a transaction that remains pending. That response doesn’t establish a zero fee or successful execution. A wallet may continue showing an estimate during this interval. Until a receipt reports the relevant gas fields, that figure remains an estimate of the proposed charge.
Pending Replacements and Failed Execution
A replacement from the same sender uses the low-priced pending transaction’s nonce and a higher gas price to seek inclusion. The nonce identifies its place in the sender’s transaction sequence. A new transaction with a different nonce doesn’t replace the pending one. The executed transaction’s receipt supplies the cost record, rather than whichever quote the wallet displayed before the replacement.
A receipt’s
status
distinguishes success from failure:
0x1
indicates success, and
0x0
indicates failure. A failed execution can consume gas, so its failure status doesn’t establish a zero charge. Record the outcome beside the gas charge, since an unsuccessful call and a successful call don’t accomplish the same operation.
Gas Charges Across Contract Calls and Networks
A contract interaction can involve multiple transactions, and each execution receipt accounts for its own transaction’s gas charge. The number of application actions doesn’t establish the number of transactions. Several internal contract calls can belong to one transaction, whose receipt measures the enclosing execution. Separate transactions have separate cost records. An estimate and receipt for one of them don’t describe the total expense of a broader activity that also includes other transactions.
Ethereum-side bridge transactions use ETH for gas, while transactions that execute on Shibarium use BONE. The execution network determines the fee currency, even when a contract handles a different token. That distinction keeps bridge-related gas separate from the token quantity moving between networks. Each receipt concerns execution on its own chain.
Matching RPC field names don’t imply matching fee currencies. Their native-token denomination follows the chain that supplied the receipt.
Mainnet, Puppynet, and Fee Comparability
An RPC endpoint supplies estimates and receipt data for the particular network that it serves. Mainnet uses chain ID 109, while Puppynet uses chain ID 157. A testnet estimate describes testnet execution and pricing; it doesn’t supply a production quote. Identical wallet addresses don’t make the network contexts interchangeable. Comparing an estimate with a receipt therefore requires the same chain as well as matching transaction details. Switching networks changes the estimation context, even when the intended contract action has the same description.
Shibarium: quick answers
Why Does cumulativeGasUsed Differ From gasUsed?
cumulativeGasUsed includes gas from earlier transactions in the same block, while gasUsed covers the individual transaction. The cumulative field measures block execution up to that receipt’s transaction position. A larger cumulative value doesn’t mean that the sender paid for other transactions. Use the individual gas quantity when interpreting that transaction’s fee.
Can a Wallet Balance Change Reveal Just the Gas Charge?
A decrease in the native BONE balance can equal the gas charge when the interval contains no other native-value changes. Transfers and other activity can alter the same balance. Balance queries describe an address at a selected block, so two snapshots may bracket several transactions. A receipt ties gas usage and paid unit price to one execution.
What Does a Null Transaction Lookup Mean for Fee Tracking?
A null response from eth_getTransactionByHash means that the queried node didn’t find that transaction. This differs from a null receipt for a known pending transaction. Neither response establishes a completed operation or a zero gas charge. A transaction object with no inclusion block can describe a pending submission; the receipt supplies the actual execution data.
Does an ERC-20 Transfer Amount Set the Gas Charge?
The transferred token amount alone doesn’t determine the gas charge for an ERC-20 contract call. Execution work and the paid price per gas unit determine that charge. Contract logic can make particular inputs relevant to execution, so the amount should remain part of the intended call’s encoded arguments. A network gas fee isn’t a fixed percentage of the ERC-20 quantity.
Is Empty Call Data Enough to Estimate a Specific Contract Function?
A call to a named contract function needs encoded input identifying that function and any required arguments. An estimate with missing or different input tests a different call from the intended function invocation. The sender, target contract, and native value also supply execution context. Matching those details makes the returned gas estimate relevant to the proposed transaction.
Are Raw RPC Gas Values Already Decimal BONE Amounts?
Raw JSON-RPC gas quantities use hexadecimal notation and represent gas units or base-unit prices, depending on the field. A gasUsed quantity is an execution-unit count, so converting it directly into BONE produces the wrong kind of value. A price field carries currency per gas unit. Wallet displays may format these quantities differently from raw RPC responses.
Could Two RPC Nodes Return Different Gas Estimates?
Gas estimates can differ because estimation depends on EVM mechanics and node performance. Matching the network and call details is necessary for a useful comparison between responses. A larger returned quantity doesn’t establish a separate on-chain tariff or a larger final charge. The executed transaction’s receipt remains the record of actual gas usage.
How Can ETH and BONE Gas Charges Be Added Together?
ETH and BONE gas charges need a common valuation unit before their amounts can form a meaningful combined cost. Each receipt establishes a charge in its network’s native currency. It doesn’t establish an exchange rate or a valuation time. Preserve the original token amounts alongside any conversion, so the combined figure doesn’t obscure the underlying charges.