A Hybrid decentralized ZK Sequencer


High-performance decentralized applications (dApps), such as games, often require a mixture of high-security/low interactivity with low-security/high interactivity.

For instance, during a game round, players may frequently interact with others (low-security, high-interactivity), leading to the minting of an NFT as a result (high security/low interactivity).

Posting all user low security low value game actions to the ZK rollup may slow down the game and affect is interactivity.

We propose a hybrid decentralized ZK sequencer,
which is a modular distributed ledger incorporating two chain IDs

  • a Layer 2 ZK EVM chain rolled into ETH Main net
  • a lower-security, high-speed fast chain (e.g., a Layer 3 chain).

The ledger will feature intermingled blocks from both chains while maintaining a global order of events.

Users will typically store their assets on the ZK chain but engage in complex interactions on the fast chain. With both chains running on the same ledger, quick transfers between chains are possible.

In case the fast chain is compromised, all users will lose is the value of assets currently transferred to the fast chains. In many cases this value can be close to zero, since the fast chain may need only proofs of ownership of the assets, instead of actual assets

Example: a game

  • A user possesses an NFT that grants authentication access to the game.
  • The NFT is stored on the ZK chain.
  • The user will generate an ownership proof for the NFT and submit it to the fast chain, where all game interactions take place.
  • After the game concludes, the user will send a game report to the ZK chain. This can result in minting of a new NFT based on this report. The new NFT can then be traded on a DeFi market hosted on the ZK chain.

Note in the example above, if the fast chain is compromised maximum what the user will use is the gain made in the current round. The ZK chain can effectively limit damage done if the fast chain is compromised in a single game round by assigning a limit on NFTs minted in a particular game round.

By separating assets and high-activity tasks, users can benefit from high interactivity for low-security transactions while ensuring the security of assets and high-security tasks.

Crowdsourced decentralized ZK Rollups



Computational requirements for ZK provers can lead to centralization of ZK rollups, and make them
vulnerable to censorship, in particular, from the government.

This can be avoided by asking users to do ZK proofs on transactions they submit.
Unfortunately when a user submits a transaction, transaction ordering and state roots are not yet known. This can be addressed by asking the users to do proofs on previously ordered transactions, and paying them in ZKPOW token, which can later used to submit transactions to the chain.


A decentralized crowdsourced ZK rollup can consists of the following components:

  • a decentralized sequencer, which is itself a PoS EVM chain, which has an additional feature of the ZKPoW token described below

  • submission agents that post ordered transactions from the sequencer to the ETH main net. Each node in the sequencer chain can also be a submission agent. Each submission agent can be allocated a time slot to post to the mainnet.

  • user browser plugins performing ZK proofs

The transaction processing then works as follows:

  • A user submits a transaction to the sequencer, paying gas fees in ZKPoW token

  • The transaction is ordered, committed to the chain and processed by the EVM in the usual way. At this point the ZK proof does not yet exist, but before/after state roots are already known

  • The unproven committed transaction is then assigned psueudorandomly to one of active browser plugins for processing. The plugin will perform the computation and submit the proof back to the sequencer chain, so that it can get included on chain.

  • For every successful computation, the user plugin is paid in ZKPOW.

  • If the proof is not submitted within the required period of time, the user is penalized a fixed amount of ZKPoW. This can include going negative on user ZKPoW balance. Another plugin is then assigned to the computation.

  • user plugins can mark themselves active/inactive by issuing heart beat transactions on the sequencer chain. Only active plugins are assigned work and penalized. The ZKPoW bounty can increase if the number of active plugins drops.

  • In order to prevent the sequencer from getting stuck, the bounty paid for a given transaction will increase with time the transaction stays unproven.

  • When there are enough contiguous proven transactions to form the next sequencer block, the proofs are aggregated in a similarly crowdsourced fashion

  • when a fully proven block is formed on the sequencer, it is submitted to Eth mainnet by a submission agent