What is the peaq mainnet RPC endpoint?

peaq is an EVM-compatible Layer-1 blockchain built on Substrate and connected to the Polkadot ecosystem. It is designed for DePIN (decentralized physical infrastructure networks) and machine-oriented applications, but from an RPC perspective it behaves like a standard EVM chain with chain ID 3338 and the native PEAQ token. This article covers the peaq mainnet RPC setup, chain settings, JSON-RPC examples, endpoint selection, and common issues you may hit when connecting wallets or backend services.

peaq mainnet RPC decision checklist

Before you add peaq to your wallet or wire peaq RPC into your backend, run through the following list:

• Confirm the chain ID is 3338 (0xd0a). A wrong chain ID will cause transaction signing errors in wallets and libraries.
• Use HTTPS for JSON-RPC over HTTP and WSS for WebSocket subscriptions. Plain HTTP and WS should only be used in local testing.
• Prefer a managed endpoint or dedicated node for production traffic instead of a shared public URL. Public URLs can be rate-limited or changed without notice.
• Verify that the endpoint supports the Ethereum JSON-RPC methods you need, such as eth_chainId, eth_blockNumber, eth_getLogs, and eth_sendRawTransaction.
• Check whether you need Substrate-specific methods. peaq runs on Substrate, so some providers also expose methods such as chain_getBlock and chain_getFinalizedHead.
• Test your app's request pattern before launch. Large eth_getLogs queries, repeated polling, and WebSocket subscriptions all affect endpoint behavior.
• Decide whether you need archive data. If your application reads historical balances or past events, you may need an archive node or an archive-capable RPC plan.
• Monitor latency, error rates, and failover behavior. A single RPC URL can be a bottleneck in production.

What is peaq mainnet?

peaq is a Layer-1 network that supports the "Economy of Things" by giving machines and physical infrastructure a place to register identities, transact, and monetize data. The network is built with Substrate and operates as a Polkadot parachain. It provides two execution environments: EVM smart contracts written in Solidity and Substrate pallets written in Rust.

For developers, this dual execution model means peaq mainnet RPC is not only an Ethereum-compatible JSON-RPC endpoint. The same node can expose Polkadot-style JSON-RPC methods. In practice, most EVM tooling works out of the box: Hardhat, Foundry, ethers.js, viem, and MetaMask can all interact with peaq once you configure the correct network settings. If you are working with Substrate-based tooling, you can also query the chain using RPC methods from the Polkadot API ecosystem.

peaq mainnet chain settings at a glance

The table below lists the settings you are most likely to need when adding peaq to a wallet, indexer, or middleware service.

You can verify the current list of public endpoints and chain metadata in aggregators such as ChainList, but always confirm the endpoint against the network's official documentation before you use it in production.

How to connect to peaq mainnet RPC

The simplest way to test a peaq RPC endpoint is to send a JSON-RPC request and compare the returned chain ID. A curl request looks like this:

curl -sS -X POST https://peaq.api.onfinality.io/public -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

If the endpoint is healthy, the response contains "result":"0xd0a", which is the hexadecimal representation of 3338.

You can do the same check in JavaScript with ethers.js:

import { ethers } from "ethers";

const provider = new ethers.JsonRpcProvider("https://peaq.api.onfinality.io/public");
const network = await provider.getNetwork();
console.log(network.chainId.toString()); // 3338

For production applications, replace the public URL with an endpoint from your RPC provider account. Managed providers typically give you an API key and a dashboard where you can monitor usage and rotate the key when needed.

What should you check before using a peaq mainnet RPC endpoint

A working endpoint is the bare minimum. Before you rely on it, check how it behaves under the workload your application will actually create.

Method coverage

peaq supports both Ethereum and Substrate style RPC methods. A provider might expose the full Ethereum JSON-RPC surface, or it might only expose a subset. If your application calls eth_subscribe for pending transactions or event logs, confirm the provider supports that method over WSS. If your application needs Substrate methods, confirm those are also available.

Archive and trace support

Archive nodes keep historical state, which is useful for indexers, analytics, and dapps that display historical balances. Not every peaq RPC endpoint provides archive data. If you know your application will query past state, choose a provider that offers archive or trace-capable nodes. Trace methods are less common on peaq RPC, so verify availability before building features that depend on them.

WebSocket reliability

