Launch Aave V3 on Metis

is this some kind of a joke? The entire metis chain just stopped itself today giving users only 30 mins of notice. What kind of a chain does this? They are still to publish any kind of explaination on why they had to do this. Is AAVE going to take responsibility for loss of user funds? And why are we not prioritizing so many other chains that are far more battle tested?

1 Like

Almost 24 hours and no explaination of why Metis had to make an emergency upgrade. They posted a BS explainer about why the system went down (they had only one sequencer!) but no explainer as to why they had to push an upgrade at almost no notice. This is crazy stuff and not even Solana did this. This proposal is nonsense.

1 Like

Metis Bridge ETH to Metis Andromeda

There was a upgrade of the network on February 3rd 2022 due to a bug in the Optimism’s codebase found by a whitehat hacker:

This exploit was revealed to us and was quickly patched:

To improve network stability, Metis performed a scheduled upgrade on August 15, 2022:

reviving this thread as Metis just got Chainlink price feeds.

price feeds were technically required to proceed with this onboarding proposal.

if the community agrees to proceed to the snapshot phase of this deployment.

please consider the governance guideline for new chains deployments :

  • vote should start at least 24h after publication of the snapshot vote
  • vote should last at least 3 days (I would recommend at least 7 as summer is lower activity)
  • vote should have at least 3 options (YAE/NAE/ABSTAIN)

quorum for new chains deployment is currently set at 150k YAE votes.


Bridge Security

As there have been more cross-chain bridge attacks, we would like to post an overview to the Metis Smart L2 mechanism and outline more details and security processes in the system.

The Metis Bridge is a Natively Verified bridge, which means that it is secured by the native Smart L2 protocol. This means that there are no multisigs or external validators present that could compromise the security of the bridge. The Metis bridge does have a set withdrawal time of 7 days as it is verified Optimistically.

Comparison and Differences to other Rollups

Currently, both Optimism and Boba have similar security mechanisms as Metis. The key difference between the implementations is that the Metis Smart L2 mechanism stores the transaction batch data off-chain, but may bring the data on-chain at any time to execute a fraud proof. The off-chain data component is the actual transaction data and is posted by the Sequencer in the Memolabs decentralized storage, similar to IPFS. Transaction data can also be accessed by the Peer Network. If the Sequencer does not post the Transaction batch data to Memolabs, then a Verifier can request that the transaction data that the Sequencer has attested can be posted on-chain.

In any case, there are mechanisms in place to access the transaction batch data, bring it back on chain, and execute the fraud proofing process. If the transaction data cannot be brought on-chain, since the Sequencer has attested the transaction data that they submitted, then the batch can be invalidated and the Sequencer can be punished for not bringing it on-chain.

How do you deal with the Data Availability Problem / Speaker-Listener Dilemma?

Game Theory Mechanics

Both the Sequencers and Verifiers benefit from acting in the best interest of the network. The Sequencer would retain the fees that they would make from processing the transactions normally without withholding data. The Verifiers would benefit by not losing money for making needless data requests. Based on these mechanics, there is no direct guaranteed incentive by attacking the network.


Griefing is the process of needlessly requesting data to be on-chain. It is done as a malicious action towards the Verifier or the Sequencer, where both parties lose monetary value.

If the Sequencer is griefing data requests to the Verifiers

This occurs when the Sequencer does not submit data to Memolabs and the Peer Network transaction data does not match what was posted on Layer 1. Since data is not available and cannot be retrieved, the only way to do so would be to request the data directly from the Sequencer. If the Sequencer provides it, and it turns out to be valid, then no direct punishment can occur.

This is an attack vector and can affect network security since the Sequencer can force all Verifiers to pay for transaction data to needlessly be brought on-chain. In the case when there are no Verifiers remaining because of attrition (fees), the Sequencer can submit a falsified Merkle Tree State Root (MTSR) and withdraw funds from the network after the 7-day withdrawal period. There are 2 flows to prevent this from happening:

The Rotation Flow

  • The Sequencer checks if it is selected by Layer 1 for the current rotation;
    • If the Sequencer is the current selected Sequencer:
      • The Sequencer continues with the regular flow, in this case they download the transaction data from the Peer Network.
    • If the Sequencer is NOT the current selected Sequencer:
      • The Sequencer waits for the selection into the next slot on Layer 1.

