BGD. Aave <> megaETH. Infrastructure/technical evaluation

[bgdlabs]

Following our framework of Aave’s infrastructure evaluation and the positive signaling by the community on the forum, we present the analysis of MegaETH regarding its suitability to deploy an instance of the Aave v3 (v3.6) protocol.

---

DISCLOSURE. This is an independent assessment of different technical components that we consider important for the Aave software to run optimally, not a categorical analysis stating the network is “good” or “bad”, and no kind of “requirement” for Aave to be deployed on the candidate network. That decision is up to the Aave governance, no matter our opinion.

In addition, currently, we have absolutely no financial/investment/services-engagement/any kind of interest in the MegaETH ecosystem.

When doing the evaluation, we contacted the MegaETH team as an important source of information, which has always been exemplary and supportive, but everything in this report comes finally and exclusively from our independent criteria.

Report

1. Introduction to MegaETH

MegaETH is an L2 rollup built on top of heavily customized OP Stack and reth fork, MegaETH achieves over 100,000 transactions per second with sub-millisecond latency and 10ms block time. The network uses specialized node architecture with a centralized sequencer to maximize throughput, settling on Ethereum while leveraging EigenDA for data availability. Like other optimistic rollups, MegaETH is in its early stages of development. The team is actively working to evolve the network’s infrastructure and address key areas such as decentralization, transaction costs, and security mechanisms.

Please note: At the time of publication, MegaETH is operating in a Private Mainnet / Frontier state, and we were granted access to this preliminary infrastructure to conduct our analysis. As this represents early-stage deployment, our findings reflect the current state of the network and may be subject to changes as the infrastructure continues to develop.

2. Our methodology

Methodology and scoring details

This report does not attempt to provide a full, detailed analysis of the X Layer network. Instead, it focuses on the high-level aspects necessary for the Aave community to decide whether to deploy the Aave v3 (v3.6) liquidity protocol there.

In addition to being extensive, this report tries to be simple enough for all participants in Aave governance to understand. However, given its technical nature, it is unavoidable to assume a certain familiarity with some relevant concepts, such as rollups, oracles, RPC nodes, or blockchain explorers, among others.

In order to simplify the interpretation of this report, we will evaluate each key component for Aave separately, and assign simplified “grades”, defined as follows:

Optimal. Fulfilling all minimal requirements, and with extra positive aspects.

Good. Fulfilling the requirements, but improvements can be made.

Acceptable. Fulfilling the requirements, but with “buts”.

Needs improvement. Mandatory requirements were not fulfilled at all. Aave will not work properly

3. Evaluation

3.1. Oracle Infrastructure

The Aave protocol uses various types of oracles within a standalone blockchain. We consider it essential to have Chainlink providing oracles for prices in any deployment, with alternatives only considered on an ad-hoc basis due to the additional complexity introduced during evaluation and integration.

Since the network is in frontier phase, the price feeds are not available, but as confirmed by the Chainlink team, the price feeds would be available ****at the time of launch, which is acceptable.

MegaETH Network	Oracle Infrastructure available	Info/Links
Chainlink Price Feeds		Chainlink docs

3.2. Blockchain explorer

For Aave, same as for any other blockchain project, block explorers like Etherscan are a fundamental component, specifically for the following:

1. Verifiable smart contracts code visualization.
2. Read/write interface with smart contracts.
3. Basic data analysis tool for misc aspects like token holders.

The official blockchain explorer of MegaETH, which is an instance of Etherscan is not public yet, but there also exists a Blockscout instance which can be found here.

3.3. Compatibility with Ethereum RPC standard

Basic compatibility with the Ethereum nodes RPC de-facto standard (eth_, web3_) is quite an important requirement for Aave or any other protocol, given that it helps to have tools built for Ethereum (or other similar networks) working out-of-the-box just by plugging them to node, of MegaETH in this case.

MegaETH HAS strong compatibility with the node running a fork of reth. Several non-standard endpoints are not supported, such as eth_sendTransaction, eth_sign, eth_subscribe but we have validated it should not affect the protocol and the toolings around it. Depending on the node provider, there can also be support for non-standard endpoints (e.g., trace_*) in the future.

