Moonbeam RPC Guide: Endpoints, XCM Methods, Cross-Chain Patterns (2026)

Moonbeam is Polkadot’s primary Ethereum-compatible parachain. It runs full EVM compatibility on top of Polkadot infrastructure, enabling developers to deploy Ethereum contracts while accessing Polkadot’s cross-chain interoperability. From an RPC perspective, Moonbeam exposes standard Ethereum JSON-RPC methods plus a set of Moonbeam-specific custom methods that expose Polkadot-native functionality like XCM cross-chain messaging and parachain finality status.

This guide covers public Moonbeam RPC endpoints, multi-library connection examples, Moonbeam-specific custom API methods, XCM call patterns, common production issues.

For BoltRPC endpoint setup and MetaMask configuration, see the Moonbeam chain page.

Moonbeam vs Standard EVM Chains: What Changes for RPC

Moonbeam is EVM-compatible, but there are important architectural differences that affect how you use its RPC:

Block production is parachain-dependent. Moonbeam produces blocks in sync with Polkadot’s Relay Chain slot cadence (approximately 12 seconds). This is structurally fixed, not a governance parameter. You cannot expect faster blocks through protocol upgrades as you might on a standalone EVM chain.

Finality comes from Polkadot, not EVM consensus. A block on Moonbeam is not “finalized” in the Ethereum sense until Polkadot’s Relay Chain finalizes it. This is typically one or two Relay Chain blocks after the Moonbeam block, adding a few additional seconds. Moonbeam provides custom RPC methods to check finality status directly.

Moonbeam-specific custom methods exist. Moonbeam exposes methods prefixed with moon_ that are not available on standard EVM chains. These include finality checks and subscription methods specific to parachain operation.

XCM precompiles extend EVM functionality. Cross-chain messaging (XCM) is accessible through precompiled contracts at fixed EVM addresses. You interact with them using standard eth_call and eth_sendRawTransaction, but the execution crosses into the Polkadot runtime.

Canary network is Moonriver. Moonriver on Kusama is Moonbeam’s canary network. New features deploy to Moonriver first. If you are building for both environments, BoltRPC supports both chains under a single provider.

Public Moonbeam RPC Endpoints

Provider	HTTP Endpoint	WSS Endpoint	Notes
Moonbeam (official)	https://rpc.api.moonbeam.network	wss://wss.api.moonbeam.network	Official, rate limited
dRPC	https://moonbeam.drpc.org	wss://moonbeam.drpc.org	Public tier available
OnFinality	https://moonbeam.api.onfinality.io/public	wss://moonbeam.api.onfinality.io/public-ws	Free tier available
Blast	https://moonbeam.public.blastapi.io	wss://moonbeam.public.blastapi.io	Public tier

Chain ID: 1284 Native token: GLMR Block explorer: https://moonscan.io

For production, use BoltRPC: https://eu.endpoints.matrixed.link/rpc/moonbeam?auth=YOUR_KEY

Connecting to Moonbeam

ethers.js

import { ethers } from "ethers";

// HTTP provider
const provider = new ethers.JsonRpcProvider(
  "https://eu.endpoints.matrixed.link/rpc/moonbeam?auth=YOUR_KEY"
);

// WebSocket provider for subscriptions
const wsProvider = new ethers.WebSocketProvider(
  "wss://eu.endpoints.matrixed.link/ws/moonbeam?auth=YOUR_KEY"
);

// Check chain ID (should be 1284 for Moonbeam)
const network = await provider.getNetwork();
console.log("Chain ID:", network.chainId); // 1284n

// Get latest block
const blockNumber = await provider.getBlockNumber();
console.log("Latest block:", blockNumber);

// Read GLMR balance
const balance = await provider.getBalance("0xYourAddress");
console.log("GLMR balance:", ethers.formatEther(balance));

Web3.py

from web3 import Web3

# Connect to Moonbeam
w3 = Web3(Web3.HTTPProvider(
    "https://eu.endpoints.matrixed.link/rpc/moonbeam?auth=YOUR_KEY"
))

