Private Krest RPC Endpoints on a Dedicated Node

Krest is peaq's canary network on Kusama, a decentralized simulation platform for Decentralized Physical Infrastructure Networks (DePIN) and the Economy of Things. It is a live environment where developers test and deploy dApps and DePINs with real value before graduating to peaq mainnet, because Krest mirrors the peaq runtime.

Krest is peaq's canary, or "living", network. It runs the same Substrate-based peaq stack and mirrors the peaq runtime, but as a Kusama parachain rather than a Polkadot one. Teams use Krest to battle-test integrations, then graduate to peaq mainnet. The native token is KRST and the EVM chain ID is 2241.

Yes. Krest supports EVM-based development while its chain design is Substrate-based, like peaq. Your app may need Ethereum-style JSON-RPC for wallets and Solidity contracts, plus Substrate-style access for runtime data. We size and prepare your Krest RPC setup around that mixed workload instead of treating it like a basic EVM-only endpoint.

Public Krest RPC endpoints are useful for testing, light reads, and early builds. Production apps need more control. With RedSwitches, your dedicated Krest RPC node runs on single-tenant hardware with private access rules, NVMe storage, DDoS protection, and a 99.99% infrastructure uptime SLA. You avoid shared endpoint pressure and keep your app's RPC path under your own policy.

Yes. Krest block production relies on collators that group transactions, build blocks, and pass them to Kusama relay-chain validators. We provision single-thread-tuned bare metal for the peaq-node collator with steady uptime and fast recovery via IPMI and KVM. You hold the keys, we run the metal.

Yes. The peaq-node client serves Substrate JSON-RPC and Ethereum JSON-RPC over both HTTP and WSS. With RedSwitches, we can prepare HTTP and WSS access for wallets, dashboards, bots, indexers, and app servers that need live Krest RPC data, and keep them private with IP allowlisting.

You may need an archive Krest RPC node if your product depends on older state, long-range scans, reward reviews, analytics, or audit records. Live app traffic and history-heavy reads should not always share the same node role. We can help you plan archive access as part of a dedicated Krest RPC node setup with separate live and history roles.

Yes. RedSwitches can provide the peaq-node client installed and bring your Krest node online according to sync time. You can choose unmanaged access for full DevOps control or ask us for support around setup, recovery, server resources, and scaling. We also provide free 24/7 technical support for dedicated RPC node customers.

No. Unlike shared RPC providers that bill per "compute unit" and throttle you past a quota, a dedicated node is a flat monthly price with unlimited requests and zero overages. One node equals all the throughput your hardware can serve. That makes budgeting predictable and removes the surprise bills that come with usage-based RPC pricing.

Shared RPC pools serve thousands of customers from pooled infrastructure, so you inherit rate limits, noisy-neighbor latency, and compute-unit billing. A RedSwitches node runs on single-tenant bare metal that is yours alone: reserved CPU, RAM, and NVMe, a dedicated 10/25 Gbps port, and a private endpoint you control. Performance tracks your hardware, not another tenant's traffic.

No. We provision from current snapshots so your node is live in hours rather than syncing from genesis for days. You can run it yourself with full root access, or choose our fully managed option where our engineers handle the sync, updates, and monitoring. Either way you receive a working private endpoint, not an empty server.

Yes. With 20+ Tier III locations across the US, EU, Asia, and Australia you can place your node in the same region as your users or a chain's sequencer to cut round-trip latency. Tell us your target region and we will recommend the closest facility. You can also run multi-region nodes for redundancy and split read and write endpoints.