When did peaq mainnet launch, and what does it mean for your 2025 build?

What the peaq mainnet launch actually changed for builders

peaq's mainnet went live in 2024, which is the short answer most people are looking for. The longer answer is more useful if you are shipping a DePIN application: the launch moved peaq from a testnet-only environment into a production Layer 1 where device identities, machine payments, and DePIN primitives run against real state.

Before mainnet, most peaq development happened on the Agung testnet. Agung is still useful for contract testing, faucet-funded experiments, and CI pipelines, but it is not where production traffic lives. Once mainnet launched, the practical question for teams shifted from "can I deploy this?" to "can my RPC layer keep up with device-scale request volume?"

DePIN workloads look different from typical DeFi traffic. A fleet of sensors, vehicles, or robots may emit many small reads and writes continuously rather than bursts of large transactions. That pattern puts steady pressure on your endpoint, and it is the main reason peaq builders should think about node infrastructure early rather than after their first traffic spike.

Quick recommendation: public endpoint or dedicated node?

Use this as a starting filter before you read the rest of the page.

If you are still deciding, start on a public endpoint, measure your real request mix, then move to dedicated infrastructure when your traffic becomes predictable enough to size. OnFinality offers both RPC API access and dedicated nodes, so you can start small and scale the same network without changing your application code.

peaq mainnet timeline in context

The launch did not happen in isolation. It was the end of a multi-stage process that most DePIN teams watched closely.

• Testnet phase (Agung). Agung served as the public testing ground for peaq's DePIN modules, parachain-style tooling, and early machine identity work. Teams used it to validate contracts and integrations before mainnet existed.
• Mainnet launch (2024). peaq mainnet opened for production deployment, giving DePIN projects a live network for device registration, machine-to-machine payments, and tokenized machine economies.
• 2025 and beyond. The focus for most teams has moved to scaling: more devices, more frequent state updates, and more demanding read patterns. This is where RPC and node choices start to matter more than the launch date itself.

If you are reading this in 2025 and wondering whether peaq is "ready," the more useful framing is that the network is live and the operational burden has shifted to your infrastructure choices.

Chain settings for connecting to peaq

Exact chain metadata such as chain ID, native currency, and explorer URLs should always be confirmed against the peaq network page before you hardcode anything, because these values can be updated. The pattern below shows how a typical EVM-style network configuration is structured; treat it as a template and fill in the current values from the network page.

{
  "chainName": "peaq",
  "rpcUrls": ["<your OnFinality peaq endpoint>"],
  "nativeCurrency": {
    "name": "peaq",
    "symbol": "PEAQ",
    "decimals": 18
  },
  "blockExplorerUrls": ["<explorer URL from the peaq network page>"]
}

For a wallet or dapp network switcher, the same values go into the wallet_addEthereumChain call. Keep the endpoint in an environment variable rather than committing it, and use a separate value for testnet so a misconfigured build cannot accidentally write to mainnet.

// Example: add peaq to an EVM wallet
await window.ethereum.request({
  method: "wallet_addEthereumChain",
  params: [{
    chainId: "0x...", // confirm current chain ID on the peaq network page
    chainName: "peaq",
    nativeCurrency: { name: "peaq", symbol: "PEAQ", decimals: 18 },
    rpcUrls: [process.env.PEAQ_RPC_URL],
    blockExplorerUrls: ["<explorer URL>"]
  }]
});

Verifying your endpoint before you ship

A launch date does not tell you whether your endpoint is healthy today. Run a few basic checks against your chosen RPC URL before you point production traffic at it.

# Confirm the chain is reachable and check the reported chain ID
curl -s -X POST "$PEAQ_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

# Check the latest block so you can confirm the node is synced
curl -s -X POST "$PEAQ_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

If eth_chainId returns a value that does not match the current peaq mainnet chain ID, you are almost certainly pointed at a testnet or a stale configuration. If eth_blockNumber lags noticeably behind a public explorer, the node may be syncing or degraded. Both are worth catching in staging rather than in production.

What DePIN traffic does to a shared endpoint

Most RPC troubleshooting advice assumes bursty traffic: a user opens a wallet, sends a transaction, and leaves. DePIN apps often behave differently.

