Cronos
Cronos gas fees reflect contract work, gas limits, and the price paid in CRO
Cronos gas fees pay for transaction execution on Cronos EVM using native CRO. Contract calls often require more gas than plain CRO transfers because they execute additional instructions and access contract state. The final charge combines billable gas with the effective price per unit. Your selected gas limit also matters because Cronos applies a configurable minimum gas charge. A wallet's maximum fee budget can therefore differ from the amount ultimately charged.
Gas units, transaction pricing, and the CRO charge
Gas measures the work that a transaction requires; the gas price expresses what each unit costs. Multiplying the gas that the chain bills by the effective gas price gives the network charge. A demanding contract call can cost more than a simple transfer at the same price per gas. Conversely, an unchanged operation can become more expensive when its effective gas price increases.
The amount transferred is a separate quantity. Network gas is not a fixed percentage of the CRO sent or the tokens exchanged. Contract code, transaction data, and fee settings determine execution costs. A wallet can display the transferred value alongside a fee budget, while an explorer reports the settled network charge. Comparing those fields requires keeping transaction value, billable gas, and price per gas distinct.
Plain transfers and contract execution
Transaction type changes the work that the EVM meters. Plain CRO transfers avoid contract logic, while contract interactions can include storage changes and calls to other contracts.
Native CRO transfers
A plain native CRO transfer between ordinary accounts without executable code has a baseline intrinsic requirement of 21,000 gas. That figure assumes no additional transaction data, access-list entries, or authorization entries. It describes the simple transfer's gas requirement, not a universal fee in CRO. Sending to a contract can trigger its code, and an oversized gas limit can affect the billable amount.
Contract calls and deployments
Contract execution adds work beyond the transfer baseline. Storage access, computation, and calls into other contracts can increase gas consumption. Deployment also executes creation code and installs runtime code. These operations have different requirements, so a transfer's gas figure cannot establish the cost of a deployment or application interaction. Even repeated calls to one function can differ when contract state changes the execution path.
Base fees and transaction fee caps
Cronos EVM supports legacy gas pricing and EIP-1559 fee fields. Both express a per-gas price, but they encode the sender's pricing choice differently.
Legacy gas price
A legacy transaction specifies a single gas price. That price still has to satisfy the applicable network fee requirements. The base fee follows network utilization relative to the configured gas target, and a minimum gas price can constrain pricing. A previously successful gas price does not establish that a later transaction will meet admission requirements. The gas price and the transaction's gas limit remain separate settings.
Dynamic fee fields
An EIP-1559 transaction specifies a maximum fee per gas and a maximum priority fee per gas. For an accepted transaction, the effective price is the lower of the fee cap and the base fee plus the priority fee cap. The overall cap therefore also limits the effective tip. Multiplying the maximum fee per gas by the gas limit describes a maximum fee budget, rather than the settled charge.
Gas limits and minimum billable gas
A gas limit bounds the gas available for execution. Cronos EVM applies a configurable minimum gas charge derived from a transaction's gas limit. The minimum gas multiplier determines that floor. Gas accounting uses the greater of execution consumption and the floor when determining billable gas. This makes the selected limit relevant to cost even when execution needs less gas than the amount supplied.
Raising a limit far beyond the transaction's requirements can therefore increase the charge when the floor becomes decisive. Reducing it below the required execution budget introduces a different problem: the operation can run out of gas. An estimate for the actual call provides a basis for the limit. The governing multiplier is a network parameter, so a historical setting should not be treated as an immutable percentage. Read min_gas_multiplier with cronosd query feemarket params for the selected network.
How much CRO must remain available for gas?
The sending account needs enough native CRO on Cronos EVM to cover its fee budget and any CRO included as transaction value. There is no single reserve that fits every operation.
Spendable CRO on the selected network
A token balance does not automatically supply the native CRO that an ordinary EVM transaction uses for fees. CRO held on Cronos POS is also a balance on a separate network. Bridging can change where funds are available, but an EVM fee calculation uses the sending account's EVM balance. The wallet's portfolio total can include assets that the fee-paying account cannot spend as gas.
Transaction value and affordability
A native CRO transfer requires funds for both the transferred amount and gas. Dynamic fee transactions can also face affordability checks against their maximum fee budget, even if the eventual effective price is lower. Spending the entire displayed CRO balance leaves no native funds for that charge. An application transaction can need gas while carrying no CRO as transaction value, because contract execution still consumes resources.
Estimates before signing
A gas estimate evaluates a proposed call against a particular blockchain state. Cronos exposes eth_estimateGas for this purpose, alongside pricing methods such as eth_gasPrice and eth_feeHistory. Estimating gas requirements and obtaining a price answer different questions. Their combination produces a fee estimate, subject to the transaction's actual fee fields and the chain's billing rules.
The sender, recipient, transaction data, and native value help define the call being estimated. A different sender can have a different token allowance or balance, and changed contract state can alter execution. Estimates therefore do not promise an identical result in a later block. A failed estimate can expose a contract restriction or funding problem that increasing the fee price will not resolve.
From the wallet quote to the settled fee
A wallet may show an estimated charge or a maximum fee budget; a receipt records the gas billed after execution. The gas limit connects these stages by bounding execution and influencing the minimum charge. The fee fields connect them by constraining the price that the sender authorizes.
| Transaction stage | Meaning of the fee information | Failure or uncertainty |
|---|---|---|
| Estimation | A simulation estimates gas; pricing inputs support the proposed fee budget. | A failed simulation does not itself create an on-chain gas charge. |
| Authorization and submission | The signed transaction fixes its gas limit and fee fields. | A transaction hash alone does not establish execution or a settled fee. |
| Execution and settlement | The receipt reports billable gas and execution status. | Included failed execution can still incur gas fees. |
For an EIP-1559 transaction, the receipt's gasUsed and effectiveGasPrice provide the basis for the settled network fee. For a legacy transaction, use the transaction's gasPrice in place of effectiveGasPrice. The calculation still uses the chain's reported billable gas. It does not establish an application's separate charge or the amount of tokens received.
From the wallet quote to the settled fee
A wallet may show an estimated charge or a maximum fee budget; a receipt records the gas billed after execution. The gas limit connects these stages by bounding execution and influencing the minimum charge. The fee fields connect them by constraining the price that the sender authorizes.
- Transaction stage: Estimation Meaning of the fee information: A simulation estimates gas; pricing inputs support the proposed fee budget. Failure or uncertainty: A failed simulation does not itself create an on-chain gas charge.
- Transaction stage: Authorization and submission Meaning of the fee information: The signed transaction fixes its gas limit and fee fields. Failure or uncertainty: A transaction hash alone does not establish execution or a settled fee.
- Transaction stage: Execution and settlement Meaning of the fee information: The receipt reports billable gas and execution status. Failure or uncertainty: Included failed execution can still incur gas fees.
For an EIP-1559 transaction, the receipt's gasUsed and effectiveGasPrice provide the basis for the settled network fee. For a legacy transaction, use the transaction's gasPrice in place of effectiveGasPrice. The calculation still uses the chain's reported billable gas. It does not establish an application's separate charge or the amount of tokens received.
Failed execution and rejected submissions
A simulation error occurs before an on-chain transaction executes. It can reveal insufficient funds, a failed contract condition, or unsuitable call inputs. Running that simulation does not deduct an on-chain execution fee from the account.
A submission that the node rejects before on-chain execution also differs from a confirmed failed call. An interface error message alone may not identify which state applies. A receipt supplies execution information; a submission acknowledgement supplies earlier information.
A confirmed contract revert rolls back the reverted execution's state changes while leaving a gas charge for the transaction. The network performed work before encountering the failure. A fee payment therefore does not prove that the intended token movement or contract update succeeded.
An out-of-gas failure means the execution exhausted its available gas. A higher limit can address a genuinely inadequate execution budget, but a higher price per gas does not provide more execution units. Contract restrictions can still cause a revert even with ample gas available.
Unused prepaid gas follows Cronos's refund and minimum-charge rules. A failed transaction does not receive a blanket refund of its fee. Repeating an operation that continues to fail can produce additional charges for each included attempt. The failure reason determines whether a changed limit, funding, or call input can address it.
Application charges alongside network gas
An application's own charge can coexist with the CRO fee for executing its contract call. A trading fee or another contract-defined deduction belongs to that application's pricing, while network gas pays for execution. A bridge operation can likewise involve costs beyond its source transaction's gas. Those costs need their own applicable route and fee conditions. A receipt's network fee cannot, by itself, explain the difference between a quoted asset amount and the amount ultimately received.
Does a higher priority fee speed up a Cronos transaction?
A higher effective priority fee can improve transaction ordering under Cronos EVM's prioritized mempool, but it cannot guarantee an inclusion time. The effective tip depends on the base fee and the overall fee cap. Raising the priority fee cap alone may have no effect if the maximum fee per gas leaves insufficient room for a larger tip.
Transaction validity and account ordering still apply. A higher tip cannot repair a missing earlier account nonce, an insufficient balance, or a contract condition that causes failure. Increasing the gas limit addresses execution capacity, which is a separate concern. Increasing a fee cap creates pricing headroom; it does not instruct the EVM to perform less work.
Comparable costs under changing conditions
A meaningful comparison of Cronos gas fees keeps the operation, billable gas, and effective price on a consistent basis. CRO-denominated charges also differ from their displayed cash equivalent, which changes with the conversion price. A plain transfer's cost does not establish an application's cost, and a historical receipt does not quote a future call. The answer changes when execution state, fee settings, network pricing, or the minimum gas multiplier changes.
Helpful answers
Which denomination does gwei represent in a Cronos EVM fee display?
One gwei in a Cronos EVM gas-price display equals 0.000000001 CRO per gas unit. The denomination scales the displayed price; it does not change the asset used for the network fee. Multiplying a price expressed in gwei by billable gas gives a charge expressed in gwei, which must then be converted to CRO. A cash estimate additionally needs a CRO conversion price.
Are token approvals required before every Cronos application transaction?
A sufficient existing allowance can avoid another approval when the same contract spends the same token. For allowance-based tokens, permission belongs to a particular owner, token, and spender. A different spender or insufficient allowance can require a permission change. An on-chain approval transaction incurs its own gas charge, while the application's later execution has its own fee. Permission mechanisms differ, so an application action should not automatically be counted as two transactions.
Will a higher swap slippage tolerance lower the Cronos gas charge?
Slippage tolerance does not set Cronos's network gas price. It changes the execution outcome that a swap will accept, such as its minimum output for an exact-input exchange. A wider tolerance can permit a less favorable return without reducing the price of gas. A swap that breaches its execution condition can revert and still incur a fee if included on-chain. Gas estimates and output limits answer different cost questions.
Can receiving an ordinary CRO transfer incur gas for the recipient?
The sender pays gas for an ordinary native CRO transfer on Cronos EVM. Receiving that transfer does not require the recipient to submit a separate transaction or fund its own gas payment. A later outbound transfer or contract interaction is a separate operation with its own funding requirements.
How are internal contract calls reflected in the transaction fee?
Internal contract calls consume gas within the transaction that invokes them. An explorer can show multiple internal calls under one transaction hash, even though the sender submitted one transaction. Their execution contributes to its gas consumption; the listed calls are not automatically separate sender-paid transactions. A contract may also handle asset transfers or application charges during those calls, so the gas fee alone does not describe every balance change.
Does checking a Cronos balance consume CRO for gas?
Reading a Cronos balance through a node does not submit an on-chain transaction. Balance queries and local contract simulations do not debit an execution fee from the account being queried. An operation that submits a transaction can incur gas even when its purpose includes reading contract data. The distinction concerns how the operation runs, rather than whether the interface calls it a balance check.
Could an exchange withdrawal fee differ from Cronos network gas?
An exchange's CRO withdrawal charge can differ from the gas fee of its on-chain transfer. The withdrawal quotation describes what the provider charges the customer's account under its fee schedule. The blockchain transaction records the execution fee paid by the submitting address. These amounts measure different charges, so a provider's withdrawal fee should not be used as a direct quote for a transfer from a personal Cronos EVM account.
When are testnet fee estimates useful for a mainnet cost comparison?
Testnet estimates can help examine contract gas requirements when the code, inputs, and relevant state match the mainnet case. They do not establish the current mainnet CRO charge. Network fee parameters, utilization, and contract state can differ between environments. A test result therefore supports a comparison of execution requirements within those conditions, while mainnet pricing and billing parameters determine the actual mainnet fee.