PoS Sequencer Pool: Decentralizing an Optimistic Rollup


Centralized Sequencers in Layer 2 (L2) networks present a potential single-point-of-failure. Metis, operating as an optimistic rollup L2 network, is proposing a transition to a decentralized sequencer pool. This discussion delves into the technical nuances of this proposition, its implications for L2 networks, and the broader shift towards community governance.


The move to a decentralized sequencer pool is another step towards complete decentralization of the network.
This approach ensures:

  • Expulsion of malfunctioning or malicious entities.
  • Seamless and safe sequencer rotation.
  • Enhanced network stability.

Moreover, the overarching goal is to transition the ownership of the network to the public. This ensures that even if the original developers or operators cease operations, the Metis network remains operational, preserving the integrity and continuity of services for its users.

Abstracted structure:

Abstracted entities:

  1. User: sends transactions;
  2. Admin: manages the locking nodes;
  • Whitelists potential sequencers.
  • Sets an upper bound on the stake that a single node can hold.
  • Controls reward emissions based on block production.
  1. Metis Node (Sequencer) consists of:

  • L2 Geth (including the OP-Node) - Responsible for transaction sequencing and the assembly of the blocks on Metis layer;
  • Adapter module - Responsible for interacting with the other external modules on the consensus layer (POS Node);
  • Batch submitter (Proposer) - Responsible for building the batches and submitting them to L1 after it gets signed by multiple sequencers;
  1. POS Node — works on 3 layers:

  • Ethereum layer:
    • A set of smart contracts on the Ethereum network responsible for locking and rewards for validators;
  • Consensus (PoS) layer:
    • A set of PoS Nodes based on Tendermint, these nodes run in parallel on the Ethereum mainnet
    • When started, it detects the MPC addresses and calls the MPC module (see below) to trigger the keys generation if they do not exist;
    • When the sequencer submits L2BatchTxs to L1, the signature needs to be generated by multiple existing sequencers (more than 2/3 of the Sequencer nodes participate in MPC signing);
    • When the new sequencer node joins or exits, it performs the MPC resharing of private key shards without updating the verification address in the locking contract (the verification address can also be generated if needed);
    • Provides a variety of data query interfaces for Metis layer;
  • Metis layer:
    • On this layer, for every new epoch another entity called Block Producer is getting selected and/or rotated according to the information generated by the consensus layer;

4.1 MPC module:

  • It is responsible for the management of the entire life-cycle of the multisignature keys.
  • Conducts external operations such as
    • Multisig generation;
    • Key resharing;
    • Applying the signature;
    • Deletion of signature.
  • Provides support for the asynchronous usage of many multisignatures;

4.2 TSS Library - Threshold Signature Scheme Library - open-source multisig tool library and the main source of MPC logic:

  • Responsible for the multisig key algorithm layer;

4.3 Key Local Storage:

  • Conducts the saving and encrypting the key’s info in the local kv storage (levelDB) provided by the corresponding node;

4.4 Tendermint channel - open source p2p communication and consensus library provided by cosmos-sdk:

  • PoS Node creates a separate Tendermint channel for communication messages between multiple p2p nodes during MPC operations;

4.5 libp2p

  • libp2p Is an open-source p2p network communication library
  • MPC Will use libp2p inCommunication messages between multiple different p2p nodes, supporting information transmission during MPC operation
  1. Bridge module: The connection between Consensus layer (POS) and Sequencer (Metis node). It has 2 functions:
  • Listener: It monitors the L1 Staking contract events and obtains the info about Sequencer node list (join/exit/update), also it listens to Metis block’s events to determine whether to send tasks;
  • Processor: It sends the transactions to TSS/Themis for consensus. Scans epoch and Metis block information. Asks Themis to resend the proposal for the epoch if the block is wrong. Scans the MPC service interface and sends the transaction batches to the consensus layer for MPC signing.


  • Staking Mechanism: Nodes will be allowed to stake an amount of Metis. The upper bound of this stake will be initially controlled by the Admin, but will be subject to change later based on governance decisions.
  • Reward Emissions: While initially will be controlled by the Admin, the plan is to transition this to a more decentralized mechanism, potentially influenced by community governance.
  • Transition to Community Governance: As the network matures and more sequencers join, the aim is to transfer the Admin’s responsibilities to a community governance model. This would ensure that key decisions, like whitelisting sequencers or adjusting staking bounds, are made collectively by the network’s participants.


Discussion Points:

  • Impact on the performance and security metrics of traditional centralized sequencers
  • potential challenges or flaws introduced by transitioning to a decentralized sequencer pool
  • The need for decentralized sequencers, and impact on the broader landscape of L2 Rollups

The role of the Consensus layer seems to be insignificant. Why do more than two-thirds of sequencers sign L2BatchTxs? What are they verifying?

1 Like

The Sequencers need to agree on the order for block production. In order to do this, the majority of Sequencers need to agree that the Sequencer that is submitting the batch is assigned to submit the batch in that specific slot.

1 Like

Consensus layer:

  • Elect a sequencer for each epoch.
  • What should be verified before signing each L2BatchTxs? For example, should the current sequencer be verified for legitimacy? Should the order and validity of transactions be verified?

The sequencer pool ensures that the members are legitimate and meets the requirements for entering the pool (e.g. stake amount). Before any transaction is sent, the current sequencer needs to be assigned to the specific range of blocks that they can submit. >2/3 of the sequencers in this pool need to agree before the batch is accepted and sent.

The validity of transactions are determined by the sequencers signing via MPC before pushing to L1, this verifies the transactions that are included in the batch.

The order of the transactions are determined by the Block Proposer. This is rotated based on the Consensus (POS) layer. This process reduces the centralization risk for MEV.

1 Like

Great read!

We have also been working on decentralizing rollups using a blockchain please a take a look at


You said here
Staking Mechanism: Nodes will be allowed to stake an amount of Metis. The upper bound of this stake will be initially controlled by the Admin, but will be subject to change later.

My question, is there a specific amount of Metis that can be allowed for staking?
How do you mean by the upper bound will be controlled by the Admin?

1 Like

What is the role of the MPC module in generating key signatures for the L2BatchTxs submitted to L1 in the Ethereum network?

1 Like

Decentralising the sequencer is a really bold move towards absolute decentralization for a layer2, and I support it.

Metis about to become a headline layer2.

However, with the introduction of different operators, what are the penalties for faulting?

This is indeed a bold step towards enhancing platform decentralization and security. However, I’m also concerned about its potential impact on the cost-effectiveness that users currently enjoy.

My question is: To what extent should users anticipate the impact of this latest improvement?

There’s a minimum stake (lower bound) that a sequencer node needs to lock on L1 and there’s a maximum amount (upper bound) that a node can lock.

And both of these amounts will be initially decided by the admin of the sequencer pool contract, but to be later transferred to community governance.

The reason why the MPC module exists when submitting batches is to ensure order and correctness of the batched transactions by ensuring more than 2/3rds of Sequencers agree before the transactions are committed.

This move is essential and comes with a lot of benefits to Metisans. Corcerning the transfer of Admin’s responsibilities to a community governance model, how long will it take to effect this change or a range of sequencers to attain.

The Sequencer that faults will have their stake slashed.

1 Like

There are no additional overhead that users will experience.

I am not sure why you need an MPC module.

If the batches are part of the blockchain, it automatically means 2/3 of nodes agree, provided the block is finalized.

The PoS determines the order of nodes for block production.

The MPC Module manages the keys that enable the Sequencers to commit the transaction batches that were produced by the Block Producers.

The combination of both ensures proper Block Producer rotation with transaction finality.

Great article! I’m curious about the intricacies of multisignature key management in the transition to a decentralized sequencer pool. Could you share more details on how the life cycle of multisignature keys is managed and the specific role the MPC module plays in this process? Thanks!

Here are some specific questions I have about the decentralized sequencer pool:

1 How will the sequencers be coordinated?
2 What security measures will be in place to protect the pool from compromise?
3 How will the performance of the decentralized sequencer pool be monitored?
4 What are the plans for transitioning the governance of the decentralized sequencer pool to the community?

looks interesting and a little complex. :+1: :+1: :+1: