HTTP · WS

Solana RPC, tuned for trading.

Performance-tuned RPC over HTTP and WebSocket - co-located with the cluster, single-tenant on dedicated, and never throttled by credit math.

Read the RPC docs →

OVERVIEW

rpc edge runs Solana JSON-RPC over HTTP and WebSocket on infrastructure racked beside Solana stake clusters and the Jito Block Engine. It is the read-and-write workhorse of your stack: account lookups, program scans, simulations, subscriptions, and transaction submission.

Where public and shared endpoints add hops, rate limits, and unpredictable latency, our nodes are tuned end to end - kernel, network stack, and RPC layer - so your reads return fast and your writes reach the leader.

packet-race → current leader 0 HOPS · CO-LOCATED

// the co-located packet reaches the leader first - illustrative

CAPABILITIES

What it does.

HTTP + WebSocket

The full JSON-RPC surface over HTTP, plus WebSocket subscriptions for accounts, logs, and signatures.

No credit counting

Plans are scoped to throughput, not opaque per-method credits - so getProgramAccounts doesn't quietly cost 5x.

Co-located, low-hop

Racked beside stake clusters and the Jito Block Engine, so the distance between you and the cluster is as short as physics allows.

Single-tenant option

On dedicated, your RPC runs on private bare-metal - your tail latency and jitter are yours alone.

rpc.ts
// read and write over the same co-located endpoint
const account = await rpcedge.getAccountInfo(PUBKEY, {
  commitment: "processed",
});

const sig = await rpcedge.sendTransaction(tx, {
  skipPreflight: true,
  maxRetries: 0, // you own the retry loop
});

WHY rpc edge

Latency is a location problem.

01

Co-located by design

Our nodes are racked beside Solana stake clusters and the Jito Block Engine. Fewer hops, less distance, lower latency - physics, not promises.

02

Shreds from many sources

We aggregate shreds across multiple upstreams and serve whichever arrives first - so you never wait on a single point of delay.

03

Tuned for HFT

Every node is performance-optimized for high-frequency streaming - kernel, network stack, and RPC layer, end to end.

USE CASES

  • Trading bots that need fast, reliable reads and writes
  • Indexers and backfills that hammer getProgramAccounts
  • Apps moving off public endpoints to predictable infra

Frequently asked questions

How is this different from a public or shared RPC?
Public and shared endpoints add network hops, rate limits, and noisy-neighbor jitter. Our RPC is performance-tuned and co-located with the cluster, and dedicated plans give you single-tenant bare-metal so your latency is deterministic.
Do you charge per method or per credit?
No. Plans are scoped to throughput rather than per-method credits, so heavy calls like getProgramAccounts don't carry surprise multipliers.

GET ACCESS

Put RPC on your strategy.

Start free, or talk to the infra team to scope a dedicated, co-located setup tuned to your latency and volume.

HTTP · WS

  • HTTP + WebSocket
  • No credit counting
  • Co-located, low-hop
  • Single-tenant option