Polkadex is a Polkadot-based network focused on non-custodial trading, with an on-chain orderbook and a Substrate-style RPC interface. If you are building a wallet, a trading dashboard, a bot, or an indexer, the first practical question is usually the same: which endpoint do I point my app at, and what do I do when calls start failing?
This page answers that quickly, then goes deeper into endpoint selection, wallet configuration, JSON-RPC debugging, and the build-versus-buy decision for node infrastructure. It is written for developers who already know they need to talk to Polkadex and want a reliable path to production.
Quick recommendation: managed RPC vs self-hosted node
Before you write any code, decide how you will reach the chain. That decision affects your latency, maintenance load, and how much of your team's time goes into infrastructure instead of product.
| Situation | Recommended approach | Why |
|---|---|---|
| Prototyping, hackathons, or early testing | Public or shared RPC endpoint | Fastest path to a first successful call; no server to run |
| Production dApp with steady read traffic | Managed RPC API from a provider | Offloads node upgrades, sync, and monitoring |
| High-frequency trading bot or indexer | Dedicated node | Predictable resources and isolated throughput |
| Compliance or data-residency requirements | Self-hosted or dedicated node | Full control over where data and keys live |
| You need archive or trace-style historical data | Provider with archive support | Avoids running and storing a large archive node yourself |
If you are still evaluating providers, a good starting point is our guide on how to choose an RPC provider. If you already know you need isolated capacity, look at dedicated nodes.
What the Polkadex RPC interface actually exposes
Polkadex is built with Substrate, so its RPC surface follows the familiar Substrate/Polkadot.js pattern rather than the Ethereum JSON-RPC method set. In practice you will work with a few method families:
-
Chain and state methods such as
chain_getHeader,chain_getBlockHash, andstate_getMetadatafor reading chain state and metadata. -
Runtime and storage queries through
state_getStorageandstate_getKeys, which underpin most application-level reads. -
Submission methods like
author_submitExtrinsicandauthor_pendingExtrinsicsfor sending and tracking transactions. -
Subscription methods such as
chain_subscribeNewHeadsandstate_subscribeStoragefor real-time updates over WebSocket.
Because the exact method set and runtime metadata change with network upgrades, always fetch current metadata from the node you connect to rather than hardcoding types. Libraries like Polkadot.js and Substrate-based SDKs handle this automatically when you connect to a live endpoint.
Chain settings at a glance
When you configure a wallet or a client, you need the network's identifying details. Use the values below as a checklist, and confirm them against the Polkadex network page before shipping.
| Setting | What to confirm |
|---|---|
| Network name | Polkadex (mainnet) |
| Token symbol | PDEX |
| Address format | SS58, Polkadot ecosystem prefix |
| RPC transport | HTTP(S) for request/response, WebSocket for subscriptions |
| Metadata | Fetch at runtime; do not hardcode |
| Explorer | Use the official Polkadex explorer for transaction lookup |
If your tooling expects an Ethereum-style chain ID, note that Substrate networks do not use one in the same way. Instead, your client identifies the chain by its genesis hash and metadata. Wallets and SDKs that support Substrate will ask for an RPC URL and derive the rest.
Connecting from JavaScript and the command line
Most Polkadex integrations use Polkadot.js or a Substrate client. A minimal connection looks like this:
import { ApiPromise, WsProvider } from '@polkadot/api';
const provider = new WsProvider('wss://your-polkadex-rpc-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}`);
For a quick health check without a full SDK, a raw JSON-RPC call over HTTP is often enough:
curl -s -H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"system_chain","params":[]}' \
https://your-polkadex-rpc-endpoint
A healthy node returns the chain name in the result field. If you get a connection error, the endpoint is unreachable; if you get a method-not-found error, you may be pointed at a node that does not expose the method you need.
Subscriptions and real-time data
Trading interfaces and dashboards usually need live updates rather than polling. Substrate nodes expose WebSocket subscriptions for this purpose:
const unsub = await api.rpc.chain.subscribeNewHeads((header) => {
console.log(`New block: ${header.number}`);
});
Two practical notes for production:
- Reconnect logic is mandatory. WebSocket connections drop. Your client should detect disconnects and resubscribe, ideally with backoff.
- Not every endpoint supports subscriptions. If you connect over HTTP only, subscription methods will fail. Confirm WebSocket support with your provider before designing around live data.
Debugging common Polkadex RPC failures
When something breaks, the error message usually points to one of a few root causes. Use this table to narrow it down quickly.
| Symptom | Likely cause | Next step |
|---|---|---|
| Connection refused or timeout | Wrong URL, endpoint down, or network blocked | Verify the URL and try a second endpoint |
Method not found |
Node does not expose that RPC method | Check provider method support or switch endpoint |
| Metadata or type errors | Client types out of date after a runtime upgrade | Re-fetch metadata and update SDK |
| Transactions stuck pending | Low fee, nonce gap, or node not propagating | Check author_pendingExtrinsics and resubmit |
| Subscription stops silently | WebSocket dropped | Add reconnect and resubscribe logic |
| Inconsistent reads across endpoints | Nodes at different block heights | Pin reads to a specific block hash |
A useful habit is to log the block hash alongside every read. When two endpoints disagree, the block hash tells you whether you are looking at a sync lag problem or a genuine data difference.
Production readiness checklist
Before you move from testing to production, walk through these items. They catch most of the issues that surface only under real traffic.
- Endpoint redundancy: configure at least two RPC endpoints and fail over automatically.
- Rate and load behavior: understand your provider's request limits and how your app behaves when it hits them.
- Archive needs: if you query historical state, confirm the endpoint serves archive data.
- WebSocket support: required for subscriptions; verify it is enabled.
- Monitoring: track request success rate, latency, and error types, not just uptime.
- Key management: never embed private keys in frontend code; sign server-side or in the wallet.
- Upgrade handling: treat runtime metadata as dynamic and test against new versions.
OnFinality provides RPC API access and dedicated node infrastructure for Polkadex and many other networks. You can review RPC pricing and the full list of supported RPC networks to see what fits your workload.
Evaluating an RPC provider for Polkadex
If you decide not to run your own node, the provider you pick becomes part of your stack. Compare candidates on the dimensions that actually affect your application.
| Provider | Method coverage | Archive & trace | WebSocket | Dedicated option | Notes |
|---|---|---|---|---|---|
| OnFinality | Substrate RPC methods for supported networks | Available depending on network and plan | Supported | Yes | RPC API plus dedicated nodes; see api-service |
| Provider B | Varies by network | Often limited on shared tiers | Sometimes | Sometimes | Confirm before relying on it |
| Provider C | Varies | Varies | Varies | Rarely | Check method support per network |
When you evaluate, ask concrete questions: Which RPC methods are exposed? Is archive data available? Is WebSocket supported? What happens when you exceed your plan? Can you get an isolated node if shared throughput is not enough? The answers matter more than a headline number.
When to move to a dedicated node
Shared RPC endpoints are efficient for most read-heavy applications. But some workloads outgrow them:
- Trading bots that need consistent, low-variance response times.
- Indexers that scan large ranges of blocks and state.
- Applications with strict isolation needs, where noisy-neighbor effects are unacceptable.
- Teams that want predictable capacity rather than shared pools.
A dedicated node gives you isolated resources and more control over configuration. The tradeoff is cost and the operational work of running it, which is why many teams start on a managed RPC API and move to dedicated capacity only when their traffic justifies it. See dedicated nodes for how that option works.
Key Takeaways
- Polkadex uses a Substrate-style RPC interface, so plan around Substrate methods and runtime metadata rather than Ethereum JSON-RPC.
- Choose your access method early: shared RPC for most apps, dedicated nodes for high-frequency or isolated workloads.
- Always configure more than one endpoint and build failover into your client.
- Fetch metadata at runtime and keep SDK types current to survive runtime upgrades.
- Log block hashes with reads to distinguish sync lag from real data differences.
- Confirm archive, trace, and WebSocket support with your provider before designing around them.
Frequently Asked Questions
Does Polkadex use Ethereum-style JSON-RPC?
No. Polkadex is a Substrate-based network, so its RPC surface follows the Substrate/Polkadot.js method set. If your tooling assumes Ethereum methods, you will need a Substrate-compatible client.
Can I use a public RPC endpoint for production?
Public endpoints are fine for testing and light use, but production applications generally benefit from a managed RPC API or dedicated node with clearer capacity and support expectations.
Why do my transactions stay pending?
Common causes include insufficient fees, a nonce gap, or a node that is not propagating transactions well. Check pending extrinsics and consider switching endpoints.
Do I need an archive node?
Only if you query historical state or scan old blocks. If you do, confirm archive support with your provider, since not every shared endpoint serves it.
How do I handle runtime upgrades?
Treat metadata as dynamic: fetch it at connection time and update your SDK regularly. Hardcoded types are the most common cause of post-upgrade breakage.
Where can I see which networks OnFinality supports?
The supported RPC networks page lists current networks, and RPC pricing covers plan options.
Related resources
Originally published at OnFinality.
Top comments (0)