What should I know about the peaq network?

When you need a peaq RPC endpoint (and when you do not)

Most developers searching for the peaq network fall into one of three groups: they are evaluating peaq as a settlement layer for a DePIN project, they already have a contract or pallet deployed and need a reliable way to read and write chain state, or they are connecting a wallet or indexer and hit connection problems. The decision that matters is not whether peaq supports RPC — it does, through a Substrate-based JSON-RPC interface — but how you will access that interface in production.

If you are prototyping, a public endpoint is usually enough to deploy a contract, query balances, and test extrinsics. If you are running a backend service, an indexer, or a device fleet that submits transactions continuously, you will want either a managed RPC provider or a dedicated node. The tradeoff is operational: a public endpoint is free but shared and rate-limited, a managed endpoint is paid but monitored and supported, and a dedicated node gives you isolated capacity at the cost of running the infrastructure yourself or paying a provider to run it for you.

This article explains what peaq is, how its RPC interface works, how to connect, and how to decide between public, managed, and dedicated access. It does not assume you already know Substrate tooling.

What the peaq network actually is

peaq is a Layer-1 blockchain designed for Decentralized Physical Infrastructure Networks — networks of machines, sensors, vehicles, and robots that need to identify themselves, transact, and be rewarded without a central operator. Where a general-purpose chain treats devices as ordinary accounts, peaq builds machine-focused primitives into the protocol layer.

The most relevant primitives for developers are:

• Self-sovereign machine identity. Devices can hold a decentralized identifier (DID) and prove ownership or control without a centralized registry.
• Machine NFTs and tokenized assets. Physical assets can be represented on-chain so they can be financed, leased, or shared.
• Autonomous transaction flows. Machines can pay each other for data, energy, or compute using the network's native token.
• Substrate-based runtime. peaq is built with Substrate, which means it exposes the standard Substrate JSON-RPC surface alongside EVM-compatible tooling where supported.

Because peaq is Substrate-based, the RPC interface is not identical to an Ethereum node. You will see methods like chain_getHeader, state_getStorage, and author_submitExtrinsic rather than eth_getBlockByNumber alone. If your application assumes an Ethereum-shaped RPC, check which compatibility layer you are targeting before you write integration code.

Chain settings at a glance

Before you connect, confirm the network parameters for the environment you are targeting. peaq has both a mainnet and a testnet (agung), and mixing them is one of the most common sources of confusing errors.

If you are not sure which environment you need, start on the testnet. Deploy, test your extrinsic flow, and only move to mainnet once your integration is stable. OnFinality lists peaq among its supported RPC networks, and the peaq network page is the canonical place to confirm current endpoint details.

Connecting to peaq: configuration and code

Substrate tooling typically connects through Polkadot.js, Substrate RPC libraries, or a WebSocket endpoint. The pattern below shows a minimal connection and a balance query using Polkadot.js. Replace the endpoint placeholder with the endpoint from your provider or the peaq network page.

import { ApiPromise, WsProvider } from '@polkadot/api';

// Use the WebSocket endpoint issued by your RPC provider.
const provider = new WsProvider('wss://<your-peaq-endpoint>');
const api = await ApiPromise.create({ provider });

const [chain, nodeName, nodeVersion] = await Promise.all([
  api.rpc.system.chain(),
  api.rpc.system.name(),
  api.rpc.system.version(),
]);

console.log(`Connected to ${chain} via ${nodeName} v${nodeVersion}`);

// Query the balance of an SS58 address.
const { data: { free } } = await api.query.system.account('<SS58_ADDRESS>');
console.log(`Free balance: ${free.toHuman()}`);

For a quick connectivity check without installing dependencies, a curl request against the HTTP endpoint confirms the node is reachable and responding:

curl -sS -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"system_chain","params":[]}' \
  https://<your-peaq-endpoint>

A healthy response returns the chain name. If you get a connection error, the endpoint is wrong or unreachable; if you get a JSON-RPC error, the method is unsupported on that node. That distinction saves time when you are debugging.

Production readiness checklist

Moving from a testnet prototype to a live DePIN workload changes what you need from an endpoint. Work through this list before you ship:

