Dedicated RPC nodes and private endpoints, explained.

What is a dedicated RPC node?

A dedicated RPC node is a physical server that runs a blockchain client exclusively for you. Your applications talk to the chain through it: reading state, streaming events, sending transactions. Nobody else's traffic touches the machine, so its full throughput, every RPC method, and every open connection belongs to your workload alone.

The alternative is shared RPC: a provider runs a cluster and sells thousands of customers slices of it. To keep the cluster alive, they must meter everyone, which is why shared plans come with requests-per-second tiers, connection caps, credit systems, and "premium method" surcharges for heavy calls like debug_ and trace_.

A dedicated node has none of that, because none of it is needed. There is one tenant. If the hardware can serve it, you can send it.

What is a private RPC endpoint?

A private RPC endpoint is the address your applications call, served by a node nobody else uses. A public or shared endpoint is one cluster answering thousands of customers, which is why it is rate limited. A private endpoint on a dedicated node answers only your applications: on your own domain if you want one, locked to the IP addresses you allowlist, with no rate limit because there is nobody to share with.

Some providers call a personal API key on a shared cluster a "private endpoint". That is a private key to a shared machine. Ask which one you are buying.

When shared RPC stops making sense

Shared endpoints are the right choice for prototypes and small apps. They stop making sense at a predictable set of moments:

• You get rate limited at the worst time. Trading bots and MEV searchers lose exactly the transactions that mattered.
• Backfills eat your credit budget. Indexers running archive queries burn through metered plans in days.
• Connection caps break real-time UX. Wallets and dApps hit WebSocket limits as usage grows.
• The bill scales with your success. Per-request pricing means growth is punished, not rewarded.
• The provider refuses your chain. Shared clusters only exist for chains with mass demand.

Any one of these is the signal to move. At sustained volume, a flat-price dedicated node is usually cheaper than the metered bill it replaces, and it is always faster.

What to demand from a dedicated node provider

"Dedicated" is used loosely in this market. Some providers sell virtualised slices or managed servers that still carry plan caps. Before you pay anyone, including us, demand:

• Bare metal, single tenant. Not a VM, not a "dedicated cluster" shared with anyone.
• No artificial limits. No requests-per-second tiers, no connection caps, all methods enabled.
• Measured, not promised. Live p50/p99 latency for the actual machine, in your dashboard.
• Your configuration. Choice of client, sync method, and workload tuning.
• One flat price. If trace calls, support, or your own domain cost extra, it is a meter with better marketing.

This checklist is our spec sheet. Every Argusnodes node passes it by construction: see what others cap, meter, or refuse.

How an Argusnodes dedicated node works

You pick the chain and the node type: full, archive, or validator. You choose the client, sync method, and tuning for your workload (bot and MEV focused, transaction-heavy, or indexing), plus the city it deploys in. We build the machine, sync it, tune it, and hand you the endpoint on your own domain with IP allowlisting, live p50/p99 latency in your dashboard, and humans on call 24/7.

Pricing is a flat monthly figure from four standard bands, starting at $99 and topping out at $999 for Solana's own hardware class. Every capability is included in the band price. See the pricing sheet for the full system.

Prefer to own the hardware yourself? We also run nodes on your machines: see bring your own hardware.