Zksync
Zksync Era transaction fees include execution and pubdata costs
Zksync Era transaction fees cover computation, protocol overhead, and the public data that the rollup publishes to Ethereum. That data, called pubdata, includes compressed storage changes, contract bytecode, and L2-to-L1 messages. Era accounts for publication costs alongside execution when determining a transaction’s gas requirements. A wallet’s gas allowance therefore needs room for both, while refunds can reduce the final charge. The price varies with the transaction’s state changes, network conditions, and Ethereum data costs.
Updated ·Estimating an Era contract call
An Era contract-call estimate accounts for the resources needed to validate and execute the transaction, including the publication costs associated with its resulting changes. The relevant input includes the sending account, target contract, call data, and any attached value. Account validation can also affect the required gas. A quote for a different account or different call arguments may therefore describe a different execution, even when the contract address stays the same.
Era supports
eth_estimateGas
for estimating a call’s gas requirement. The result is an allowance in gas units, which needs a gas price to become a monetary fee. Execution-only measurements from a different virtual machine can miss Era-specific validation, overhead, and pubdata charges. Those measurements cannot replace a transaction estimate for the intended Era execution.
An estimate describes execution against a particular state. Later storage changes or different publication prices can change the gas allowance or fee required.
Pubdata behind storage updates
Pubdata supplies the information needed to reconstruct the rollup’s state, including storage differences, contract bytecode, and L2-to-L1 logs and messages. Era publishes the changes that survive batch execution. This relationship makes storage behavior relevant to transaction costs, beyond the computation that a contract performs.
Final storage differences
Storage differences describe how a storage location changes across a batch. Multiple writes to the same location can collapse into a single published difference. A temporary change that returns to its original value can remove that difference, although the computation still consumes resources. Consequently, counting individual storage-write operations does not establish the final pubdata byte count.
Previously published storage locations also have compact identifiers. The compression format can encode changes relative to earlier values, reducing the bytes needed for suitable updates. The savings depend on the actual storage history and values; repeated contract calls do not necessarily receive identical discounts.
Messages and contract bytecode
L2-to-L1 messages and their associated logs add publication data of their own. Native EraVM deployments can also require publication of previously unknown bytecode through factory dependencies. Bytecode reuse can avoid publishing the same code again, while constructor execution and new storage changes still contribute costs. Storage compression therefore explains only part of a deployment or messaging fee.
What does gas per pubdata actually limit?
The
gasPerPubdata
field in a Zksync EIP-712 transaction limits the gas that its sender accepts per published byte. This price limit differs from the transaction’s total
gasLimit. It does not specify how many bytes the transaction will produce. Lowering this price cap does not compress storage changes or message contents, and an insufficient limit can prevent inclusion at the required publication rate.
Era tracks pubdata during execution and checks whether the remaining gas covers its publication charge afterward. If the transaction completes its computation without enough gas for that charge, it reverts. The computation still incurs a fee, while the reverted execution’s state changes do not survive.
Ethereum-compatible transaction formats omit the sender-defined pubdata field and use the block’s applicable publication setting.
Ethereum publication through blobs and calldata
Ethereum blobs provide a data-availability channel for rollup publication, and Era’s publication machinery supports both blob-based commitments and calldata-based commitments. Blob data and ordinary Ethereum execution gas have distinct fee markets. Publication pricing therefore follows the applicable channel and the operator’s fee inputs. Lower publication costs can reduce a transaction’s data component, while execution, validation, and batch overhead still consume resources. Blob support does not establish a permanent transaction price.
Gas allowances, actual charges, and refunds
An Era gas allowance reserves capacity for execution and publication before the system knows the transaction’s final resource consumption. This upfront requirement explains why a wallet can display a larger allowance than the gas that a completed transaction ultimately incurs. The maximum gas price and the maximum gas quantity also describe separate limits.
Upfront capacity
Batch processing involves proving and settlement costs alongside limits on transaction slots, encoded transaction memory, and publication capacity. The fee model assigns overhead to transactions that consume those resources. An estimate can reserve more than the execution eventually needs because the precise resource use emerges during processing. Setting the allowance to a bare computation measurement can leave essential costs unfunded.
A higher gas limit permits more consumption. It does not, by itself, establish how much gas the transaction will actually use.
The settled network fee
An
Era transaction’s network fee equals its receipt’s
gasUsed
multiplied by
effectiveGasPrice.
The charged gas accounts for applicable refunds, so the original limit alone cannot establish the final fee. Pubdata forms part of Era’s transaction accounting; adding another publication estimate to that completed network fee would count the same component twice.
Refunds can cover unused resources and excess upfront charges. The model also uses overhead allowances that reflect batch costs across transactions, so it does not promise an identical refund percentage or reimbursement of every estimated overhead component. A transferred asset amount remains separate from this network-fee calculation.
Publication scope across Era operations
Era operations generate different kinds of publication data, which explains why similar-looking contract interactions can carry different costs. Storage updates, deployments, and messaging can overlap within one transaction. Their data requirements do not form separate universal fee tiers.
| Era operation | Data that can require publication |
|---|---|
| Storage-updating contract call | Storage differences that survive batch execution, with compression depending on the locations and values. |
| Native EraVM deployment | Previously unpublished bytecode supplied through factory dependencies, alongside deployment-related state changes. |
| L2-to-L1 message | The message payload and its associated L2-to-L1 log. |
Native EraVM factory dependencies also face batch publication limits. A large dependency set may require more than one publication transaction. Each individual contract must still fit the relevant size limits; a higher fee allowance cannot override them.
Subcall limits and later publication charges
A contract’s subcall gas allowance constrains computation, while Era’s later pubdata accounting can add costs outside that local allowance. This matters when an application calls other contracts and assumes that forwarding limited gas also bounds the call’s total fee impact. The enclosing transaction must still fund the pubdata that those calls generate. A costly publication requirement can exhaust that budget even when the subcall obeys its computation limit.
The
GasBoundCaller
helper checks a routed call’s added pubdata cost against a total gas allowance, with margins for its own processing, and reverts the routed call if the allowance is insufficient. Its integration must supply compatible computation and total-cost allowances; the callee can spend the computation gas it receives. The helper also propagates a callee’s revert. Its bound concerns the routed call and does not automatically cap every cost of the enclosing transaction.
Bridge charges outside the Era receipt
A bridge operation can involve fees on more than one chain, so an Era execution fee covers only its Era transaction. An Ethereum-originated deposit incurs an Ethereum transaction cost and requires funding for the requested L2 execution. A standard withdrawal initiated on Era incurs its L2 fee, while finalization on Ethereum requires a separate Ethereum transaction. Those charges belong to different executions, even when an interface presents a combined quote.
A paymaster can change who supplies the Era network fee. Sponsorship or token-payment arrangements depend on that integration’s terms and do not remove the underlying publication cost.
An Era contract-call estimate excludes any separate Ethereum transaction that the overall operation requires. Comparing complete bridge quotes therefore requires keeping those chain-specific charges within the total.
Questions people ask about Zksync
Does an Era fee estimate include ETH sent to a contract?
A network-fee estimate and the ETH value attached to a call describe separate amounts. The attached value goes to the call’s recipient if execution succeeds; the fee pays for transaction processing. A self-funded transaction needs sufficient funds for both obligations. The value field can affect execution and therefore its estimate, but the transferred amount is not itself a gas charge.
Can a read-only contract query generate an Era transaction fee?
A read-only query through eth_call does not create a blockchain transaction and incurs no Era transaction fee. The node executes the requested call to return its result without committing the simulated changes. A submitted transaction that calls a read-only function still consumes transaction-processing resources.
Is zks_estimateFee the recommended method for new Era integrations?
zks_estimateFee is deprecated in Era’s RPC interface. It returns estimated fields such as gas_limit, max_fee_per_gas, and gas_per_pubdata_limit where a node still supports it. For new integrations, eth_estimateGas supplies the gas estimate, while compatible provider methods populate the transaction’s pricing fields. Deprecation does not mean that every node has removed the endpoint.
How can software inspect Era’s active publication-price parameters?
The zks_getFeeParams method returns EraVM fee configuration and pricing inputs. Its response includes L1 gas and pubdata prices, batch overhead settings, and resource limits. Those values describe the node’s active fee model; they are not permanent protocol-wide prices. Software must preserve the response’s version structure and units when interpreting them, and still estimate the actual transaction’s gas requirements.
What happens if validation cannot cover its own pubdata charge?
Era rejects a transaction when its validation phase leaves insufficient gas for the pubdata generated during validation. That rejection occurs before block inclusion. A later failure during transaction execution has a different consequence: the included transaction can revert and still incur computation fees. The failure stage therefore determines whether the error represents rejection or an execution that consumed billable resources.
Will a higher priority fee speed up Era transaction inclusion?
EraVM does not use Ethereum-style priority fees as bids for faster transaction inclusion. Increasing maxPriorityFeePerGas therefore does not create that fee-auction behavior on Era. The transaction still needs an adequate overall fee cap and gas allowance. This rule concerns EraVM; it should not be carried over to a chain with a different execution and fee-accounting model.
Are Era’s fee assumptions valid on Zksync OS chains?
EraVM-specific fee assumptions do not apply unchanged to Zksync OS chains. Zksync OS tracks execution-environment gas and native resources through a different accounting model. Some RPC endpoints also have explicit EraVM-only scope. An integration must use its target chain’s execution model and supported estimation methods, even when both networks belong to the same ecosystem.