- The semantics of status
PENDINGstatus is broken into
- State changes for transactions in the new
PENDINGstate are reflected in the API by adding the argument
call, 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
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
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:
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.