3.4 Compatibility with Ethereum account format (addresses)

One of the strengths of non-Ethereum networks (e.g. Polygon, Avalanche C-Chain, etc) is its compatibility with Ethereum private/public keys of accounts. This allows existing account holders on those networks to use the others without creating an ad-hoc wallet for it.

MegaETH is fully compatible with the Ethereum account format.

3.5. RPC public endpoints and providers

Basic and reliable public RPC infrastructure is a must for Aave, as it is the way to connect to the network, both for data reading and transaction submission.

MegaETH HAS an official endpoint at https://mainnet.megaeth.com/rpc. Third-party RPCs like Alchemy are also available.

3.6. Custom behavior (lack of) of the execution layer

Whenever a network has custom/extended behavior with respect to Ethereum, it is important to be aware of it and evaluate if it has any impact on the Aave protocol.

Examples of this potential behavior are the presence of new pre-compiles (compared with Ethereum or similar rollups like Optimism), EVM opcodes, native account abstraction/meta-transactions, chainId definition out of the norm, etc.

MegaETH is strongly aligned with the Optimism execution layer implementation, being part of the OP-Stack. This is really important from Aave’s perspective, given the protocol is already flawlessly running on Optimism mainnet.

Even if not doing a full evaluation of the Optimistic Virtual Machine implementation (it is a relatively daunting task), we have checked the following, given that historically have been critical aspects:

• The chainId behavior is appropriate, with the id 6343 for MegaETH not clashing with any other.

• MegaETH runs on its latest hardfork, Rex, which is based on Optimism Isthmus, and is compatible with the Prague (Pectra) EVM version.

• There are no extra opcodes compared with Optimism.

• There are no extra pre-compiles compared with Optimism.

• SELFDESTRUCT opcode is not supported by MegaETH, but it should not affect Aave.

• The max contract size has been increased from 24kB to 512kB, and the max initcode size increased from 48kB to 536kB compared to Ethereum.

• MegaETH introduces a new multidimensional gas model, which separates gas into two types: compute gas (identical to Ethereum’s standard gas for execution) and storage gas (a new metric specifically for operations that create persistent data). Most operations only consume compute gas, but storage-intensive operations like zero-to-nonzero storage writes, account creation, contract deployment, event logs, and calldata also incur storage gas costs.

• The base transaction cost also increases from 21,000 to 60,000 gas (21,000 compute + 39,000 storage) compared to Ethereum.

• MegaETH also tweaks the gas forwarding rule parameter, as defined in EIP-150, from 63/64 to 98/100 compared to Ethereum, meaning a caller can now forward up to 98% of remaining gas to the callee, with only 2% reserved. This was introduced because of the introduction of the multidimensional gas model.

• As part of an extra security procedure, we deployed a test instance of the Aave v3.6 protocol on MegaETH network and performed end-to-end tests on core protocol functionalities. We found no issues during testing, and the protocol behaved consistently with deployments on other networks.

Additionally, we have a confirmation from the MegaETH team that there is no custom basic behavior affecting the model of execution on the virtual machine.

3.7. Support of wallet providers

Wallet products like Metamask, Ledger, Kraken Wallet, and others are fundamental pieces of the infrastructure for users to access the Aave protocol. So it is a strong requirement for a network to be supported by a subset of them.

Given its EVM compatibility in the context of this document, MegaETH is transparently supported by the majority of chain-agnostic wallets, such as Metamask, Ledger, Rabby, Kraken Wallet, or Frame.

3.8. On-chain multi-signature infrastructure

The permissions on the Aave ecosystem are directly held by on-chain governance smart contracts or scheduled to be like that once cross-chain governance infrastructure can be applied across all the networks.

However, different protection/emergency mechanisms, like the capability of canceling cross-chain governance proposals, or pausing an Aave asset/pool, depend on the Aave Guardian, who is capable of acting faster than the governance process.

Consequently, having on-chain multi-signature contracts is a requisite to have Aave on a different network, with a high preference for industry-standard tools like Gnosis Safe.

