Gas Fees
Last updated
Last updated
There are two parties a user pays for when submitting a transaction:
The poster, if reimbursable, for L1 resources such as the L1 calldata needed to post the tx
The network fee accounts for L2 resources, which include computation, storage, and other burdens L2 nodes must bare to service the tx
The L1 component is the product of the transaction's estimated contribution to its batch's size β computed using Brotli on the transaction by itself β and the L2's view of the L1 data price, a value which dynamically adjusts over time to ensure the batch-poster is ultimately fairly compensated. For details, see .
The L2 component consists of the traditional fees Geth would pay to stakers in a vanilla L1 chain, such as the computation and storage charges applying the state transition function entails. ArbOS charges additional fees for executing its L2-specific , whose fees are dynamically priced according to the specific resources used while executing the call.
The L2 gas price on a given AlienX chain has a set floor, which can be queried via 's getMinimumGasPrice method (currently 0.01 gwei on AlienX).
Calling an AlienX Node's eth_estimateGas RPC gives a value sufficient to cover the full transaction fee at the given L2 gas price; i.e., the value returned from eth_estimateGas multiplied by the L2 gas price tells you how much total Ether is required for the transaction to succeed. Note that this means that for a given operation, the value returned by eth_estimateGas will change over time (as the L1 calldata price fluctuates.)
The sequencer prioritizes transactions on a first-come first-served basis. Because tips do not make sense in this model, they are ignored. AlienX users always just pay the base fee regardless of the tip they choose.
When a transaction schedules another, the subsequent transaction's execution when estimating gas via the node's RPC. A transaction's gas estimate, then, can only be found if all the transactions succeed at a given gas limit. This is especially important when working with retryables and scheduling redeem attempts.
Because a call to donates all of the call's gas, doing multiple tasks requires limiting the amount of gas provided to each subcall. Otherwise, the first will take all of the gas and force the second to necessarily fail irrespective of the estimation's gas limit.
Gas estimation for Retryable submissions is possible via the and similarly requires the auto-redeem attempt to succeed.