How to get a MegaETH RPC endpoint

TL;DR

MegaETH RPC endpoints power real-time applications on MegaETH’s high-throughput L2. With ~10 ms mini-blocks and the Realtime API, infrastructure must handle low-latency queries, rapid event streams, and reliable transaction delivery.

A MegaETH RPC endpoint connects your application to MegaETH’s real-time sequencer. While it uses the standard Ethereum JSON-RPC interface, MegaETH’s ~10 ms blocks and Realtime API require infrastructure optimized for high-frequency queries and streaming workloads.

What is a MegaETH RPC endpoint

A MegaETH RPC endpoint is your application’s gateway to the MegaETH network. It uses the same JSON-RPC interface as Ethereum (eth_call, eth_getBalance, eth_sendRawTransaction) but connects to MegaETH’s real-time sequencer — an Ethereum Layer 2 capable of processing up to 100,000 transactions per second with 10ms mini-block intervals. That speed advantage places unique demands on RPC infrastructure that standard Ethereum tooling was never built to handle.

Every user-facing blockchain action in your product depends on it:

• Reading wallet balances and contract state
• Estimating gas with MegaETH’s custom gas model
• Broadcasting signed transactions via the Realtime API
• Monitoring contract events in real time using eth_getLogs and filter subscriptions

That is why endpoint quality directly determines user experience. At 10ms block intervals, a single slow RPC query costs you hundreds of missed mini-blocks. If your endpoint is unstable, real-time applications fail in ways that are invisible on slower chains but immediately apparent on MegaETH.

How MegaETH RPC differs from Ethereum RPC

MegaETH runs on top of Ethereum as an L2 rollup, which means the JSON-RPC interface is familiar — but the operating environment is fundamentally different. The table below maps the key distinctions that affect provider selection.

This is exactly why provider selection for MegaETH must account for Realtime API support, low-latency streaming, and correct gas estimation behavior — not just raw RPS limits.

MegaETH RPC endpoint options

Choosing the right endpoint is a reliability and latency decision. You are balancing convenience, cost, and operational risk at a speed that magnifies every infrastructure gap.

Public vs Private MegaETH RPC endpoints

Official public MegaETH endpoints:

• Mainnet: https://mainnet.megaeth.com/rpc
• Testnet: https://carrot.megaeth.com/rpc
• Rate limits: Dynamic CU + bandwidth limits per user (see MegaETH RPC docs)
• Critical limitation: debug/trace methods are unavailable on all public endpoints

📖 The full RPC method availability list — including restrictions on gas limits and block ranges — is documented in the official MegaETH RPC docs at docs.megaeth.com/rpc.

Public RPC endpoints are suitable for testing and prototyping. For production workloads — especially high-frequency trading, DeFi bots, or real-time analytics — use a managed infrastructure provider with predictable rate limits.

Full node vs Archive MegaETH node

Your data requirements should drive this decision. MegaETH’s 10ms block cadence produces significantly more state than slower chains, which affects archive storage costs and query latency.

If your product depends on historical state queries or event backfills spanning more than recent blocks, validate archive availability explicitly before launch. MegaETH’s block density means archive nodes carry more data than equivalent Ethereum archives.

HTTPS vs WebSockets

Transport choice has a larger impact on MegaETH than on slower chains because block frequency amplifies the cost of every round trip.

In practice, most teams use HTTPS for standard contract reads and transaction submission, then layer in WebSocket subscriptions for real-time event delivery. On MegaETH specifically, test WebSocket stability under burst traffic early — mini-block rates generate subscription pressure that is orders of magnitude higher than Ethereum mainnet.

How to get a private MegaETH RPC endpoint with Chainstack

1. Log in to the Chainstack console (or create an account)
2. Create a new project
3. Select MegaETH as your blockchain protocol
4. Choose network: MegaETH Mainnet (MegaETH Testnet only for Dedicated Nodes)
5. Deploy the node
6. Open Access/Credentials and copy your HTTPS and WebSocket endpoints
7. Run a quick connectivity check before wiring it into production code

Connect from your application (ethers.js)

