As a zkEVM Layer 2 blockchain, the Modulus Network consists of 4 main components.

Consensus Contract

Modulus uses the Polygon zkEVM technology as a foundation. The first implementation of this technology was Polygon Hermez 1.0, which was based on the Proof of Donation (PoD) consensus mechanism.

The next iteration was to add support of permissionless participation of multiple coordinators to produce batches in L2.

The current, and latest version of the zkEVM Consensus Contract uses Proof of Efficiency (PoE). Proof of Efficiency works so that the batches proposed by the Sequencers in L1 are sorted by their appearing position in the L1, and contain the transaction data. The PoE smart contract will accept as valid the first validity proof that updates to a new valid state including one or more of the proposed batches.


zkNode is the software needed to run any zkEVM node. It is a client that the network requires to implement the Synchronization and govern the roles of the participants (Sequencers or Aggregators). You can either run a Node passively, so you can read the state of the network at any time, or through participation as a Sequencer or Aggregator.

Incentivisation Model

The two permissionless participants of the zkEVM network are: Sequencers and Aggregators. Proper incentive structures have been devised to keep the zkEVM network fast and secure. Below is a summary of the fee structure for Sequencers and Aggregators:

  • Sequencer

    • Collect transactions and publish them in a batch

    • Receive fees from the published transactions

    • Pay L1 transaction fees + CULT

    • CULT goes to Aggregators

    • Profitable if: txs fees > L1 call + CULT fee

  • Aggregator

    • Process transactions published by Sequencers

    • Build zkProof

    • Receive CULT from Sequencer

    • Static Cost: L1 call cost + Server cost (to build a proof)

    • Profitable if: CULT fee > L1 call + Server cost


zkEVM employs advanced zero-knowledge technology to create validity proofs. It uses a zero-knowledge prover (zkProver), which is intended to run on any server and is being engineered to be compatible with most consumer hardware. Every Aggregator will use this zkProver to validate batches and provide Validity Proofs.

It consists of a Main State Machine Executor, a collection of secondary State Machines (each with its own executor), a STARK-proof builder, and a SNARK-proof builder.

In a nutshell, the zkEVM expresses state changes in a polynomial form. As a result, the constraints that each proposed batch must meet are polynomial constraints or polynomial identities. To put it another way, all valid batches must satisfy specific polynomial constraints.


The Bridge contract is the link between Layer 1 and Layer 2, and it is deployed on both networks, with an identical contract. It provides a permissionless method for users to move their assets between L1 Mainnet and Modulus. You can read more about the Bridge in our guide on the previous pages.

Last updated