Network Roles

Understanding the network protocol through its active participants

Defining Network Roles

There are currently four roles for nodes on Mantle network, namely Sequencers, Multi Party Computation (MPC) nodes, Rollup Verifiers, and Data Availability (DA) nodes. Here's a simple description of their responsibilities.


  • Receive and record transactions sent by users in real time
  • Produce blocks on L2
  • Rollup transactions to generate batches with execution state roots
  • Get blocks validated by the MPC network
  • Broadcast block data across the network (L1 and L2)
In the initial phases of release, Mantle core team will operate its own centralized Sequencer. However, as part of our roadmap we will be decentralizing the Sequencer eventually, creating another opportunity for nodes to contribute to Mantle.

Multi-Party Computation (MPC) Nodes

  • "Sign off" transaction batches produced by Sequencers to be sent to L1
  • Broadcast batches across the L2 network after verification using Multi-Party Computation
MPC nodes verify the state roots generated by Sequencers to determine their correctness. The state roots MUST be signed by an MPC node before they are sent to Ethereum to be recorded.
During the initial phases of release, MPC nodes are run by a group of reputable institutions, but will eventually be voted in via BitDAO governance permissionlessly.

Rollup Verifiers

  • Sync rollup data from Mantle's trusted sequencer
  • Verify the state roots submitted by Sequencers on L2
  • Initiate fraud proofs when invalid state data is found
  • Serve rollup data to users

DA Nodes

  • Opt into taking the responsibility of storing a copy of Mantle transaction data to have it ready for access whenever necessary
  • Make a commitment by signing the block data they provide using the BLS signature scheme guaranteeing its usability. These signatures are verified by an EigenDA contract on Ethereum
DA nodes will be incentivized with $BIT in the form of gas fees collected by the execution layer. Learn more about this works in the Solving Data Availability section.
The EigenDA protocol consists of a set of supported interactions between four major components as described below.


The service providers of EigenDA and need to confirm their commitment through digital signatures, which place staked assets as a collateral guarantee on their participation. An Operator carries out the following tasks:
  • Run nodes which store chunks of data for a pre-defined time period and serve these chunks upon request
  • Earn a pro rata (relative to their stake) share of the fees collected by EigenDA


They're the users of EigenDA’s data availability service, paying for its economic guarantees of data availability. This role may be played by a rollup Sequencer. A Disperser performs the following tasks:
  • Encodes its data into chunks, posts funds for making the data available for a fixed amount of time, and distributes the encoded chunks to EigenDA operators
  • Aggregates signatures from the operators and posts an attestation to the blockchain, confirming availability of the data of interest for the specified time period


They're interested parties who play an important role in the Proof of Custody protocol. Challengers perform the following tasks:
  • Monitor certain verifiable operations of the protocol (which in the optimistic case are not verified or resolved on-chain)
  • Permissionlessly force problematic operations to be resolved on-chain, resulting in an operator’s stake being slashed

EigenDA Smart Contracts

The EigenDA collection of smart contracts running on Ethereum take care of the following:
  • Ensure that data is only accepted as available when a group of operators having a sufficient amount of stake has collectively signed
  • Implement the proof-of-custody protocol and provide mechanisms for a challenger to disclose data on chain
  • Verify the validity of data submitted by Challengers against a signed commitment, and enact slashing as dictated by the proof-of-custody protocol

Node Interactions

The conditions for a secure network require that at least one honest Rollup Verifier can validate the integrity of the rollup chain and serve blockchain data to users. The following diagram depicts the expected interaction between Sequencers and (Rollup) Verifiers:

Running a Node

Mantle uses the same codebase to run both Sequencer and Rollup Verifier nodes. A configuration file is used to determine which mode of operation a node is in.
To run your node in the Rollup Verifier mode, add the flag --rollup.verifier to your config.
You can visit Deploying a Rollup Verifier for more information on modifying the config file.

Why Run a Rollup Verifier Node?

There are multiple advantages of running a Rollup Verifier node.
  1. 1.
    It grants many of the benefits of running an Ethereum node, such as the ability to simulate L2 transactions locally without rate-limiting (public RPCs may face such limitations).
  2. 2.
    Allows anyone to verify the work performed by Sequencers by re-deriving output roots and comparing them against those submitted by the Sequencer. In case of a mismatch, verifiers can perform a fault check and claim rewards by submitting fraud proofs.
dApp builders are encouraged to consider the value addition of running a Rollup Verifier node given that the overhead costs tend to be low.
The diagram below illustrates how the Sequencer and Rollup Verifier fit together. Note that actions in red are performed by a Sequencer, while actions in blue are performed by a Rollup Verifier: