Metisnetwork sequencers order Andromeda transactions while rotation and consensus establish L2 finality

Normal Block Production and Sequencer Reselection

Andromeda's transaction path runs through the active sequencer during normal operation; a missed ordering window moves recovery into the proof-of-stake (PoS) layer, which selects a replacement producer.

Signed Transactions and Peer Verification

Signed L2 transactions first enter the remote procedure call (RPC) network. The Bridge & Adapter coordinates with the PoS layer to reach the current sequencer's transaction pool. That sequencer forms a block and broadcasts it across the peer-to-peer network. Other sequencers verify its signature before saving the received block.

Reselection After a Sequencer Fault

A sequencer missing its ordering window or initiating transactions with duplicate L2 TxIDs can trigger reselection. The PoS layer chooses a replacement, and multi-party computation (MPC) signing supports the update to the L2 sequencer list. Rotation handling can hold an ordinary transaction while the node applies the current sequencer-set update. Processing then follows the refreshed state.

When Does an Andromeda Block Reach L2 Finality?

Andromeda's sequencer pool considers an L2 block number finalized after rotation and consensus from two-thirds of the sequencers. The denominator is the sequencer pool. Inclusion places a transaction in a block, while L2 finality concerns agreement on the chain's finalized block number. A newer visible block can therefore represent a different confirmation stage from a finalized height.

Staking Weights and Rotation Records

Sequencer selection uses voting power derived from locked METIS, so an operator's probability depends on its share of total voting power. Andromeda's weighted selection process chooses producers for a span using those relative weights. Equal membership therefore does not imply equal selection probability. The PoS layer bases rotation on staking information from Ethereum, while the L2 MetisSequencerSet contract records the list nodes follow. This links L1 staking information to authority to produce L2 blocks. Pool membership and selection as the current producer concern different parts of that relationship.

Batch Signing and Ethereum Commitments

Ethereum anchoring requires signed batch records, so the batcher prepares batches for MPC signing before the network submits the associated L2 state commitments to Layer 1. The batcher, consensus layer and verifier perform different jobs.

Batch Data and State Roots

The batcher prepares transaction batch data and state root batch data. Transaction records describe operations in the L2 blocks; a state root commits to the resulting blockchain state. The CanonicalTransactionChain maintains ordered transaction records, while state-commitment structures record commitments to the L2 chain.

Coordinated MPC Signing

MPC allows sequencer participants to coordinate a batch signature. The PoS layer checks the sequencer's batch transaction signature and initiates MPC signing. After signing, the batch can proceed to Ethereum. This signature concerns the batch submission, with its own participating nodes and key management. A user's signature authorizes the individual transaction earlier in the processing path.

The State Commitment Chain

The State Commitment Chain (SCC) on Ethereum records cryptographic commitments to Andromeda's L2 state. A verifier synchronized with Ethereum checks batch integrity and the alignment of finalized block numbers across layers. Andromeda's processing model places batch submissions approximately every 30 minutes when L2 blocks reach finality. That cadence cannot specify when a newly submitted transaction will meet an application's completion requirement.

Receipts, Execution Status and Finalized Heights

An Andromeda transaction receipt describes an included transaction's execution and containing block, while the finalized height concerns the network's consensus over blocks. Standard EVM receipt status values distinguish success from failure: 0x1 denotes success and 0x0 denotes failure. The receipt's block number identifies the height whose finality matters. Successful execution can answer a contract-level question before later confirmation checkpoints matter to the application. A finalized failed transaction still records failed execution; finality does not convert it into a successful operation.

A missing receipt means the queried node returned no receipt for that hash; it does not identify the cause. The transaction may still be pending. Finalized-height information must concern the same chain and block history as the receipt. Ethereum anchoring additionally concerns the matching batch commitment. An unrelated successful Ethereum transaction provides no confirmation for the Andromeda block.

Andromeda and Hyperion Sequencer Scope

Andromeda's sequencer pool finality conditions apply to Andromeda, while Hyperion has a separate networking and consensus design. Hyperion's design includes leader rotation, timeout failover and BLS multisignatures for quorum certificates. Its parallel execution framework concerns how transactions access shared state during computation. Those execution dependencies differ from choosing the sequencer responsible for transaction ordering. A quorum certificate belongs to Hyperion's consensus design; Andromeda's MPC-signed Ethereum batches follow Andromeda's processing model. The Andromeda rotation threshold does not supply a universal Hyperion finality rule.

---

Checks for a Delayed Andromeda Transaction

A successful receipt with a block awaiting finality calls for monitoring that block's consensus status. A missing receipt leaves execution unresolved. If the active producer has missed its ordering window, protocol reselection must update the sequencer role before regular processing continues. That fault concerns the producer, so repeating the wallet action does not complete the network repair.

Open full-size image

• If a receipt exists, use its execution status and containing block as the starting record.
• If the receipt is missing, keep execution unresolved instead of classifying the transaction as successful or failed.
• If network records identify a sequencer fault, distinguish producer reselection from retrying the user's contract call.
• If the application needs L2 finality, compare the containing block with the finalized Andromeda block record.
• If Ethereum anchoring matters, require the corresponding batch's state commitment on Ethereum.

Before any client retry, establish the original transaction's execution state; producer reselection alone cannot answer that question.

Sequencer Decentralization and Security Dependencies

Andromeda distributes responsibility for block production through its pool and rotation process, while Ethereum contracts and verifiers address additional parts of L2 security. A peer signature check establishes the validity of the sequencer's transaction signature. A state root commits to the resulting L2 state. Neither a signature check nor a state commitment alone establishes that the state transitions are valid. Sequencer availability, transaction ordering and state validity remain related concerns with different enforcement mechanisms.

Sequencer decentralization and fraud-proof deployment are separate engineering decisions. The 2026 roadmap lists proof-system upgrades and migration to Ethereum blob data availability as separate Andromeda milestones. A change in pool membership or the active sequencer cannot establish the deployment status of those mechanisms.

Receipt status supports earlier execution feedback; L2 finality adds sequencer consensus, while Ethereum anchoring adds the batch record on Layer 1.