The Governance Flow

  • A proposal is submitted to the Governance Protocol to remove the Sequencer;
  • The affected Verifiers can get compensated for any lost transaction fees through the data requests made by the Sequencer;
  • If the Governance Protocol succeeds, the Sequencer gets removed from the Sequencer pool. The Sequencer will also lose a portion of their funds that are present in Layer 1 to pay for the affected data requests that the Verifiers made;
  • A Sequencer rotation is executed.

Using a rotated Sequencer would enable network resilience, as the Sequencer has a limited amount of transactions that it can process per slot. Because of the automatic Sequencer rotation, the damage that a single Sequencer can produce is minimized per slot. In combination with the Protocol Governance, the malicious Sequencer can be manually removed from the Sequencer Pool to prevent further damage to the network.

If the Verifier is griefing data requests to the Sequencer

This occurs when the data is present on Memolabs or the Peer Network transaction data matches what was posted on Layer 1, but the needless request is sent to the Sequencer for execution. This is significantly less serious than a griefing attack done by the Sequencer, as it only affects the efficiency of the network. This griefing attack does NOT affect the security of the network and the worst-case scenario is that there would no longer be any Sequencers on the network to process transactions, halting the network and freezing the funds until a new Sequencer is rotated. Since this only affects the efficiency of the platform, a governance flow is included to prevent this attack:

  • A proposal is submitted to the Governance Protocol to remove the Verifier;
  • The Sequencer can get compensated by any lost transaction fees through the data requests made by the Verifier.
  • The Verifier gets banned from making requests to the Sequencer. The Verifier will also lose any funds that are present in Layer 1. There is no rotation needed since other Verifiers work asynchronously.


For additional process descriptions, please see the Metis Documentation

1 Like

l2beat would like to add few points of consideration to the discussion:

Bridge Security

Right now, similarly to Optimism and Boba, bridge is not secured at all as fraud proofs are not deployed since the upgrade from OVM 1.0. So it is strictly not true that the bride is “natively verified”. We are looking forward to Optimism, Boba and Metis to deploy fraud proof mechanism in near future so that the bridge is not secured solely by the centralised Sequencer. Until then, end users - if they spot erroneous L2 state root commit to L1 - have 7 days to alert the community with no ability to challenge Sequencer.

Data Availability Problem

Metis, as of April 2022, is not posting transaction data to the Ethereum chain. The mechanism, as described in the documentation, that will allow Validators to request data from Sequencer, is not yet fully implemented. Again, we are looking forward to the final implementation to fully assess the severity of the grieving problem that such constructions suffer from. Having said that, in general, Ethereum community regards grieving problem as unsolvable and the ultimate security, in the worst case scenario where Sequencer is grieving Validators, falls back to the Governance that would need to boot out malicious Sequencer. The ultimate fallback to Governance is acknowledged by Metis themselves.

Sequencer Rotation

We would like to ask Metis team to point out the exact code that implements Sequencer Rotation and other mechanism mentioned in the documentation. Currently deployed system does not seem to implement this mechanism and there is only one Sequencer (0xcDf02971871B7736874E20B8487c019D28090019) that is whitelisted to post transaction batches.

System Validators

Metis relies on Data Availability Validators so that potentially malicious Sequencer can be challenge, if data is withheld, however right now there is only one address (0x48fE1f85ff8Ad9D088863A42Af54d06a1328cF21) that is whitelisted to perform such challenge. Our understanding is that ultimately this functionality will be permissionless and open to everyone, in the meantime end users have to fully trust Sequencer that it posts data to external data store. This is in stark contrast to Optimism and Boba that post data on-chain and even though there is no fraud proof mechanism implemented, users can always verify the state by re-executing posted L2 transaction batches and they have 7 days to alert the community if anything malicious was going on. With Metis, as it stands, if data is not posted to MEMO, there is no way to know for end users if L2 state root is correct or not so - in a way - any potential fraud might go undetected in practice.


We are very much looking forward for the Metis team to fully implement all the mechanisms described in their blog posts and documentation so that full assessment of the security of their proposed architecture can be performed. Until then, in our opinion, Metis users have to fully trust that Sequencer is honest.