• Continuous reads. Device dashboards and telemetry views may poll balances, device state, or events on a fixed interval across many devices.
• Many small writes. Machine-to-machine payments and identity updates can produce a high count of small transactions rather than a few large ones.
• Long-lived connections. If you use WebSocket subscriptions for device events, connection stability matters as much as raw throughput.
• Historical lookups. Audits, reward calculations, and analytics may need state from blocks well in the past.

A shared public endpoint can handle early-stage versions of all of these. The friction usually appears when device count grows and your request pattern becomes predictable enough that you can no longer treat it as "just some traffic." That is the point where dedicated capacity, clearer rate terms, and archive or trace support become worth evaluating.

Choosing an RPC provider for a peaq production app

When you compare providers for a DePIN workload, the launch date is irrelevant and the operational terms are everything. Use the criteria below as an evaluation matrix rather than a feature checklist.

OnFinality provides peaq RPC through its API service and offers dedicated node options when you need more predictable capacity. You can review RPC pricing and the full list of supported RPC networks to see how peaq fits alongside the other chains you run. For a broader framework, the RPC provider selection guide walks through the same criteria in more depth.

Migration checkpoints: from testnet to mainnet

If you built on Agung before mainnet and are now moving to production, work through these checkpoints in order.

1. Separate your environments. Use distinct endpoints and environment variables for Agung and peaq mainnet. Never let a test build inherit a mainnet URL.
2. Re-verify chain settings. Chain ID, explorer URL, and currency metadata should be re-checked against the peaq network page rather than copied from an old testnet config.
3. Re-deploy and re-verify contracts. Addresses do not carry over between networks. Confirm deployment and initialization on mainnet.
4. Re-test your read paths. Dashboards, indexers, and bots that worked on testnet may hit different rate or history limits on mainnet.
5. Add a failover endpoint. Configure a secondary RPC URL and test that your app degrades gracefully if the primary is unavailable.
6. Instrument before you scale. Add basic monitoring for request count, error rate, and latency so you can size capacity with data.

Common pitfalls after launch

A few mistakes show up repeatedly once teams move to mainnet.

• Hardcoding a public endpoint. Public endpoints are fine for development but should not be the only URL in a production config.
• Assuming testnet history exists on mainnet. State and logs from Agung do not exist on peaq mainnet; any historical logic must be rebuilt from mainnet data.
• Ignoring WebSocket reconnection. Long-lived subscriptions need reconnect and resubscribe logic, or your device dashboard will silently stop updating.
• Sizing for average, not peak. Device fleets often have synchronized reporting windows. Size for the peak, not the mean.
• Skipping archive planning. If you need old state for rewards or audits, confirm archive support before you commit to a provider.

Key Takeaways

• peaq mainnet launched in 2024, ending the testnet-only phase and opening the network for production DePIN deployments.
• Agung remains useful for testing, but mainnet is where production device traffic belongs.
• The launch date is a starting point; the operational decision that matters now is your RPC and node setup.
• Public endpoints suit prototyping; steady DePIN traffic usually justifies dedicated capacity and clearer rate terms.
• Verify chain settings against the peaq network page and keep testnet and mainnet endpoints strictly separate.
• OnFinality offers peaq RPC through its API service and dedicated nodes, with details on RPC pricing and supported networks.

Frequently Asked Questions

When did peaq mainnet launch?

peaq mainnet went live in 2024. If you need the exact date for a specific integration or audit, confirm it against peaq's official channels, since this page focuses on what the launch means for developers rather than serving as an official announcement.

Is peaq mainnet available in 2025?

Yes. The network is live in 2025, and most teams building on peaq today are focused on scaling device traffic rather than waiting for launch.

What is the difference between peaq mainnet and Agung?

Agung is peaq's testnet, used for development and testing with faucet-funded accounts. Mainnet is the production network where real value and real device identities live. They have separate chain settings and separate state.

Can I use a public RPC endpoint for a production peaq app?

You can start there, but production DePIN workloads with steady device traffic usually benefit from dedicated capacity and clearer rate and concurrency terms. Measure your request pattern first, then size accordingly.

Does OnFinality support peaq?

Yes. OnFinality provides peaq RPC access through its API service and offers dedicated node options. See the peaq network page and RPC pricing for current details.

What should I check first when connecting to peaq mainnet?

Confirm the current chain ID and endpoint against the peaq network page, run an eth_chainId and eth_blockNumber check, and make sure your testnet and mainnet configurations cannot be mixed up.