1. Separate read and write paths. Indexers and dashboards should not compete with transaction submission for the same connection budget.
2. Use WebSocket for events. Device state changes and extrinsic confirmations are easier to track through subscriptions than polling.
3. Plan for reconnects. Long-lived WebSocket connections drop. Your client should reconnect and re-subscribe automatically.
4. Monitor block height. A stalled block-height metric is the fastest signal that your endpoint has fallen behind.
5. Keep a fallback endpoint. If your primary provider has an incident, a second endpoint prevents a full outage.
6. Confirm archive needs. If you query historical state, verify the endpoint serves archive data rather than only recent blocks.
7. Test with realistic load. A device fleet submitting transactions behaves differently from a single test script.

If any of these items are hard to satisfy with a public endpoint, that is the signal to move to managed or dedicated infrastructure. OnFinality's RPC API service and dedicated node options are built for exactly this transition.

Public, managed, and dedicated access compared

There is no single correct way to access peaq. The right choice depends on how much control and reliability you need versus how much operational work you want to absorb.

OnFinality is listed first here because it is the option this site operates; the comparison is meant to be factual rather than promotional. The key question is not which row is "best" but which row matches your workload. A hackathon project and a fleet of 10,000 devices have very different requirements.

Where peaq integrations usually break

Most peaq RPC problems are not exotic. They cluster around a few recurring causes:

• Wrong network. A mainnet address queried against a testnet endpoint returns an empty balance, which looks like a bug but is a configuration error.
• HTTP used for subscriptions. Substrate subscriptions require WebSocket. If your event listener never fires, check the transport first.
• Address format mismatch. SS58 and EVM-style addresses are not interchangeable. Validate the format before submitting.
• Rate limiting on shared endpoints. Bursty workloads against a public endpoint get throttled, which surfaces as intermittent timeouts.
• Stale or non-archive nodes. Historical queries against a pruned node fail even though recent queries succeed.
• Unhandled reconnects. A dropped WebSocket that is never re-established makes a healthy service look dead.

A useful debugging habit is to isolate the layer. Run the curl check above against your endpoint. If it succeeds, the problem is in your client or your request. If it fails, the problem is the endpoint or the network. That single test eliminates half of the possible causes.

Choosing an RPC provider for peaq

If you decide to use a managed provider, evaluate candidates on the criteria that actually affect a DePIN workload rather than on headline numbers.

• Transport support. Confirm both HTTP and WebSocket are available, since subscriptions are central to device-state tracking.
• Archive availability. If you need historical state, ask explicitly. Not every provider serves archive data.
• Method coverage. Verify the Substrate methods you depend on are exposed, especially any custom runtime methods.
• Failover and redundancy. Ask how the provider handles node failures and whether you can configure a fallback.
• Observability. You want metrics you can alert on, not just a status page.
• Support model. For production DePIN, a support channel with real response expectations matters more than a small price difference.

For a broader framework, see how to choose an RPC provider. For cost planning, review RPC pricing and match the plan tier to your expected request and subscription volume.

Key Takeaways

• peaq is a Substrate-based Layer-1 built for DePIN and machine economies, with machine identity, tokenized assets, and autonomous transaction primitives.
• Its RPC interface is Substrate-shaped, so Ethereum-only assumptions will not transfer cleanly.
• Use WebSocket for subscriptions, HTTP for request/response, and always confirm whether you are on mainnet or the agung testnet.
• Public endpoints suit prototyping; managed RPC and dedicated nodes suit production workloads that need monitoring, support, and isolation.
• Most integration failures come from wrong network, wrong transport, address-format mismatch, or rate limiting — all diagnosable with a single connectivity check.
• OnFinality offers peaq RPC API and dedicated node infrastructure; start from the peaq network page and supported networks.

FAQ

Is peaq EVM-compatible? peaq is Substrate-based and exposes Substrate JSON-RPC methods. EVM compatibility depends on the specific runtime and tooling layer you target, so confirm the method set your application needs against the endpoint you plan to use before building.

Do I need a dedicated node to build on peaq? No. For prototyping and low-volume testing, a public or managed endpoint is sufficient. Dedicated nodes make sense when you need isolated capacity, predictable throughput, or stricter control over the node environment.

Why does my peaq subscription never fire? The most common cause is using an HTTP endpoint where a WebSocket endpoint is required. Substrate subscriptions need a persistent WebSocket connection, and clients should reconnect and re-subscribe if the connection drops.

How do I know if I am on mainnet or testnet? Query the chain name with system_chain and compare it against the network you intended to use. peaq mainnet and the agung testnet are separate networks with separate tokens and state.

Can I use OnFinality for peaq? Yes. OnFinality provides managed RPC API access and dedicated node infrastructure for peaq. Check the peaq network page for current endpoint details and RPC pricing for plan options.