Sequencer
Sequencers receive transactions from users, package and bundle them into blocks, execute transactions, etc. However, nearly all Layer 2 sequencers are centralized, which presents several issues, such as transaction censorship, unrestricted Miner Extractable Value (MEV) extraction, and single points of failure
In this phase of the end-to-end transaction flow, transactions go through different stages, depending on the user’s GasPriceSigned:
Sequencing transactions coming from the transaction pool manager.
Estimating the effective gas price (EEGP) using the current L1GasPrice and RPC’s estimated GasUsedRPC.
where the priority ratio is given by:
Depending on whether or not, transactions get executed with either the or the
Amongst the transactions that are computed with the , further gas savings can be achieved by:
Computing the new effective gas price (NEGP), using the current state and the EEGP.
Calculating the gas consumption deviation percentage and comparing it to a fixed deviation parameter. i.e.
There’s no further execution if the gas consumption deviation percentage is less than the fixed parameter,
Otherwise, check if If true, then execute transactions again using the If false, continue to the next stage.
Checking the usage of and opcodes
Transactions with these two opcodes get executed with the
Otherwise, they are executed with the
Since the sequencer is obliged to execute all transactions in the transaction pool manager, each transaction is executed during a particular stage of the flow described above.
The entire sequencer flow is summarized in the figure below.

Example (Sequencer flow)
Let’s continue the numerical example we have been using throughout this document.
As seen in previous examples, the figure below displays L1 gas prices above the timeline, while the associated suggested L2 gas prices are shown below the timeline.
At the time of sequencing the transaction, the suggested gas price is given by,

Suppose the user signed a gas price of
Recall how we previously obtained the of
According to the figure above, the network recommends a gas price of 3, which corresponds to an L1 gas price of 20.
This results in the following priority factor:
and an estimated effective gas price:
This amounts to a increment to the gas price for transaction prioritization.
Since the signed gas price is bigger than the estimated effective gas price, the transaction can be executed with the
The sequencer can use the current and correct state, together with the computed , in order to obtain a more accurate measure of the gas used, call it . Suppose that, in this case, we obtain
which is bigger than the RPC-estimated gas of
With the new an adjusted effective gas price can be computed by the following steps. Firstly, the total transaction cost:
where a breakeven factor is applied. Thirdly, the new effective gas price:
Observe that the transaction cost is much higher than the RPC-estimation of , even when the L1 gas price has decreased from 21 to 20 due to a huge increase in gas.
Observe that there is a significant deviation between both effective gas prices:
Executing the transaction with the signed gas price, while the deviation is this big, amounts to penalizing the user unfairly.
Thus, since the new EGP is smaller than the signed gas price:
instead of charging the signed gas price, a further attempt to adjust the gas price is made by charging the to the user.
In the case where the transaction has none of the two opcodes, and , in the source address opcodes, the transaction gets executed with the NEGP:
Observe that should be the same as . Finally, the and are computed as follows:
Observe that the user has been charged of the gas price they signed at the time of sending the transaction.
Last updated