MegaETH HAS an official instance of the Gnosis Safe contracts on-chain, supported natively inside the official interface.

3.9. Transactions simulation infrastructure (fork)

Lately, a really important development experience component is the ability to execute test transactions (simulations) on forked production networks.

A good part of the tooling around Aave depends on simulations by using different libraries/frameworks like Hardhat, Foundry, or Tenderly. This way, it is possible to rapidly prototype new developments, get extra assurances on governance proposals and protocol upgrades, change risk parameters, etc.

In terms of tooling that can be used for simulation supporting MegaETH:

• Tenderly is not available at the time of writing, but the team confirmed it would be made available at a later stage after the public launch.

• Blocksec is also not available at the time of writing, but the team confirmed it would be made available by end of January. **

• Foundry and Hardhat are supported on MegaETH.

** Note: At the time of writing, foundry scripts do no account for MegaETH’s native gas estimation so --skip-simulation flag should be used to avoid its built-in EVM, or manually specified high gas limit should be provided via the --gas-limit flag.

3.10. Chain data/indexing solutions

For different projects and entities integrating Aave, and even if not a blocker for deployment, it is important that solutions like TheGraph or Dune are operating on the candidate network, to avoid building from scratch data pipelines.

MegaETH is supported on both TheGraph and Dune and several other indexing solutions like Goldsky as well.

3.11. Bridging infrastructure: assets, messages

Given the central role of Ethereum in the DeFi and Aave ecosystems, proper bridging infrastructure to/from is a must for any candidate network.

3.11.1 Assets Bridging

MegaETH supports native asset bridging using the OP-Stack StandardBridge, however, users can bridge assets using third-party as well.

3.11.2 General Message Bridging

MegaETH supports bi-directional generic message passing via the native L1CrossDomainMessenger bridge, with the same mechanism as Optimism. This is especially important for Aave in order to activate cross-chain governance.

3.12. Network security/technical model

At the core of any candidate network analysis are its morphology (which type of network it is) and security model (which parties are involved in the control over the network; decentralization degree).

Regarding its morphology/type, MegaETH is technically an optimist rollup as an instance of the OP-stack, which is similar to the Optimism mainnet.

Regarding its security model, MegaETH’s approach is almost the same as Optimism’s mainnet: MegaETH benefits through Optimism’s shared security approach and the so-called Fault proofs, which allow users to withdraw ETH on mainnet from the OP stack with a withdrawal proof that it was included in the OP stack chain.

3.12.1. Sequencer and Proposer Downtime

In situations where the sequencer refuses to execute your transaction requests or experiences prolonged downtime, a mechanism known as forced withdrawal or forced transaction inclusion becomes essential to better safeguard user funds.

As part of the OP Stack, MegaETH users can force transactions by sending them directly through the OptimismPortal contract on the L1. This bypasses the sequencer and automatically includes the transaction in the L2.

MegaETH Native oracles:

The MegaETH sequencer also incorporates a sidecar mechanism to support native oracle functionality through integration with Chainlink Data Streams. Native oracles embed the oracle path directly into block production, enabling just-in-time price data delivery with sub-millisecond latency.

Please Note: While MegaETH supports this native oracle infrastructure for applications requiring ultra-low latency data, Aave’s deployment will utilize standard Chainlink Price Feeds, which follow the traditional oracle model with regular onchain updates.

Architecture:

• When a user transaction calls a view function to read from the native oracle proxy, the sequencer intercepts this read and resolves it directly from its local KV cache rather than from the EVM world state.

• The sequencer maintains a local Key-Value cache organized as data stream ID → latest report from Chainlink Data Streams.

• The sequencer injects a transaction immediately before the user read transaction that updates a designated storage slot in a system contract with the cached value.

• Validators replay blocks by executing the injected state-update transaction followed by the user transaction as standard EVM operations, requiring no special oracle-aware logic.

(Source: Chainlink)

We have validated that this mechanism has been audited and does not introduce any secondary risks or unintended consequences for Aave’s deployment.

3.12.2. Upgradeability and control model (decentralisation)

