TLDR
- The semantics of status
PENDING
is changed -
PENDING
status is broken intoPENDING
andACCEPTED_ON_L2
- State changes for transactions in the new
PENDING
state are reflected in the API by adding the argumentblockNumber=pending
tocall
, support in the CLI will be added soon. - Pending transactions don’t have block hashes
- Added ability to query the current block under construction with
blockNumber=pending
You may have noticed that we recently made a small change to the life cycle of a transaction. So far, the transaction status cycle was RECEIVED
, PENDING
, and ACCEPTED_ONCHAIN
. As the names suggest, RECEIVED
implied a transaction was received internal and ACCEPTED_ONCHAIN
implied that a proof for a block containing this transaction was accepted on L1. PENDING
indicated that the sequencer closed the next block to be proved.
Following a recent upgrade to the sequencer’s behavior, a transaction now becomes PENDING
before the next block is closed (while the block it’s expected to be included in is still under construction). A new status was added to better capture this flow, a transaction lifecycle now follows the path: RECEIVED
, PENDING
, ACCEPTED_ON_L2
, and ACCEPTED_ON_L1
.
Note that the semantics of PENDING
is now different: a transaction becomes PENDING
once the sequencer decides to include it in the next block, but is still updating said block. Consequently, pending transactions will not have a block hash. The new status, ACCEPTED_ON_L2
(analogous to the previous semantics of pending) indicates that the block was closed.
To query the block under construction and see the transactions it currently includes, simply use the get_block API with blockNumber=pending
. To see the effects of pending transactions on the state, use the call API with blockNumber=pending
(by default call
will not reflect changes caused by pending transactions). Note that this is still not supported in the CLI, but only by calling the API directly.