Ir al contenido principal

MegaETH RPC

With Quicknode, you get access to our global MegaETH network which always routes your API requests to the nearest available location, ensuring low latency and the fastest speeds.

Descripción general de MegaETH

MegaETH is a high-performance blockchain platform featuring MegaEVM, an advanced execution environment built on Ethereum standards. The latest hardfork, Rex, is based on Optimism Isthmus (derived from Ethereum Prague), ensuring broad smart contract compatibility with the Ethereum ecosystem.

MegaETH is EVM-compatible, allowing most existing Ethereum-based Solidity contracts to run with minimal or no changes. All standard development tools like Hardhat, Foundry, and Remix work seamlessly. Key enhancements include a multidimensional gas model (separating compute and storage costs), higher contract limits (512 KB vs Ethereum's 24 KB), and advanced resource management. Note that contracts using deprecated opcodes like SELFDESTRUCT or relying on specific gas mechanics may require adjustments.

Interacting with MegaETH's APIs

MegaETH nodes expose a JSON-RPC interface that is compatible with Ethereum's JSON-RPC API. This means developers can use Ethereum's native tools, such as Foundry, Hardhat, and popular Web3 libraries, without modification.

However, due to MegaETH's architectural differences (including its multidimensional gas model and enhanced contract limits), some RPC methods may behave differently from those on Ethereum. We highly recommend cross-referencing with the official MegaETH documentation for the latest updates and technical specifications.

Make MegaETH API Calls

The quickest way to start building on MegaETH is to create a Quicknode endpoint and send your first JSON-RPC request.

Quicknode provides managed MegaETH endpoints, giving you immediate access to the MegaETH Mainnet and Testnet without the overhead of running infrastructure. These endpoints offer:

  • Alta fiabilidad: infraestructura distribuida a nivel mundial diseñada para minimizar el tiempo de inactividad
  • Rendimiento mejorado: latencia optimizada y gestión de solicitudes para aplicaciones de nivel de producción
  • Ecosistema integrado: funcionalidad adicional a través de API especializadas (complementos) disponibles en Quicknode Marketplace y productos como Streams

Visita la página de inicio rápido para crear tu punto final y enviar tu primera solicitud.

Redes compatibles

Quicknode provides access to the following MegaETH networks:

Red principal
Tipo:Producción
ID de la cadena:
4326
HTTP:
WSS:
Archivo:No
Pruning:Block and transaction data retained indefinitely; historical state data pruned with ~15-day retention window

Data Availability & Pruning Policy

Quicknode's MegaETH nodes run with --prune.policy=full, which applies a ~15-day (1,296,064-block) retention window for certain data categories. Here's what this means for data availability:

Available indefinitely:

  • Block data — Block headers and bodies are never pruned. Methods like eth_getBlockByNumber y eth_getBlockByHash work for all historical blocks.
  • Transaction data — Transaction records and hash-to-block lookups are retained indefinitely. Methods like eth_getTransactionByHash work for all historical transactions.

Subject to ~15-day retention window:

  • Receipt data — Transaction receipts (eth_getTransactionReceipt, eth_getBlockReceipts) are pruned from the database after ~15 days but are also persisted in static files.
  • Historical state queries — Methods that require account or storage history at a past block (e.g., eth_call, eth_getBalance, eth_getStorageAt, eth_getCode, eth_getTransactionCount with a historical block number) are limited to the ~15-day pruning window. Queries for state older than ~15 days may return errors or incomplete data.
Pruning Details

The following data categories are pruned under the full policy:

  • account_history — account state change sets (~15-day window)
  • storage_history — storage state change sets (~15-day window)
  • receipts — transaction receipts (~15-day window)
  • salt_history — salt change sets (~15-day window)
  • withdrawal_history — (~90-day window)
  • sender_recovery — fully pruned

The following are never pruned: headers, transacciones, transaction_lookup, bodies_history.

Comparte este documento