Above assessment is derived purely from the analysis of deployed smart contracts listed in Metis Andromeda – L2BEAT. These contracts were deployed in April 2022. If this list is inaccurate and Metis was recently upgraded to new implementation that we are unaware of, we are more than happy to change the current risk profile, however the only change that we have observed was the recent change of the Metis Manager from EOA address 0xDD6FFC7D9a4Fb420b637747edc6456340d12d377 to the Gnosis Safe 0x48fE1f85ff8Ad9D088863A42Af54d06a1328cF21

1 Like

Thank you for the response. Some points for clarification, as the purpose of the risk analysis is to outline criticisms in the overall architecture and to provide clarity into how the system functions as a whole. The current state of the system is similar in the state of how both Optimism and Boba are currently implemented. Working fraud proofs and the decentralization of the Sequencer role are both technical challenges that are the main barriers to the system functioning in a decentralized way. We are aligned with the bedrock release of Optimism, which would introduce fraud proofs into Metis as well; the decentralization of the Sequencer will follow shortly after. As our technological innovation is to reduce gas costs below what Optimism and Boba currently costs, we still maintain similar security mechanisms as both those solutions, with a 1 of N trust model.


Pavel, can you post a list of all things that Metis has to complete in order to meet all AAVE requirements?

Currently, the understanding of the Metis community is that there are major problems that the Metis team has to solve. If this is not the case, please clarify it here.

You don’t want your core followers and early adopters to feel concerned about all that. Instead, we should know that you are in control of everything. Currently, it doesn’t look this way.

Let’s clarify this and keep on!
Thank you.

We have fulfilled all of the requirements listed for an AAVE proposal. The requirements for the AAVE proposal are listed by Marc Zeller in the previous post in this thread. We can launch the proposal at any time, but we would like to take the time to answer any questions.

Optimism, Boba, and Metis use the same core codebase, we have originated as a hardfork from Optimism. All 3 implementations do not have a working fraud proof mechanism currently. This means that you need to rely on the Sequencer to post the correct transaction data and if false data is posted, then network funds can potentially be at risk. Because of this, all 3 implementations currently have a trusted centralized Sequencer to post the requests.

One of Metis’ main focus has been the decentralization of the network, we have mentioned this within 2 of our roadmaps:

In order for Sequencer Rotation and fulfillment of data requests, working fraud proofs must be implemented, hence the current whitelisting for both. Working fraud proofs will be implemented in Q4 (our 2nd-half roadmap).

As a recap, we have described the security mechanisms of our architecture and the overall process flow, no criticisms for the overall architecture was mentioned. The implementation of the process flow relies on the fraud proofing mechanism, this mechanism does not currently exist for any Optimism-based projects (Optimism, Boba, Metis). After fraud proofing is implemented, the Sequencer rotation and the fulfillment of on-chain data requests will be implemented with it. We are as secure as both Optimism and Boba in the current stage, which have both passed the AAVE proposal for deployment.


Thank you Pavel!

This is a great response!

How long are you still going to leave it open for question before you submit the proposal?

Thank you for asking and appreciate the questions. We want to give it some more time and we will likely make an announcement within the coming weeks.

This is actually not true, as both Optimisms and Boba post data on-chain while Metis does not. This significantly changes the security assumptions, even with fraud proofs disabled.

The ability to bring data back on-chain is outlined in the architecture above, and we already have the ability to do so, which is currently whitelisted until fraud proofs are enabled.

In the scenario that transaction data is not supplied, all participants will know that the transaction data cannot be downloaded and it will be automatically flagged as a security concern of the associated states, See insecure transaction state. Since the request is attributed to the Sequencer that initially posted it, they can be punished if the data is not provided on-chain within a set amount of time (currently 24 hours).

Please let me know the scenario that you are referring to that changes the security assumptions, since everything can be attributed to the Sequencer and all you need is 1 honest Verifier to secure the network, even in the case that data is not available.

If the outcome is the same currently, in this case, the inability to act upon invalid state roots and the architecture holds the 1 of N trust model, then we currently have the same security as both Boba and Optimism.

Why does it feel like Mr. @l2beat is just out2beat Metis?


@psinelnikov let’s go with the proposal and voting!

The Marathon + AAVE + positive sentiment in markets will bring a great combination.

What else are we waiting for? It looks like there are no more questions and everything is all clear for voting. Or?

Can you provide a link to the deployed source code (and not to the documentation) of such punishment mechanism ?