print("Connected:", w3.is_connected())
print("Chain ID:", w3.eth.chain_id)  # 1284
print("Block number:", w3.eth.block_number)

# Fetch latest block with transaction details
block = w3.eth.get_block("latest", full_transactions=True)
print("Block timestamp:", block["timestamp"])
print("Transactions:", len(block["transactions"]))

# Read contract state on Moonbeam
contract_address = Web3.to_checksum_address("0xYourContract")
abi = [{"name": "balanceOf", "type": "function", "inputs": [{"name": "account", "type": "address"}], "outputs": [{"name": "", "type": "uint256"}]}]
contract = w3.eth.contract(address=contract_address, abi=abi)
balance = contract.functions.balanceOf("0xYourAddress").call()
print("Token balance:", balance)

Moonbeam-specific custom methods (curl)

# Standard eth_blockNumber
curl https://eu.endpoints.matrixed.link/rpc/moonbeam?auth=YOUR_KEY \
  -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# moon_isBlockFinalized: check if a specific block hash is finalized by Polkadot
curl https://eu.endpoints.matrixed.link/rpc/moonbeam?auth=YOUR_KEY \
  -X POST -H "Content-Type: application/json" \
  --data '{
    "jsonrpc":"2.0",
    "method":"moon_isBlockFinalized",
    "params":["0xYourBlockHash"],
    "id":1
  }'

# moon_isTxFinalized: check if a transaction hash is finalized
curl https://eu.endpoints.matrixed.link/rpc/moonbeam?auth=YOUR_KEY \
  -X POST -H "Content-Type: application/json" \
  --data '{
    "jsonrpc":"2.0",
    "method":"moon_isTxFinalized",
    "params":["0xYourTxHash"],
    "id":1
  }'

WebSocket subscription

import { ethers } from "ethers";

const wsProvider = new ethers.WebSocketProvider(
  "wss://eu.endpoints.matrixed.link/ws/moonbeam?auth=YOUR_KEY"
);

// Subscribe to all blocks
wsProvider.on("block", (blockNumber) => {
  console.log("New Moonbeam block:", blockNumber);
});

// Subscribe to XCM-related events from a specific contract
const xcmPrecompileAddress = "0x000000000000000000000000000000000000080b";
const filter = {
  address: xcmPrecompileAddress,
  fromBlock: "latest"
};

wsProvider.on(filter, (log) => {
  console.log("XCM event:", log.transactionHash, log.topics);
});

Example Moonbeam RPC Methods

Code examples are for reference. Verify against the official Moonbeam documentation before production use.

Standard Ethereum Methods (fully supported)

Method	Purpose
`eth_blockNumber`	Get current block height
`eth_call`	Read contract state
`eth_estimateGas`	Estimate transaction gas
`eth_sendRawTransaction`	Broadcast transaction
`eth_getLogs`	Fetch contract events by filter
`eth_getTransactionReceipt`	Get transaction result
`eth_subscribe`	WebSocket subscriptions

Moonbeam Custom Methods

Method	Purpose	Parameters
`moon_isBlockFinalized`	Check if block is finalized by Polkadot	`[blockHash]`
`moon_isTxFinalized`	Check if transaction is finalized	`[txHash]`
`moon_getLatestSyncedBlock`	Get latest synced block number	`[]`

Important: moon_isBlockFinalized returns false for recent blocks even after they appear in eth_blockNumber. Polkadot Relay Chain finality lags by one to two Relay Chain blocks (approximately 12-24 seconds after the Moonbeam block). If your application requires finality guarantees, use this method rather than counting block confirmations.

XCM Precompiles: Cross-Chain Calls via EVM

XCM (Cross-Consensus Messaging) on Moonbeam lets you interact with other Polkadot parachains directly from Solidity contracts or from your RPC calls. Precompiled contracts at fixed EVM addresses expose XCM functionality through standard eth_call and eth_sendRawTransaction.

Key precompile categories:

