Skip to main content

​
Batch and Block Limits

To avoid overloading the prover and ensure that it can produce a proof within a bounded time frame for a single batch, the protocol imposes the following limits:
  • There can be at most 100 blocks in a batch.
  • There can be at most 5 transactions in a block.

​
Transaction Fees

The fee schedule is separated into fees for sequencer-committed transactions, which are paid on the keystore, and fees for L1-initiated transactions, which are paid on L1.

​
Sequencer-Included Transactions

The fee for transactions sent to the sequencer is comprised of two parts, a L2 execution fee and a L1 data fee. Fees from transactions committed to L1 by the sequencer are funded on the keystore and collected by the sequencer. The execution fee is denominated in gas, which users bid on on a per unit basis. The gas cost by transaction type is listed below (DEPOSIT transactions must be L1-initiated and are not shown).
Transaction TypeL2 Gas
WITHDRAW100_000
UPDATE100_000
The L1 data fee is dynamically calculated using the following function:
Solidity
function getDataFee(
    bytes memory transaction,
    uint256 l1Origin,
    uint256 l1BaseFeeScalar,
    uint256 l1BlobBaseFeeScalar
) returns (uint256) {
    return transaction.length *
      (16 * l1Origin.readL1BaseFee() * l1BaseFeeScalar
      + l1Origin.readL1BlobBaseFee() * l1BlobBaseFeeScalar)
      / 1e6;
}
In this function:
  • transaction is the serialized transaction envelope specified in Keystore Transactions
  • l1Origin is the sequencer-assigned L1 origin of the batch in which the tx was executed.
    • The l1Origin.readL1BaseFee() and l1Origin.readL1BlobBaseFee() are the values from the L1 origin block. How this is enforced depends on the execution context.
  • l1BaseFeeScalar and l1BlobBaseFeeScalar are scalars applied to the L1 base fee and L1 blob base fee respectively
    • The scalar values allow the sequencer to adjust the proportion of DA costs allocated to calldata versus blobs.
    • Both values are interpreted as fixed-point decimals with 6 decimal places.
Estimation for L1 data fees is also performed using the above function. Note that the actual fees charged and fee estimates may diverge based upon differences in L1 origin between the estimate and actual L1 inclusion of the batch. The L1 data fee is deducted from the balance of the sending or sponsoring account. It is not currently possible to limit the maximum L1 data fee a transaction is willing to pay.

​
L1-Initiated Transactions

L1-initiated transactions pay transaction fees on L1 as part of the L1-initiation transaction. The fee schedule for L1-initiated transactions is:
Transaction TypeValue
DEPOSIT0.001 ether
WITHDRAW0.005 ether
UPDATE0.005 ether
Transaction fees from L1-initiated transactions are paid on the bridge and directed towards the prover. Note: Because of the L1-initiation fee, depositing onto the keystore is not free, which is necessary because automatic inclusion of L1 transactions imposes proving costs on the prover. Under normal operations, the sequencer is responsible for paying the prover1. However, when the sequencer is bypassed via an L1-initiated transaction, that burden is shifted to the user. These fees should not affect most users, since we expect users to primarily transact via native gas sponsorship. We anticipate deposits will primarily be used by gas sponsors, who generally assume a small cost for deposits to pay L1 gas fees in any case.

​
Native Gas Sponsorship

All Update transactions can have fees either paid for by the user or sponsored by a sponsor account.

Footnotes

  1. Currently, the sequencer and prover are both run by the same entity, and the protocol does not provide a way for provers to receive payments from the sequencer. However, the protocol is designed to enable such payments in the future. ↩
⌘I