Mantle RPC: Endpoints, EigenDA, and What's Different

Point your wallet at Mantle and the first few RPC calls feel completely familiar — eth_chainId returns 5000, eth_blockNumber ticks along, eth_call works exactly as you'd expect. Mantle is EVM-equivalent and speaks standard JSON-RPC, so most of your tooling just works. Then you go to estimate a transaction's cost, multiply gas by gas price, format it as ETH — and the number is meaningless, because Mantle's gas token isn't ETH, it's MNT. That's the first of two things that make Mantle different from a vanilla OP-Stack rollup, and both are worth understanding before you ship.

This post is a developer's-eye view of Mantle: what's the same, what's genuinely different (the MNT gas token and its EigenDA data-availability layer), and how to connect.

What Mantle is

Mantle is an Ethereum Layer 2 — an optimistic rollup whose execution layer is derived from the OP Stack, so at the EVM level it behaves like Optimism or Base. Transactions execute off-chain, and the rollup inherits security from Ethereum. Where it diverges from the standard rollup design is where the transaction data goes and what you pay gas in. Mantle calls itself a modular rollup for the first reason; the second is a deliberate token-economics choice tied to its large treasury (a legacy of the BitDAO era).

Difference #1: gas is paid in MNT

On almost every other EVM chain, the native currency you pay gas in is ETH (or a wrapped equivalent). On Mantle it's MNT. Your RPC calls don't change — eth_gasPrice, eth_estimateGas, eth_maxPriorityFeePerGas all still work — but the units of the numbers they return are MNT-denominated, and a few things follow from that:

• Cost math. gasUsed × gasPrice gives you a cost in MNT wei, not ETH wei. If you display fees, convert with the MNT price, not ETH.
• Funding. An account needs MNT to pay for gas, not ETH. Bridged ETH on Mantle is just an ERC-20; it won't pay for transactions.
• Gas estimation quirks. Mantle has historically used a higher gas-per-transaction accounting than mainnet (token decimals and an internal gas multiplier), so don't hardcode mainnet gas assumptions. Always call eth_estimateGas against a Mantle endpoint rather than reusing an Ethereum estimate.

None of this requires special RPC methods — it requires remembering that the denomination is MNT when you read the standard fields back.

Difference #2: data availability runs on EigenDA

A rollup has to publish its transaction data somewhere so anyone can reconstruct and verify the L2 state — that's data availability (DA). Most rollups post that data to Ethereum itself, as calldata or, since EIP-4844, as blobs. Mantle instead publishes it to EigenDA, EigenLayer's dedicated data-availability network secured by restaked ETH.

For a developer reading state over RPC, this is mostly invisible — you still query the Mantle execution layer the same way. But it shapes the chain's properties in ways worth knowing:

• Cost structure. Moving DA off Ethereum calldata is the main reason Mantle's fees are low; the chain isn't paying L1 calldata/blob prices for every byte.
• The trust model is different from a pure Ethereum-DA rollup. Data availability is guaranteed by EigenDA's operator set rather than by Ethereum consensus directly. For most apps this is a fine trade; for high-value settlement you should understand that the DA guarantee comes from a different source than a rollup that posts straight to L1.
• It doesn't change your JSON-RPC. You don't query EigenDA for normal reads — eth_getLogs, eth_getTransactionReceipt, and friends all hit the Mantle RPC as usual. DA is an infrastructure-layer concern, not an API-surface one.

If you want the deeper background on how an L2 orders and publishes transactions, our explainer on what a sequencer is covers the ordering-and-batching pipeline that EigenDA slots into here.

What's the same (almost everything else)

Beyond those two points, building on Mantle is ordinary EVM work:

• Standard JSON-RPC over HTTP and WebSocket — eth_call, eth_getLogs, eth_subscribe, eth_sendRawTransaction, the full set.
• EVM-equivalent execution, so Solidity contracts, ethers/viem/web3.py, and existing ABIs work without modification.
• WebSocket subscriptions for live blocks, logs, and pending transactions.
• Standard tooling — block explorers, indexers, and multicall all function as they do on other OP-Stack chains.

Practical tip: when you reuse a deployment script from Optimism or Base, the two things to audit are (1) anywhere it assumes ETH-denominated gas or balances, and (2) any eth_getLogs range assumptions, since L2 block rates are high — see how eth_getLogs range caps bite you for that one.

Connecting to Mantle

Point your client at the SwiftNodes Mantle endpoints — HTTP and WebSocket, one API key:

https://rpc.swiftnodes.io/rpc/mantle?key=YOUR_API_KEY
wss://rpc.swiftnodes.io/ws/mantle?key=YOUR_API_KEY

With viem:

import { createPublicClient, http } from "viem";

const client = createPublicClient({
  transport: http("https://rpc.swiftnodes.io/rpc/mantle?key=YOUR_API_KEY"),
});

const chainId = await client.getChainId();   // 5000
const block = await client.getBlockNumber();
// Remember: fee values here are denominated in MNT, not ETH.
const gasPrice = await client.getGasPrice();

Adding it to MetaMask or a wallet config: chain ID 5000, currency symbol MNT, and the HTTPS endpoint above. The full Mantle RPC page has the network details and a free-tier key.

The short version

Mantle is an EVM-equivalent, OP-Stack-derived L2 with two characteristics that catch developers out: gas is paid in MNT, so all your fee/balance math is MNT-denominated, and data availability runs through EigenDA rather than Ethereum calldata, which is why fees are low and why its DA trust model differs from a pure Ethereum-DA rollup. Your JSON-RPC doesn't change — just connect, estimate gas against a real Mantle endpoint, and denominate costs in MNT.

Start free and point your Mantle app at https://rpc.swiftnodes.io/rpc/mantle?key=YOUR_API_KEY — flat-rate, HTTP + WebSocket, one key across 75+ chains.