XCM Transactor: Send XCM messages to other parachains. Address: 0x000000000000000000000000000000000000080b. Used to call extrinsics on other parachains (e.g., transfer assets to Acala, trigger operations on other Polkadot chains).

X-Tokens: Transfer assets to other parachains. Address: 0x0000000000000000000000000000000000000804. Handles multi-asset transfers using Polkadot’s XCM asset format.

Relay Encoder: Encode Relay Chain operations. Address: 0x0000000000000000000000000000000000000805. Needed to construct Relay Chain extrinsics for operations like staking on the Relay Chain from Moonbeam.

From an RPC perspective, calling a precompile looks identical to calling any EVM contract:

// Example: check XCM channel status via eth_call on a precompile
const xcmInterface = new ethers.Interface([
  "function transferMultiAsset(tuple(uint8 parents, bytes[] interior) dest, tuple(tuple(uint8 parents, bytes[] interior) id, tuple(uint8 tokenType, uint256 amount) fun) asset, uint64 weight) external"
]);

// Encode the call
const calldata = xcmInterface.encodeFunctionData("transferMultiAsset", [...]);

// Execute via standard eth_call
const result = await provider.call({
  to: "0x0000000000000000000000000000000000000804",
  data: calldata
});

Parachain Finality Model

Understanding Moonbeam’s finality model prevents common confirmation logic errors.

Block inclusion: A transaction included in a Moonbeam block has eth_getTransactionReceipt status = 1. This is equivalent to Ethereum’s “included” state.

Parachain confirmation: Moonbeam’s collator has accepted the block. This is fast (within the 12-second block window).

Relay Chain finality: Polkadot’s Relay Chain has finalized the Moonbeam block. This takes one to two Relay Chain slots (12-24 seconds) after Moonbeam block production. Use moon_isBlockFinalized to check this status.

For most DeFi operations, parachain confirmation is sufficient. For bridge operations, cross-chain transfers, or any operation that generates XCM messages to other parachains, wait for Relay Chain finality before considering the operation complete.

Production Issues on Moonbeam

XCM event parsing complexity. XCM operations that span multiple parachains generate receipt logs with multiple nested events. Standard eth_getTransactionReceipt returns these events, but parsing them requires understanding both EVM log encoding and XCM event structures. The Moonbeam documentation provides ABI definitions for each precompile’s events. Index by address (the precompile address) and topics[0] (the event signature hash).

Log range limits on public nodes. Public Moonbeam nodes cap eth_getLogs range at 1,024 blocks. Because Moonbeam produces approximately 5 blocks per minute, this covers roughly 3.4 hours of history per query. For longer historical lookups, paginate with consecutive block ranges.

Polkadot collator upgrades. Moonbeam is a parachain and receives runtime upgrades through Polkadot governance. Upgrades can change gas mechanics, add precompile addresses, or modify XCM behavior. Monitor the Moonbeam changelog before production deployments. Runtime upgrades do not require infrastructure changes on your side but may change call behavior.

GLMR balance for gas. All Moonbeam transactions require GLMR for gas, including XCM operations initiated through precompiles. Ensure your sending wallets have GLMR for gas regardless of which asset the XCM message is transferring.

Moonbeam vs Moonriver Deployment Pattern

The standard Polkadot parachain deployment pattern:

Deploy and test on Moonriver (Kusama canary, chain ID 1285)
Validate behavior, especially XCM integrations
Deploy identical code to Moonbeam (Polkadot production, chain ID 1284)

With BoltRPC, switching environments requires changing one environment variable:

const CHAIN_ENDPOINTS = {
  moonriver: "https://eu.endpoints.matrixed.link/rpc/moonriver?auth=YOUR_KEY",
  moonbeam:  "https://eu.endpoints.matrixed.link/rpc/moonbeam?auth=YOUR_KEY"
};

const provider = new ethers.JsonRpcProvider(
  CHAIN_ENDPOINTS[process.env.CHAIN_ENV || "moonriver"]
);

Chain IDs for validation:

Moonriver: 1285
Moonbeam: 1284

Choosing a Moonbeam RPC Provider

Consideration	What to Look For
Custom method support	`moon_isBlockFinalized`, `moon_isTxFinalized` must work
WebSocket for XCM events	Cross-chain event monitoring needs persistent connections
Both Moonbeam + Moonriver	Single provider for both simplifies multi-env deployments
Parachain expertise	Provider should understand Polkadot infrastructure, not just EVM
Flat pricing	XCM apps generate more calls than standard EVM apps

For dedicated Moonbeam and Moonriver RPC: BoltRPC Moonbeam endpoint.

Moonbeam RPC FAQ

What are the public Moonbeam RPC endpoints? Official public HTTP: https://rpc.api.moonbeam.network. Official public WSS: wss://wss.api.moonbeam.network. Both are rate limited. For production, use a dedicated provider.

What is moon_isBlockFinalized and when should I use it? moon_isBlockFinalized is a Moonbeam-specific custom RPC method that returns true when a block has been finalized by Polkadot’s Relay Chain. Use it when your application requires confirmed finality rather than just block inclusion. For example, in bridge operations or cross-chain transfers where you need to know the Moonbeam state is irreversible from Polkadot’s perspective.

What is the difference between Moonbeam and Moonriver? Moonbeam is the production parachain on Polkadot (chain ID 1284). Moonriver is its canary network on Kusama (chain ID 1285). New features and protocol upgrades deploy to Moonriver first. Both run real economic activity and real MOVR/GLMR tokens.

What is XCM on Moonbeam? XCM (Cross-Consensus Messaging) is Polkadot’s protocol for passing messages between parachains. On Moonbeam, XCM is accessed through EVM precompiles at fixed addresses. You can send assets and trigger operations on other Polkadot parachains directly from Solidity contracts or from RPC calls.

Why does Moonbeam have 12-second block times? Moonbeam block production is tied to Polkadot’s Relay Chain slot cadence. Parachains produce one block per Relay Chain slot (approximately 12 seconds). This is a structural constraint of the parachain architecture, not a configuration parameter.

Do I need special tooling for Moonbeam or does standard ethers.js work? Standard Ethereum libraries (ethers.js, Web3.py, viem) work with Moonbeam for all standard eth_* methods. The Moonbeam-specific moon_* methods require direct provider.send() calls since they are not part of standard EVM library interfaces.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What are the public Moonbeam RPC endpoints?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Official public HTTP: https://rpc.api.moonbeam.network. Official public WSS: wss://wss.api.moonbeam.network. Both are rate limited. For production use, use a dedicated provider such as BoltRPC."
      }
    },
    {
      "@type": "Question",
      "name": "What is moon_isBlockFinalized and when should I use it?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "moon_isBlockFinalized is a Moonbeam-specific RPC method that returns true when a block has been finalized by Polkadot's Relay Chain. Use it for bridge operations or cross-chain transfers where you need confirmed finality rather than just block inclusion."
      }
    },
    {
      "@type": "Question",
      "name": "What is the difference between Moonbeam and Moonriver?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Moonbeam is the production parachain on Polkadot (chain ID 1284). Moonriver is its canary network on Kusama (chain ID 1285). New features deploy to Moonriver first. Both run real economic activity."
      }
    },
    {
      "@type": "Question",
      "name": "What is XCM on Moonbeam?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "XCM (Cross-Consensus Messaging) is Polkadot's protocol for passing messages between parachains. On Moonbeam, XCM is accessed through EVM precompiles at fixed addresses, letting you send assets and trigger operations on other Polkadot parachains from standard Ethereum tooling."
      }
    },
    {
      "@type": "Question",
      "name": "Why does Moonbeam have 12-second block times?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Moonbeam block production is tied to Polkadot's Relay Chain slot cadence of approximately 12 seconds. This is a structural constraint of the parachain architecture, not a configuration parameter."
      }
    }
  ]
}
</script>

Moonbeam RPC Guide: Endpoints, Methods, Code Examples 2026