1 Like

The goal of all the efforts at l2beat is to provide transparency, not judgement. We are trying to make sure that projects are honest about their claims, they verify source code of the deployed contracts so that others can audit them, they make sure that there is no discrepancy between whitepaper / documentation and the deployed code. Ultimately users should be aware of the security assumptions of the given scaling solutions. We are not trying to pick sides or winners. Is there anything specific that we said that you found factually incorrect ?


I am concerned by the lack of real community engagement here. At the moment, it seems the excitement and support @MarcZeller outlines in his comment is lacking.

Many of these original commentators are brand new accounts with very little substance. The discussion was fragmented and reignited in August; its state is not indicative of community enthusiasm

The Metis team is welcome to proceed to Snapshot but feels a bit ambitious. It seems there is more support and education needed for voters to better evaluate this proposal.

1 Like

@psinelnikov, I do not quite agree with @fig, but he is right that not too much is happening here.

It really looks strange. Pavel, can you once and for all share what your plan is. Please be more specific, because the vagueness hurts Metis, of which I am a big supporter.

We want to hear a clear plan:
and timeline.

Or at least be sincere and share with the community whether you are postponing it for a later stage.
Something specific, please. Currently, it is not enough. Thank you very much!

1 Like

Hello AAVE community. This is Peter from Metis and one of the cofounders. My team made me aware of this post and some questions from supporters. First of all, thank you Pavel for helping answer the concerns and questions. Pavel is very knowledgeable about what we want to achieve and the inner workings of L2. I think he has provided enough material to the community for everyone to get an idea of our approach to provide enterprise level fee structure while minimizing the additional security assumptions.

But the I saw there are some specific implementation questions, which I will help to answer.

First all, @l2beat when we chat about this, I recall I also highlighted that we are aware of the lack of punishment because currently the fraud proof is disabled. Without punishment, it is also dangerous to enable the sequencer rotation and open it to public. thus we have been delaying to release the sequencer rotation.

As for why we stopped adding rotation code to the existing contract, it is simply because our partners are all hoping we can move to the bedrock architecture as well. Moving into that architecture is a lot of additional work for us because we have changed quite a lot based on the optimism’s code. yes we have also done a large number of geth changes, which we are trying to minimize in the same spirit of bedrock architecture. For this transition to happen, we also need to reevaluate the smart contracts especially the one relate to the transaction commits.

I always want to point out every time when people say metis doesn’t upload any transaction data to l1, it is not entirely true. We submitted all the transaction metadata info such as timestamp, l1 block number and etc along with a computer merkletree root of all call data in the batch. If Metis truly doesn’t upload any transaction data at all, the price would be even cheaper. And I also made very clear in multiple occasions that I simply don’t like the idea of having data availability committee.

But with fraud proof disabled, it is factually wrong to claim Metis security assumption difference is significant compared to the current state of other optimism’s chains. Because as soon as the sequencer, which currently is a trusted entity, does not make the data available offline, the verifiers who are constantly checking and reporting verified blocks will immediately flag the issue and report to the community. This is exactly the same as optimism’s sequencer submitting fabricated transaction and state roots. Because the fraud proof is disabled, there isn’t a punishment implemented on chain yet. However, we are all honest entities. Optimism has 2b TVL. Metis at one point also had 800M TVL. Both of us have very strong track record of being honest. Both of our goal is to promote adoption of ethereum, while Metis’s goal is more on the enterprise side and optimism’s is more general. IMHO, I failed to find facts to support your claim.

Finally, I saw a community member asking for roadmap. We tried to provide roadmap every 6 months. And I have explained the reasons of the delay earlier. However, I want to point out that we are working on some very challenging stuff, including the recent zkp effort, that is being developed in the open. We can only give a very high level roadmap. There are many different challenges that we face everyday when we progress through the tasks. I believe people that worked on the blockchain core infrastructure code understand what I mean. so please bear with us with some vagueness. Cuz it is very hard to make promises until it’s close to the release. If you look at our history, when we actually announce the dates, we honor them very well.

Sorry for the long notes. I do feel guilty not reaching out to aave community earlier. But as a tech guy, most of my time is spent on tech development. But I hope it will help aave community to understand who Metis is, what mission we are on and why we made certain decisions.


1 Like