The rumors are true: Metis is leading innovation among all L2s.


  • The Electric Lightbulb: “a conspicuous failure”, “good enough for our transatlantic friends … but unworthy of the attention of practical or scientific men.” (British Parliament)
  • Alternating current —“fooling around with alternating current is just a waste of time. Nobody will use it, ever.” (George Westinghouse)
  • The telephone — “obvious limitations of his device, which is hardly more than a toy.” (Western Union Company)
  • Automobiles: “The prices will never be sufficiently low”, “the horse is here to stay but the automobile is only a novelty — a fad,” (president of the Michigan Savings Bank)
  • Smart L2s: “Metis is not a real L2” (?)

ELI5: So, what is a Smart L2 after all?

  1. Collect or, roll up a batch of transactions
  2. Post Transaction data to Memolabs with its Merkle Tree Roots (think of MTRs as identifier tags) and post the Tx Batch MTR and the state roots on Mainnet
  3. Whenever needed (fraud proof posted / data needing to be verified on L1): the rest of the data gets brought back on-chain via the indentifier tag and everything is resolved in Layer 1.

How are Smart L2s different from other solutions?

  • Optimistic Rollup: assumes transactions are valid by default and only runs computation, via a fraud proof, in the event of a challenge.
  • Zero-Knowledge Rollup: runs computation off-chain and submits a validity proof to the chain.

So, based on the definitions found on, we can conclude that:

  1. Metis is not a sidechain, because Metis doesn’t have its own consensus protocol.
  2. Metis is not a Plasma nor Validium, because neither Plasma or Validium support general computation, and Metis is EVM-Equivalent (the complete opposite).
  3. Metis is not a zk-Rollup, as it doesn’t use validity proofs.
  4. Metis is very similar to Optimistic Rollups, but with enhanced efficiency.

Deep Dive and Comparison: Optimistic Rollups vs Smart L2s

How an Optimistic Rollup Works


  • Individual transactions go to the Sequencer.
  • The Sequencer posts the transaction data to Ethereum to the Canonical Transaction Chain (CTC). The Sequencer also executes the transaction data and posts the resulting state in the State Commitment Chain (SCC) as a state root.
  • The Verifier then downloads the data from the CTC on Layer 1 and executes the transaction batch locally.
  • If the transaction execution results in the same state as the sequencer has submitted on the SCC, then nothing else happens.
  • If the transaction execution results in a mismatch, the Verifier posts a Fraud Proof to Layer 1, which is executed by Ethereum. The Sequencer is then slashed and the Verifier who has submitted the fraud proof is rewarded with a portion of the slashed fee.


  • Posting transaction data on L1 — Canotical Transaction Chain
  • Posting state root on L1 — State Commitment Chain
  • Posting Fraud Proofs on L1

How Metis’ Smart L2 Works

  • Individual transactions go to the Block Producer. The Block Producer will take the transaction and propagate it to the Peer Network. The peers are there to guarantee that the transaction is valid, if it is not, it will get rejected. The Sequencer is part of the Peer Network and downloads the data from there (peer network). This mechanism is described as Temporary Finality.
  • The Sequencer then posts the transaction data to Memolabs storage with the identifier from the merkle tree root (MTR) of the transaction bundle and submits the MTR of the transaction bundle to Layer 1. The Sequencer also posts the resulting state in the State Commitment Chain (SCC) as a state root.
  • The Validator retrieves the transaction data from the Peer Network. They are also able to retrieve the data from the Memolabs storage.
  • If the MTR of the transaction bundle matches the locally-calculated MTR from the downloaded transaction bundle, then the local results are compared with the MTR submitted by the Sequencer. If both the MTR for the transaction data and the state root equal the local copy that the verifier has, then nothing happens.
  • If either the MTR of the transactions or the state root does not match, the data is attempted to be retrieved by the Sequencer.
  • Because there is no transaction data on Layer 1, the Sequencer that has posted the MTR of the transaction data has the responsibility to post the data. A request is made by the Validator to the Sequencer to post the data to Layer 1. This request is combined with an amount of ETH required to post the batch. This amount must be paid by the Validator. The Sequencer has 24 hours to post the transaction data on-chain. The Sequencer will post all of the transaction data on Layer 1 and Ethereum will verify the validity of the data with a Fraud Proof posted by the Validator.
  • If the Sequencer does not submit the data after the 24 hour period, the Sequencer is slashed and the Validator who has paid the ETH will be reimbursed. A new Sequencer is randomly chosen and the new Sequencer posts the MTR of the transaction bundle and the resulting state. The data is retrieved from the Peer Network or Memolabs.


  • Posting merkle tree root of the transaction
  • Propagating transactions
  • Maintaining ordering
  • Sharing transaction data information
  • Peers verify the data that the Block Producer submits
  • Permanent storage of transaction data
  • Makes requests to the sequencer to post the data