To summarize the detailed privileged roles of the core contracts of MegaETH:

• MegaETH has control of the L1 ProxyAdmin contract, which can upgrade core contracts, through a Safe 4-of-7.

• MegaETH has control of the L1 SystemConfig contract used to manage MegaETH’s configuration, through a Safe 4-of-7.

• MegaETH has control of the L2 ProxyAdmin contract, which can upgrade L2 core contracts, through a Safe 4-of-7.

3.12.3. Security audits

MegaETH audits can be referred to the OP audit reports as part of the OP-Stack ecosystem. Apart from those, the mega-evm has undergone audits by Sherlock, Cantina, and Blocksec.

3.12.4. Security programs (e.g., bug bounty)

MegaETH currently does not have an active bug bounty program or plans to have one in the near future, as confirmed by the MegaETH team.

3.12.5. Commitment to security incidents

A communication channel will be maintained between MegaETH and the assigned technical team of the Aave community (e.g., BGD) for any necessary updates concerning the network and, consequently, Aave on MegaETH.

3.12.6. Transaction Lifecycle

1. Submission: Users send signed transactions through available RPC nodes using standard eth_sendRawTransaction or realtime_sendRawTransaction for immediate receipt return.

2. Sequencing: The single active sequencer orders and executes transactions, packaging them into mini blocks every 10 milliseconds. The sequencer stores the entire EVM world state in memory for high-throughput parallel execution.

3. Mini Block Production: Transactions receive preconfirmation once packaged into mini blocks (~10ms latency), providing the same guarantees as EVM blocks.

4. Distribution: Mini blocks and state diffs are broadcast via P2P network to:

   • Replica nodes: Apply state diffs directly without re-execution

   • Full nodes: Re-execute transactions for validation (higher hardware requirements)

   • Provers: Validate blocks asynchronously using stateless validation

5. EVM Block Aggregation: Every 100 mini blocks aggregate into a 1-second EVM block, maintaining Ethereum compatibility.

6. Proof Generation: Provers generate validity proofs that replica nodes use for indirect block validation. Full nodes achieve faster finality through direct re-execution

3.12.7. Data availability

MegaETH uses EigenDA for data availability. Transaction data (blocks, witness data, state diffs) is submitted to EigenDA, which returns a DA certificate that must be verified on L1 before the block can be finalized. EigenDA achieves high throughput (15-50 MB/s) through erasure-coded data sharding with KZG commitments, ensuring data reconstruction even if some nodes are unavailable. This enables replica nodes, full nodes, and provers to access necessary data even if the sequencer withholds information.

3.13. Comparison with similar Networks: characteristics and differences

As Aave expands to new blockchains, those networks end up sharing different aspects in their layers, which can influence the protocol’s behaviour. By understanding these similarities, we can have a high-level preview during and after its implementation, which facilitates the protocol’s general usability and maintenance.

In the case of MegaETH, it shares foundational similarities with OP Stack chains while introducing unique architectural features:

• MegaETH runs on mega-evm which is built on top of revm and op-revm. The pre-compiled contracts and addresses that facilitate cross-chain communication with the L1 are the same, with no custom behaviour expected.

• MegaETH submits transactions using a single sequencer, as the OP Stack currently allows only one active sequencer at a time.

• MegaETH has two types of blocks: mini blocks with block time of 10ms and EVM blocks with 1s block time. EVM blocks are identical to the other EVM chains, ensuring compatibility with existing tools and applications while mini-blocks were created for compactness and low latency and is specific to MegaETH. Preconfirmation of mini blocks by the sequencer has the same level of guarantees as EVM blocks.

• The infrastructure’s control model also mirrors the early stage of other OP stack chains, with some level of centralization around its upgradability, handled by safe wallets controlled by the team.

4. Summary

An expansion of Aave to MegaETH will imply allocating some development resources for both the initial setup and some overhead for maintenance and monitoring over time, similar to other networks.

From our analysis, we conclude that MegaETH, even in a relatively early stage, is an acceptable network candidate in terms of technical requirements, with no current hard blockers for the Aave v3 (v3.6) protocol to work properly.