const { ethers } = require("ethers");
var urlInfo = {
  url: "YOUR_CHAINSTACK_ENDPOINT",
};
var provider = new ethers.providers.JsonRpcProvider(urlInfo, NETWORK_ID);
provider.getBlockNumber().then(console.log);

• NETWORK_ID — MegaETH network ID:
  • Mainnet: 4326
  • Testnet: 6342

This confirms your application can connect and read live chain data before integrating more complex logic. Note that MegaETH’s custom gas model means you should always use on-chain gas estimation via the RPC rather than relying on local EVM simulation — some toolchains may throw “intrinsic gas too low” errors without this adjustment.

📖 For a full list of MegaETH-compatible tools including MetaMask, Hardhat, ethers.js, viem, and Foundry, see the Chainstack MegaETH tooling documentation.

Using the Realtime API

MegaETH exposes a custom realtime_sendRawTransaction method on top of standard JSON-RPC. This enables sub-second transaction confirmation paths that are not possible on standard Ethereum endpoints. Check provider availability for this method before building latency-critical flows — it may not be present on all third-party endpoints.

📖 For more information on the MegaETH Realtime API, see the official documentation.

Using Chainlist

Chainlist can quickly add MegaETH to wallets like MetaMask or Rabby by auto-filling the correct RPC URL and chain parameters. This is useful for wallet configuration and end-user onboarding.

Chainlist is not an infrastructure provider. For production applications, always replace any public or community RPC URL from Chainlist with your managed endpoint before launch. Public endpoints obtained through Chainlist carry no uptime guarantees and may not support archive queries or the Realtime API.

Chainstack pricing for MegaETH RPC

Chainstack uses request-unit-based pricing, which is easier to forecast than compute-unit models — especially important on MegaETH, where high TPS can amplify compute-weighted billing unpredictably.

Advanced options:

• Unlimited Node add-on: Flat monthly pricing for unmetered usage within RPS tier
• Dedicated Nodes: From $0.50/hour (+ storage) for isolated high-performance workloads

How to estimate monthly cost

• Forecast average and peak requests per day
• Convert to monthly request units
• Add 20–30% buffer for burst spikes — MegaETH’s high TPS means traffic patterns are more volatile than Ethereum
• Verify that your RPS tier matches peak traffic — 10ms blocks can generate 100x more requests than equivalent Ethereum workloads
• Compare shared tier vs dedicated economics at projected scale

For MegaETH specifically: if your application is latency-critical (trading bots, real-time DeFi, or on-chain gaming), throughput tiers and overage policy matter more than base plan price.

Production readiness checklist

Before launch, validate these controls:

• Primary and fallback RPC provider configured
• Request timeout policy set (MegaETH’s fast blocks mean stale responses age out quickly)
• Retry logic with exponential backoff implemented
• Chain ID validated at startup via eth_chainId (0x10e6 for mainnet)
• Gas estimation routed through RPC, not local simulation
• Credentials stored in environment variables or a secrets manager — never hardcoded
• Monitoring for latency, error rate, and throttling (429 responses)
• Alerts for sustained degradation
• eth_getLogs access confirmed and block range limits understood
• debug/trace method availability verified with provider if needed

These controls prevent the most common RPC incidents in production on MegaETH. The gas model difference is the most frequently missed item for teams migrating from Ethereum.

Troubleshooting common MegaETH RPC issues

Conclusion

MegaETH’s real-time architecture makes RPC provider selection far more critical than on standard Ethereum L1 or L2 chains. At 10ms block intervals and up to 100,000 TPS, infrastructure gaps that are invisible on slower networks become immediate application failures.

Your provider must support burst traffic, reliable event delivery via eth_getLogs, stable WebSocket connections, correct gas estimation, and ideally the Realtime API for latency-sensitive transaction flows — not just basic JSON-RPC uptime.

Use public endpoints for prototyping, then migrate to managed infrastructure with confirmed MegaETH support and SLA-backed reliability before production launch.

Start with Chainstack, validate your query and gas estimation patterns in staging, then scale to dedicated infrastructure as traffic grows.

FAQ

Additional resources

• MegaETH methods
• MegaETH Chainstack tooling