Wallets and real-time dashboards rely on WebSocket connections to receive new blocks, logs, and transaction confirmations. A stable WSS endpoint is as important as the HTTPS endpoint. If you only test with curl, you might miss connection drops, high reconnection rates, or subscription limits that only appear under sustained use.

Rate limits

Shared or public RPC endpoints often answer many requests from many users at once. Under load, you may see HTTP 429 responses or connection throttling. Managed RPC providers offer higher limits and clearer usage metrics, while a dedicated node gives you an endpoint that is not shared with other workloads.

Public RPC, managed RPC, or dedicated node for peaq?

Your choice depends on whether you are prototyping, running a small production app, or operating infrastructure with tight control requirements.

• Public RPC endpoints are useful for quick tests, tutorials, and local development. They are not a stable foundation for production because their availability and limits can change.
• A managed RPC API, such as the OnFinality RPC API, gives you a hosted endpoint with API key management, usage monitoring, and network-specific configuration. This is a good middle ground for teams that want to avoid node operations.
• A dedicated node gives you an isolated peaq node that you can use for data-heavy workloads, archive queries, custom tuning, and scenarios where you do not want to share infrastructure with other projects. OnFinality offers dedicated node provisioning for teams that need this level of control.

You can compare the current options on the RPC pricing page and see which networks are covered on the supported networks page. For peaq specifically, the peaq network page lists current endpoint options and connection details.

Debugging common peaq RPC issues

Even with the correct chain settings, you may hit issues when connecting to peaq mainnet. Here are common failure modes and how to approach them.

Wrong chain ID in the wallet or SDK

If your transaction signing fails or the wallet shows the wrong network, check the chain ID. peaq mainnet is 3338. Some tools accept the chain ID in hex, for example 0xd0a. Be careful not to use the peaq testnet chain ID by mistake.

HTTP 429 or rate limiting

When a request fails with 429 Too Many Requests, the endpoint is throttling your traffic. Reduce batch sizes, add backoff, or move to a managed/dedicated provider. Public endpoints should not be treated as unlimited infrastructure.

Timeouts on eth_getLogs

Querying logs over a wide block range can time out, especially on a shared endpoint. Use smaller block ranges and run the query in parallel, or use an indexer if the app regularly needs large log scans.

WebSocket disconnects

WebSocket connections can drop due to network changes, idle timeouts, or provider limits. Implement a reconnection strategy with exponential backoff and subscribe to a WSS endpoint that supports your use case.

Missing Substrate RPC methods

If a tool expects chain_getBlockHash or similar Substrate methods, confirm the endpoint is a Substrate-compatible peaq node. Some providers expose only the EVM surface; in that case, use a provider that exposes both surfaces.

Using OnFinality for peaq mainnet RPC

OnFinality provides hosted RPC infrastructure for peaq and many other networks. If you need a peaq mainnet RPC endpoint without operating your own node, you can create an API key and use the managed RPC API. OnFinality also offers dedicated nodes for teams that need isolated infrastructure for archive queries, high request volumes, or custom requirements. The exact capabilities and plans are documented on the peaq network page and the RPC pricing page.

Because peaq is a Substrate-based chain with EVM compatibility, you may want to use both Ethereum JSON-RPC methods and Substrate methods in the same application. OnFinality supports the network through its general RPC API service and dedicated node service. Check the network page for current endpoint formats and access details before you start.

Key Takeaways

• peaq mainnet uses chain ID 3338 and the native token PEAQ.
• You can connect with standard Ethereum JSON-RPC tools because peaq is EVM-compatible.
• WSS is necessary for real-time subscriptions; HTTPS is sufficient for request/response calls.
• Public endpoints are fine for testing, but production workloads should use a managed RPC provider or dedicated node.
• Verify endpoint method coverage, archive support, and rate limits before you scale.
• OnFinality provides managed RPC and dedicated node options for peaq; check the network page for current details.

Frequently Asked Questions

What is the peaq mainnet RPC chain ID?

The peaq mainnet chain ID is 3338, which is 0xd0a in hexadecimal.

Is peaq mainnet EVM-compatible?

Yes. peaq is built on Substrate but supports the Ethereum JSON-RPC API, so EVM wallets and SDKs can connect to it with the right chain settings.

What token is used for gas on peaq mainnet?

The native PEAQ token is used for gas and value transfers on peaq mainnet.

Can I use a public peaq RPC endpoint in production?

Public endpoints are okay for testing, but they are shared and may be rate-limited. For production, use a managed RPC service or a dedicated node so you have stable access and clear usage limits.