> For the complete documentation index, see [llms.txt](https://docs.shyft.to/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.shyft.to/solana/shyft-rpcs.md).

# Shyft RPCs

RPCs are the gateway to blockchains. They enable developers and users to interact with the Solana blockchain by making requests to the network. These requests can include querying blockchain data, submitting transactions, and more.

A standard Solana node handles this through one monolithic process: the same software doing account lookups, tracking ledger/transaction history, and streaming updates, all sharing the same resources. Under load, one gets slow, they all get slow.

Shyft takes a different approach: <mark style="color:yellow;">decouple</mark> the three things an RPC actually does, <mark style="color:yellow;">rebuild it from the ground up</mark>, and <mark style="color:yellow;">optimize</mark> each independentl&#x79;**.**

<mark style="color:$primary;">→</mark> **Account state:** Reading current on-chain data (`getProgramAccounts`, `getAccountInfo`). Instead of scanning raw state on every call like a standard node, our proprietary **Rust-based accounts engine** indexes account state separately, so reads resolve in single-digit milliseconds instead of seconds.

<mark style="color:$primary;">→</mark> **Ledger / transaction history:** Serving blocks, transactions, and signature lookups. Powered by our own transaction engine, purpose-built for this data instead of relying on the standard RPC's general-purpose query path, which is what makes `getTransactionsForAddress` possible as a single call.

<mark style="color:$primary;">→</mark> **Streaming:** Real-time updates as they happen on-chain, through RabbitStream and Yellowstone gRPC. Both are under continuous improvement, including plugin-level work, to push latency lower.

Each piece is built and scaled on its own - so a spike in one doesn't degrade the others, and each can be optimized for exactly what it does instead of being a generalist doing three jobs at once.

Shyft RPCs are built with speed and reliability in mind, plus the most cost-efficient way of accessing Solana.

To access Shyft RPCs, [<mark style="color:red;">get an API key</mark>](https://shyft.to/get-api-key) and start interacting with the fastest chain in town, Solana.

{% embed url="<https://shyft.to/get-api-key>" fullWidth="false" %}
Get your Shyft API key from this link
{% endembed %}

<mark style="color:yellow;">**Mainnet RPC**</mark> : **<https://rpc.shyft.to/?api\\_key={your\\_api\\_key}>**

<mark style="color:yellow;">**Devnet**</mark> <mark style="color:yellow;">**RPC**</mark>: **<https://devnet-rpc.shyft.to/?api\\_key={your\\_api\\_key}>**

***

### Quick Start

{% stepper %}
{% step %}

### Sign up to Shyft

Go to [<mark style="color:yellow;">Shyft Website</mark>](https://shyft.to/) and click on the [<mark style="color:yellow;">"Get API Key"</mark>](https://dashboard.shyft.to/get-api-key) Button

<figure><img src="/files/OMdDc96R64oZcAC9nsw7" alt=""><figcaption></figcaption></figure>

{% endstep %}

{% step %}

### Get your RPC URL&#x20;

Log in — your dashboard will show your RPC URL

<figure><img src="/files/n6US5xALFNgARchTpRKt" alt=""><figcaption></figcaption></figure>

{% endstep %}

{% step %}

### Make a Request

Your RPC URL will look like this:\
`https://rpc.shyft.to/?api_key={your_api_key}`

Copy the cURL request below into Postman (or your terminal) and replace the URL with your own RPC URL (or only the key part), or alternatively, use the script below with your RPC URL to make the request:

{% tabs %}
{% tab title="cURL" %}
{% code overflow="wrap" %}

```bash
curl --location 'https://rpc.shyft.to/?api_key=YOUR-API-KEY' \
--header 'Content-Type: application/json' \
--data '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSlot"
}'
```

{% endcode %}
{% endtab %}

{% tab title="JavaScript" %}
{% code overflow="wrap" %}

```javascript
const response = await fetch('https://rpc.shyft.to/?api_key=YOUR-API-KEY', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'getSlot'
  })
});

const data = await response.json();
console.log(data);
```

{% endcode %}
{% endtab %}
{% endtabs %}
{% endstep %}
{% endstepper %}

***

### Key Features

#### **Accelerated getProgramAccounts**

Standard `getProgramAccounts` scans raw account state on every call - slow by design, worse under load. Shyft's accelerated version, powered by proprietary Rust-based accounts engine, sub-10ms on covered programs resolves the most <mark style="color:yellow;">common queries in under 10ms</mark>, same method, same parameters, no code changes.

<mark style="color:$primary;">→</mark> **Covers 10+ program/offset combinations** across Raydium, Meteora, Orca, Pump.fun and more.

<mark style="color:$primary;">→</mark> Falls through to standard RPC transparently if your query isn't in the accelerated set.

<mark style="color:$primary;">→</mark> New programs added on request, no downtime.

[<mark style="color:yellow;">**Full Accelerated gPA Docs →**</mark>](/solana/accelerated-getprogramaccounts.md)

#### **getTransactionsForAddress**

Fetching an address's transaction history normally takes two calls - `getSignaturesForAddress`, then `getTransaction` per signature - plus manual pagination and filtering on your end. `getTransactionsForAddress` <mark style="color:yellow;">collapses that into one request</mark>, with slot/status/token-account filtering handled server-side.

<mark style="color:$primary;">→</mark> Single call, signature-level or complete transaction payloads.

<mark style="color:$primary;">→</mark> Server-side filters: slot, status, token accounts.

<mark style="color:$primary;">→</mark> 2 epochs of history available.

[<mark style="color:yellow;">**Full getTransactionsForAddress Docs →**</mark>](/solana/get-transactions-for-address.md)

{% hint style="info" %}
Please note that transaction history is currently available upto 3-4 days.&#x20;
{% endhint %}

#### **Globally Distributed, Geo-Routed & Multi-Region Failover**

Geo DNS automatically routes every call to the nearest of our 5 regional clusters - <mark style="color:yellow;">NY, VA, Fra, Ams, Sgp</mark>. Calls route to the nearest gateway automatically. If a node lags or goes down, traffic fails over to the backup pool - no dropped requests, no manual region switching.

#### **Unlimited RPC Credits**

No credit counting, no upper limits, no overages. One flat rate, every call included - predictable bills every month, whether you're making a thousand calls or a million.

***

### Supported RPC Methods

Shyft RPC supports the full set of standard Solana JSON-RPC methods over HTTP and WebSocket, plus commitment-level controls for balancing speed and safety.

[<mark style="color:yellow;">**View all HTTP methods →**</mark>](/solana/rpc-calls/http.md)

[<mark style="color:yellow;">**View all WebSocket methods →**</mark>](/solana/rpc-calls/solana-websockets.md)

***

### Dedicated RPC Nodes

For teams with high-volume or latency-sensitive requirements, Shyft offers fault-tolerant dedicated nodes - isolated infrastructure, not shared capacity at the best pricing possible.

<mark style="color:$primary;">→</mark> Starting from $1,800/month

<mark style="color:$primary;">→</mark> <mark style="color:yellow;">Fallback mechanism included</mark> - your requests automatically route to a backup cluster if your node lags, goes down, or needs an upgrade

<mark style="color:$primary;">→</mark> Gen5 AMD CPUs, built for <mark style="color:yellow;">consistent low-latency</mark> performance

<mark style="color:$primary;">→</mark> Our proprietary <mark style="color:yellow;">Rust-based accounts engine is also supported</mark> on your dedicated node, bringing the same sub-10ms Accelerated gPA performance to your isolated infrastructure

Get in touch with us on [<mark style="color:yellow;">Discord</mark>](https://discord.com/invite/8JyZCjRPmr) or book a call with us [<mark style="color:yellow;">here</mark>](https://calendly.com/shyft-dev/lets-talk)<mark style="color:yellow;">.</mark>&#x20;

***

### Pricing

No credits, no bandwidth metering, no overage invoices. One flat rate - stream and query as much as you need, whether it's a quiet Sunday or a Pump.fun launch at 3am.

<mark style="color:$primary;">→</mark> **Unlimited RPC calls** - no per-call credits, no rate throttling on usage

<mark style="color:$primary;">→</mark> **Predictable billing** - one price, every month, regardless of volume

<mark style="color:$primary;">→</mark> **Custom/Enterprise** - for larger volume or bespoke requirements, reach out on Discord

[<mark style="color:yellow;">View full pricing →</mark>](https://shyft.to/solana-rpc-grpc-pricing)

***

### Frequently Asked Questions

<details>

<summary>Is Shyft RPC compatible with standard Solana RPC methods?</summary>

Yes. Shyft RPC supports the full set of standard Solana JSON-RPC methods over HTTP and WebSocket — it's a drop-in replacement, no SDK or code changes required.

</details>

<details>

<summary>How is Shyft RPC different from a standard Solana node?</summary>

Shyft RPC is built on custom infra from the ground up, not a standard node. This powers accelerated methods like `getProgramAccounts` — via our proprietary Rust-based accounts engine (sub-10ms on covered programs) — and `getTransactionsForAddress` (single call instead of two), plus geo-routing and staked endpoints for better transaction landing.

</details>

<details>

<summary>Do I get charged per RPC call?</summary>

Depends on your plan. On Hack, Launch, and Scale, each RPC call uses 1 credit from your plan's allotment — Launch and Scale allow overages once you exceed it, Hack does not. Build, Grow, and Accelerate are credit-less — no per-call counting, no overages, one flat rate regardless of call volume. [View pricing →](https://shyft.to/solana-rpc-grpc-pricing)

</details>

<details>

<summary>What is Accelerated getProgramAccounts?</summary>

Our proprietary Rust-based accounts engine that resolves the most common `getProgramAccounts` queries in under 10ms instead of the seconds a standard scan takes — same method, same parameters, no code changes. [Learn more →](https://docs.shyft.to/solana/accelerated-getprogramaccounts)

</details>

<details>

<summary>What does getTransactionsForAddress do?</summary>

It replaces the standard `getSignaturesForAddress` + `getTransaction` + manual pagination workflow with a single call, with server-side filtering by slot, status, and token accounts. [Learn more →](https://docs.shyft.to/solana/get-transactions-for-address)

</details>

<details>

<summary>What are staked endpoints, and why do they matter?</summary>

Staked endpoints run on infrastructure that validators prioritize under network load, giving your transactions a better chance of landing during congestion — not just faster reads. This matters most for trading bots and time-sensitive transactions.

</details>

<details>

<summary>Is Shyft RPC SWQoS-enabled?</summary>

Yes. Shyft's staked endpoints route through stake-weighted connections to validators, so your transactions get prioritized lanes instead of competing in the unstaked queue — the same mechanism as SWQoS, giving you better landing rates during network congestion without any extra configuration on your end.

</details>

<details>

<summary>How much stake does Shyft have, and does that matter?</summary>

SWQoS bandwidth isn't allocated as a flat "staked vs. not" split — validators typically reserve the majority of transaction lanes for staked connections, but within that pool, priority is proportional to the amount of stake behind the connection. So it's not just about being staked, it's about how much stake is backing the RPC you're sending through — a connection backed by more stake gets a larger share of that prioritized bandwidth, especially under congestion when everyone in the staked lane is competing for the same leader. That's the reasoning behind why Shyft's staked endpoints improve landing rates — you're not just getting past the unstaked queue, you're getting proportional priority within it.

</details>

<details>

<summary>How can I use durable nonces to improve transaction landing rates?</summary>

A durable nonce replaces the normal recent-blockhash requirement with a nonce account, so your transaction stays valid indefinitely instead of expiring after \~60-90 seconds. This is especially useful when broadcasting the same signed transaction across multiple RPC providers at once — since the transaction doesn't expire, you can fire it to Shyft and other RPCs in parallel and let whichever lands first win, without worrying about blockhash mismatches invalidating the others. It's a common pattern for time-sensitive submissions where landing matters more than which specific RPC gets credit.

</details>

<details>

<summary>Which regions does Shyft RPC run in?</summary>

Shyft RPC runs across 5 regions — NY, VA, Fra, Ams, Sgp — with Geo DNS automatically routing your calls to the nearest cluster and automatic failover if a node lags or goes down.

</details>

<details>

<summary>Does Shyft offer dedicated RPC nodes?</summary>

Yes, for teams with high-volume or latency-sensitive needs, starting from $1,800/month, with automatic failover to a backup cluster included, and the option to enable our proprietary Rust-based accounts engine for Accelerated gPA performance on your dedicated node. [Get in touch →](https://calendly.com/shyft-dev/lets-talk)

</details>

<details>

<summary>Why am I getting rate limited (429)?</summary>

Shyft applies separate rate limits for normal RPC calls, index calls, and `sendTransaction` — each has its own threshold, so hitting one doesn't mean you're capped on the others. If you're seeing 429s, check which call type is triggering it and see the full breakdown of limits per plan. View rate limits →

</details>

<details>

<summary>Why am I getting rate limited (429) even though I'm within my plan limits?</summary>

Your plan limit is a ceiling, not a guarantee against 429s — normal RPC calls, index calls, and `sendTransaction` each enforce their own separate threshold, typically on a per-second basis rather than just a total. So you can be well under your overall monthly/plan allowance and still get 429'd if one specific call type bursts past its own limit in a short window — for example, firing a batch of index calls back-to-back even though your total request count for the day is low. Check which call type is triggering the 429 and pace or batch those specifically. View rate limits →

</details>