Transaction Statuses

Transactions on Zircuit pass through several stages before they are fully recorded on the blockchain, which are described on this page.

Transaction Statuses

The underlying layer one for Zircuit referenced on this page is Sepolia for Zircuit testnet.

Pending

When a transaction is sent to the sequencer, it first appears as pending. At this stage, the transaction has been accepted by the sequencer but has not yet been added to a block. This initial status means the transaction is awaiting inclusion in a batch of transactions that will eventually be submitted to the layer one. During this time, the transaction is not yet part of the blockchain, and there is no guarantee that it will be included in the final blockchain.

Pending transactions are held in a mempool (memory pool), where they await sequencing. The sequencer processes these transactions, prioritising them based on factors such as gas fees and the order of arrival. The transaction will remain in this state until the sequencer includes it in a block.

To view all pending transactions, use the JSON-RPC method eth_getBlockByNumber with the param set to pending. Monitoring the pending state can help in diagnosing issues like transaction congestion or delays. It also allows users to cancel or replace transactions if they need to adjust gas fees to expedite processing.

Quarantined

Zircuit protects users at the sequencer level by monitoring the mempool for malicious transactions and preventing their inclusion into a block. This novel approach means that our sequencer scrutinises transactions for potential malicious intent before they are finalized on layer two. This functionality is described on the Sequencer Level Security page.

Zircuit monitors the mempool for new transactions and if it finds out that a transaction is considered risky, it is quarantined. This means it will be blocked from being including in layer two blocks. This transaction's status will be quarantined .

The quarantined transaction can either be released or retired depending on the matching criteria. Zircuit continuously monitors for release criteria which may result in the transaction's inclusion in layer two blocks. Release criteria are also described on the Sequencer Level Security page.

To check, whether a transaction's status is quarantined, we have introduced an additional RPC call to the Geth client. zirc_isQuarantined takes a transaction hash as a parameter and outputs the quarantine status of the transaction. The RPC call can be done through any tool of choice, such as Foundry's cast:

cast rpc zirc_isQuarantined 
--rpc-url https://zircuit1-mainnet.p2pify.com/
 0x9b629147b75dc0b275d478fa34d97c5d4a26926457540b15a5ce871df36c23fd 

{
  "IsQuarantined": true,
  "Quarantine": {
    "TransactionHash": "0x9b629147b75dc0b275d478fa34d97c5d4a26926457540b15a5ce871df36c23fd",
    "QuarantinedAt": "2024-07-24T13:15:22.644132Z",
    "ExpiresOn": "2024-07-25T13:15:22.644131Z",
    "ReleasedReason": "",
    "QuarantinedBy": "Oracle",
    "QuarantinedReason": "transaction simulation returned a risk",
    "ReleasedBy": ""
  }
}

Key points about "Quarantined" status:

1. You can view the list of quarantined transactions on the explorer page.

2. The quarantined transaction can be automatically released or retried. Zircuit uses AI enabled features to quarantine a transaction and in some cases a genuine transaction can be quarantined as well. If you need help with releasing your transaction, please contact to us via discord.

Sequencer Confirmed / Unsafe

A transaction becomes "sequencer confirmed" or "unsafe" when the sequencer adds it to a block, but that block has not yet been published to layer one. This status means the transaction is included in a provisional block that resides on the layer two chain, but it hasn't been fully secured by being anchored to the underlying layer one. During this period, the transaction is more likely to be included in the blockchain, but it is not yet certain.

At this stage, the block containing the transaction is stored locally by the sequencer and is accessible to users and applications interacting with the Zircuit. However, the block's contents can still be altered or discarded if the sequencer encounters issues or fails to publish the block within the defined sequencing window.

To view the latest "sequencer confirmed" block, use the JSON-RPC method eth_getBlockByNumber with the parameter safe and compare this to the latest block number. If the safe block is not the most recent block, the next immediate block after the safe block is considered the earliest "sequencer confirmed" block.

Key points about the "sequencer confirmed" / "unsafe" status:

1. The transaction is provisionally included in the layer two blockchain but has not yet been anchored to the underlying layer one. This means the transaction could be reversed if not published in time.

2. Applications should inform users about the provisional nature of this status to manage expectations about the transaction's finality.

3. There is a small window during which the transaction could be excluded if the block fails to be published to the underlying layer one within the required time frame.

Published to Ethereum / Safe

A transaction is deemed "safe" once it is included in a block by the sequencer and that block has been published to the underlying layer one, but not yet finalized. At this stage, the block containing the transaction has been posted to the underlying layer one, significantly increasing the likelihood that the transaction will be part of the final blockchain. However, there is still a slight chance that it could be excluded if the layer one blockchain undergoes a reorganisation.

Key points about the "Published to Ethereum / Safe" status:

1. Although not yet finalized, the transaction is now highly likely to be included in the final blockchain, providing a higher degree of certainty.

2. Users and applications can interact with the transaction data with increased confidence, knowing it has been anchored to the underlying layer one.

3. Users can track the status of their transactions using various block explorers or by calling the JSON-RPC method eth_getBlockByNumber with safe as the block number to see the latest "safe" block.

Finalized

A transaction reaches the finalized status when it has been included in a block by the sequencer, that block has been published to the underlying layer one, and the block has been finalized. Finalisation provides the highest level of certainty that the transaction is immutably part of the Zircuit blockchain. This status guarantees that the transaction cannot be reversed or altered, providing complete assurance of its inclusion in the blockchain.

Key points about the "Finalized" status:

1. Finalized transactions are permanently recorded in the blockchain and cannot be altered or removed, offering the highest level of security and certainty.

2. Applications and users requiring the utmost certainty for high-value or critical transactions should wait for this status before considering the transaction complete.

3. Users can verify the finalization of a transaction using various block explorers or by calling the JSON-RPC method eth_getBlockByNumber with finalized as the block number to see the latest "finalized" block.