{
"capability": "universal",
"daLayer": [
"Ethereum"
],
"hostChain": {
"id": "ethereum",
"slug": "ethereum",
"name": "Ethereum"
},
"layer": "layer2",
"proofSystem": {
"type": "Optimistic",
"name": "OPFP",
"challengeProtocol": "Interactive"
},
"purposes": [
"Universal"
],
"reasonsForBeingOther": [
{
"label": "Closed proofs",
"shortDescription": "There are less than 5 external actors that can submit challenges",
"description": "Projects without a sufficiently decentralized set of challengers rely on few entities to safely update the state. A small set of challengers can collude with the proposer to finalize an invalid state, which can cause loss of funds."
"description": "Projects without a sufficiently decentralized set of challengers rely on few entities to safely update the state. A small set of challengers can collude with the proposer to finalize an invalid state, which can cause loss of funds.",
"explanation": "The current proof system is forked from the standard permissionless OP stack proof system. Importantly, new state root proposals do not create new dispute games and although challenge requests can be made by any bonded user, creating dispute games (creator role) and deleting a state root (state deleter role) after winning a challenge is not permissionless."
}
],
"stacks": [
"OVM"
],
"stage": "Stage 0",
"type": "Other",
"vm": [
"EVM"
]
}
scalingTechnology+1-1
{
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "Transaction data is posted to Ethereum using blobs. Initially, data was posted to the CanonicalTransactionChain contract, then it moved to just posting hashes to an EOA address, and as of May 2025, the system uses blobs for data availability.",
"risks": [],
"references": [
{
"title": "Blobs batcher - Metis source code",
"url": "https://github.com/MetisProtocol/mvm/blob/e816c6c461a8e91db3a9ccaa33d2d0f6a60633d5/go/op-program/chainconfig/rollupcfg.go#L85"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production.",
"isCritical": true
}
],
"references": [
{
"title": "Transaction finality - Metis documentation",
"url": "https://docs.metis.io/andromeda/sequencer/architecture/transaction"
}
]
}
],
"forceTransactions": {
"name": "Users can't force any transaction",
"description": "There is no general mechanism to force the sequencer to include the transaction.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"references": [
{
"title": "CanonicalTransactionChain - Etherscan source code",
"url": "https://etherscan.io/address/0x56a76bcC92361f6DF8D75476feD8843EdC70e1C9#code"
}
]
},
"operator": {
"name": "The system has a decentralized sequencer set",
"description": "As of April 2024 Metis uses a permissioned sequencer pool running a Tendermint consensus. Once consensus is reached on a block, an MPC address is used to submit a block hash to Ethereum. The infrastructure to manage the MPC is offchain and not trustless because Ethereum does not verify the validity of MPC address.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": [
{
"title": "Decentralized Sequencer - Metis documentation",
"url": "https://docs.metis.io/andromeda/sequencer/architecture/mpc"
}
]
},
"otherConsiderations": [
{
"name": "EVM compatible smart contracts are supported",
"description": "Metis uses the Optimistic Virtual Machine (OVM) 2.0 to execute transactions.",
"risks": [
{
"category": "Funds can be lost if",
"text": "there are mistakes in the highly complex OVM implementation."
}
],
"references": [
{
"title": "MVM repository - Metis source code",
"url": "https://github.com/MetisProtocol/mvm"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "State root proposals",
"description": "Dispute game contracts for state validation are deployed but not used to propose state roots as in standard OP Stack chains. Instead, the permissioned proposer submits state roots through the appendStateBatch function in the `StateCommitmentChain` contract. A state root gets confirmed if the challenge period has passed and the state batch is not disputed.",
"references": [
{
"title": "StateCommitmentChain - Etherscan source code",
"url": "https://etherscan.io/address/0xA738573Ec0FD7959BfA60Aaa8a23Fe7BEC6c4Bd7#code"
}
]
},
{
"title": "Challenges",
"description": "Games can only be created on demand by the permissioned GameCreator should a dispute be requested. Users can signal the need for a dispute through the dispute() function of the `DisputeGameFactory`. If a game is not created by the `GameCreator` within the dispute timeout period of 2d, anyone can call `disputeTimeout()`. This function calls `saveDisputedBatchTimeout()` on the `StateCommitmentChain`, which marks the batch as disputed. This blocks L2->L1 messaging and withdrawals for the disputed batch and any subsequent batches until the dispute is deleted. Should a game be created and resolved, disputed state batches can be marked as such in the `StateCommitmentChain`. Then, these flagged batches can be deleted (within the fraud proof window). Batches can only be deleted by the MVM_Fraud_Verifier contract address, which currently corresponds to the `Metis Security Council` minority.",
"description": "Games can only be created on demand by the permissioned GameCreator should a dispute be requested. Users can signal the need for a dispute by bonding 4.0 METIS and calling the dispute() function of the `DisputeGameFactory`. If a game is not created by the `GameCreator` within the dispute timeout period of 2d, anyone can call `disputeTimeout()`. This function calls `saveDisputedBatchTimeout()` on the `StateCommitmentChain`, which marks the batch as disputed. This blocks L2->L1 messaging and withdrawals for the disputed batch and any subsequent batches until the dispute is deleted. Should a game be created and resolved, disputed state batches can be marked as such in the `StateCommitmentChain`. Then, these flagged batches can be deleted (within the fraud proof window). Batches can only be deleted by the MVM_Fraud_Verifier contract address, which currently corresponds to the `Metis Security Council` minority.",
"risks": [
{
"category": "Funds can be frozen if",
"text": "an invalid state root is successfully disputed but it is not deleted by the permissioned MVM_Fraud_Verifier (Metis Security Council minority)."
},
{
"category": "Funds can be stolen if",
"text": "the GameCreator colludes with the StateDeleter to block Challenges in the proof system.",
"isCritical": true
}
],
"references": [
{
"title": "DisputeGameFactory - No games are created to propose state roots",
"url": "https://etherscan.io/address/0x1C2f0A08762f0aD4598fB5de8f9D6626a4e4aeE3"
}
]
}
]
}
}