# Welcome to RPC Fast

RPC Fast delivers high-performance Solana RPC endpoints, real-time streaming APIs, and enterprise-grade node infrastructure for production Web3 apps.

## About Us

RPC Fast provides high-performance infrastructure for **Solana applications** and **data-intensive Web3 services**, while also supporting other blockchains such as **Ethereum, Base, BSC, Polygon**, and others.

Our platform is designed to deliver low-latency RPC access, real-time data streaming, and highly available node infrastructure for projects that require reliable blockchain connectivity at scale.

We operate geo-distributed, auto-scaling infrastructure and high-availability node clusters, enabling developers and companies to run production workloads without managing complex DevOps operations. Our infrastructure leverages PredictKube autoscaling technology to maintain high throughput, resilience, and near-continuous uptime even under heavy load.

RPC Fast helps teams focus on building their products while our infrastructure ensures stable, fast, and scalable blockchain access.

## Focus on the Solana Ecosystem

Since 2023, RPC Fast has been strongly focused on the Solana ecosystem, providing specialized infrastructure for applications that depend on **low latency and real-time blockchain data**.

Our **Solana RPC SaaS** combines high-performance RPC endpoints with Yellowstone gRPC streaming and our in-house Aperture gRPC solution, enabling reliable access to on-chain data for demanding workloads such as:

* High-frequency trading and MEV strategies
* Blockchain analytics platforms
* DeFi protocols and wallets
* Data indexers and real-time monitoring tools
* High-scale dApps and infrastructure providers

By combining scalable infrastructure, streaming data access, and performance-focused architecture, RPC Fast helps teams build and operate **production-grade Solana applications** with confidence.


# Introduction

Low-latency Solana RPC + streaming for high-scale dApps, HFT bots, DeFi, and analytics.

## Solana RPC SaaS

Solana RPC SaaS is built on top of RPC Fast’s proven infra stack. We provide a high level of security, stable connection, and an intuitive dashboard for your dApps.

* **Standard Interface:** Get access to our JSON-RPC endpoint and 100% healthy dedicated nodes.
* **Uptime:** Our nodes are updated automatically without service interruption.
* **High-level Security:** Production-grade networking, observability, failover.
* **Integration with DoubleZero:** Enabling access to high-throughput internet layer for Solana.
* **Control Panel:** RPC Fast dashboard is intuitive and provides automatic reports about your dApps.
* **Geo:** Frankfurt, Equinix FR13.

{% hint style="success" icon="child-reaching" %}
For any presale or tech questions, please [contact us on Telegram](https://t.me/rpc_fast): Our team will get back to you shortly within the Community Support chat. Please be aware of impersonators!
{% endhint %}

### Performance We Target:

* **Fast event source** via gRPC and raw shreds
* **The lowest latency** to RPC node (high-throughput connection and nodes tuning)
* **Fast transaction propagation route**
* **No bandwidth limitations**
* **Heavy methods** inclusion
* **gRPC included** in affordable plans (starting from Stream Plan)
* **High landing rate** (SWQoS via partners' network)

***

### High-Throughput Connection

RPC Fast is plugged into [DoubleZero](https://x.com/rpcfast/status/2018613773024833881?s=20) – a high-throughput dedicated internet layer built specifically for high-performance blockchains like Solana.

By connecting our RPC infra to DoubleZero, we aim to make performance more predictable & execution more consistent, especially under heavy network load.

{% hint style="success" icon="rabbit-running" %}
Result: Lower latency to Solana leaders, higher landing rates, more consistent execution quality for HFTs and latency-sensitive apps.
{% endhint %}

***

### Custom gRPC Streaming Solution: Aperture

Custom-built Solana data/shred streaming solution by RPC Fast.\
Available in Beta within the Aperture Plan. [Read more](/rpc-fast-saas-solana/data-streaming/aperture-grpc-beta).

***

### Geolocation

Currently, we are present in Frankfurt only.

For the most efficient performance / lowest latency, we recommend deploying your app in the same region data center. Recommended providers: OVH, Teraswitch, Cherry Servers, Latitude, AWS, GCP.

***

## Development Roadmap

#### Q4'2025

* [x] Initial geo location infra setup: Frankfurt
* [x] Shredstream, gRPC
* [x] Performance tuning

#### H1'2026

* [x] [DoubleZero integration](https://x.com/rpcfast/status/2018613773024833881?s=20)
* [x] "Heavy" RPC methods inclusion (`getProgramAccounts` and others)
* [x] Solana RPC SaaS launch – March
* [x] Testing access for paid plans
* [x] Devnet integration
* [x] Hackathon plan / Colosseum Frontier support
* [x] RPC Fast Beam sender service
* [x] Unified API key for all products
* [x] Tech integrations: raw shreds from partners network
* [x] Benchmarking & performance tuning
* [x] Billing & UI tuning
* [x] Crypto payments integration
* [x] Resolved ALT for versioned transactions (Aperture gRPC)

#### H2'2026

* [x] Tech integrations: new partnerships
* [x] Aperture Trxstream – new, faster gRPC service
* [x] Real-time simulation of deshredded transactions
* [x] Benchmarking & performance tuning
* [ ] Hackathon plan / Colosseum support
* [ ] Geo-distribiuted endpoints
* [ ] Historical data endpoints
* [ ] DAS / Enhanced APIs


# Getting Started

Welcome to RPC Fast! Create your first dApp in a few simple steps.

### Sign Up / Sign In

1. Sign up for the **Start plan** (free of charge) in the dashboard: <https://rpcfast.com/>.

* Click **Log In** button in the header and choose **Solana dashboard.**

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

* **Sign up** for a new account. Make sure that you use your active email account, which can be further used for communication with our Support. We are sorry for the poor log in/sign up UI – it will get better soon, we promise.
* **Enjoy your free RPC endpoint!** Feel free to explore the dashboard (it's as simple as it gets).

{% hint style="success" icon="child-reaching" %}
For any presale or tech questions, please [contact us on Telegram](https://t.me/rpc_fast): Our team will get back to you shortly within the Community Support chat. Please be aware of impersonators!
{% endhint %}

### First dApp Creation

The first Solana Mainnet RPC app is created automatically.

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

Create more apps in three simple steps:

1. Tap the button "Create app".
2. Name your app and provide optional description. Choose the product available: Mainnet RPC, gRPC Yellowstone, or Shredstream gRPC (available depending on your plan).

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

3. Click on your app to review the detailed information about RPC traffic, methods used, response time, and other stats.

#### API Endpoints

You will see the unique API key in the "API key" section. There are also Https and Websocket endpoints for your use.

Keep this information strictly confidential!

#### Sending Requests

An API key allows you to send requests on RPC Fast. Check out plans limits in [Pricing and Plans](/rpc-fast-saas-solana/pricing-and-plans).


# Pricing and Plans

## Shared Solana RPC & Data Streaming Services

We offer a free subscription for those who start developing on Solana. Sign up via email; no credit card is required.

More advanced plans are available for dedicated builders.

* **Start** → onboarding / testing / lightweight apps
* **Focus** → early production workloads
* **Stream** → scaling production apps with meaningful real-time streaming
* **Aperture** → HFT / heavy indexing / MEV / trading infrastructure

{% hint style="success" icon="child-reaching" %}
For any presale or tech questions, please [contact us on Telegram](https://t.me/rpc_fast): Our team will get back to you shortly within the Community Support chat. Please be aware of impersonators!
{% endhint %}

### Subscription Rate Limits

<table data-header-hidden><thead><tr><th width="156.0845947265625"></th><th></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Plan / Feature</strong></td><td><strong>Start</strong></td><td><strong>Focus</strong></td><td><strong>Stream</strong></td><td><strong>Aperture</strong></td></tr><tr><td><strong>Price / Month</strong></td><td>$0</td><td>$45</td><td>$249</td><td>$499</td></tr><tr><td><strong>Monthly Credits (CU)</strong></td><td>1.5M</td><td>12M</td><td>60M</td><td>120M</td></tr><tr><td><strong>RPC Rate Limit</strong></td><td>15 req/s</td><td>50 req/s</td><td>150 req/s</td><td>500 req/s</td></tr><tr><td><strong>"Heavy" RPC Methods</strong></td><td>❌</td><td>✅</td><td>✅</td><td>✅</td></tr><tr><td><strong>sendTransaction (no SwQoS)</strong></td><td>Within the same rate limit</td><td>Within the same rate limit</td><td>Within the same rate limit</td><td>Within the same rate limit</td></tr><tr><td><strong>Bandwidth</strong></td><td>50 GB</td><td>Unlimited</td><td>Unlimited</td><td>Unlimited</td></tr><tr><td><strong>WebSockets</strong></td><td>1 concurrent</td><td>10 concurrent</td><td>20 concurrent</td><td>50 concurrent</td></tr><tr><td><strong>gRPC Yellowstone</strong></td><td>❌</td><td>❌</td><td>✅ Up to 10 streams</td><td>✅ Up to 25 streams</td></tr><tr><td><strong>gRPC Shredstream</strong></td><td>❌</td><td>❌</td><td>❌</td><td>✅ Up to 10 streams</td></tr><tr><td><strong>Aperture TxStream</strong></td><td>❌</td><td>❌</td><td>✅ Up to 10 streams.<br><strong>Limited version*</strong> (no real-time tx execution simulation)</td><td>✅ Up to 25 streams.<br><strong>Full version</strong> with the real-time tx execution simulation<br>✅ <strong>Aperture gRPC*</strong>(Yellowstone-compatible) </td></tr><tr><td><strong>SWQoS</strong></td><td>RPC Fast Beam (Beta)</td><td>RPC Fast Beam (Beta)</td><td>RPC Fast Beam (Beta)</td><td>RPC Fast Beam (Beta)</td></tr><tr><td><strong>Beam:</strong> Transaction Sending Rate Limits</td><td>60 tx/min</td><td>200 tx/min</td><td>500 tx/min</td><td>500 tx/min</td></tr><tr><td><strong>Geo</strong></td><td>FRA (DE),<br>Equinix FR13</td><td>FRA (DE),<br>Equinix FR13</td><td>FRA (DE),<br>Equinix FR13</td><td>FRA (DE),<br>Equinix FR13</td></tr><tr><td><strong>Infrastructure</strong></td><td>Shared</td><td>Shared</td><td>High-performance shared</td><td>Priority high-performance shared</td></tr><tr><td><strong>Support Level</strong></td><td>Community</td><td>Email – SLA 24h**</td><td>Email – SLA 12h**</td><td>Priority chat – SLA 8h**</td></tr></tbody></table>

\*For a limited time, Aperture TxStream is available on the **Stream plan** – without transaction execution simulation. The full version with real-time simulation is included in the **Aperture plan**.\
Starting September 1, the Aperture TxStream protocol will become exclusive to the Aperture plan.\
**Aperture (Yellowstone-compatible) gRPC** remains available for Aperture plan, although it will be deprecated in the future as Aperture TxStream becomes our primary low-latency streaming protocol.

\*\*SLA refers to the initial answer timeframe, not the final issue resolution. We offer assistance **during Support Chat hours.** All requests outside of support hours are handled under the "Best Effort" SLA.

{% hint style="success" icon="child-reaching" %}
For more details on Customer Support working schedule, please refer to [Support.](/rpc-fast-saas-solana/support)
{% endhint %}

***

### Geolocation

Currently, shared RPC infrastructure is present in Frankfurt, the **Equinix FR13** DC.

{% hint style="warning" %}
For the most efficient performance and lowest latency, we recommend deploying your app in the **same region data center** or close. Recommended providers: Cherry Servers, Teraswitch, Latitude, AWS, GCP.
{% endhint %}

***

### Billing, Payments, and Terms of Use

By creating an account, joining the waitlist, accessing the dashboard, or using the Service, you agree to be bound by our [Terms of Service](https://docs.rpcfast.com/legal/terms-of-service). If you do not agree, you must not use the Service.

Subscription plans include a defined monthly allocation of Compute Units (CU) and are billed in advance at the start of each billing cycle using your selected payment method.

You authorize RPC Fast (or its third-party payment processor) to charge all applicable fees, taxes, and overage charges to your payment method.

RPC Fast uses Stripe to process payment card transactions and generate invoices, and CoinGate for crypto payments. By making a payment, you agree to the applicable terms and policies of the relevant payment provider.

{% hint style="warning" %}
All fees are **non-refundable** unless required by applicable law.
{% endhint %}

Read more about the subscription plans, credits & billing, applicable taxes, as well as general usage restrictions, refund policy, and abuse prevention & fair use policy in the [Terms of Service](https://docs.rpcfast.com/legal/terms-of-service).

***

## Dedicated Self-Hosted Infrastructure

For mid- and large-sized companies and Web3 projects, we offer custom approach – [dedicated Solana nodes](https://rpcfast.com/dedicated-solana-nodes) and [high-availability clusters of nodes](https://rpcfast.com/dedicated-cluster) (2+) on a specific blockchain of your choice, whether your goal is to run a validator, RPC nodes for [DeFi](https://rpcfast.com/defi-infrastructure), trading, and/or blockchain analytics, or archive nodes for data ETL solutions.

The self-hosted cluster offers premium advantages such as load balancing, autoscaling, speed optimization, geo-distribution, and HFT-focused tools, based on the business goals.

{% hint style="info" %}
Contact our [Sales Team](https://telegram.me/dysnix_rpc) on Telegram to discuss your technical brief for a dedicated setup.
{% endhint %}


# Testing Access

Test Yellowstone gRPC / Shredstream gRPC performance on paid plans.

We provide a **24-hour trial endpoint** to help you evaluate our paid plans and Yellowstone, Shredstream, and Aperture gRPC performance.

### Geolocation

Currently, we are present in Frankfurt only, **Equinix FR13** data center.

{% hint style="warning" %}
For the most efficient performance and lowest latency, we recommend deploying your app in the **same region data center** or close. Recommended providers: Cherry Servers, Teraswitch, Latitude, AWS, GCP.
{% endhint %}

***

### How to Request Access

#### 1. Create an account

Sign up for the **Start plan** (free of charge) in the dashboard: <https://rpcfast.com/>.

* Click **Log In** button in the top right corner and choose **Solana dashboard.**

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

* **Sign up** for a new account. Make sure that you use your active email account, which can be further used for communication with our Support. We are sorry for the poor log in/sign up UI – it will get better soon, we promise.
* **Enjoy your free RPC endpoint!** Feel free to explore the dashboard (it's as simple as it gets).

***

#### 2. Send a request

Email us at `solana-support@rpcfast.com`, using the **same email** as your RPC Fast account, so we can identify you.

Pick the right product you want to test.

Mail subject: **Test gRPC**

In your message, please specify:

* **Plan to test:**
  * `Stream` – if you are interested in Yellowstone gRPC only;
  * `Aperture` – for Shredstream gRPC, [Yellowstone gRPC](/rpc-fast-saas-solana/data-streaming/yellowstone-grpc), and [Aperture gRPC](/rpc-fast-saas-solana/data-streaming/aperture-grpc-beta).
* If you want your trial to start on specific date/time, please mention **preferred timing** (inlcude the timezone).

***

#### 3. Get access

The selected plan trial will be activated on your account **within 24-48 hours** upon receiving the request. If you run into any issues or need a trial extension, just reply to the same email.

***

### Trial & Upgrade Terms

{% hint style="warning" icon="light-emergency-on" %}
We recommend **preparing your test setup in advance** to make the most of your trial.
{% endhint %}

* You can end the trial at any time by upgrading to a paid plan, or simply let it expire automatically.
* While the trial is active, the *Start* plan cannot be re-selected.
* Trials are **not available** for accounts that are already on a paid plan.

***

{% hint style="success" icon="rabbit-running" %}

#### Happy testing – may your latency be low and your shreds fly!

{% endhint %}


# Billing

We use Compute Units as an alternative to the ‘pay-per-click’ method. It provides greater flexibility and cost savings.

## Compute Units (CU) balance

The **CU balance** allows you to use methods with a specific price for the application. It enables you to optimize your spending and calculate the usage more precisely – pay only for methods you use.

#### RPC methods cost in CU

Applying each RPC method on Solana will cost you 1 CU. The only exception is [getProgramAccounts](https://solana.com/docs/rpc/http/getprogramaccounts) (10 CU).

<table><thead><tr><th width="373">Method</th><th>Cost in CU</th></tr></thead><tbody><tr><td>Any Solana RPC method</td><td>1</td></tr><tr><td><code>getProgramAccounts</code></td><td>10</td></tr></tbody></table>

Certain methods are available on **paid plans only** or on a [dedicated Solana node](https://rpcfast.com/dedicated-solana-nodes). Read more in [Solana RPC Methods](/rpc-fast-saas-solana/solana-rpc-methods).

#### Do unused Compute Units (CU) roll over?

Unused Compute Units do **not** roll over to the next billing period.

Your CU allocation **resets at the beginning of each monthly billing cycle** according to the limits included in your subscription plan.

If your usage regularly approaches or exceeds your monthly CU allocation, consider upgrading your plan to ensure consistent capacity and avoid overage charges.

#### Websockets usage

Websockets are only limited by the amount of opened subscriptions. The amount of data transferred does not incur any CU usage.

#### Is bandwidth metered?

{% hint style="success" icon="rabbit-running" %}
RPC Fast does not charge for bandwidth usage!
{% endhint %}

All paid plans include **unlimited bandwidth**, meaning you are not billed based on the amount of data transferred through RPC, WebSocket, or gRPC streams.

Some RPC providers charge additional fees based on **bandwidth consumption** (e.g., per GB of data transferred). With RPC Fast, bandwidth is not metered, allowing you to stream on-chain data without worrying about unpredictable usage-based costs. However, please be aware of possible overage usage of your plan CU allocation – [see below](https://docs.rpcfast.com/rpc-fast-saas-solana/billing#overage-usage).

Your usage is instead measured through **Compute Units (CU)** and the **stream limits** defined in your subscription plan.

***

## Billing

#### When does my billing period start?

Your billing period begins when you activate a paid plan.\
Subscriptions are billed **in advance for each 30-day billing cycle** and automatically renew unless canceled.

#### Plans

* Each payment plan has its limitations.
* We count all requests received from each single account.
* We charge users by calculating the whole number of CUs for all apps, regardless of the apps number.

Check the **Dashboard** –> [Billing and Usage](https://solana.rpcfast.com/billing-and-usage/) for your plan CU allocation and usage and other stats.

Click "Manage" to change your plan at any moment.

#### Upgrade / Downgrade

You can upgrade or downgrade your subscription at any time. Select the plan that best fits your needs and follow the payment instructions.

If you **upgrade**, the new plan and its limits become available **immediately**.

If you **downgrade**, the change will take effect **at the end of the current billing period**, and your existing plan will remain active until then.

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

**Willing to upgrade shortly after starting with your current plan?** We can handle the upgrade manually – you only need to pay the price difference between your current plan and the higher-tier one.

For example, if you’ve been using the Stream plan for a week but realize you need ShredStream access, you can simply pay the difference and upgrade to Aperture. Your billing period will remain unchanged, with the upgrade applied immediately for the remainder of the current cycle. To request this type of upgrade, contact us using the **Support** button in the dashboard.

***

## Overage usage

#### How can I track my usage?

You can monitor:

* Compute Units (CU) consumption
* Active gRPC streams
* RPC request statistics

directly in the **RPC Fast dashboard** in real time.

#### What's the overage rate?

If your usage exceeds the monthly Compute Unit (CU) allocation included in your plan, additional usage will be billed at the overage rate of **$5 per 1M CU** at the end the active billing period.

#### What happens if I don't pay for overage usage in time?

If your account exceeds the allowed CU overage cap and the outstanding balance is not settled in time, **your account may be temporarily suspended** until the payment is resolved.

You are fully responsible for all usage and any overage charges incurred under your account.

If your usage regularly approaches or exceeds your monthly CU allocation, consider **upgrading your plan** to ensure consistent capacity and avoid overage charges.

{% hint style="success" %}
You can increase CU allocation by upgrading your plan ahead of the recurring subscription date.
{% endhint %}

***

## How Are gRPC Streams Counted?

A **gRPC stream** represents a single active streaming connection established between your application and the RPC Fast endpoint using Yellowstone gRPC (Geyser) or Shredstream gRPC. Each active connection counts as **one stream** toward the stream limit defined in your subscription plan.

For example, if your application opens multiple parallel subscriptions (to different programs, accounts, or transaction filters), each concurrent connection counts as a separate stream.

* A **stream is counted per active connection**, not per event or message.
* Multiple filters or subscriptions within the same connection are counted as **one stream**.
* Opening additional connections (for scaling, redundancy, or different services) will increase the number of streams used.
* Each plan defines the maximum number of concurrent streams allowed for your account.

If your application requires more simultaneous streams than your current plan allows, you can **upgrade to a higher plan** to increase the available stream capacity.

***

## Can I Cancel My Subscription?

Yes. You can cancel your subscription at any time by **downgrading to Start plan** through the "Billing" section of the dashboard. If you choose to downgrade, your current paid plan will still remain active until the end of the current billing period, after which it will not renew. Start plan is free of charge – feel free to come back to us when you are ready.

Alternatively, you may also delete your account completely.

## How to Delete My Account?

Go to "My Account" (menu in the top right) → "Delete Account" and follow the instructions to complete the process. Please note that **all associated data will be permanently deleted** once you confirm the request.


# Payments

## Billing Cycle

Each billing period is **thirty (30) days**, unless otherwise specified in your selected plan.

Your subscription begins on the date you activate or select a plan and renews automatically every thirty (30) days unless canceled.

***

#### Overage Usage

Usage exceeding the included monthly Compute Units allocation will be charged at the applicable overage rate during the active billing period.

You are fully responsible for all overage charges incurred under your account.

***

#### Plan Changes

You may upgrade or downgrade your subscription plan via the Billing section of the dashboard.

* **Upgrades** take effect immediately. After a new plan price is paid, the billing period is re-calculated to thirty (30) days from the date of payment.
* **Downgrades** become effective at the end of the then-current billing period.

***

## Payments

RPC Fast uses [Stripe](https://stripe.com/) to process payment card transactions and generate invoices for fiat payments.

RPC Fast supports cryptocurrency payments through [CoinGate](https://coingate.com/), which acts as a third-party payment processor for supported digital assets.

By making a payment, you agree to the applicable terms and policies of the relevant payment provider.

***

#### Cryptocurrency payments

RPC Fast supports cryptocurrency payments for Solana RPC subscriptions. Available payment methods and supported cryptocurrencies may change (USDC, SOL by default).

**CoinGate** applies a currency exchange rate when converting the invoice amount from USD to the selected cryptocurrency or stablecoin. Also, an additional network processing fee (**service fee**) is applied at checkout. This fee is **not retained by RPC Fast** and is used to facilitate timely confirmation of transactions on the underlying blockchain network. The amount of the fee is dynamic and may vary based on network conditions and transaction demand.

Any applicable tax fees, processing fees, and total payment amount is displayed during checkout. The breakdown of fees is also available on the order info page.

***

#### Fees & Payment

Subscription plans include a defined monthly allocation of Compute Units (CU) and other services within defined plan limits and are billed in advance at the start of each billing cycle using your selected payment method.

You authorize RPC Fast (or its third-party payment processor) to charge all applicable fees, taxes, and overage charges to your payment method.

{% hint style="warning" %}
All fees are **non-refundable** unless required by applicable law. For exceptions, see section **Refund Policy.**
{% endhint %}

***

#### VAT & Taxes

**All fees are exclusive of applicable taxes.** Any taxes required by law will be calculated and charged at checkout (such as VAT for the EU-based customers). Customers are responsible for all applicable taxes associated with their purchase and use of the Service.

RPC Fast runs under a company registered and VAT-liable in Estonia (EU). All prices for individual (non-business) customers are subject to Estonian VAT at the applicable local rate.

**Why Estonian VAT applies to EU customers:** Under EU VAT rules, digital service providers whose annual cross-border B2C sales remain below the EU-wide OSS registration threshold are permitted to apply their home country’s VAT rate rather than the customer’s local rate. Hence, Estonian VAT applies to all individual customers regardless of their EU country of residence.\
This approach is compliant with Council Directive 2006/112/EC of 28 November 2006 on the common system of value added tax (as amended by Council Directive (EU) 2017/2455 of 5 December 2017 regarding VAT obligations for supplies of digital services and the introduction of the OSS threshold).

**Business customers (B2B):** If you are purchasing on behalf of a VAT-registered business in another EU country, please contact our support and provide your valid VAT ID. The reverse charge mechanism will apply and no Estonian VAT will be charged.

***

#### Failed Payments

If a payment attempt fails, RPC Fast will automatically retry the charge using the payment method on file.

* RPC Fast will make up to three (3) additional payment attempts over a period of approximately six (6) days. During this period, access to the subscribed plan will continue uninterrupted.
* If all payment attempts are unsuccessful, RPC Fast reserves the right to suspend paid features and downgrade the account to the free **Start** plan.&#x20;
* Any outstanding fees incurred prior to the downgrade remain payable by the Customer.

Customers are responsible for maintaining valid and up-to-date payment information and ensuring sufficient funds are available to cover subscription fees and applicable charges.

***

#### Refund Policy

Access to the Services is provided immediately upon successful payment. By purchasing a subscription, the Customer expressly requests immediate access to the Services and acknowledges that, to the extent permitted by applicable law, any statutory *right of withdrawal or cancellation* that would otherwise apply is waived once access to the Services has begun.

Accordingly, all fees paid for the Services are generally **non-refundable.**

Notwithstanding the above, the Company may, at its sole discretion, grant a full or partial refund on an exceptional basis if:

* the Customer submits a refund request within **three (3) calendar days** from the date of purchase; and
* the Customer demonstrates that the Services failed to perform substantially as described due to a verified quality or technical issue attributable to the Company.

We will investigate each request individually. Refunds will not be granted for reasons including, but not limited to, changes in the Customer's business needs, lack of usage, configuration errors, incompatibility with third-party software or infrastructure outside the Company's control, or issues caused by the Customer's own systems or actions.

Any decision to issue a refund outside the circumstances described above is made solely at the Company's discretion and does not create an obligation or precedent for future cases.


# Solana RPC Methods

Interact with Solana nodes directly with the JSON RPC API via the HTTP and Websocket methods.

Applying each RPC method within RPC Fast Solana SaaS will cost you 1 CU. The only exception is [getProgramAccounts (10 CU)](https://solana.com/docs/rpc/http/getprogramaccounts). Read more in [Compute Units](/rpc-fast-saas-solana/billing).

Please refer to [Solana Documentation](https://solana.com/docs/rpc) for detailed guidelines on each RPC method. Here's how the methods break down by category:

<table><thead><tr><th width="213.3585205078125">Category</th><th width="269.2017822265625">Methods</th><th>What they do</th></tr></thead><tbody><tr><td>Block &#x26; Slot information</td><td>getBlock,<br>getBlocks,<br>getBlockHeight,<br>getBlockTime,<br>getSlot,<br>getBlockCommitment,<br>getFirstAvailableBlock,<br>getLatestBlockhash</td><td>Retrieve block data, slot numbers, and blockchain height. Essential for syncing and monitoring the chain state.</td></tr><tr><td>Transaction queries</td><td>getTransaction,<br>getSignatureStatuses,<br>getSignaturesForAddress,<br>getRecentPerformanceSamples</td><td>Look up transaction details, confirmation status, and historical signatures for addresses.</td></tr><tr><td>Account data</td><td>getAccountInfo,<br>getBalance,<br>getMultipleAccounts,<br>getStakeActivation</td><td>Fetch account balances, metadata, and stake information. Core methods for wallets and dApps.</td></tr><tr><td>Network &#x26; Validator info</td><td>getClusterNodes,<br>getEpochInfo,<br>getHealth,<br>getIdentity,<br>getInflationRate,<br>getLeaderSchedule,<br>getSupply,<br>getVersion,<br>getVoteAccounts</td><td>Monitor network health, validator performance, and epoch data.</td></tr><tr><td>Transaction submission</td><td>sendTransaction,<br>simulateTransaction</td><td>Submit transactions to the network and test them before sending.</td></tr><tr><td>Fee &#x26; Rent calculations</td><td>getFeeForMessage,<br>getMinimumBalanceForRentExemption,<br>getRecentPrioritizationFees</td><td>Calculate transaction fees and rent requirements.</td></tr></tbody></table>

### RPC Methods Availability

Certain RPC methods are only available on paid plans:

* getProgramAccounts
* getTokenAccountsByOwner
* getTokenAccountsByDelegate
* getTokenLargestAccounts

**Start Plan:**

Calling `getProgramAccounts` RPC method will lead to a warning:

{% code overflow="wrap" %}

```
{"jsonrpc": "2.0", "id": 1, "error": {"code": -32602, "message": "Method usage requires an upgrade to a paid plan. See "}}
```

{% endcode %}

**Paid plans:**

If the user specifies any of the program IDs below, the following error will occur:

{% code overflow="wrap" %}

```
{"jsonrpc": "2.0", "id": 1, "error": {"code": -32000, "message": "getProgramAccounts error: provided program account is not allowed to be used."}
```

{% endcode %}

```
kinXdEcpDQeHPEuQnqmUgtYykqKGVFq6CeVX5iAHJq6  # KIN
metaqbxxUerdq28cj1RbAWkYQm3ybzjB6a8bt518x1s  # metaplex
4R3gSG8BpU4t19KYj8CfnbtRpnT8gtk4dvTHxVRwc2r7 # jito tip distribution
TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA  # token program
```

{% hint style="success" icon="child-reaching" %}
For any presale or tech questions, please [contact us on Telegram](https://telegram.me/+SpMbJTPTakAxNjdi): Our team will get back to you shortly within the community chat. Please be aware of impersonators!
{% endhint %}


# Data Streaming


# Data Access Options

Data streaming on Solana refers to mechanisms that deliver real-time blockchain updates from a node to your application without repeated polling.

## Data Access Options

At the moment, RPC Fast does not provide direct UDP shred ingestion to end users. Instead, Solana data is available to our clients via three high-performance gRPC interfaces:

* **Aperture TxStream**
* **Aperture gRPC**
* **ShredStream gRPC**

All three services are sourced directly from validator-level UDP shreds, ensuring minimal delay from the network.

{% hint style="info" %}
Track gRPC performance [here](https://docs.rpcfast.com/rpc-fast-saas-solana/performance-and-benchmarking).
{% endhint %}

### Aperture TxStream

**TxStream** is RPC Fast's optimised, transaction-only protocol. It streams decoded transactions through a compact protobuf surface, supports server-side filters, resolved ALT addresses, optional batching, and opt-in **real-time transaction simulation.** Use the official Rust client for the supported integration path. [Read more](/rpc-fast-saas-solana/data-streaming/txstream).

### Aperture gRPC

Aperture gRPC **reconstructs raw shreds into a structured stream** compatible with the Yellowstone gRPC model, while bypassing traditional RPC node processing.

{% hint style="info" %}
Aperture gRPC supports only slots, entries and transactions streaming, without replay metadata, such as inner program instructions, balance changes, etc. For blocks, accounts updates and extended transaction metadata, use Yellowstone gRPC.
{% endhint %}

{% hint style="warning" %}
Yellowstone-compatible version of the Aperture gRPC **will be deprecated** in the short future as **Aperture TxStream** becomes our primary low-latency streaming protocol.
{% endhint %}

Compared to standard Yellowstone deployments, this approach:

* Reduces end-to-end latency by \~30–40 ms
* Avoids RPC node overhead (banking stage, account indexing, etc.)
* Delivers ordered, near-real-time transactions stream
* Supports server-side transaction filtering (account mentions, signatures, etc.)
* Provides a drop-in developer experience for existing Yellowstone clients

In short, **Aperture combines shred-level speed with Yellowstone-level usability**. [Read more](#aperture-grpc).

### ShredStream gRPC

ShredStream gRPC provides a more direct representation of the underlying data flow by streaming Solana Entries reconstructed from shreds.

Key characteristics:

* Streams raw entry data (closer to validator pipeline)
* No built-in filtering – all parsing and selection must be handled client-side
* Suitable for teams that require maximum control over decoding and processing

| Feature              | TxStream                                   | Aperture gRPC                | ShredStream gRPC                   | Yellowstone gRPC                                       |
| -------------------- | ------------------------------------------ | ---------------------------- | ---------------------------------- | ------------------------------------------------------ |
| Data source          | UDP shreds                                 | UDP shreds                   | UDP shreds                         | Node Geyser interface                                  |
| Output format        | Compact decoded transaction protobuf       | Yellowstone-compatible       | Solana Entry stream                | Yellowstone                                            |
| Latency              | Lowest in the matched-signature comparison | Very low                     | Very low; client decoding required | Moderate                                               |
| Filtering            | Server-side                                | Server-side                  | Client-side only                   | Server-side                                            |
| ALT resolution       | Included when available                    | Included when available      | Client responsibility              | Replay-derived                                         |
| Real-time simulation | Opt-in transaction simulation              | No                           | No                                 | No                                                     |
| Use case             | HFT, trading bots, real-time simulation    | Existing Yellowstone clients | Custom low-level pipelines         | Replay-derived data and non-latency-critical workloads |

***

## Overview

Solana supports real-time blockchain data delivery through native streaming mechanisms. Instead of repeatedly polling RPC endpoints over HTTP, applications can subscribe to live updates and receive notifications as state changes occur. This is essential for responsive, **state-aware applications** such as explorers, dashboards, bots, wallets, and trading systems.

**Streaming enables:**

* Real-time UI updates (wallet balances, dashboards)
* Transaction tracking
* Program activity monitoring
* Trading and automation systems
* Indexing and analytics pipelines

Solana provides two primary streaming approaches:

1. **WebSocket JSON-RPC PubSub** (official RPC interface)
2. **gRPC Streaming via Geyser plugins** (validator-level streaming)

Both methods allow applications to stay synchronized with on-chain state – with different performance and architectural tradeoffs.

| Streaming Method       | Best For                                                                        |
| ---------------------- | ------------------------------------------------------------------------------- |
| **JSON-RPC WebSocket** | Lightweight apps, UI dashboards, wallet balance notifications, basic monitoring |
| **gRPC Streaming**     | High-frequency trading, indexing, analytics, heavy event loads, backend engines |

Streaming complements rather than replaces regular HTTP RPC calls. While HTTP queries are great for on-demand lookups (e.g., historical data), streaming ensures your app is **kept up-to-date in real time** without hammering RPC endpoints.

{% hint style="success" %}
RPC Fast provides both lightweight WebSocket subscriptions and high-performance streaming solutions designed for production-grade Solana infrastructure.
{% endhint %}

***

## Solana RPC WebSocket PubSub

Solana’s official RPC interface includes a PubSub system over WebSockets, documented in the [Solana Documentation](https://solana.com/docs).

Instead of calling `getAccountInfo` repeatedly, clients:

1. Open a persistent WebSocket connection
2. Send a subscription request
3. Receive push notifications when matching events occur

> This form of streaming uses standard JSON-RPC over WebSockets (persistent connection, JSON payloads) and is part of Solana’s official RPC interface.

### Architecture

```
Client Application
│
│ WebSocket (JSON-RPC)
▼
RPC Fast Solana Node
│
▼
Solana Validator Network
```

### Supported Subscription Types

The RPC WebSocket interface supports:

<table><thead><tr><th width="266.76177978515625">Subscription</th><th>Description</th></tr></thead><tbody><tr><td><code>accountSubscribe</code></td><td>Notifies when an account’s lamports or data change</td></tr><tr><td><code>programSubscribe</code></td><td>Notifies when accounts owned by a program change</td></tr><tr><td><code>logsSubscribe</code></td><td>Streams program log output</td></tr><tr><td><code>signatureSubscribe</code></td><td>Tracks transaction confirmation status</td></tr><tr><td><code>slotSubscribe</code></td><td>Notifies when a new slot is processed</td></tr><tr><td><code>blockSubscribe</code></td><td>Streams block data (if enabled)</td></tr><tr><td><code>rootSubscribe</code></td><td>Tracks finalized root changes</td></tr></tbody></table>

{% hint style="info" %}
RPC Fast SaaS endpoints do not support `all` and `allWithVotes` filters for WebSocket subscriptions. As a best practice, include more specific filters to reduce latency and bandwidth usage.
{% endhint %}

### Commitment Levels

Each subscription may specify a commitment level:

* `processed` → lowest latency
* `confirmed` → voted by supermajority
* `finalized` → irreversible state

Choosing the right commitment is a latency vs. safety tradeoff.

### Example: Account Subscription

```
import WebSocket from "ws";

const ws = new WebSocket("wss://your-rpc-endpoint");

ws.on("open", () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "accountSubscribe",
    params: [
      "ACCOUNT_PUBLIC_KEY",
      { commitment: "confirmed" }
    ]
  }));
});

ws.on("message", (data) => {
  console.log("Update:", data.toString());
});
```

### When to Use WebSocket Streaming

Best suited for:

* Wallet balance updates
* Basic trading bots
* UI dashboards
* Lightweight monitoring
* Applications with moderate subscription counts

***

## High-Performance Streaming (gRPC-based)

For **low-latency or high-throughput** streaming use cases (e.g., trading engines, real-time analytics), many providers build on Solana’s **Geyser plugin architecture** to expose streaming via **gRPC** rather than plain WebSockets. This approach is more efficient for binary data and supports advanced filtering and throughput.

### What Is gRPC Streaming?

* Solana validators and nodes can load Geyser plugins that expose on-chain data events at the lowest possible level.
* Clients then connect via **gRPC** (binary protocol on HTTP/2) and receive a stream of structured data (accounts, transactions, blocks, slots).
* This avoids JSON overhead and enables *continuous streaming* with minimal latency.

### Architecture

```
Client Backend
       │
       │  gRPC (HTTP/2, Protobuf)
       ▼
RPC Fast Geyser Stream
       │
       ▼
Validator Runtime (Geyser plugin)
```

### Data Types Typically Streamed

* Account updates (raw + parsed)
* Transactions
* Entry/slot updates
* Blocks
* Vote updates

### Benefits of gRPC Streaming

* **Low latency & high throughput:** Binary streaming pushes data as soon as it’s processed in memory.
* **Structured protocols:** Strong typing and efficient serialization (Protocol Buffers).
* **Advanced filtering:** Clients can subscribe only to the data types or accounts they care about.
* **Better for backend engines:** Helpful when handling many subscriptions or large volumes of data.

This pattern forms the basis for many existing Solana streaming services (e.g., Yellowstone gRPC, Dragon’s Mouth implementations across providers).

### When to Use gRPC Streaming

Recommended for:

* High-frequency trading (HFT)
* Real-time arbitrage engines
* MEV systems
* Large-scale indexing
* Analytics pipelines
* Applications handling thousands of updates per second

***

## WebSocket vs gRPC Comparison

<table><thead><tr><th width="194.23046875">Feature</th><th>WebSocket RPC</th><th>Geyser gRPC</th></tr></thead><tbody><tr><td>Protocol</td><td>JSON over WebSocket</td><td>gRPC (Protobuf over HTTP/2)</td></tr><tr><td>Latency</td><td>Low</td><td>Very Low</td></tr><tr><td>Throughput</td><td>Moderate</td><td>High</td></tr><tr><td>Filtering</td><td>Basic</td><td>Advanced</td></tr><tr><td>Best For</td><td>Frontend apps</td><td>Backend engines</td></tr><tr><td>Setup Complexity</td><td>Simple</td><td>Advanced</td></tr></tbody></table>

***

## Streaming vs HTTP Polling

| HTTP Polling                | Streaming              |
| --------------------------- | ---------------------- |
| Repeated requests           | Persistent connection  |
| Higher latency              | Near real-time         |
| Higher RPC load             | Efficient push updates |
| Good for historical queries | Good for live state    |

Most production systems combine:

* **HTTP RPC** → historical queries
* **WebSocket** → reactive updates
* **gRPC** → high-performance ingestion

***

## Concepts & Patterns

**Commitment Levels:**\
Commitment determines how “final” a piece of data must be before it triggers a notification (`processed` → earliest, `finalized` → safest). This choice affects latency vs. certainty.

**Subscription Lifecycle:**

Connect → request one or more subscriptions → receive events → unsubscribe → close connection.

**Filtering:**\
Many streaming clients support filtering (e.g., specific accounts or programs) to reduce noise and bandwidth. gRPC streams often provide *richer*, more granular filtering options.

***

## Design Considerations

**1. Backpressure Handling**

Applications consuming streams must be able to process events quickly or queue them appropriately.

**2. Reconnection Strategy**

WebSocket and gRPC connections should implement:

* Automatic reconnect
* Subscription replay
* Idempotent state handling

**3. Commitment Strategy**

Lower commitment = faster but less final.\
Higher commitment = safer but slower.

**4. Filtering Strategy**

Over-subscribing can overwhelm systems. Use account and program filters to reduce noise.

***

## Summary

* **Solana supports real-time blockchain streaming natively** via RPC WebSocket PubSub — part of its core RPC API — enabling clients to subscribe to account, transaction, log, slot, and other events.
* **For advanced workloads, Geyser gRPC streaming** is used by many services to deliver low-latency, structured data streams with more throughput and filtering power.
* **Streaming is essential** for building responsive dApps: wallets, analytics dashboards, explorers, trading bots, monitoring tools, and more.

Streaming allows applications to remain synchronized with on-chain state efficiently, reduce polling overhead, and react to events with minimal latency.


# Yellowstone gRPC

Production-grade Solana data streaming designed for performance and throughput.

***

Yellowstone gRPC is a structured Solana data stream built on the Geyser model. It exposes real-time blockchain events over gRPC, with support for transactions, transaction status, accounts, slots, blocks, block metadata, and entries streaming.

Yellowstone gRPC has better throughput and latency than the standard Solana WebSocket API because it uses protobuf over gRPC instead of JSON-RPC over WebSocket, supports richer structured payloads, and is better suited for long-lived high-throughput ingestion pipelines.

### What Yellowstone gRPC provides

Yellowstone gRPC gives applications a single bidirectional subscription interface for Solana streaming.

Supported streamed data includes:

* accounts
* slots
* transactions
* transaction status updates
* blocks
* block metadata
* entries

### Use cases

Yellowstone gRPC is designed for applications that continuously consume Solana data and process it server-side.

Typical use cases include:

* indexers
* real-time analytics pipelines
* trading infrastructure
* alerting systems
* event-driven backend services
* database ingestion workers
* queue and stream processors

### gRPC subscription model

Yellowstone uses a bidirectional gRPC stream. The client opens a subscription, sends a `SubscribeRequest`, and then receives matching updates continuously.

A single request can include filters for multiple stream categories at once.

#### Top-level request fields

Common top-level fields include:

* `accounts`
* `slots`
* `transactions`
* `transactions_status`
* `blocks`
* `blocks_meta`
* `entry`
* `accounts_data_slice`
* `commitment`
* `ping`

#### Filter semantics

Yellowstone filters are designed to reduce client-side discard work.

General behavior:

* different filter fields are combined with logical **AND**
* values inside arrays are combined with logical **OR**
* account `filters` are combined with logical **AND**
* empty filters usually mean a broad stream for that category, unless provider-side limits disallow it

#### Commitment levels

Yellowstone supports three commitment levels:

* `processed`
* `confirmed`
* `finalized`

For latency-sensitive ingestion, `processed` is usually the default choice. If you require stronger consensus confidence, `confirmed` or `finalized` may be more appropriate.

#### Supported filters

**Accounts**

Account subscriptions can be filtered by:

* `account`
* `owner`
* `filters`

`filters` follows the same model as `getProgramAccounts`, including `dataSize` and `Memcmp`.

For accounts:

* fields are combined with logical **AND**
* values inside arrays are combined with logical **OR**
* nested `filters` are also treated as logical **AND**

**Transactions**

Transaction subscriptions can be filtered by:

* `vote`
* `failed`
* `signature`
* `account_include`
* `account_exclude`
* `account_required`

For transactions:

* empty filters broadcast all transactions
* fields are combined with logical **AND**
* values inside arrays are combined with logical **OR**

**Slots**

Slots support `filter_by_commitment`, which restricts slot updates to the selected commitment level instead of streaming every slot lifecycle update.

**Blocks**

Block subscriptions support:

* `account_include`
* `include_transactions`
* `include_accounts`
* `include_entries`

**Block metadata**

`blocks_meta` provides block-level metadata without the full block payload.

**Entries**

Entries are a fundamental building block of Proof of History. Each entry contains a unique ID that is the hash of the Entry before it, plus the hash of the transactions within it. Entries cannot be reordered, and its field `num_hashes` represents an approximate amount of time since the last Entry was created.

### Yellowstone gRPC vs WebSocket

The standard Solana WebSocket interface uses JSON-RPC PubSub over WebSocket. Yellowstone uses gRPC over HTTP/2 with protobuf payloads.

In practice, this means Yellowstone is usually a better fit for:

* higher-throughput streaming workloads
* lower-overhead backend ingestion
* typed decoding with protobuf clients
* richer data flows than typical WebSocket subscriptions
* long-lived service-to-service streaming

WebSocket subscriptions are still useful for lightweight apps, dashboards, and simpler live-update flows. Yellowstone is the stronger choice when the stream feeds backend logic, analytics, storage, or trading systems.

***

### Usage limits

{% hint style="info" %}
RPC Fast applies concurrent connection and filter limits to keep Yellowstone gRPC performance predictable under shared high-load usage.
{% endhint %}

#### Max concurrent Yellowstone gRPC connections by plan

One active gRPC connection counts as one stream.

Multiple filters sent over the same connection still count as one stream.

| Plan     | Yellowstone gRPC limit |
| -------- | ---------------------: |
| Stream   |       up to 10 streams |
| Aperture |       up to 25 streams |

#### Filter limits

RPC Fast’s Yellowstone limits are designed for targeted subscriptions rather than unrestricted firehose filters.

**Global**

* Filter name length: up to **128 characters**

**Accounts**

* **1** accounts filter
* Empty filter (match everything) is **not supported**
* Up to **10** pubkeys in `account`
* Up to **10** pubkeys in `owner`
* Up to **2** `accounts_data_slice` ranges

**Slots**

* **1** slots filter

**Transactions**

* **1** transactions filter
* Empty filter (match everything) is **not supported**
* Up to **10** pubkeys in `account_include`
* Up to **10** pubkeys in `account_exclude`
* Up to **10** pubkeys in `account_required`

**Transaction status**

* **1** transaction-status filter
* Empty filter (match everything) is **not supported**
* Up to **10** pubkeys in `account_include`
* Up to **10** pubkeys in `account_exclude`
* Up to **10** pubkeys in `account_required`

**Entries**

* **1** entries filter

**Block metadata**

* **1** block-metadata filter

**Blocks**

* **1** blocks filter
* Up to **10** pubkeys in `account_include`
* Empty `account_include` is **not supported**
* Transactions are included
* Accounts and entries inclusion **is disabled**

### Keep-alive and long-lived subscriptions

Long-lived gRPC subscriptions should enable both transport-level and application-level keepalive.

RPC Fast recommends:

* TCP keepalive enabled
* HTTP/2 keepalive enabled
* handling Yellowstone `ping` messages on the stream

This helps reduce disconnects caused by load balancers, proxies, NAT timeouts, and idle connection cleanup.

***

### Code examples

Replace `YOUR-TOKEN-HERE` with your Yellowstone gRPC token.

{% tabs %}
{% tab title="Rust" %}

```rust
use futures::StreamExt;
use std::collections::HashMap;
use std::time::Duration;
use yellowstone_grpc_client::{ClientTlsConfig, GeyserGrpcClient};
use yellowstone_grpc_proto::geyser::{
    subscribe_update::UpdateOneof,
    CommitmentLevel,
    SubscribeRequest,
    SubscribeRequestFilterTransactions,
};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let _ = rustls::crypto::aws_lc_rs::default_provider().install_default();

    let mut client = GeyserGrpcClient::build_from_shared("https://solana-yellowstone-grpc.rpcfast.com:443")?
        .x_token(Some("YOUR-TOKEN-HERE"))?
        .http2_keep_alive_interval(Duration::from_secs(30))
        .keep_alive_timeout(Duration::from_secs(10))
        .keep_alive_while_idle(true)
        .tcp_keepalive(Some(Duration::from_secs(30)))
        .tcp_nodelay(true)
        .tls_config(ClientTlsConfig::new().with_native_roots())?
        .connect()
        .await?;

    let mut tx_filters = HashMap::new();
    tx_filters.insert(
        "raydium".to_string(),
        SubscribeRequestFilterTransactions {
            vote: Some(false),
            failed: Some(false),
            signature: None,
            account_include: vec![
                "675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8".to_string(),
            ],
            account_exclude: vec![],
            account_required: vec![],
        },
    );

    let request = SubscribeRequest {
        transactions: tx_filters,
        commitment: Some(CommitmentLevel::Processed as i32),
        ..Default::default()
    };

    let (_sink, mut stream) = client.subscribe_with_request(Some(request)).await?;

    println!("Yellowstone stream started");

    while let Some(message) = stream.next().await {
        let message = message?;

        if let Some(UpdateOneof::Transaction(tx_update)) = message.update_oneof {
            println!("slot={}", tx_update.slot);

            if let Some(tx) = tx_update.transaction {
                if !tx.signature.is_empty() {
                    println!(
                        "signature={}",
                        bs58::encode(&tx.signature).into_string()
                    );
                }
            }
        }
    }

    Ok(())
}
```

{% endtab %}

{% tab title="TypeScript" %}

```ts
import Client, {
  CommitmentLevel,
  SubscribeRequest,
  ChannelOptions,
} from "@triton-one/yellowstone-grpc";
import bs58 from "bs58";

const X_TOKEN = "YOUR-TOKEN-HERE";

async function main() {
  const channelOptions: ChannelOptions = {
    grpcHttp2KeepAliveInterval: 30_000,
    grpcKeepAliveTimeout: 10_000,
    grpcKeepAliveWhileIdle: true,
    grpcTcpKeepalive: 1,
  };

  const client = new Client(
    "https://yellowstone-grpc.rpcfast.com:443",
    X_TOKEN,
    channelOptions
  );

  await client.connect();

  const stream = await client.subscribe();

  stream.on("data", (update) => {
    if (update.transaction?.transaction?.transaction?.signatures?.length) {
      const signature = bs58.encode(
        update.transaction.transaction.transaction.signatures[0]
      );
      console.log("signature:", signature);
      console.log("slot:", update.transaction.slot);
    }

    if (update.ping) {
      const pong: SubscribeRequest = {
        ping: { id: update.ping.id },
        accounts: {},
        slots: {},
        transactions: {},
        transactionsStatus: {},
        blocks: {},
        blocksMeta: {},
        entry: {},
        accountsDataSlice: [],
      };
      stream.write(pong, () => {});
    }
  });

  stream.on("error", (err) => {
    console.error("stream error:", err);
  });

  const request: SubscribeRequest = {
    transactions: {
      raydium: {
        vote: false,
        failed: false,
        accountInclude: ["675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8"],
        accountExclude: [],
        accountRequired: [],
      },
    },
    accounts: {},
    slots: {},
    transactionsStatus: {},
    blocks: {},
    blocksMeta: {},
    entry: {},
    accountsDataSlice: [],
    commitment: CommitmentLevel.PROCESSED,
  };

  await new Promise<void>((resolve, reject) => {
    stream.write(request, (err: Error | null | undefined) => {
      if (err) reject(err);
      else resolve();
    });
  });
}

main().catch(console.error);
```

{% endtab %}

{% tab title="grpcurl" %}

```bash
grpcurl \
  -proto geyser.proto \
  -H "x-token: YOUR-TOKEN-HERE" \
  -d '{
    "transactions": {
      "raydium": {
        "vote": false,
        "failed": false,
        "account_include": [
          "675kPX9MHTjS2zt1qfr1NYHuzeLXfQM9H24wFSUt1Mp8"
        ]
      }
    },
    "accounts": {},
    "slots": {},
    "transactions_status": {},
    "blocks": {},
    "blocks_meta": {},
    "accounts_data_slice": [],
    "commitment": "PROCESSED"
  }' \
  yellowstone-grpc.rpcfast.com:443 \
  geyser.Geyser/Subscribe
```

{% endtab %}
{% endtabs %}

***

### Summary

Yellowstone gRPC is RPC Fast’s developer-oriented streaming interface for Solana backends that need:

* structured real-time data
* server-side filtering
* richer payloads than standard WebSocket subscriptions
* low client-side parsing overhead
* stable long-lived streaming over gRPC

For backend services that ingest, enrich, persist, or react to Solana events continuously, Yellowstone gRPC is generally the preferred integration surface.


# Aperture TxStream

RPC Fast's optimised protocol for real-time deshredded Solana transactions and transaction simulation.

TxStream is RPC Fast's purpose-built gRPC protocol for receiving decoded Solana transactions directly from the shred pipeline. It is a highly flexible protocol with transaction filtering, real-time transaction simulation, signatures-only responses, and batch transaction delivery.

**We reinvented shred-level transaction streaming:** RPC Fast reconstructs, recovers, deshreds, decodes, filters, and streams transactions through one optimised path, before normal validator replay metadata is available.

{% hint style="success" %}
Use TxStream when transaction arrival time matters more than confirmed post-execution metadata.
{% endhint %}

{% hint style="info" %}
For a limited time, Aperture TxStream is also available on the **Stream plan** – without transaction execution simulation. The full version with real-time simulation is included in the Aperture plan.

Starting **September 1,** the Aperture TxStream protocol will become **exclusive to the Aperture plan**.
{% endhint %}

## Why Use TxStream?

* **Faster transaction delivery.** The protocol is optimised specifically for transaction streaming, with compact payload and batch delivery modes.
* **Lower client overhead.** Transactions arrive decoded, with no raw shred or Solana Entry reconstruction required in your application.
* **Server-side filters.** Filter by vote status, signature, included accounts, excluded accounts, or required accounts before data crosses the network.
* **Compact modes.** Use `signatures_only` for timing and monitoring workloads, or batch transaction delivery to reduce per-message gRPC overhead.
* **Resolved Address Lookup Tables.** RPC Fast was one of the first providers to resolve ALTs for deshredded transactions. Loaded writable and read-only addresses are included when available and participate in account filters.
* **Real-time transaction simulation.** RPC Fast is the first provider to offer real-time simulation of deshredded transactions. Transaction-status simulation achieves approximately 95% accuracy compared with actual execution results.

## Performance Comparisons

RPC Fast compares identical transaction signatures received at the same observer. The comparison uses local receive timestamps.

### TxStream vs ShredStream

This comparison measures when the decoded transaction becomes available to the client. TxStream delivered the decoded transaction first in most matched races.

| TxStream mode            | TxStream arrived first | TxStream median lead when first | TxStream p90 lead when first |
| ------------------------ | ---------------------: | ------------------------------: | ---------------------------: |
| Signatures only          |                  77.6% |                          231 us |                       531 us |
| Full transaction payload |                  75.6% |                          197 us |                       463 us |

### TxStream vs Aperture Yellowstone interface

| TxStream mode            | TxStream arrived first | TxStream median lead when first | TxStream p90 lead when first |
| ------------------------ | ---------------------: | ------------------------------: | ---------------------------: |
| Signatures only          |                  96.3% |                          280 us |                       641 us |
| Full transaction payload |                  93.8% |                          232 us |                       509 us |

### TxStream vs Yellowstone gRPC

| TxStream mode            | TxStream arrived first | TxStream median lead when first | TxStream p90 lead when first |
| ------------------------ | ---------------------: | ------------------------------: | ---------------------------: |
| Signatures only          |                 99.97% |                         7.77 ms |                     22.35 ms |
| Full transaction payload |                 99.97% |                         7.72 ms |                     22.28 ms |

## Protocol Reference

Full protocol reference can be found at <https://github.com/dysnix/aperture-grpc-proto>

TxStream uses the `aperture.Aperture` gRPC service and a single request format for both delivery modes.

### Request Format

Both subscription methods accept `SubscribeTransactionsRequest`:

| Field                | Type             | Default           | Description                                                               |
| -------------------- | ---------------- | ----------------- | ------------------------------------------------------------------------- |
| `vote`               | `VoteFilter`     | `VOTE_FILTER_ALL` | Stream all transactions, votes only, or non-votes only.                   |
| `signature`          | `bytes`          | empty             | Match one 64-byte primary transaction signature.                          |
| `account_include`    | repeated `bytes` | empty             | Match when any listed 32-byte static or loaded account is present.        |
| `account_exclude`    | repeated `bytes` | empty             | Reject when any listed 32-byte static or loaded account is present.       |
| `account_required`   | repeated `bytes` | empty             | Match only when every listed 32-byte static or loaded account is present. |
| `signatures_only`    | `bool`           | `false`           | Return only transaction identity and timing fields.                       |
| `include_simulation` | `bool`           | `false`           | Add a transaction-status simulation result to each response.              |

Different filter fields are combined with logical **AND**. Values inside `account_include` and `account_exclude` use **OR**, while every `account_required` value must match. With no filters, TxStream delivers all transactions.

### Non-Batch and Batch Delivery

<table><thead><tr><th width="236.21875"></th><th width="269.11328125">Non-batch mode</th><th width="246.015625">Batch transaction delivery</th></tr></thead><tbody><tr><td>RPC</td><td><code>/aperture.Aperture/SubscribeTransactions</code></td><td><code>/aperture.Aperture/SubscribeTransactionBatches</code></td></tr><tr><td>Response stream</td><td><code>DecodedTransaction</code></td><td><code>DecodedTransactionBatch</code></td></tr><tr><td>Delivery behavior</td><td>Emits each matching transaction in its own gRPC message.</td><td>Immediately emits available matching transactions, up to 64 per batch, without waiting for the batch to fill.</td></tr><tr><td>Best suited for</td><td>Minimum transaction-by-transaction delivery delay.</td><td>High-throughput consumers that want fewer protobuf and gRPC messages.</td></tr><tr><td>Ordering without simulation</td><td>Transactions are delivered in stream order, with indexes <code>0, 1, 2, …</code>.</td><td>Transactions remain ordered within each batch and across consecutive batches.</td></tr><tr><td>Ordering with simulation</td><td>Transactions are delivered as soon as their simulations complete. Delivery may therefore be out of order—for example, <code>1, 2, 0</code>—while <code>index</code> preserves the original stream order.</td><td>Transaction order is preserved. A batch is delivered only after all simulations in that batch finish, so its latency is determined by the slowest simulation.</td></tr></tbody></table>

The same filters, `signatures_only` mode, and simulation option are available in both delivery modes.

{% hint style="success" icon="circle-info" %}
Use the non-batch stream when the lowest possible simulation latency is the priority. Use the batch stream when preserving delivery order is more important.
{% endhint %}

### Transaction Response Format

`DecodedTransaction` contains:

| Field                       | Type                           | Description                                               |
| --------------------------- | ------------------------------ | --------------------------------------------------------- |
| `slot`                      | `uint64`                       | Solana slot containing the transaction.                   |
| `index`                     | `uint64`                       | Transaction index within the subscription.                |
| `is_vote`                   | `bool`                         | Whether this is a vote transaction.                       |
| `created_at_unix_nanos`     | `uint64`                       | Transaction stream timestamp in Unix nanoseconds.         |
| `signatures`                | repeated `bytes`               | Transaction signatures; each signature is 64 bytes.       |
| `version`                   | `TransactionVersion`           | `TRANSACTION_VERSION_LEGACY` or `TRANSACTION_VERSION_V0`. |
| `header`                    | `MessageHeader`                | Required-signature and read-only-account counts.          |
| `static_account_keys`       | repeated `bytes`               | Static 32-byte account keys from the transaction message. |
| `loaded_writable_addresses` | repeated `bytes`               | Resolved writable 32-byte ALT addresses.                  |
| `loaded_readonly_addresses` | repeated `bytes`               | Resolved read-only 32-byte ALT addresses.                 |
| `recent_blockhash`          | `bytes`                        | The transaction's 32-byte recent blockhash.               |
| `instructions`              | repeated `CompiledInstruction` | Compiled transaction instructions.                        |
| `simulation`                | `TransactionSimulation`        | Present when `include_simulation` is enabled.             |

`MessageHeader` contains `num_required_signatures`, `num_readonly_signed_accounts`, and `num_readonly_unsigned_accounts`. `CompiledInstruction` contains `program_id_index`, the instruction's account indexes, and its raw instruction data.

Instruction account indexes refer to the following concatenated key list:

`static_account_keys + loaded_writable_addresses + loaded_readonly_addresses`

When `signatures_only` is enabled, responses retain `slot`, `index`, `is_vote`, `created_at_unix_nanos`, `signatures`, `version`, and an optional simulation result. Transaction message fields are omitted.

### Batch Response Format

`DecodedTransactionBatch` contains one field:

| Field          | Type                          | Description                                               |
| -------------- | ----------------------------- | --------------------------------------------------------- |
| `transactions` | repeated `DecodedTransaction` | One to 64 transactions matching the subscription request. |

Each transaction has the same format as a non-batch response.

### Simulation Response Format

When requested, `TransactionSimulation` contains:

| Field                     | Type               | Description                                      |
| ------------------------- | ------------------ | ------------------------------------------------ |
| `bank_slot`               | optional `uint64`  | Slot used for the simulation result.             |
| `status`                  | `SimulationStatus` | Simulation outcome.                              |
| `error`                   | optional `string`  | Error details when simulation is not successful. |
| `simulated_at_unix_nanos` | `uint64`           | Simulation timestamp in Unix nanoseconds.        |
| `processing_time_nanos`   | `uint64`           | Simulation processing duration in nanoseconds.   |

`SimulationStatus` values:

<table data-search="false"><thead><tr><th>Status</th><th>Meaning</th></tr></thead><tbody><tr><td><code>SIMULATION_STATUS_SUCCEEDED</code></td><td>The simulation succeeded.</td></tr><tr><td><code>SIMULATION_STATUS_FAILED</code></td><td>The simulation failed.</td></tr><tr><td><code>SIMULATION_STATUS_INVALID_TRANSACTION</code></td><td>The transaction is invalid.</td></tr><tr><td><code>SIMULATION_STATUS_BANK_NOT_AVAILABLE</code></td><td>The required Bank state was unavailable. The transaction may still be valid, but no simulation outcome is available.</td></tr><tr><td><code>SIMULATION_STATUS_SERVER_OVERLOADED</code></td><td>Simulation exceeded its time limit. RPC Fast limits simulation time to preserve TxStream delivery performance.</td></tr><tr><td><code>SIMULATION_STATUS_INTERNAL_ERROR</code></td><td>An internal error occurred during simulation.</td></tr></tbody></table>

## Use the Official Rust Client

As a best practice, use the official [`dysnix/aperture-grpc-client`](https://github.com/dysnix/aperture-grpc-client). It provides byte-safe filters, tuned HTTP/2 flow control, TLS native roots, keepalives, `X-Token` authentication, and automatic reconnection.

Set `APERTURE_X_TOKEN` to your RPC Fast token before running the example.

```rust
use aperture_grpc_client::{
    ApertureClientConfig, ApertureGrpcClient, SubscribeFilters, VoteFilter,
};
use futures_util::StreamExt;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let token = std::env::var("APERTURE_X_TOKEN")?;
    let config = ApertureClientConfig::new("https://aperture-txstream.rpcfast.com:443")
        .with_x_token(token);
    let client = ApertureGrpcClient::new(config);

    let filters = SubscribeFilters::default().vote(VoteFilter::NonVoteOnly);
    let mut stream = Box::pin(client.subscribe_with_reconnect(filters));

    while let Some(message) = stream.next().await {
        let transaction = message?;
        println!(
            "slot={} index={} signatures={}",
            transaction.slot,
            transaction.index,
            transaction.signatures.len()
        );
    }

    Ok(())
}
```

An empty filter streams all transactions. Apply the narrowest server-side filter that serves your workload to reduce bandwidth and client-side work.

## Request Real-Time Simulation

Set the client's `include_simulation` option when you need a predicted result for every matching deshredded transaction.

```rust
use aperture_grpc_client::{
    ApertureClientConfig, ApertureGrpcClient, SimulationStatus, SubscribeFilters,
    VoteFilter,
};
use futures_util::StreamExt;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let token = std::env::var("APERTURE_X_TOKEN")?;
    let config = ApertureClientConfig::new("https://aperture-txstream.rpcfast.com:443")
        .with_x_token(token);
    let client = ApertureGrpcClient::new(config);

    let filters = SubscribeFilters::default()
        .vote(VoteFilter::NonVoteOnly)
        .include_simulation();
    let mut stream = Box::pin(client.subscribe_with_reconnect(filters));

    while let Some(message) = stream.next().await {
        let transaction = message?;
        let Some(simulation) = transaction.simulation else {
            continue;
        };
        let status = SimulationStatus::try_from(simulation.status)
            .unwrap_or(SimulationStatus::Unspecified);

        println!(
            "slot={} status={status:?} bank_slot={:?} error={:?}",
            transaction.slot,
            simulation.bank_slot,
            simulation.error
        );
    }

    Ok(())
}
```

Simulation results can include:

* simulation status and error
* simulation slot
* simulation timestamp and processing time

{% hint style="warning" %}
Enabling simulation adds latency. Simulation results are predictive and may differ from the transaction's eventual execution outcome; transaction-status simulation accuracy is approximately 95% compared with actual execution results.
{% endhint %}

Clients that do not request simulation remain on the immediate pre-execution path. For a compact prediction feed, combine `include_simulation` with `signatures_only`.

### Simulation Delivery Latency

The matched-signature comparison measured simulation-enabled TxStream against the equivalent non-simulation stream:

| TxStream mode            | Median added delivery time | p90 added delivery time |
| ------------------------ | -------------------------: | ----------------------: |
| Signatures only          |                     832 us |                 1.72 ms |
| Full transaction payload |                     791 us |                 1.62 ms |

## Receive Transaction Batches

Use the batch stream when throughput and lower protobuf/gRPC overhead matter more than emitting each transaction in its own message.

```rust
use aperture_grpc_client::{
    ApertureClientConfig, ApertureGrpcClient, SubscribeFilters, VoteFilter,
};
use futures_util::StreamExt;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let token = std::env::var("APERTURE_X_TOKEN")?;
    let config = ApertureClientConfig::new("https://aperture-txstream.rpcfast.com:443")
        .with_x_token(token);
    let client = ApertureGrpcClient::new(config);
    let filters = SubscribeFilters::default()
        .vote(VoteFilter::NonVoteOnly)
        .signatures_only();
    let mut stream = Box::pin(client.subscribe_batches_with_reconnect(filters));

    while let Some(message) = stream.next().await {
        let batch = message?;
        println!("transactions={}", batch.transactions.len());
    }

    Ok(())
}
```

## Important Semantics

TxStream is an early transaction feed, not a final source of execution truth.

* A streamed transaction can fail, never confirm, or land on a fork that does not survive.
* The normal pre-execution stream does not contain confirmed balances, inner instructions, rewards, execution status, or final program logs.
* ALT addresses are emitted when resolved. You must tolerate unresolved addresses and must not treat the stream as authoritative replay state.
* Reconnect after transport failures. The official client does this automatically with exponential backoff.

Use [Yellowstone gRPC](/rpc-fast-saas-solana/data-streaming/yellowstone-grpc) when you need confirmed execution metadata, account updates, blocks, or other replay-derived data.

## Test TxStream with grpcurl

Download the official [`txstream.proto`](https://raw.githubusercontent.com/dysnix/aperture-grpc-proto/main/proto/aperture/txstream.proto) file to your current directory, set `APERTURE_X_TOKEN`, and start a non-vote transaction stream:

```bash
grpcurl \
  -proto txstream.proto \
  -H "x-token: ${APERTURE_X_TOKEN}" \
  -d '{
    "vote": "VOTE_FILTER_NON_VOTE_ONLY",
    "signaturesOnly": true
  }' \
  aperture-txstream.rpcfast.com:443 \
  aperture.Aperture/SubscribeTransactions
```

Set `"includeSimulation": true` in the request body to test the simulation-enabled stream.

## When to Use TxStream

The use cases can be split into two categories:

1/ **Decoded, reconstructed transactions –** better developer experience, less engineering work.

Key benefit: less custom infrastructure, faster integration, and no need to decode shreds or reconstruct transactions yourself.

Best for

* **HFT bot developers** looking for the fastest path to production with minimal engineering effort.
* **Trading platforms** that need transaction parsing without maintaining their own decoder.
* **Wallets** tracking pending user transactions.
* **Analytics & monitoring platforms** consuming structured real-time transaction data.
* **Copy trading platforms** monitoring market activity before block confirmation.
* **Solana developers** who need pre-confirmation data without building a shred reconstruction pipeline.

2/ **Real-time execution simulation** – decision-making edge for latency-sensitive applications).

Key benefit: fewer wasted transactions, fewer false positives, lower compute costs, and faster decision-making under tight latency constraints.

Best for

* **MEV searchers** filtering profitable opportunities from transactions that will actually execute.
* **Arbitrage bots** avoiding failed swaps and reducing false-positive signals.
* **Liquidation bots** confirming liquidation candidates before committing capital.
* **High-frequency trading (HFT) systems** making routing decisions with higher confidence.
* **Market makers** reacting only to executable market events.
* **Copy-trading platforms** replicating only transactions likely to succeed.
* **Risk engines** estimating execution outcomes before block inclusion.


# Aperture gRPC

Low Latency Solana Data, Forged in Performance.

### What is Aperture gRPC?

Aperture gRPC reconstructs validator shreds into a structured gRPC stream compatible with the Yellowstone subscription model, while bypassing traditional RPC node processing.

In practice, that means earlier transaction visibility than standard Yellowstone-style streams, with server-side filtering and a client experience that feels familiar if you already use Yellowstone.

{% hint style="info" %}
Aperture is designed for applications where reaction time matters more than full post-execution metadata.
{% endhint %}

{% hint style="warning" %}
Yellowstone-compatible version of the Aperture gRPC **will be deprecated** in the short future as **Aperture TxStream** becomes our primary low-latency streaming protocol.
{% endhint %}

### What Data is Available?

Aperture gRPC is designed for **low-latency transactions streaming**.

Following transaction data is available:

* signatures
* slot number
* recent blockhash
* is\_vote
* static account keys
* address lookup tables
* instructions

Because the stream is reconstructed directly from shreds before full transaction execution completes, it does not include the extended replay metadata typically available in Yellowstone transaction feeds, such as:

* errors
* balance changes
* inner instructions (CPI)
* program logs
* compute unit usage
* transaction status

Think of Aperture gRPC as receiving the transaction message **as soon as it can be decoded from shreds**, not after a validator has completed full execution and metadata generation.

### Why Use Aperture?

Use **Aperture gRPC** when your application needs:

* the earliest possible visibility into incoming Solana transactions
* Yellowstone-style subscription ergonomics
* server-side filtering by signature or mentioned accounts
* reduced bandwidth usage compared to ShredStream when filters are applied
* ALT (Address Lookup Table) resolution for versioned transactions
* minimal client-side decoding compared to raw UDP shreds or ShredStream gRPC

Typical use cases include:

* trading systems
* searchers
* real-time analytics
* ingestion pipelines
* latency-sensitive backend services

### Compatibility Model

Aperture gRPC follows the Yellowstone's subscription model. The same general request shape applies: a bidirectional stream where the client sends a `SubscribeRequest` and receives matching updates continuously.

For transaction subscriptions, the familiar Yellowstone filter semantics apply:

* if all transaction filter fields are empty, all transactions are streamed
* different fields are combined with logical **AND**
* values inside each array are combined with logical **OR**

Common transaction filters include:

* `vote`
* `signature`
* `account_include`
* `account_exclude`
* `account_required`

### Important Limitations

**Aperture gRPC prioritises speed, so it is not a substitute for every Yellowstone use case.**

Consider using **Yellowstone gRPC** instead, when you need:

* full transaction execution metadata
* balance updates
* program logs
* fully resolved address lookup tables
* account state changes and block data

{% hint style="warning" %}
Aperture should be treated as an **early transaction stream,** not as a final source of execution truth.
{% endhint %}

A decoded transaction may still fail, never confirm, or land on a fork that does not survive.

### Subscription Examples

Replace the `YOUR-TOKEN-HERE` placeholder below with your Aperture gRPC token.

{% tabs %}
{% tab title="Rust" %}

```rust
use futures::StreamExt;
use std::collections::HashMap;
use std::time::Duration;
use yellowstone_grpc_client::{ClientTlsConfig, GeyserGrpcClient};
use yellowstone_grpc_proto::geyser::{
    subscribe_update::UpdateOneof,
    CommitmentLevel,
    SubscribeRequest,
    SubscribeRequestFilterTransactions,
};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let _ = rustls::crypto::aws_lc_rs::default_provider().install_default();

    let mut client = GeyserGrpcClient::build_from_shared("https://aperture-grpc.rpcfast.com:443")?
        .x_token(Some("YOUR-TOKEN-HERE"))?
        .http2_keep_alive_interval(Duration::from_secs(30))
        .keep_alive_timeout(Duration::from_secs(10))
        .keep_alive_while_idle(true)
        .tcp_keepalive(Some(Duration::from_secs(30)))
        .tcp_nodelay(true)
        .tls_config(ClientTlsConfig::new().with_native_roots())?
        .connect()
        .await?;

    let mut tx_filters = HashMap::new();
    tx_filters.insert(
        "pumpfun".to_string(),
        SubscribeRequestFilterTransactions {
            vote: Some(false),
            failed: None,
            signature: None,
            account_include: vec![
                "pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA".to_string(),
            ],
            account_exclude: vec![],
            account_required: vec![],
        },
    );

    let request = SubscribeRequest {
        transactions: tx_filters,
        commitment: Some(CommitmentLevel::Processed as i32),
        ..Default::default()
    };

    let (_sink, mut stream) = client.subscribe_with_request(Some(request)).await?;

    println!("Aperture stream started");

    while let Some(message) = stream.next().await {
        let message = message?;
        if let Some(UpdateOneof::Transaction(tx_update)) = message.update_oneof {
            println!("slot={}", tx_update.slot);

            if let Some(tx) = tx_update.transaction {
                if !tx.signature.is_empty() {
                    println!("signature={}", bs58::encode(&tx.signature).into_string());
                }
            }
        }
    }

    Ok(())
}
```

{% endtab %}

{% tab title="TypeScript" %}

```typescript
import Client, {
  CommitmentLevel,
  SubscribeRequest,
  ChannelOptions
} from "@triton-one/yellowstone-grpc";
import bs58 from "bs58";

const X_TOKEN = "YOUR-TOKEN-HERE";

async function main() {
  const channelOptions: ChannelOptions = {
    grpcHttp2KeepAliveInterval: 30_000,
    grpcKeepAliveTimeout: 10_000,
    grpcKeepAliveWhileIdle: true,
    grpcTcpKeepalive: 1,
  };

  const client = new Client(
    "https://aperture-grpc.rpcfast.com:443",
    X_TOKEN,
    channelOptions
  );

  await client.connect();

  const stream = await client.subscribe();

  stream.on("data", (update) => {
    if (update.transaction?.transaction?.transaction?.signatures?.length) {
      const signature = bs58.encode(update.transaction.transaction.transaction.signatures[0]);
      console.log("signature:", signature);
      console.log("slot:", update.transaction.slot);
    }

    if (update.pong) {
      console.log("pong");
    }
  });

  stream.on("error", (err) => {
    console.error("stream error:", err);
  });

  const request: SubscribeRequest = {
    slots: {},
    accounts: {},
    transactions: {
      pumpfun: {
        vote: false,
        accountInclude: ["pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA"],
        accountExclude: [],
        accountRequired: [],
      },
    },
    transactionsStatus: {},
    blocks: {},
    blocksMeta: {},
    entry: {},
    accountsDataSlice: [],
    commitment: CommitmentLevel.PROCESSED,
  };

  await new Promise<void>((resolve, reject) => {
    stream.write(request, (err: Error | null | undefined) => {
      if (err) reject(err);
      else resolve();
    });
  });

  setInterval(() => {
    const ping: SubscribeRequest = {
      ping: { id: 1 },
      slots: {},
      accounts: {},
      transactions: {},
      transactionsStatus: {},
      blocks: {},
      blocksMeta: {},
      entry: {},
      accountsDataSlice: [],
    };

    stream.write(ping, () => {});
  }, 1_000);
}

main().catch(console.error);

```

{% endtab %}

{% tab title="grpcurl" %}

```shell
grpcurl \
  -proto geyser.proto \
  -H "x-token: YOUR_TOKEN" \
  -d '{
    "slots": {},
    "accounts": {},
    "transactions": {
      "pumpfun": {
        "vote": false,
        "account_include": [
          "pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA"
        ]
      }
    },
    "blocks": {},
    "blocks_meta": {},
    "accounts_data_slice": [],
    "commitment": "PROCESSED"
  }' \
  aperture-grpc.rpcfast.com:443 \
  geyser.Geyser/Subscribe
```

{% endtab %}
{% endtabs %}

### Choosing Commitment Level

Aperture gRPC always streams data at `processed` commitment level, so specifying any higher commitment level is ignored.

### Keep-alive and Reconnection

For long-lived gRPC streams, it is recommended that you use both:

* *TCP keepalive*, so dead TCP connections are detected earlier.
* *HTTP/2 keepalive*, so intermediaries such as load balancers, proxies, or NAT devices are less likely to silently drop idle connections.

This is especially important for applications that keep a subscription open for a long time with uneven traffic patterns.

### Aperture vs. Shredstream vs. Yellowstone

|                     | Aperture gRPC                                                  | Shredstream gRPC                      | Yellowstone gRPC                      |
| ------------------- | -------------------------------------------------------------- | ------------------------------------- | ------------------------------------- |
| **Data source**     | Validator shreds                                               | Validator shreds                      | RPC Node                              |
| **Output format**   | Yellowstone-compatible transactions, slots, and entries stream | Raw Solana entry stream               | Full Yellowstone stream               |
| **Latency profile** | \~30–40 ms faster than Yellowstone                             | Slightly slower than Aperture (\~1ms) | Higher than shred-derived streams     |
| **Filtering**       | Server-side                                                    | Client-side only                      | Server-side                           |
| **Client work**     | Low                                                            | Highest                               | Low                                   |
| **Best fit**        | Shred-level latency with easy integration                      | Maximum low-level control             | Rich metadata and broader replay data |

#### Aperture vs. Yellowstone

**Aperture gRPC delivers transactions earlier** by decoding them directly from validator shreds instead of waiting for the full Geyser pipeline.

This typically reduces latency by 30–40 ms, while trading away extended replay metadata.

**Yellowstone gRPC remains the better fit** when your system depends on:

* transaction status
* balance updates
* inner instructions
* logs
* richer post-execution context

#### Aperture vs. Shredstream

**Shredstream gRPC** exposes a lower-level Solana entry gRPC stream and leaves decoding and filtering to the client.

**Aperture gRPC** shines with even better latency characteristics, streams already-decoded transaction data in Yellowstone gRPC format and supports server-side filtering. That reduces implementation complexity for teams that want shred-level speed without building a shred-decoding pipeline themselves, as well as saves bandwidth due to server-side filtering.

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

### Summary

**Aperture gRPC** is the right tool when you want:

* the earliest practical Solana transaction visibility
* Yellowstone-style subscriptions and filtering
* less infrastructure and parsing work than raw shred or entry feeds

Use **Yellowstone gRPC** when correctness and metadata depth matter more than raw arrival time.

Use **Shredstream gRPC** only when you intentionally want the full control over low-level decoding and processing and don't mind higher bandwidth usage.


# Shredstream gRPC

Coming soon


# WebSockets

Coming soon

Refer to Docs for more info: <https://solana.com/docs/rpc/websocket>


# Sending transactions

Blazing-fast transaction sending service

##


# SWQoS

**RPC Fast** offer own sender service – **Beam**, which routes signed transactions through partner delivery paths such as SWQoS-backed validators, Jito Block Engine submission, and other provider-specific low-latency infrastructure. [Read more](/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta).

## Overview

**Stake-Weighted Quality of Service (SWQoS)** is a networking mechanism in Solana that prioritizes transaction delivery based on validator stake.

Because Solana runs on Proof of Stake, validators with more delegated SOL are allocated proportionally more bandwidth when forwarding transactions to the current leader. SWQoS uses this stake weighting to determine **how much transaction traffic** a node is allowed to push through **to a leader’s TPU** (Transaction Processing Unit).

In simple terms:

> Stake = network bandwidth priority.

During congestion, stake-backed traffic receives preferential access to the leader, while unstaked traffic is significantly rate-limited.

* RPC nodes themselves *cannot stake*, but they can form trusted, peered connections with a **staked validator**. The validator then forwards transactions on the RPC’s behalf – effectively giving the RPC *virtual stake access* to that priority lane.

SWQoS ensures that transactions sent through staked connections are much more likely to be admitted quickly into the leader’s pipeline – before on-chain priority fees and ordering – reducing packet loss and delays under load.

***

### How SWQoS Works

<table><thead><tr><th width="274.19281005859375">Concept</th><th>Impact</th></tr></thead><tbody><tr><td><strong>SWQoS Priority Lanes</strong></td><td>Higher chance that transactions make it to the leader, especially under congestion.</td></tr><tr><td><strong>Staked Validator Peering</strong></td><td>RPCs gain priority by proxying through validator stake.</td></tr><tr><td><strong>Pre-Priority Fee Optimization</strong></td><td>SWQoS improves <em>access</em>, while priority fees affect <em>inclusion ordering</em>.</td></tr><tr><td><strong>Critical for HFT/DeFi</strong></td><td>Ensures timing reliability, landing rates, and lower variance.</td></tr></tbody></table>

1. **Staked Validator Priority:**\
   Validators with significant delegated stake are allowed to send more packets / receive proportionally more quota to establish QUIC/TPU connections to leaders, acting like a *priority lane* relative to non-stake traffic.
2. **Peered RPCs Gain Priority via Validators:**\
   Since RPCs are unstaked, they must be paired with a staked validator. That validator configures stake maps/peering so your RPC traffic inherits a portion of their access, boosting your transaction throughput.\
   **Staked connection:** Your RPC → Trusted staked validator → Current leader
3. **Bandwidth Allocation:**\
   SWQoS does *not* eliminate fee competition; it improves *access*. Once on the leader’s pipeline via SWQoS lanes, transactions still compete based on priority fees.

#### SWQoS ≠ Priority Fees

It’s important to separate the two:

<table><thead><tr><th width="276.80145263671875">Layer</th><th>What It Controls</th></tr></thead><tbody><tr><td><strong>SWQoS</strong></td><td>Whether your transaction reaches the leader under congestion</td></tr><tr><td><strong>Priority Fees</strong></td><td>Ordering of transactions once inside the leader queue</td></tr></tbody></table>

You can pay high priority fees – but if your packets never reach the leader because your connection is rate-limited, the fee doesn’t matter.

For high-performance systems, **delivery probability comes first.**

***

### Why SWQoS Matters for High-Performance Use Cases

Here’s where SWQoS becomes **crucial** for latency- and reliability-sensitive applications:

#### HFT & Trading Bots

* **Consistent landing rates:** Bots competing for arbitrage or liquidation opportunities must consistently land transactions in the same slot as targets. SWQoS increases the likelihood that a transaction *reaches the leader’s TPU queue early*, reducing misses during momentary congestion.
* **Reduced uncertainty:** Without SWQoS, even high priority fees may fail to deliver a transaction if the network refuses the connection itself under load. SWQoS helps ensure the connection isn’t the bottleneck.

#### DeFi Infrastructure

* **Reliability under load:** Time-critical DeFi ops like liquidations or automated market making thrive on guaranteed delivery. Public or unstaked RPC endpoints can easily fail during peak mints/NFT launches – SWQoS routes around this.
* **Scalability:** As demand scales, staked connections deliver higher *effective throughput* and can be further bolstered with stake-backed allocation models (e.g., TPS quotas tied to liquid stake holdings).

#### General RPC Performance

* **Fewer dropped packets:** By bypassing the limited non-staked queue, you avoid dropped or delayed transaction packets, which boosts user experience for wallets, games, and other dApps during traffic spikes.
* **Improved Sybil resistance:** Stake weighting makes the network harder to spam, lowering risk of malicious congestion.

***

### Why Combining SWQoS + ShredStream Matters

Latency-sensitive systems operate in a tight feedback loop:

> Detect opportunity –> Construct transaction –> Deliver to leader –> Observe inclusion/result

ShredStream improves information latency; SWQoS improves delivery probability. **Together, they reduce both information lag and execution uncertainty.**

**You likely need both** SWQoS and ShredStream if:

* You compete in same-slot MEV races.
* Your strategy depends on reacting within sub-slot windows.
* Your PnL is sensitive to packet drops.
* You operate during high network contention periods.

For casual dApps, neither is required. For adversarial systems, both become infrastructure basics.


# RPC Fast Beam (Beta)

Solana transaction delivery for latency-sensitive workloads.

## Overview

{% hint style="info" %}
RPC Fast Beam is currently in beta. Core changes may be introduced as the product evolves.
{% endhint %}

**RPC Fast Beam** is a low-latency Solana transaction submission service for execution-sensitive systems.

Beam routes signed transactions through partner delivery paths such as **SWQoS-backed validators**, **Jito Block Engine submission**, and other provider-specific low-latency infrastructure. This improves landing probability during congestion and reduces latency variance.

Beam is built for HFT, MEV searchers, liquidation bots, arbitrage engines, latency-sensitive market makers, and apps that care about delivery quality.

Beam is also useful for users who need maximum transaction protection from sandwich attacks, front-running, and toxic MEV.

{% hint style="info" %}
RPC Fast Beam is a **transaction delivery service** – not a general-purpose Solana RPC endpoint.
{% endhint %}

### At a Glance

| Capability             | Details                                                                                                                                                           |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Purpose                | Fast Solana transaction delivery                                                                                                                                  |
| HTTP endpoint          | `https://beam.rpcfast.com`                                                                                                                                        |
| QUIC endpoint          | `beam.rpcfast.com:9900`                                                                                                                                           |
| Tip feed               | `wss://beam.rpcfast.com/tips?provider=<provider>`                                                                                                                 |
| Provider score feed    | `wss://beam.rpcfast.com/provider-scores`                                                                                                                          |
| HTTP methods           | `sendTransaction`, `sendBundle`                                                                                                                                   |
| QUIC methods           | `sendTransaction`, `sendTransactionFast`                                                                                                                          |
| Rust QUIC client       | [`beam-quic-client`](https://crates.io/crates/beam-quic-client)                                                                                                   |
| Providers              | `astralane`, `bloxroute`, `nozomi`, `falcon`                                                                                                                      |
| Modes                  | `fastest`, `mev_protect`                                                                                                                                          |
| Authorization          | `api_key` query arg or `X-Token` header                                                                                                                           |
| Availability           | All plans                                                                                                                                                         |
| CU cost                | `5 CU` per request                                                                                                                                                |
| Rate limit             | <ul><li>Start plan - <code>60 txs/minute</code></li><li>Focus plan - <code>200 txs/minute</code></li><li>Stream, Aperture - <code>500 txs/minute</code></li></ul> |
| Required on every send | Tip transfer instruction                                                                                                                                          |
| Ignored on send path   | Node-side retries and preflight controls                                                                                                                          |

***

### How Beam Works

When you send a transaction through Beam, it’s routed via your selected provider.

Under the hood, Beam leverages provider-specific low-latency infrastructure – such as **SWQoS-backed validator paths**, **Jito Block Engine**, **Harmonic**, or **Rakurai** submission – to maximize how quickly your transaction reaches the current leader. In competitive conditions, this can significantly improve landing probability.

This becomes critical in scenarios where packet delivery speed matters just as much as on-chain priority fees.

For deeper background, see [SWQoS](/rpc-fast-saas-solana/sending-transactions/swqos) and [Aperture gRPC](/rpc-fast-saas-solana/data-streaming/aperture-grpc-beta).

#### Abuse prevention policy

**Users are prohibited from abusing the platform infrastructure,** including but not limited to excessive spam transaction generation, persistent failed bundle submissions, artificial traffic amplification, or any activity that negatively impacts platform stability, SWQoS partners, or other users of the service.

Because our sender service is currently provided in Beta, our abuse-detection systems, fair-use thresholds, rate limits, and enforcement policies may change at any time without prior notice. We reserve the right to make enforcement decisions at our sole discretion when necessary to protect the platform, infrastructure providers, or other users. Read more in the [Terms of Service](https://docs.rpcfast.com/legal/terms-of-service#id-4.-subscription-plans-credits-and-billing).

***

### Endpoints

#### Transactions submission endpoint

Supports `sendTransaction` and `sendBundle` methods.

```http
https://beam.rpcfast.com
```

#### QUIC submission endpoint

Use the Beam QUIC endpoint provided for your account.

```http
beam.rpcfast.com:9900
```

#### Tip guidance feed

```http
wss://beam.rpcfast.com/tips?provider=<provider>
```

Replace `<provider>` with one of:

```
astralane
bloxroute
nozomi
falcon
```

***

### Authorization

Beam accepts an API key through either of these methods:

* `api_key` query argument
* `X-Token` header

#### Query argument

```bash
curl 'https://beam.rpcfast.com/?api_key=<your-api-key>' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'
```

#### Header

```bash
curl 'https://beam.rpcfast.com/?mode=fastest&provider=bloxroute' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'X-Token: <your-api-key>' \
  -d '{}'
```

#### QUIC

For QUIC, pass the same RPC Fast API key to `BeamQuicClient::connect`. The client authenticates with an ephemeral client certificate whose Common Name contains the API key; the key is not sent as a query argument, HTTP header, or request-frame field.

***

### Query Arguments

Beam supports transaction mode selection and provider override through URL query arguments.

#### Provider override

```
provider=astralane | bloxroute | nozomi | falcon
```

If `provider` is not specified, Beam detects the provider from the tipping address you have included in your transaction.

**Example**

```
https://beam.rpcfast.com/?provider=falcon
```

#### Submit mode

```
mode=fastest | mev_protect
```

If `mode` is not specified, Beam uses `fastest` by default.

Supported modes depend on the selected provider. See [Providers](#providers).

| Mode          | Use when                                                                  | Notes                                                            |
| ------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| `fastest`     | Lowest possible submission latency matters most                           | Best for HFT, arbitrage, liquidations, and same-slot competition |
| `mev_protect` | Protection against frontrunning, backrunning and sandwiching matters most | Best for sensitive order flow and execution privacy              |

Choose the mode that matches the intent of the transaction.

***

### QUIC Transaction Submission (Beta)

Use Beam QUIC when transaction delivery latency matters more than HTTP compatibility. It is best suited for HFT systems, MEV searchers, liquidation bots, arbitrage engines, and market makers that keep a long-lived sender process running.

Beam QUIC supports:

| Method                | Use when                                                                                           | Response             |
| --------------------- | -------------------------------------------------------------------------------------------------- | -------------------- |
| `sendTransaction`     | You want low-latency submission and still need Beam to return the signature and routed provider.   | :white\_check\_mark: |
| `sendTransactionFast` | You want the lowest-latency fire-and-forget path and can track the transaction in your own system. | :x:                  |

`sendTransactionFast` is intentionally a separate low-latency path:

* `provider` is required.
* Beam does not return a response.
* Beam does not wait for an upstream provider response.
* Beam skips Beam-side transaction deserialization, signature extraction, and tip validation.
* If `signature` is provided, Beam can use it for landing metrics.

{% hint style="warning" %}
Use regular QUIC `sendTransaction` if your application needs immediate request-level feedback. Use `sendTransactionFast` only when your application can handle fire-and-forget submission.
{% endhint %}

#### Rust QUIC client

The recommended Rust integration is the shared [`beam-quic-client`](https://crates.io/crates/beam-quic-client) crate.

```toml
[dependencies]
beam-quic-client = "0.1.0"
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }
```

The client reuses a QUIC connection, generates the Beam client certificate automatically, places your API key in the certificate Common Name, and reconnects if the connection is closed.

See the `Rust QUIC` tab in [Code Examples](#code-examples) for a complete integration that fetches a blockhash, appends a provider tip, signs the transaction, and submits it through `beam-quic-client`.

***

### Providers and Tips

Every transaction sent through Beam **must include a valid tip** instruction to the addresses provided in these docs.

{% hint style="warning" %}
RPC Fast Beam does not inject tip instructions automatically. Your application must append the provider-specific tip transfer before signing and sending.
{% endhint %}

Sending a transaction without a valid provider tip **is not supported** and will lead to send failure.

It is strongly recommended to **rotate the tip account** on every transaction.

Regular QUIC `sendTransaction` follows the same provider and tip validation rules as HTTP `sendTransaction`.

`sendTransactionFast` requires an explicit `provider` and skips Beam-side tip validation/signature extraction for latency reasons. Your transaction should still include the appropriate provider tip instruction before signing.

#### Providers

<table><thead><tr><th width="103.109375">Provider</th><th width="415.18359375">Tip accounts</th><th>Min. required tip</th><th width="101.1328125">Bundle support</th><th>Mode support</th></tr></thead><tbody><tr><td>Astralane</td><td><pre><code>ASdXviZw2kbViFuAgZF26RPZL1HdybUoWdcveG2nfU8D
Ax2JBnTPUpBFWe75z3YtgueWUfvZPZ6ZFXiMWJMUnjbo
</code></pre></td><td>0.0001 SOL</td><td><span data-gb-custom-inline data-tag="emoji" data-code="2705">✅</span></td><td><code>fastest</code>, <code>mev_protect</code></td></tr><tr><td>bloXroute</td><td><pre><code>rfBP8KJ6KMqvBhmqaV7EoNHVexXQdn1sX4CJ9aLv5w2
rfBkmha9yK5QS7h562Pn6Bfw6cPjsrgVqgcnnXBoXj7
rfBxDPw4XK2WKBinv7Vbr68inD964H7HTMLMWshe3jT
</code></pre></td><td>0.001 SOL</td><td><span data-gb-custom-inline data-tag="emoji" data-code="2705">✅</span></td><td><code>fastest</code>, <code>mev_protect</code></td></tr><tr><td>Nozomi by Temporal</td><td><pre><code>Eag4Jt2M7tiCV3daC7jCwM9CZZa7C8tZPGn5kURT7qUE
3ZMMzsRp3mCftMgyX9tCeg9kRwFU8siYTvamTxHCdHoC
tJgbQbGhNtUE2h6pSa7LV2NbUuftTq5wrxQkXbLK4mu
AoJAVKY58jmTa3gT9bx29bdeYpKdE4beoXFrjMJk7A5q
9Uq39ZFGW55zGrafsa1D35uKgchNcQEKsWoCq2CjwUW9
F2onQMdej9rLW8wdUF46dodDDRakYynjm1VT9hDysFRK
CCm7t7d8Q2zpqJRDAcKzCbMbuWuJxj71N6o3A3MHeE8J
BhawUhJ9G6W7D3Q4JGjkbXjs1v2GyyTANFodWmCsPJyu
</code></pre></td><td>0.001 SOL</td><td><span data-gb-custom-inline data-tag="emoji" data-code="274c">❌</span></td><td><code>fastest</code></td></tr><tr><td>Falcon by Corvus</td><td><pre><code>rfCCxFtXuwjjnP9cXAaEgvCzLkrzXwAiWQadJ4uNKmf
rfCTcFU5p63roQ7S8sTwpQ93NHfGxf5ThSsbH1CjQbf
rfC18Jx6rqwhvwjWpkZnX8q7vE45vzxBXtic1jLr32R
rfCmxTvz2LeEzVmFZHvcfLvz4EaT6Rbkkff98RufbdZ
rfCaRhB66prehCypC53XeSPJ83cTjzwa8cHMeNpenQ8
</code></pre></td><td>0.001 SOL</td><td><span data-gb-custom-inline data-tag="emoji" data-code="274c">❌</span></td><td><code>fastest</code></td></tr></tbody></table>

`sendBundle` is supported only by `astralane` and `bloxroute`.

`mev_protect` is supported only by `astralane` and `bloxroute`.

#### Recommended tip amounts

RPC Fast Beam provides real-time tip guidance over WebSocket.

**WebSocket URL**

```
wss://beam.rpcfast.com/tips?provider=<provider>&api_key=YOUR_API_KEY
```

**Example response**

```json
{
  "time": "2026-04-15T11:03:44Z",
  "provider": "bloxroute",
  "25th_percentile": 0.001,
  "50th_percentile": 0.001,
  "75th_percentile": 0.001,
  "95th_percentile": 0.001,
  "99th_percentile": 0.001
}
```

All percentile values are denominated in `SOL`.

Higher percentiles generally improve landing probability during contention. Lower percentiles may be enough in quieter conditions.

#### Provider score feed

RPC Fast Beam provides real-time provider scoring feed over WebSocket.

**WebSocket URL**

```
wss://beam.rpcfast.com/provider-scores?api_key=YOUR_API_KEY
```

**Example response**

```json
[
  {
    "provider": "bloxroute",
    "score": 0.9,
    "success_rate": 1.0,
    "landing_latency": 186.263,
    "landing_rate": 1.0
  },
  {
    "provider": "astralane",
    "score": 1.0,
    "success_rate": 1.0,
    "landing_latency": 95.177,
    "landing_rate": 1.0
  },
  {
    "provider": "falcon",
    "score": 0.95,
    "success_rate": 1.0,
    "landing_latency": 145.311,
    "landing_rate": 1.0
  }
]
```

**Response fields**

* `landing_latency` - delay between transaction received on Beam and first seen across shreds.
* `landing_rate` - ratio of landed vs sent transactions
* `success_rate` - ratio of valid vs sent transactions
* `score` - computed score with following weights
  * 50 for landing\_rate
  * 30 for landing\_latency
  * 20 for success\_rate

***

### Pricing & Availability

Beam is available on all RPC Fast plans!

Transaction bundles submission is available **only on paid plans**.

#### Compute Units cost

Each transaction submission request costs **5 CU.**

***

### Rate limits

RPC Fast Beam currently offers:

* **60 transactions per minute** on Start plan
* **200 transactions per minute** on Focus plan
* **500 transactions per minute** on Stream and Aperture plans

These limits apply to both `sendTransaction` and `sendBundle` methods. Each transaction in a bundle is taken into account when calculating the rate limit.

QUIC submissions are subject to the same Beam plan limits as HTTP submissions. `sendTransactionFast` counts as a transaction submission request.

{% hint style="warning" %}
Please note that Beam has built-in **spam classifier**, so you need to maintain the quality of your transactions, otherwise **rate limit penalties** may be applied to your account.

For more info: [Spam Transactions & Abuse Prevention Policy (Beta)](/rpc-fast-saas-solana/sending-transactions/spam-transactions-and-abuse-prevention-policy-beta)
{% endhint %}

{% hint style="info" %}
Beam is currently in beta, and rate limits are subject to change as the service evolves.
{% endhint %}

***

### Supported Submission Methods

Beam currently supports HTTP JSON-RPC and QUIC submission methods.

HTTP JSON-RPC supports:

* `sendTransaction`
* `sendBundle`

QUIC supports:

* `sendTransaction`
* `sendTransactionFast`

#### sendTransaction

Submit a signed transaction using the standard Solana JSON-RPC payload.

```bash
curl 'https://beam.rpcfast.com/' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendTransaction",
    "params": [
      "<base64-encoded-signed-transaction>",
      {
        "encoding": "base64"
      }
    ]
  }'
```

#### Ignored `sendTransaction` options

Beam ignores Solana retry and preflight controls on the send path.

The following parameters are ignored:

* `maxRetries`
* `skipPreflight=false`

Retry logic must be implemented in your application. If a transaction does not land, rebuild or re-sign as needed and resubmit according to your own policy.

#### sendBundle

Use `sendBundle` when submitting bundles through a supported provider path. Bundles are mostly used in cases where you need atomic execution of transactions. These transactions are executed sequentially. If one of transaction fails the whole bundle gets reverted and never appears on-chain.

Supported providers: `astralane`, `bloxroute`.

```bash
curl 'https://beam.rpcfast.com/?mode=fastest' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "sendBundle",
    "params": [
      [
        "<base64-encoded-signed-transaction-1>",
        "<base64-encoded-signed-transaction-2>"
      ]
    ]
  }'
```

***

### Code Examples

The same rules apply in every language:

* Reuse one RPC client across all sends.
* Use HTTP/2.
* Keep connections warm.
* Enable keep-alive and TCP keepalive where supported.
* Rotate the tip account for every transaction.
* Append the tip instruction before signing.
* For Rust QUIC integrations, use the shared `beam-quic-client` crate and reuse one long-lived client.

{% tabs %}
{% tab title="Rust QUIC" %}

```rust
use std::sync::atomic::{AtomicUsize, Ordering};
use std::time::Duration;

use anyhow::{anyhow, Result};
use beam_quic_client::{
    BeamQuicClient, Provider, RoutingMode, SendTransactionFastOptions, SendTransactionOptions,
};
use reqwest::{
    header::{HeaderMap, HeaderValue, CONTENT_TYPE},
    Client,
};
use serde_json::{json, Value};
use solana_sdk::{
    hash::Hash,
    instruction::Instruction,
    message::Message,
    pubkey::Pubkey,
    signature::{Keypair, Signature, Signer},
    system_instruction,
    transaction::Transaction,
};

const RPCFAST_TOKEN: &str = "YOUR_RPCFAST_TOKEN";
const SOLANA_RPC_URL: &str = "https://solana-rpc.rpcfast.com";
const BEAM_QUIC_ENDPOINT: &str = "beam.rpcfast.com:9900";

const BLOXROUTE_TIP_ACCOUNTS: [&str; 3] = [
    "rfBP8KJ6KMqvBhmqaV7EoNHVexXQdn1sX4CJ9aLv5w2",
    "rfBkmha9yK5QS7h562Pn6Bfw6cPjsrgVqgcnnXBoXj7",
    "rfBxDPw4XK2WKBinv7Vbr68inD964H7HTMLMWshe3jT",
];

pub struct JsonRpcClient {
    http: Client,
    rpc_url: String,
}

impl JsonRpcClient {
    pub fn new(rpc_url: impl Into<String>, token: &str) -> Result<Self> {
        let mut headers = HeaderMap::new();
        headers.insert(CONTENT_TYPE, HeaderValue::from_static("application/json"));
        headers.insert("X-Token", HeaderValue::from_str(token)?);

        let http = Client::builder()
            .default_headers(headers)
            .http2_prior_knowledge()
            .pool_idle_timeout(Duration::from_secs(90))
            .pool_max_idle_per_host(64)
            .tcp_keepalive(Duration::from_secs(30))
            .tcp_nodelay(true)
            .build()?;

        Ok(Self {
            http,
            rpc_url: rpc_url.into(),
        })
    }

    pub async fn call(&self, method: &str, params: Value) -> Result<Value> {
        let payload = json!({
            "jsonrpc": "2.0",
            "id": 1,
            "method": method,
            "params": params
        });

        let value: Value = self
            .http
            .post(&self.rpc_url)
            .json(&payload)
            .send()
            .await?
            .error_for_status()?
            .json()
            .await?;

        if let Some(error) = value.get("error") {
            return Err(anyhow!("rpc error: {error}"));
        }

        value
            .get("result")
            .cloned()
            .ok_or_else(|| anyhow!("missing result field"))
    }
}

pub struct BeamQuicExampleClient {
    // Recent blockhashes should be fetched from the standard Solana RPC endpoint.
    solana_rpc: JsonRpcClient,
    // Reuse this QUIC client for the lifetime of the process.
    beam_quic: BeamQuicClient,
    tip_accounts: Vec<Pubkey>,
    next_tip_idx: AtomicUsize,
}

impl BeamQuicExampleClient {
    pub async fn new(
        solana_rpc_url: impl Into<String>,
        beam_quic_endpoint: &str,
        token: &str,
        tip_accounts: &[&str],
    ) -> Result<Self> {
        if tip_accounts.is_empty() {
            return Err(anyhow!("tip account list must not be empty"));
        }

        let parsed_tip_accounts = tip_accounts
            .iter()
            .map(|s| s.parse::<Pubkey>())
            .collect::<std::result::Result<Vec<_>, _>>()?;

        Ok(Self {
            solana_rpc: JsonRpcClient::new(solana_rpc_url, token)?,
            beam_quic: BeamQuicClient::connect(beam_quic_endpoint, token).await?,
            tip_accounts: parsed_tip_accounts,
            next_tip_idx: AtomicUsize::new(0),
        })
    }

    fn next_tip_account(&self) -> Pubkey {
        let idx = self.next_tip_idx.fetch_add(1, Ordering::Relaxed) % self.tip_accounts.len();
        self.tip_accounts[idx]
    }

    fn build_tip_instruction(&self, payer: &Pubkey, tip_lamports: u64) -> Result<Instruction> {
        if tip_lamports == 0 {
            return Err(anyhow!("Beam requires a tip instruction on every transaction"));
        }

        Ok(system_instruction::transfer(
            payer,
            &self.next_tip_account(),
            tip_lamports,
        ))
    }

    async fn get_latest_blockhash(&self) -> Result<Hash> {
        let result = self
            .solana_rpc
            .call("getLatestBlockhash", json!([{ "commitment": "processed" }]))
            .await?;

        let blockhash = result["value"]["blockhash"]
            .as_str()
            .ok_or_else(|| anyhow!("missing blockhash"))?;

        Ok(blockhash.parse()?)
    }

    async fn build_signed_transaction(
        &self,
        payer: &Keypair,
        mut instructions: Vec<Instruction>,
        tip_lamports: u64,
    ) -> Result<Transaction> {
        let blockhash = self.get_latest_blockhash().await?;
        instructions.push(self.build_tip_instruction(&payer.pubkey(), tip_lamports)?);

        let message = Message::new(&instructions, Some(&payer.pubkey()));
        Ok(Transaction::new(&[payer], message, blockhash))
    }

    pub async fn send_transaction(
        &self,
        payer: &Keypair,
        instructions: Vec<Instruction>,
        tip_lamports: u64,
    ) -> Result<Signature> {
        let tx = self
            .build_signed_transaction(payer, instructions, tip_lamports)
            .await?;
        let tx_bytes = bincode::serialize(&tx)?;

        let result = self
            .beam_quic
            .send_transaction_bytes(
                tx_bytes,
                SendTransactionOptions {
                    provider: Some(Provider::Bloxroute),
                    mode: RoutingMode::Fastest,
                    request_id: None,
                },
            )
            .await?;

        Ok(result.signature.parse()?)
    }

    pub async fn send_transaction_fast(
        &self,
        payer: &Keypair,
        instructions: Vec<Instruction>,
        tip_lamports: u64,
    ) -> Result<Signature> {
        let tx = self
            .build_signed_transaction(payer, instructions, tip_lamports)
            .await?;
        let signature = tx
            .signatures
            .first()
            .cloned()
            .ok_or_else(|| anyhow!("missing transaction signature"))?;
        let tx_bytes = bincode::serialize(&tx)?;

        self.beam_quic
            .send_transaction_fast_bytes(
                tx_bytes,
                SendTransactionFastOptions {
                    provider: Provider::Bloxroute,
                    mode: RoutingMode::Fastest,
                    request_id: None,
                    signature: Some(signature.to_string()),
                },
            )
            .await?;

        Ok(signature)
    }
}

#[tokio::main]
async fn main() -> Result<()> {
    let beam = BeamQuicExampleClient::new(
        SOLANA_RPC_URL,
        BEAM_QUIC_ENDPOINT,
        RPCFAST_TOKEN,
        &BLOXROUTE_TIP_ACCOUNTS,
    )
    .await?;

    let payer = Keypair::new();
    let instructions: Vec<Instruction> = vec![];

    let signature = beam
        .send_transaction(&payer, instructions, 1_000_000)
        .await?;

    println!("{signature}");
    Ok(())
}
```

For fire-and-forget submission, use `sendTransactionFast`:

```rust
let fast_signature = beam
    .send_transaction_fast(&payer, vec![], 1_000_000)
    .await?;

println!("{fast_signature}");
```

{% endtab %}

{% tab title="Rust" %}

```rust
use std::sync::atomic::{AtomicUsize, Ordering};
use std::time::Duration;

use anyhow::{anyhow, Result};
use base64::Engine;
use reqwest::{
    header::{HeaderMap, HeaderValue, CONTENT_TYPE},
    Client,
};
use serde_json::{json, Value};
use solana_sdk::{
    hash::Hash,
    instruction::Instruction,
    message::Message,
    pubkey::Pubkey,
    signature::{Keypair, Signature, Signer},
    system_instruction,
    transaction::Transaction,
};

const RPCFAST_TOKEN: &str = "YOUR_RPCFAST_TOKEN";
const SOLANA_RPC_URL: &str = "https://solana-rpc.rpcfast.com";
const BEAM_URL: &str = "https://beam.rpcfast.com/?mode=fastest";

const TIP_ACCOUNTS: [&str; 6] = [
    // astralane
    "ASdXviZw2kbViFuAgZF26RPZL1HdybUoWdcveG2nfU8D",
    "Ax2JBnTPUpBFWe75z3YtgueWUfvZPZ6ZFXiMWJMUnjbo",
    // falcon
    "rfCCxFtXuwjjnP9cXAaEgvCzLkrzXwAiWQadJ4uNKmf",
    "rfCTcFU5p63roQ7S8sTwpQ93NHfGxf5ThSsbH1CjQbf",
    // bloxroute
    "rfBP8KJ6KMqvBhmqaV7EoNHVexXQdn1sX4CJ9aLv5w2",
    "rfBkmha9yK5QS7h562Pn6Bfw6cPjsrgVqgcnnXBoXj7",
];

pub struct JsonRpcClient {
    http: Client,
    rpc_url: String,
}

impl JsonRpcClient {
    pub fn new(rpc_url: impl Into<String>, token: &str) -> Result<Self> {
        let mut headers = HeaderMap::new();
        headers.insert(CONTENT_TYPE, HeaderValue::from_static("application/json"));
        headers.insert("X-Token", HeaderValue::from_str(token)?);

        let http = Client::builder()
            .default_headers(headers)
            .http2_prior_knowledge()
            .pool_idle_timeout(Duration::from_secs(90))
            .pool_max_idle_per_host(64)
            .tcp_keepalive(Duration::from_secs(30))
            .tcp_nodelay(true)
            .build()?;

        Ok(Self {
            http,
            rpc_url: rpc_url.into(),
        })
    }

    pub async fn call(&self, method: &str, params: Value) -> Result<Value> {
        let payload = json!({
            "jsonrpc": "2.0",
            "id": 1,
            "method": method,
            "params": params
        });

        let value: Value = self
            .http
            .post(&self.rpc_url)
            .json(&payload)
            .send()
            .await?
            .error_for_status()?
            .json()
            .await?;

        if let Some(error) = value.get("error") {
            return Err(anyhow!("rpc error: {error}"));
        }

        value.get("result")
            .cloned()
            .ok_or_else(|| anyhow!("missing result field"))
    }
}

pub struct BeamClient {
    // Recent blockhashes should be fetched from the standard Solana RPC endpoint.
    solana_rpc: JsonRpcClient,
    // Beam supports only sendTransaction / sendBundle.
    beam_rpc: JsonRpcClient,
    tip_accounts: Vec<Pubkey>,
    next_tip_idx: AtomicUsize,
}

impl BeamClient {
    pub fn new(
        solana_rpc_url: impl Into<String>,
        beam_url: impl Into<String>,
        token: &str,
        tip_accounts: &[&str],
    ) -> Result<Self> {
        if tip_accounts.is_empty() {
            return Err(anyhow!("tip account list must not be empty"));
        }

        let parsed_tip_accounts = tip_accounts
            .iter()
            .map(|s| s.parse::<Pubkey>())
            .collect::<std::result::Result<Vec<_>, _>>()?;

        Ok(Self {
            solana_rpc: JsonRpcClient::new(solana_rpc_url, token)?,
            beam_rpc: JsonRpcClient::new(beam_url, token)?,
            tip_accounts: parsed_tip_accounts,
            next_tip_idx: AtomicUsize::new(0),
        })
    }

    fn next_tip_account(&self) -> Pubkey {
        let idx = self.next_tip_idx.fetch_add(1, Ordering::Relaxed) % self.tip_accounts.len();
        self.tip_accounts[idx]
    }

    fn build_tip_instruction(&self, payer: &Pubkey, tip_lamports: u64) -> Result<Instruction> {
        if tip_lamports == 0 {
            return Err(anyhow!("Beam requires a tip instruction on every transaction"));
        }

        Ok(system_instruction::transfer(
            payer,
            &self.next_tip_account(),
            tip_lamports,
        ))
    }

    async fn get_latest_blockhash(&self) -> Result<Hash> {
        let result = self
            .solana_rpc
            .call("getLatestBlockhash", json!([{ "commitment": "processed" }]))
            .await?;

        let blockhash = result["value"]["blockhash"]
            .as_str()
            .ok_or_else(|| anyhow!("missing blockhash"))?;

        Ok(blockhash.parse()?)
    }

    pub async fn send_transaction(
        &self,
        payer: &Keypair,
        mut instructions: Vec<Instruction>,
        tip_lamports: u64,
    ) -> Result<Signature> {
        let blockhash = self.get_latest_blockhash().await?;
        instructions.push(self.build_tip_instruction(&payer.pubkey(), tip_lamports)?);

        let message = Message::new(&instructions, Some(&payer.pubkey()));
        let tx = Transaction::new(&[payer], message, blockhash);

        let raw_bytes = bincode::serialize(&tx)?;
        let raw_b64 = base64::engine::general_purpose::STANDARD.encode(raw_bytes);

        // Beam supports only sendTransaction / sendBundle.
        // maxRetries and preflight controls are ignored by Beam.
        let result = self
            .beam_rpc
            .call(
                "sendTransaction",
                json!([
                    raw_b64,
                    {
                        "encoding": "base64",
                        "skipPreflight": true,
                        "maxRetries": 0,
                        "preflightCommitment": "processed"
                    }
                ]),
            )
            .await?;

        let sig = result
            .as_str()
            .ok_or_else(|| anyhow!("missing signature"))?;

        Ok(sig.parse()?)
    }
}

#[tokio::main]
async fn main() -> Result<()> {
    let beam = BeamClient::new(
        SOLANA_RPC_URL,
        BEAM_URL,
        RPCFAST_TOKEN,
        &ASTRALANE_TIP_ACCOUNTS,
    )?;

    let payer = Keypair::new();
    let instructions: Vec<Instruction> = vec![];

    let signature = beam
        .send_transaction(&payer, instructions, 1_000_000)
        .await?;

    println!("{signature}");
    Ok(())
}
```

{% endtab %}

{% tab title="TypeScript" %}

```typescript
import {
  Keypair,
  PublicKey,
  SystemProgram,
  Transaction,
  TransactionInstruction,
  Connection,
} from "@solana/web3.js";
import { Agent, fetch } from "undici";

const RPCFAST_TOKEN = process.env.RPCFAST_TOKEN!;
const MODE = "fastest";

const SOLANA_RPC_URL = "https://solana-rpc.rpcfast.com";
const BEAM_URL = `https://beam.rpcfast.com/?mode=${MODE}`;

const TIP_ACCOUNTS = [
    // astralane
    "ASdXviZw2kbViFuAgZF26RPZL1HdybUoWdcveG2nfU8D",
    "Ax2JBnTPUpBFWe75z3YtgueWUfvZPZ6ZFXiMWJMUnjbo",
    // falcon
    "rfCCxFtXuwjjnP9cXAaEgvCzLkrzXwAiWQadJ4uNKmf",
    "rfCTcFU5p63roQ7S8sTwpQ93NHfGxf5ThSsbH1CjQbf",
    // bloxroute
    "rfBP8KJ6KMqvBhmqaV7EoNHVexXQdn1sX4CJ9aLv5w2",
    "rfBkmha9yK5QS7h562Pn6Bfw6cPjsrgVqgcnnXBoXj7",
];

class RotatingTipAccounts {
  private idx = 0;

  constructor(private readonly accounts: string[]) {
    if (accounts.length === 0) {
      throw new Error("tip account list must not be empty");
    }
  }

  next(): PublicKey {
    const pk = new PublicKey(this.accounts[this.idx]);
    this.idx = (this.idx + 1) % this.accounts.length;
    return pk;
  }
}

const tipAccounts = new RotatingTipAccounts(ASTRALANE_TIP_ACCOUNTS);

// Reusable HTTP/2 client with keep-alive.
// Node sockets use TCP_NODELAY by default.
const dispatcher = new Agent({
  allowH2: true,
  connections: 256,
  pipelining: 1,
  keepAliveTimeout: 10_000,
  keepAliveMaxTimeout: 60_000,
});

const customFetch: typeof fetch = (input, init = {}) =>
  fetch(input, {
    ...init,
    dispatcher,
    headers: {
      "Content-Type": "application/json",
      "X-Token": RPCFAST_TOKEN,
      ...(init.headers ?? {}),
    },
  });

// Reuse both clients across the lifetime of the process.
// Recent blockhashes should be fetched from the standard Solana RPC endpoint.
const solanaRpc = new Connection(SOLANA_RPC_URL, {
  commitment: "processed",
  fetch: customFetch as any,
});

// Beam supports only sendTransaction / sendBundle.
const beamRpc = new Connection(BEAM_URL, {
  commitment: "processed",
  fetch: customFetch as any,
});

function buildTipInstruction(
  payer: PublicKey,
  tipLamports: number,
): TransactionInstruction {
  if (tipLamports <= 0) {
    throw new Error("Beam requires a tip instruction on every transaction");
  }

  return SystemProgram.transfer({
    fromPubkey: payer,
    toPubkey: tipAccounts.next(),
    lamports: tipLamports,
  });
}

export async function sendBeamTransaction(
  payer: Keypair,
  appInstructions: TransactionInstruction[],
  tipLamports: number,
): Promise<string> {
  const { blockhash } = await solanaRpc.getLatestBlockhash("processed");

  const tx = new Transaction({
    feePayer: payer.publicKey,
    recentBlockhash: blockhash,
  });

  for (const ix of appInstructions) {
    tx.add(ix);
  }

  tx.add(buildTipInstruction(payer.publicKey, tipLamports));
  tx.sign(payer);

  const raw = tx.serialize();

  // Beam supports only sendTransaction / sendBundle.
  // maxRetries and preflight controls are ignored by Beam and should be handled application-side.
  return beamRpc.sendRawTransaction(raw, {
    skipPreflight: true,
    maxRetries: 0,
    preflightCommitment: "processed",
  });
}
```

{% endtab %}

{% tab title="Python" %}

```python
import base64
import itertools
from typing import Iterable, List, Any

import httpx
from solders.hash import Hash
from solders.instruction import Instruction
from solders.keypair import Keypair
from solders.message import Message
from solders.pubkey import Pubkey
from solders.system_program import TransferParams, transfer
from solders.transaction import Transaction


RPCFAST_TOKEN = "YOUR_RPCFAST_TOKEN"
MODE = "fastest"

SOLANA_RPC_URL = "https://solana-rpc.rpcfast.com"
BEAM_URL = f"https://beam.rpcfast.com/?mode={MODE}"

ASTRALANE_TIP_ACCOUNTS = [
    ## astralane
    "ASdXviZw2kbViFuAgZF26RPZL1HdybUoWdcveG2nfU8D",
    "Ax2JBnTPUpBFWe75z3YtgueWUfvZPZ6ZFXiMWJMUnjbo",
    ## falcon
    "rfCCxFtXuwjjnP9cXAaEgvCzLkrzXwAiWQadJ4uNKmf",
    "rfCTcFU5p63roQ7S8sTwpQ93NHfGxf5ThSsbH1CjQbf",
    ## bloxroute
    "rfBP8KJ6KMqvBhmqaV7EoNHVexXQdn1sX4CJ9aLv5w2",
    "rfBkmha9yK5QS7h562Pn6Bfw6cPjsrgVqgcnnXBoXj7",
];


class JsonRpcClient:
    def __init__(self, rpc_url: str, token: str) -> None:
        self.rpc_url = rpc_url
        self.request_id = 0
        self.http = httpx.Client(
            http2=True,
            limits=httpx.Limits(max_connections=200, max_keepalive_connections=50),
            timeout=httpx.Timeout(5.0),
            headers={
                "Content-Type": "application/json",
                "X-Token": token,
            },
        )

    def call(self, method: str, params: List[Any]) -> Any:
        self.request_id += 1
        payload = {
            "jsonrpc": "2.0",
            "id": self.request_id,
            "method": method,
            "params": params,
        }
        response = self.http.post(self.rpc_url, json=payload)
        response.raise_for_status()
        data = response.json()
        if "error" in data:
            raise RuntimeError(data["error"])
        return data["result"]


class BeamClient:
    def __init__(
        self,
        solana_rpc_url: str,
        beam_url: str,
        token: str,
        tip_accounts: List[str],
    ) -> None:
        if not tip_accounts:
            raise ValueError("tip account list must not be empty")

        # Reuse both clients for the lifetime of the process.
        # Recent blockhashes should come from the standard Solana RPC endpoint.
        self.solana_rpc = JsonRpcClient(solana_rpc_url, token)
        # Beam supports only sendTransaction / sendBundle.
        self.beam_rpc = JsonRpcClient(beam_url, token)
        self.tip_accounts = itertools.cycle(Pubkey.from_string(x) for x in tip_accounts)

    def get_latest_blockhash(self) -> Hash:
        result = self.solana_rpc.call("getLatestBlockhash", [{"commitment": "processed"}])
        return Hash.from_string(result["value"]["blockhash"])

    def next_tip_account(self) -> Pubkey:
        return next(self.tip_accounts)

    def build_tip_instruction(self, payer: Pubkey, tip_lamports: int) -> Instruction:
        if tip_lamports <= 0:
            raise ValueError("Beam requires a tip instruction on every transaction")

        return transfer(
            TransferParams(
                from_pubkey=payer,
                to_pubkey=self.next_tip_account(),
                lamports=tip_lamports,
            )
        )

    def send_transaction(
        self,
        payer: Keypair,
        instructions: Iterable[Instruction],
        tip_lamports: int,
    ) -> str:
        blockhash = self.get_latest_blockhash()

        final_instructions = list(instructions)
        final_instructions.append(self.build_tip_instruction(payer.pubkey(), tip_lamports))

        message = Message(final_instructions, payer.pubkey())
        tx = Transaction([payer], message, blockhash)
        raw_tx_b64 = base64.b64encode(bytes(tx)).decode("ascii")

        # Beam supports only sendTransaction / sendBundle.
        # maxRetries and preflight controls are ignored by Beam.
        return self.beam_rpc.call(
            "sendTransaction",
            [
                raw_tx_b64,
                {
                    "encoding": "base64",
                    "skipPreflight": True,
                    "maxRetries": 0,
                    "preflightCommitment": "processed",
                },
            ],
        )


beam = BeamClient(
    solana_rpc_url=SOLANA_RPC_URL,
    beam_url=BEAM_URL,
    token=RPCFAST_TOKEN,
    tip_accounts=ASTRALANE_TIP_ACCOUNTS,
)

payer = Keypair()

# Example:
# signature = beam.send_transaction(
#     payer=payer,
#     instructions=[...],
#     tip_lamports=1_000_000,
# )
# print(signature)
```

{% endtab %}
{% endtabs %}

***

### Best Practices

For best results with RPC Fast Beam:

* Always include a **valid tip transfer instruction.**
* Use appropriate **tip account** when specifying `provider` query parameter.
* Use only those tip accounts specified in our docs, otherwise request will be rejected.
* **Rotate tip accounts** instead of hardcoding one destination.
* Send transaction to **multiple providers in round-robin** for better resilience.
* Use the **WebSocket tip feed** to adapt tip size dynamically.
* Use provider score websocket feed to check which provider performs better.
* Reuse a long-lived RPC client.
* Use HTTP/2 and keep connections warm.
* Handle retries in the application.
* Do not rely on preflight checks on the send path.
* Keep your signing and submission path hot.
* Reuse one long-lived `BeamQuicClient` instead of reconnecting per transaction.
* Use regular QUIC `sendTransaction` when you need Beam response feedback.
* Use `sendTransactionFast` only when your application can handle fire-and-forget submission.
* Pass `signature` to `sendTransactionFast` when you want Beam-side landing metrics.
* Choose `provider` explicitly for `sendTransactionFast`.

{% hint style="success" icon="light-emergency-on" %}
**For latency-sensitive systems,** pair Beam with the [Aperture gRPC](/rpc-fast-saas-solana/data-streaming/aperture-grpc-beta) to detect opportunities earlier. Teams that prefer lower-level data can also use **Shredstream,** with more client-side decoding work.
{% endhint %}

***

### Quick Reference

#### Endpoint

```
https://beam.rpcfast.com
```

#### QUIC endpoint

```
beam.rpcfast.com:9900
```

#### Supported HTTP JSON-RPC methods

```
sendTransaction
sendBundle
```

#### Supported QUIC methods

```
sendTransaction
sendTransactionFast
```

#### Query arguments

```
provider=astralane | bloxroute | nozomi | falcon
mode=fastest | mev_protect
```

#### Defaults

```
provider=derived from the tip account used in transaction
mode=fastest
```

#### Tip feed

```
wss://beam.rpcfast.com/tips?provider=<provider>
```

***

### When to Use Beam

Beam is a strong fit for:

* High-frequency trading systems
* MEV searchers
* Liquidation bots
* Arbitrage engines
* Latency-sensitive market makers
* Wallets or apps that need stronger delivery guarantees
* Users who want protection from backrunning and sandwich attacks

For standard, low-priority transaction flows, a regular Solana RPC endpoint may be sufficient.

***

### Selecting Provider: Use Cases

A good rule of thumb is to split Beam use cases into two categories:

* **Atomic, coordinated execution** – use providers with Bundle support (Astralane, bloXroute).
* **Single-transaction speed and landing probability** – any provider (Nozomi, Falcon, Astralane, bloXroute), selecting the one with the best real-time performance score. Beam's provider scoring feed is designed exactly for this.

Use **Bundle-capable providers** (Astralane & bloXroute) for:

* MEV searchers
* Multi-leg arbitrage
* Complex liquidation strategies
* Any workflow requiring atomic execution
* User-facing swaps that need `mev_protect`

Use **any Beam provider** for:

* HFT
* Market making
* Simple arbitrage
* Standard liquidation bots
* General latency-sensitive transaction submission

The use of the `fastest` and `mev_protect` modes:

* `fastest` → optimize for lowest latency and highest landing probability (HFT, liquidations, market making).
* `mev_protect` → optimize for execution privacy and protection from frontrunning/sandwich attacks (wallets, swaps, sensitive order flow).


# Spam Transactions & Abuse Prevention Policy (Beta)

### Overview

To maintain stable and fair access to our infrastructure, we actively monitor transaction delivery quality and abusive usage patterns across the platform.

Certain behaviors, especially large-scale transaction spam through bundle systems, can negatively impact both our infrastructure and our SWQoS partners. Because of this, we have introduced **automated protection** and **penalty mechanisms** designed to prevent bad actor behavior and preserve service quality for all users.

{% hint style="warning" %}
This policy applies to all users of the Beta product and is subject to updates as the product evolves.
{% endhint %}

***

### What We Consider Spam Transactions

A transaction may be considered spam when it is intentionally or systematically submitted without a realistic intent to land on-chain.

The most common example includes:

* High-volume Jito bundle submissions that never land on-chain
* Repeated broadcast attempts with extremely low landing probability
* Artificial traffic generation aimed at saturating routing or SWQoS capacity
* Transaction flooding patterns that degrade infrastructure performance for other users

While occasional failed transactions are expected in normal Solana network conditions, persistent failure patterns indicate abusive behavior.

***

### Transaction Sending Rate Limits

|            |           |            |            |              |
| ---------- | --------- | ---------- | ---------- | ------------ |
| Plan       | **Start** | **Focus**  | **Stream** | **Aperture** |
| Rate limit | 60 tx/min | 200 tx/min | 500 tx/min | 500 tx/min   |

{% hint style="info" %}
**The number of transactions within the bundle** is calculated too, e.g. while sending bundles of 2 transactions each on Focus, the effective rate limit will look like 50 bundles/min and 6,000 bundles/hour.
{% endhint %}

***

### Landing Ratio Monitoring

We continuously evaluate the transaction landing ratio associated with an account.

#### Spam Threshold

If the majority of submitted transactions fail to reach the blockchain over a sustained observation period, this is treated as a strong indicator of consistent spam activity.

At that point, the **account will automatically enter a penalty state.**

***

### Penalty State & Throttling

Users identified as generating spam traffic may be subject to temporary restrictions, including:

* RPC endpoint throttling
* Reduced rate limits
* Bundle submission restrictions
* Temporary subscription suspension
* Additional internal review procedures

This effectively creates a de facto blockade intended to protect the platform and our infrastructure partners from abuse.

***

### Automatic Recovery

The penalty state is not necessarily permanent.

If the user stops abusive behavior and returns to normal transaction patterns, the restriction will be automatically lifted after a sustained period of compliant activity.

Once the system detects healthy behavior again:

* Rate limits gradually return to standard subscription levels
* Penalty measures may be removed automatically
* Account status returns to normal operation

***

### Important Notes About Beta Status

Our anti-spam systems, landing-ratio thresholds, rate limits, and penalty mechanisms are currently part of a Beta product environment.

Because of this:

* Detection methodologies may evolve
* Thresholds may change without prior notice
* Enforcement policies may be adjusted as infrastructure requirements evolve
* Additional protections may be introduced over time

**We reserve the right to apply protective measures whenever account activity threatens platform stability, infrastructure integrity, or service quality for other users.**

***

### Fair Use Reminder

Our infrastructure is designed for legitimate transaction delivery and low-latency blockchain operations — not for synthetic traffic generation or infrastructure abuse.

Users are expected to operate within reasonable fair-use boundaries and ensure that their transaction flow reflects genuine blockchain intent.


# bloXroute: Solana Trader API

RPC Fast partnered with bloXroute to bring SWQoS benefits to our clients.

The **Solana Trading API** provides faster transaction propagation on Solana network, as well as additional features, such as MEV protection while utilizing bloXroute's infrastructure (SWQoS) under the hood.

You can use the API along with RPC Fast's infrastructure and send transactions at no base cost. The fees applicable: 0.001 SOL tip per transaction (charged by bloXroute) + priority fees (paid to Solana network). Check the [bloXroute's Docs](https://docs.bloxroute.com/core-solutions/solana-core-solutions) for more details about the Solana Trading API – Transaction execution and protection solution.

Below, you'll find an instruction on how to use the integration.

### How to enable Trader API?

* Add `blxr_enable=1` query arg, i.e. `https://solana-rpc.rpcfast.net/?blxr_enable=1`
* Or add `/trader` to request path, i.e. `https://solana-rpc.rpcfast.net/trader`

### Authentication options

* via HTTP header `X-TOKEN: your_token`
* via HTTP query argument `api_key=your_token`

### Submit transaction via API

We have integrated Trader API with default Solana `sendTransaction` RPC method, so it is compatible with all Solana language libraries, i.e. solana/web3.js, solana.py, gagliardetto/solana-go etc.

**Example request with curl**

```bash
curl -XPOST -H 'X-TOKEN: your_token' \
https://solana-rpc.rpcfast.net/trader?tx_submit_mode=fastest&tip_amount=1000000 -d '
{
	"jsonrpc": "2.0",
	"method": "sendTransaction",
	"params": [
		"your_signed_transaction",
		{
			"encoding": "base64"
		}
	],
	"id": 1
}'
```

**Query parameters**

| **Parameter**       | **Description**                                                     | **Allowed values**                   | **Required**                              |
| ------------------- | ------------------------------------------------------------------- | ------------------------------------ | ----------------------------------------- |
| `blxr_enable`       | Enable BloXRoute Trader API integration                             | `1`                                  | Yes, except when using `/trader` endpoint |
| `tx_submit_mode`    | Transaction submission mode                                         | `fastest`, `mev_protect`, `balanced` | No                                        |
| `tip_amount`        | Tip amount in Lamports **SaaS users only**                          | min. `1000000`                       | Yes (SaaS users only)                     |
| `fallback`          | Whether to fallback to default sendTransaction on reaching CU limit | `true`, `false`                      | No                                        |
| `mev_protect_level` | MEV protection level, affects tx landing speed                      | `low`, `medium`, `high`              | No                                        |

### Transaction submission modes

| **Mode**      | **Description**                                                                                |
| ------------- | ---------------------------------------------------------------------------------------------- |
| not specified | Transaction is sent through BloXRoute's network                                                |
| `fastest`     | Transaction is send to staked nodes allowing for the fastest propagation                       |
| `mev_protect` | Enable front-running protection in cost of slower transaction propagation, routed through Jito |
| `balanced`    | Balanced mode between tx landing speed and front-running protection                            |

### Tip fee for sending transactions

Tip should be specified in lamports (1 SOL = 1,000,000,000 lamports).

The minimum required tip amount is 0.001 SOL or 1,000,000 Lamports.

**RPC Fast SaaS** users must specify tip fee using `tip_amount` query argument, it will be automatically converted to Compute Units and debited from balance.

**RPC Fast Dedicated node** users must create tip fee instruction by themselves and include it inside the transaction body. [Read more](https://docs.bloxroute.com/solana/trader-api/best-performance-for-landing-transactions#optimizing-transaction-performance).

{% hint style="success" %}
Setting a larger tip will increase propagation speed.
{% endhint %}

{% hint style="warning" %}
To check most up-to-date recommended tip amount, consider [subscribing to websocket endpoint](/rpc-fast-saas-solana/sending-transactions/solana-trader-api/websocket-endpoints).
{% endhint %}

### Transaction priority fee

**Priority fee** is an optional fee, priced in [micro-lamports](https://solana.com/docs/references/terminology#lamport) per [Compute Unit](https://solana.com/docs/references/terminology#compute-units) (e.g. small amounts of SOL), appended to transactions to make them economically compelling for validator nodes to include in blocks on the network.

Please check the [official Solana documentation](https://solana.com/developers/guides/advanced/how-to-use-priority-fees) on how to add priority fee to your transaction.

{% hint style="warning" %}
To receive up-to-date priority fees, consider subscribing to [priority fee stream websocket](/rpc-fast-saas-solana/sending-transactions/solana-trader-api/websocket-endpoints).
{% endhint %}


# bloXroute: Websocket Endpoints

### Subscribe to recently used tip amounts

This subscription provides you with percentiles for recently used tips.

{% hint style="warning" %}
Please note that using a suggested tip amount does not guarantee your transaction will be included in the next block.
{% endhint %}

**Example request**

```
wscat --header "X-TOKEN: your_token" \
	-c wss://solana-rpc.rpcfast.net/ws/trader \
	--wait 1000000 \
  --execute '{"jsonrpc": "2.0", "id": 1, "method": "subscribe", "params": ["GetBundleTipStream", {}]}'
```

**Request format**

```
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "subscribe",
  "params": ["GetBundleTipStream", {}]
}
```

**Response format**

```
{
	"jsonrpc": "2.0",
	"method": "subscribe",
	"params": {
		"subscription": "044d3209-0dd6-4a72-acee-9f80a19b48a1",
		"result": {
			"timestamp": null,
			"percentile25": 1.91875e-06,
			"percentile50": 1e-05,
			"percentile75": 3.719075e-05,
			"percentile95": 0.00099338365,
			"percentile99": 0.013046900000000005,
			"emaPercentile50": 1.0000062827311115e-05
		}
	}
}
```

**Event result format**

| **Field**         | **Type** | **Description**                                                           |
| ----------------- | -------- | ------------------------------------------------------------------------- |
| `timestamp`       | string   | The timestamp when the sample was taken                                   |
| `percentile25`    | uint64   | How much tip was paid at the 25th percentile                              |
| `percentile50`    | uint64   | How much tip was paid at the 50th percentile                              |
| `percentile75`    | uint64   | How much tip was paid at the 75th percentile                              |
| `percentile95`    | uint64   | How much tip was paid at the 95th percentile                              |
| `percentile99`    | uint64   | How much tip was paid at the 99th percentile                              |
| `emaPercentile50` | uint64   | The 1-minute Exponential Moving Average (EMA) for the 50th percentile tip |

### Subscribe to transaction priority fee stream

This subscription provides you recent priority fee based on the project over the last 100 slots.

{% hint style="warning" %}
Please note that using a suggested priority fee does not guarantee your transaction will be included in the next block.
{% endhint %}

**Example request**

```
wscat --header "X-TOKEN: your_token" \
	-c wss://solana-rpc.rpcfast.net/ws/trader \
	--wait 1000000 \
  --execute '{"jsonrpc": "2.0", "id": 1, "method": "subscribe", "params": ["GetPriorityFeeStream", {}]}'
```

**Request format**

```
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "subscribe",
  "params": [
    "GetPriorityFeeStream",
    {
      "project": "P_RAYDIUM"
    }
  ]
}
```

**Extra parameters**

<table data-header-hidden><thead><tr><th></th><th width="102"></th><th></th><th></th><th></th></tr></thead><tbody><tr><td><strong>Parameter</strong></td><td><strong>Type</strong></td><td><strong>Description</strong></td><td>Allowed values</td><td>Optional</td></tr><tr><td><code>project</code></td><td>enum</td><td>Specify which project to fetch the recent priority fee for</td><td><code>"P_JUPITER"</code>,<code>"P_RAYDIUM"</code></td><td>no</td></tr><tr><td><code>percentile</code></td><td>double</td><td>Specify how much percentile of the previous <strong>100</strong> slot's priority fee. Use <code>90</code>, if you want the top 90% percentile. Default value is <code>55</code></td><td></td><td>yes</td></tr></tbody></table>

**Response format**

```
{
    "jsonrpc": "2.0",
    "method": "subscribe",
    "params": {
        "subscription": "f29bc4fa-1c0a-42e2-b9b0-1684e6fa8b63",
        "result": {
            "project": "P_JUPITER", 
            "percentile": 55, 
            "feeAtPercentile": "71428"
        }
    }
}

```


# Performance and Benchmarking

## gRPC Performance

[gRPC stream speed report](https://s3-public-assets.rpcfast.com/grpcbench-report.html) (17/07/2026)

<figure><img src="/files/8r7O3ausrilMys1WUp5q" alt=""><figcaption></figcaption></figure>

You can track the streaming metrics comparison in our [Grafana dashboard](https://solana-metrics.rpcfast.com/public-dashboards/7ddaf20ee1864ecaba494e079a78343c).

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

**Note:** Pay attention to each metric's legend. For instance, when calculating the absolute latency compared to tx block time, we subtract 500ms since the block time unit is seconds.

**Geolocation:** Currently, we are present in Frankfurt, **Equinix FR13** data center.

{% hint style="warning" %}
For the most efficient performance and lowest latency, we recommend deploying your app in the **same region data center** or close. Recommended providers: Cherry Servers, Teraswitch, Latitude, AWS, GCP.
{% endhint %}

***

### Benchmarking Against Competitors

Use [GeyserBench](https://github.com/hmstudio-labs/geyserbench/blob/main/README.md) to compare multiple Solana gRPC endpoints simultaneously and measure their speed and reliability in detecting transactions.

Compare latency percentile profiles and reliability for each RPC endpoint.

**Example:** [RPC Fast vs. Triton](https://runs.solstack.app/run/320734d7-3556-4934-8cab-2f7c72a49c06) (May 13, 2026)

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

**Note:** The competitor's endpoint was masked to avoid exposing the client's data.

***

### Benchmarking RPC Fast gRPC Services

#### Yellowstone vs Aperture

[Benchmark overview](https://runs.solstack.app/run/0de155e9-469d-4485-a9c3-2ad4e0c49571) (May 19, 2026)

```
┌─────────────┬─────────┬────────┬────────┬────────┬──────────┬────────┬──────────┐
│ Endpoint    ┆ First % ┆ P50 ms ┆ P95 ms ┆ P99 ms ┆ Valid Tx ┆ Firsts ┆ Backfill │
╞═════════════╪═════════╪════════╪════════╪════════╪══════════╪════════╪══════════╡
│ aperture    ┆ 99.97   ┆ 0.00   ┆ 0.00   ┆ 0.00   ┆ 20000    ┆ 19994  ┆ 0        │
├╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌┤
│ yellowstone ┆ 0.03    ┆ 10.77  ┆ 35.56  ┆ 50.72  ┆ 20000    ┆ 6      ┆ 0        │
└─────────────┴─────────┴────────┴────────┴────────┴──────────┴────────┴──────────┘
```

#### Aperture vs. Shredstream

[Benchmark overview](https://runs.solstack.app/run/5af216d2-e6f0-4da5-a32b-52a74cbe599f) (May 19, 2026)

{% hint style="info" %}
**Note:** Shredstream includes shreds from our partners + Jito shreds.
{% endhint %}

```
┌─────────────┬─────────┬────────┬────────┬────────┬──────────┬────────┬──────────┐
│ Endpoint    ┆ First % ┆ P50 ms ┆ P95 ms ┆ P99 ms ┆ Valid Tx ┆ Firsts ┆ Backfill │
╞═════════════╪═════════╪════════╪════════╪════════╪══════════╪════════╪══════════╡
│ shredstream ┆ 95.59   ┆ 0.00   ┆ 0.00   ┆ 0.32   ┆ 20000    ┆ 19118  ┆ 0        │
├╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌┤
│ aperture    ┆ 4.41    ┆ 0.10   ┆ 0.41   ┆ 2.12   ┆ 20000    ┆ 882    ┆ 0        │
└─────────────┴─────────┴────────┴────────┴────────┴──────────┴────────┴──────────┘
```

**Review:** Aperture is faster than Yellowstone **by 10.7ms** on average, **by 35.5ms** in the top 5% of the results, and **by 50.7ms** in 1% of the results.

ShredStream is only **0.1ms** faster than Aperture on average, **0.4ms** in the top 5% of the results, and **2.1ms** in 1% of the results.

This signals about strong performance of the Aperture gRPC, considering that Aperture supports **server-side filters** and offers **reduced bandwidth usage**, compared to Shredstream.

{% hint style="warning" %}
**Note:** Tests were run on Latitude.sh in Frankfurt (*f4.metal.small).*
{% endhint %}

***

## WebSockets Performance

According to independent [benchmark results](https://x.com/CompareNodes/status/2077002160659677359?s=20) by CompareNodes (as of July 14), RPC Fast WebSockets deliver messages about Solana slots **faster than Alchemy.**&#x20;

Measured from 30 locations including Frankfurt using CompareNodes' public RPC Inspector Pro.

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

***

## Transaction Landing Performance: Beam

{% hint style="info" %}
[Benchmark code on Github](https://github.com/dysnix/solana-test/tree/main/sendtx-bench-rs). Create the type of transaction you need and check real-world performance.
{% endhint %}

### [Beam](https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta) Providers Performance Scoring

We evaluate each provider across five key performance metrics:

* Landing latency (milliseconds)
* Landing latency (slots)
* Transaction position within the block
* Same-slot landing rate
* Overall success rate

Each metric is normalized on a **0–100 scale** relative to the best-performing provider in the comparison set.

**For latency-related metrics,** p90 performance is weighted 4× more heavily than average performance, prioritizing consistency under load and minimizing tail latency.

**Block position** uses equal weighting between average and p90 values.

**The final performance score** is calculated as the unweighted average of all five metric scores.

#### **Five buckets:**

```
landed_ms = 0.2 × avg_score(submit_to_landed_grpc_ms)
+ 0.8 × p90_score(submit_to_landed_grpc_ms)
```

```
landed_slots = 0.2 × avg_score(submit_to_landed_slots)
+ 0.8 × p90_score(submit_to_landed_slots)
```

```
landed_idx = 0.5 × avg_score(landed_index_in_block)
+ 0.5 × p90_score(landed_index_in_block)
```

```
same_slot = higher_is_better_score(same_slot_landed_count)
```

```
success_ratio = higher_is_better_score(landed_runs / total_runs)
```

#### **Final score:**

```
performance_rate_pct = (landed_ms + landed_slots + landed_idx + same_slot + success_ratio) / 5
```

***

### Beam Providers Comparison

* Generated: `2026-05-19T15:16:33.756079549+00:00`
* Runs per provider: `10`
* Selected providers: `beam-astralane, beam-bloxroute, beam-falcon`

| Provider           | Avg Ack ms | P90 Ack ms | Avg Landed ms | P90 Landed ms | Avg Block ms | P90 Block ms | Avg Landed slots | P90 Landed slots | Avg Idx-in-Block | P90 Idx-in-Block | Avg Priority Fee | Max Slots | Min Slots | Same-slot landed | Landed runs | Block seen | Total runs | Success ratio % | Performance rate % |
| ------------------ | ---------- | ---------- | ------------- | ------------- | ------------ | ------------ | ---------------- | ---------------- | ---------------- | ---------------- | ---------------- | --------- | --------- | ---------------- | ----------- | ---------- | ---------- | --------------- | ------------------ |
| **beam-astralane** | 51.793     | 54.891     | 231.625       | 443.929       | 393.336      | 453.750      | 0.700            | 1.000            | 526.30           | 773.00           | 10000.000        | 1         | 0         | 3                | 10          | 10         | 10         | 100.00          | 99.78              |
| **beam-bloxroute** | 53.163     | 54.728     | 232.784       | 443.948       | 391.469      | 453.708      | 0.700            | 1.000            | 655.50           | 829.00           | 10000.000        | 1         | 0         | 3                | 10          | 10         | 10         | 100.00          | 99.66              |
| **beam-falcon**    | 53.888     | 54.612     | 229.601       | 443.934       | 390.611      | 453.725      | 0.700            | 1.000            | 658.30           | 830.00           | 10000.000        | 1         | 0         | 3                | 10          | 10         | 10         | 100.00          | 100.00             |

**Note:** The benchmark is optimized for same-slot landing. We subscribe to Aperture gRPC to detect new slot signals and trigger transaction submission immediately as a new slot begins. Transaction landing confirmation is determined through consensus between Aperture and Yellowstone data sources.

Aperture is not required for performance testing — unless explicitly specified, Yellowstone gRPC is used by default.

***

### Beam vs RPC Comparison

* Generated: `2026-05-19T15:22:23.427708898+00:00`
* Runs per provider: `20`
* Selected providers: `beam-astralane, rpcfast-rpc`

| Provider           | Avg Ack ms | P90 Ack ms | Avg Landed ms | P90 Landed ms | Avg Block ms | P90 Block ms | Avg Landed slots | P90 Landed slots | Avg Idx-in-Block | P90 Idx-in-Block | Avg Priority Fee | Max Slots | Min Slots | Same-slot landed | Landed runs | Block seen | Total runs | Success ratio % | Performance rate % |
| ------------------ | ---------- | ---------- | ------------- | ------------- | ------------ | ------------ | ---------------- | ---------------- | ---------------- | ---------------- | ---------------- | --------- | --------- | ---------------- | ----------- | ---------- | ---------- | --------------- | ------------------ |
| **beam-astralane** | 52.586     | 55.406     | 330.392       | 589.025       | 345.213      | 589.025      | 0.400            | 1.000            | 704.45           | 1092.00          | 10000.000        | 1         | 0         | 12               | 20          | 20         | 20         | 100.00          | 97.42              |
| **rpcfast-rpc**    | 27.570     | 38.891     | 457.492       | 1065.526      | 503.728      | 1065.526     | 0.650            | 2.000            | 574.65           | 1012.00          | 10000.000        | 4         | 0         | 12               | 20          | 20         | 20         | 100.00          | 82.20              |

***

## RPC Fast Endpoint Checker

Quick health checker for your Solana endpoint works both on mainnet and devnet: <https://check.rpcfast.com/>


# Support –> Solana

Support Chat Hours: Monday – Friday, 09:00–18:00 CET.

## Solana Endpoint Checker

Use Solana Endpoint Checker to check the current service availability using a token (no historical stats): <https://check.rpcfast.com/>.

***

## Solana RPC SaaS Support

{% hint style="warning" icon="light-emergency-on" %}
Technical support is available to our **customers on paid plans only**.\
At the moment, dedicated support is **not available** for SaaS users on blockchains other than Solana.
{% endhint %}

If you encounter any issues related to the RPC Fast service, please log in to your Solana RPC SaaS dashboard and contact us using the **Support** button.

#### Support chat hours:

Monday – Friday, 09:00–18:00 CET.

| Plan              | Start                                                            | Focus             | Stream            | Aperture                 |
| ----------------- | ---------------------------------------------------------------- | ----------------- | ----------------- | ------------------------ |
| **Support Level** | [Community Support on TG](https://telegram.me/+SpMbJTPTakAxNjdi) | Email – SLA 24h\* | Email – SLA 12h\* | Priority chat – SLA 8h\* |

\*SLA refers to the initial answer timeframe, not the final issue resolution.

We offer assistance **during Support Chat hours.** All requests outside of support hours are handled under the "Best Effort" SLA.

#### Priority chat support

{% hint style="success" icon="rabbit-running" %}
Customers on the **Aperture plan** are eligible for priority support via Telegram, providing faster communication for urgent technical or operational issues.
{% endhint %}

***

**The support service is off** during the public holidays in Ukraine:

* Independence Day of Ukraine (August 24)
* Christmas & New Year holidays (December 25 – January 3)

All requests outside of support hours are handled under the "Best Effort" SLA.


# Solana Dedicated Node

Boost your Solana project setup with dedicated high-performance infrastructure.

We offer [dedicated nodes](https://rpcfast.com/dedicated-solana-nodes) and/or high-availability clusters of nodes (2+) on Solana, whether your goal is to run a validator or RPC nodes for blockchain analytics and [trading](https://rpcfast.com/solana-trading-node).

## Why Dedicated Node?

{% hint style="success" %}
**No rate limits** – push it as far as the hardware can handle.
{% endhint %}

For **low latency use cases** like blockchain analytics and trading, high-frequency trading (HFT), real-time transactions tracking, we offer dedicated nodes along with [HFT-focused](https://rpcfast.com/solana-trading-node) tools and integrations:

* [Aperture TxStream](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/txstream) – optimised protocol for real-time deshredded Solana transactions and transaction simulation. The protocol reconstructs, recovers, deshreds, decodes, filters, and streams transactions through one optimised path, before normal validator replay metadata is available.
* **Jito Shredstream:** Get access to the lowest latency shreds from leaders on the Solana network, optimizing performance for HFT, validation, and RPC operations.
* **Yellowstone gRPC/Geyser:** Stream raw blockchain data to your dApp.
* **SWQoS:** Use [Beam](https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta) or Solana Trading API by bloXroute.
* **Custom indexing:** Track specific wallets, tokens, or contracts.
* Other plugins and tools on request.

**Node client:** Agave. Jito client can be used on request.

{% hint style="info" %}
We don't offer **historical/archival data** access while you are free to use a third-side provider of historical data APIs along with our dedicated node.
{% endhint %}

***

## Pricing

The Solana dedicated node pricing depends on the server capacity, defined by RPC methods/number of requests to be used and geo location chosen. It starts from **$2,200/month** in the EU location for 512GB RAM.

The price includes a **bare-metal server cost, setup**, and **maintenance**.

### Node Types

<table><thead><tr><th>Dedicated Node</th><th width="101.76031494140625">Server / RAM</th><th width="254.7322998046875">Limits</th><th width="258.4134521484375">Plugins &#x26; Integrations</th><th width="132.713623046875">EU, NA</th><th width="134.341796875">APAC</th></tr></thead><tbody><tr><td><strong>Light</strong></td><td>AMD EPYC 9355 <strong>512GB</strong></td><td><strong>No rate limits</strong><br><br>Default Solana RPC methods <strong>except</strong> heavy ones:<br><a href="https://solana.com/docs/rpc/http/getprogramaccounts">getProgramAccounts</a> <a href="https://solana.com/docs/rpc/http/gettokenaccountsbyowner">getTokenAccountsByOwner</a> <a href="https://solana.com/docs/rpc/http/gettokenaccountsbydelegate">getTokenAccountsByDelegate</a> <a href="https://solana.com/docs/rpc/http/gettokenlargestaccounts">getTokenLargestAccounts</a></td><td><ul><li>Yellowstone gRPC</li><li>ShredStream gRPC</li><li>Aperture gRPC (decoded shreds)</li><li>SWQoS via partners (<a href="https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta">Beam</a>) or SOL Trading API by bloXroute</li></ul></td><td>From $2,200/mo</td><td>From $2,500/mo</td></tr><tr><td><strong>Medium</strong></td><td>AMD EPYC 9355 <strong>1152GB</strong></td><td><strong>No rate limits.</strong><br><strong>All methods are available</strong></td><td><ul><li>Yellowstone gRPC</li><li>ShredStream gRPC</li><li>Aperture gRPC (decoded shreds)</li><li>SWQoS via partners (<a href="https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta">Beam</a>) or SOL Trading API by bloXroute</li></ul></td><td>From $2,700/mo</td><td>From $3,000/mo</td></tr><tr><td><strong>PRO</strong><br><br>Need something even more powerful?</td><td>AMD EPYC 9355 <strong>1.5 - 2.3TB RAM</strong></td><td><strong>No rate limits.</strong><br><strong>All methods are available</strong></td><td><ul><li>Yellowstone gRPC</li><li>ShredStream gRPC</li><li>Aperture gRPC (decoded shreds)</li><li>SWQoS via partners (<a href="https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta">Beam</a>) or SOL Trading API by bloXroute</li><li>Custom tools on request</li></ul></td><td>From $3,800/mo</td><td>From $4,000/mo</td></tr></tbody></table>

### Other Terms:

* **No setup fee!**
* **High-availability setup:** $200 one-time fee. This fee is required only **if you plan to scale** from one dedicated node to a cluster of 2+ nodes in the future, as it would allow seamless scaling.
* Both **crypto and fiat** payments are accepted.

{% hint style="info" %}
Contact our [Sales Team](https://telegram.me/dysnix_rpc) for a final quote based on your tech requirements.
{% endhint %}

***

## Testing

[Contact us](https://telegram.me/dysnix_rpc) for a dedicated node trial (paid option).

***

## Terms

**Setup timeline: \~5-7 working days** (after the server is delivered from the data center, which normally happens within 72 hours).

**Minimum contract length:** **3 months,** with the possibility of extension for an additional 3–12 months. We kindly ask for a **2-4 weeks notice** in the event of contract cancellation, to allow us sufficient time to make the necessary arrangements on our end.

**Payment:** **A flat monthly prepayment.** Both crypto and bank payments are accepted.

**Billing period:** Starts upon receipt of the server from the data center.

{% hint style="warning" %}
With one dedicated node, we can’t guarantee 100% uptime compared to a cluster of 2+ nodes, while we’ll make every effort to make the standalone node work stable and reliable without any losses. With a cluster of 2+ nodes, we can guarantee 98% uptime.
{% endhint %}


# Solana HA Cluster of Nodes

Boost your Solana project setup with high-availability, self-hosted, high-performance infrastructure.

For mid- and large-sized companies and Web3 projects, we offer [high-availability clusters of nodes](https://rpcfast.com/dedicated-cluster) (2+) on **Solana**, whether your goal is to run a validator or RPC node for blockchain analytics and trading.

## Blockchain Analytics & Trading, High-Frequency Trading (HFT)

We offer [HFT-focused](https://rpcfast.com/solana-trading-node) tools and integrations in addition to bare-metal servers **for no additional fee**, such as:

* **Jito ShredStream:** Get access to the lowest latency shreds from leaders on the Solana network, optimizing performance for HFT, validation, and RPC operations.
* **Yellowstone gRPC/Geyser:** Stream raw blockchain data to your dApp.
* **Jupiter Swap API:** Use self-hosted aggregator for fast, private swap execution.
* **swQoS integration:** Solana Trading API by bloXroute (requires additional tier purchase).
* **Custom indexing:** Track specific wallets, tokens, or contracts.
* Other plugins and tools on request.

***

## Self-Hosted Cluster on Solana

The self-hosted cluster offers additional advantages such as load balancing, autoscaling, speed optimization, geo-distribution, based on the client business goals. This allows building the most efficient infrastructure setup for your needs, to stay ahead of competitors.

**Why cluster is more efficient than a standalone node**

The ultra-fast HA node cluster surpasses traditional APIs and nodes. You get 2+ dedicated servers for **high-volume operations** with the lowest latency, customized, self-hosted infrastructure. Maintenance, customization, and support are fully covered by our team.

This is a perfect solution for:

* Blockchain analytics
* High-frequency trading
* High-load dApps
* MEV-focused projects

***

## Pricing

We spin up a minimum of two nodes within the high-availability node cluster. In the case of the cluster of validator nodes, we spin up one standby node in addition to the main node, to ensure 99-100% uptime and stable performance.

* **No setup fee!**
* For a cluster of 2+ bare-metal servers, the monthly price for our services (setup and maintenance) starts from **$2,000/month + server cost.** The server price depends on geolocation and load profile and server specs, plus any custom tools/requests placed.
* Adding one more blockchain to a cluster of nodes: **+ $1,000/month** (setup and maintenance).
* The load balancer is an additional feature depending on a data center's underlayer.
* Add-on fee (one-time, for extra expenses): **$200-400** per every setup up to 8 nodes.
* Both **crypto and fiat** payments are accepted.

{% hint style="info" %}
Contact our [Sales Team](https://telegram.me/dysnix_rpc) on Telegram to request a final quote based on your tech requirements.
{% endhint %}

***

## Terms

**Setup timeline: \~5-7 working days** (after the server is delivered from the data center, which normally happens within 72 hours).

**Minimum contract length:** **3 months,** with the possibility of extension for an additional 3–12 months. We kindly ask for a **2-4 weeks notice** in the event of contract cancellation, to allow us sufficient time to make the necessary arrangements on our end.

**Payment: A flat monthly prepayment.** Both crypto and bank payments are accepted.

**Billing period:** Starts upon receipt of the server from the data center.

{% hint style="success" %}
RPC Fast provides a fallback service (such as automated traffic rerouting to a healthy node during downtime or scheduled maintenance) with a load balancer.
{% endhint %}


# SLA for Solana Dedicated Node

RPC Fast offers an infrastructure solution by deploying and managing dedicated Solana node(s), along with optional tools such as Jito ShredStream, Yellowstone gRPC, and others upon request.

***

## Service Level Agreement (SLA) for Solana Dedicated Node

**The Setup Includes:**

* Initial configuration: servers setup, blockchain node integration.
* Testing and validation: pre-launch testing, functional validation.
* Monitoring and alerting deployment: real-time monitoring, alert configuration.
* Performance optimization: node configuration for high throughput and low latency.
* Plugins/tools setup and configuration: on request (TBD with the Client).

**The Maintenance Includes(\*):**

* Basic node monitoring: real-time monitoring, alert systems.
* Node upgrades: software updates, hard forks.
* Sync and network health: blockchain syncing, network performance tuning optimized for high network loads.

(\*) What is not included: services not directly connected with the functioning of the above.

**Scheduled Maintenance**

In the event of scheduled maintenance, the Client is promptly notified as soon as the need arises. Notifications are sent via the designated communication channel, along with a proposed maintenance window, to ensure minimal disruption to the Client’s operations.

***

### Support Schedule & SLA

We provide direct communication with our DevOps Engineers via a dedicated support channel on Slack.

**Service Level Agreement (SLA)**

{% hint style="success" %}
Guaranteed uptime of 98%, with typical availability exceeding 98-99%.
{% endhint %}

* **Priority Level 1:** Critical issues response time is up to 4 hours (\*).\
  Update of server-side software in case of detecting critical vulnerability.
* **Priority Level 2:** Non-critical issues response time is up to 1 business day (\*).\
  Install, or update, or tune the server-side software, including required by Client’s application.

<details>

<summary>(*) Support hours covered by SLA are Mon-Fri 8:00-19:00 CET.<br>All requests outside of support hours are handled under a "Best Effort" SLA.</summary>

</details>

{% hint style="warning" %}
**Important:** RPC Fast does not provide a fallback service (such as automated traffic rerouting to a healthy node during downtime or scheduled maintenance), as the setup is based on a standalone node rather than a high-availability (HA) cluster with a load balancer. Implementing a fallback mechanism is the responsibility of the Client.
{% endhint %}

The support service is off during the public holidays in Ukraine:

* Independence Day of Ukraine (August 24);
* Christmas & New Year holidays (December 25 – January 5).

**Maximum Initial Response Time**

Requests from a Client’s contact person will be answered within a **guaranteed time frame** (see above). Support requests will be acknowledged within the maximum time listed, although actual response time may be faster. This does not include the total time required to resolve the request.

A shared **dedicated channel** between RPC Fast and the Client shall be used for reporting issues or bugs and for all written communication between the RPC Fast and Client teams. Critical issues must be reported through the dedicated channel. All business and financial communications shall be conducted via email.

**Escalation Path:** In the event that the primary point of contact is unavailable or unable to resolve a critical issue, please contact the Project Manager in the designated Slack channel or via email.

***

### Important Context on SLA Design

As a dedicated infrastructure provider (not a SaaS provider for this matter), our SLA times are designed to reflect hands-on, system-level issue resolution – not just API-level service guarantees.

That said, our track record **since 2018** shows:

* **Zero recorded incidents** of actual service interruption.
* All critical or potentially critical issues **resolved immediately or within minimal time**, often proactively before any impact occurred.

We treat infrastructure uptime as the core of our service promise and implement failover strategies even for single-node deployments to ensure uninterrupted availability.


# Performance and Benchmarking

RPC Fast nodes typically outperform default self-hosted RPC node solutions, especially in the speed of receiving events from the Solana blockchain.

{% hint style="success" %}
ShredStream boosts arrival time of processed transactions by **up to 270ms** when using Yellowstone gRPC geyser subscription.
{% endhint %}

### Benchmarking

To benchmark two gRPC endpoints:\
<https://github.com/dysnix/solana-test/tree/main/yellowstone-bench>.

**Node performance with vs. without Jito:** With Jito, the node receives 99.71% of transactions faster with an average advantage of 120ms.

```
[SUMMARY]
  Matching txns: 185141
  Avg delta: 120.360582 ms
  75th percentile delta: 165.634304 ms
  90th percentile delta: 218.932224 ms
  95th percentile delta: 239.485952 ms
  99th percentile delta: 270.596147 ms
  99.71% of txns: JITO.json is faster than NONE.json
  0.29% of txns: JITO.json is slow than NONE.json
```

To measure the latency of the RPC endpoint requests, refer to the guide: [RPC latency benchmark](https://github.com/dysnix/solana-test/tree/main/rpc-latency-bench).

To compare receiving speed of processed transactions between two Yellowstone gRPC providers, refer to the guide: [Yellowstone gRPC benchmark](https://github.com/dysnix/solana-test/tree/main/yellowstone-bench).

***

### Optimisation

If you are our customer, you can **achieve even lower latency** and **maximise throughput** **to your dedicated node** in two simple steps:

1. Contact [RPC Fast](https://t.me/dysnix_rpc) and ask to **disable CloudFlare** protection of your nodes endpoint.
2. **Co-location:** Order a server or VPS in the same DC as your nodes are located. RPC Fast is your primary contact point to pick up the same hosting provider as the one hosting your nodes.

These measures may lower the latency between your workloads and RPC Fast dedicated nodes **to less than 0.9ms.**

***

### Case Studies

* [x] [HA self-hosted cluster of two nodes for quantitative trading and real-time data tracking on Solana](https://rpcfast.com/blog/hft-company-solana-nodes-case-study).
* [x] [Dedicated node on Solana + self-hosted cluster on Base: Real-time data, analytics, and trading across two blockchains](https://rpcfast.com/blog/mizar-dysnix-case-study).
* [x] [Mizar Case study (Solana, Base): Full Breakdown by OVHcloud](https://www.ovhcloud.com/en-gb/case-studies/dysnix/).


# Shredstream gRPC

### Benefits

If you're a trader or need to receive transaction data earlier than your competitors, simple subscription to [Yellowstone gRPC endpoint](https://docs.rpcfast.com/rpc-fast-api/yellowstone-grpc) to retrieve transactions data in real time might not be sufficient for you – Solana RPC node still needs to insert shreds, process and validate them, before sending them via Yellowstone gRPC subscription. To overcome this behavior, you can subscribe directly to shredstream using the gRPC interface.

RPC Fast infra receives shreds from Jito and other partner providers to boost the performance.

> **Shredstream gRPC** endpoint is offered within the **Aperture plan** (SaaS) and a [dedicated node](https://rpcfast.com/dedicated-solana-nodes) offering at no add-on cost.

Using direct gRPC subscription to the shredstream endpoint, you will

* receive transactions **\~50-100ms earlier** on average, compared to Yellowstone gRPC;
* receive **even more** transactions, including failed and votes;
* **avoid** time-consuming replay of transactions by RPC node.

{% hint style="info" %}
Check out Geyser vs Shredstream benchmark on our [Github](https://github.com/dysnix/solana-test/tree/main/geyser-vs-shredstream).
{% endhint %}

### What's inside a Solana shred?

Shred is an essential component of Solana architecture. A shred is a fragment of a Solana block. Instead of transmitting entire blocks, Solana breaks them down into smaller pieces called *shreds*, which are easier to send and recover over the network.

Each shred contains unordered transactions data, slot number, it's index inside the slot.

{% hint style="success" %}
When using Shredstream gRPC, shreds are already reconstructed to **Solana entries**, which contain already ordered and serialized transactions.
{% endhint %}

For more info about the format of Solana entry, please refer to [Solana documentation](https://docs.rs/solana-entry/latest/solana_entry/entry/struct.Entry.html).

### How to create a direct subscription to Jito Shredstream?

1. If you already have a Solana dedicated node, you can use following endpoint for gRPC subscription: `sol-shredstream-CUSTOMER.rpcfast.net:443`
2. To decode gRPC stream, you need protobuf files. You can get them here: <https://github.com/jito-labs/mev-protos>
3. Install [grpcurl](https://github.com/fullstorydev/grpcurl) software onto your machine.
4. Launch grpcurl command from the directory where protobuf files has been downloaded:\\

   ```bash
   grpcurl \
     -proto shredstream.proto \
     -H 'x-token: YOUR_AUTH_TOKEN' \
     sol-shredstream-CUSTOMER.rpcfast.net:443 \
     shredstream.ShredstreamProxy/SubscribeEntries
   ```
5. You will start to receive **encoded** Solana entries.

### How to decode Solana shreds into human-readable format?

1. Clone the repository <https://github.com/dysnix/solana-test>
2. Run the following command inside repository to download code example

   ```bash
   git submodule init && git submodule update --recursive --remote --force
   ```
3. Navigate to `jito-shredstream-proxy/examples` directory.
4. [Install Rust language](https://rustup.rs/) tools onto your machine.
5. Set environment variables

   ```bash
   export SHREDSTREAM_GRPC_URL=https://sol-shredstream-CUSTOMER.rpcfast.net
   export SHREDSTREAM_AUTH_TOKEN=YOUR-AUTH-TOKEN
   ```
6. Launch code example

   ```bash
   cargo run --example deshred
   ```
7. You will receive decoded transactions for each slot.
8. If you want to integrate this to your application code or workflow, please use `deshred.rs` as an example.


# Yellowstone gRPC

The **Yellowstone gRPC endpoint** is mostly used to subscribe to events on the Solana network, such as transactions, votes, new blocks, program executions, etc. – it is the best option to receive transaction data as fast as possible. Compared to traditional WebSocket subscriptions, gRPC has **minimal latency** and **maximum throughput.**

> **Yellowstone gRPC** endpoint is offered within the **Stream plan** (SaaS) and a [dedicated node](https://rpcfast.com/dedicated-solana-nodes) offering at no additional cost.

### How to test Yellowstone gRPC endpoint

1. Install [grpcurl](https://github.com/fullstorydev/grpcurl) software onto your machine.
2. Download Yellowstone gRPC proto files [geyser.proto](https://github.com/rpcpool/yellowstone-grpc/releases/download/v6.0.0%2Bsolana.2.2.4/geyser.proto), [solana-storage.proto](https://github.com/rpcpool/yellowstone-grpc/releases/download/v6.0.0%2Bsolana.2.2.4/solana-storage.proto) (gRPC protocol needs to know methods and how to interact with them).
3. Place these files to the folder from where you want to invoke `grpcurl` command.
4. Grab your endpoint (i.e. `sol-yellowstone-customer.rpcfast.net`) and your token, which you have received when you ordered the node.
5. From terminal, launch the command to show the current slot number of the node.

   {% code overflow="wrap" %}

   ```shell
   X_TOKEN="YOUR-TOKEN"
   YELLOWSTONE_ENDPOINT="YOUR-YELLOWSTONE-GRPC-ENDPOINT"

   grpcurl \
     -proto geyser.proto \
     -H "x-token: ${X_TOKEN}" \
     ${YELLOWSTONE_ENDPOINT} geyser.Geyser/GetSlot
   ```

   {% endcode %}
6. To test subcription to events, let's take a look at an example of subscribing to transactions on Pump.fun with "processed" commitment level:

   {% code overflow="wrap" %}

   ```shell
   X_TOKEN="YOUR-TOKEN"
   YELLOWSTONE_ENDPOINT="YOUR-YELLOWSTONE-GRPC-ENDPOINT"

   grpcurl \
     -proto geyser.proto \
     -H "x-token: ${X_TOKEN}" \
     -d '{
           "transactions": {
             "pumpfun": {
               "account_include": ["6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P"]
             }
           },
           "commitment": 0
         }' \
     "${YELLOWSTONE_ENDPOINT}" geyser.Geyser/Subscribe
   ```

   {% endcode %}7. For further usage with your applications, please refer to examples, written in Go, Rust and Node:\
   <https://github.com/rpcpool/yellowstone-grpc/tree/master/examples/golang>\
   <https://github.com/rpcpool/yellowstone-grpc/tree/master/examples/rust>\
   <https://github.com/rpcpool/yellowstone-grpc/tree/master/examples/typescript>
7. Refer to official documentation for advanced usage: \
   <https://docs.triton.one/project-yellowstone/dragons-mouth-grpc-subscriptions>.


# Low-Latency Solana Playbook for HFT

High-frequency trading (HFT) on Solana demands **sub-millisecond reaction times** and **guaranteed transaction landing**. Below is the recommended setup for traders, bots, and protocols that want the lowest possible latency.

It is possible to optimise Solana latency by combining services (ShredStream, Yellowstone, Aperture gRPC + Beam transaction sending service or bloXroute) plus infra tuning and colocation – but the gains, costs, and trade-offs (centralization/MEV exposure, complexity) vary.

#### 1. Infrastructure foundation: bare-metal + tuning by RPC Fast <a href="#id-1.-infrastructure-foundation-bare-metal--tuning-by-rpc-fast" id="id-1.-infrastructure-foundation-bare-metal--tuning-by-rpc-fast"></a>

* **Hardware:** RPC Fast provisions the most efficient bare-metal servers with 512GB-1.5TB RAM.
* **Location:** Servers colocated in proximity to Solana leader nodes constellations. Optimized regions for using SWQoS and Jito are Frankfurt, London, and NY (Latitude, Equinix, TeraSwitch datacenters).
* **Tuning & Maintenance:**
  * **Performance optimization:** node configuration for high throughput and low latency. Our engineers reduce base network latency and variance before layering Solana-specific optimizations.
  * **Recommended methods** for efficient event monitoring: [Aperture gRPC](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/aperture-grpc-beta), [ShredStream gRPC](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/data-access-options), [Yellowstone gRPC](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/yellowstone-grpc).
  * **Proactive monitoring & alerts.**
  * **Sync and network health,** full managed service – RPC Fast keeps infra always at peak.

#### 2. Market data ingestion – get shreds faster <a href="#id-2.-market-data-ingestion-get-shreds-faster" id="id-2.-market-data-ingestion-get-shreds-faster"></a>

{% hint style="info" %}
Read more about the data streaming options included in our RPC subscriptions [here](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming).
{% endhint %}

* **ShredStream** gRPC (Jito + other providers) → direct feed of leader-produced shreds. Traders see block data hundreds of ms earlier than waiting on Turbine/gossip.
* [Aperture gRPC](https://docs.rpcfast.com/rpc-fast-saas-solana/data-streaming/aperture-grpc-beta) → designed for **low-latency transactions streaming**. Aperture gRPC reconstructs raw shreds into a structured stream compatible with the Yellowstone gRPC model, while bypassing traditional RPC node processing.
* **Yellowstone gRPC** (Geyser plugin) → structured, filtered, and low-latency streams for accounts, slots, and transactions. Perfect for strategy logic, dashboards, and monitoring.
* **bloXroute OFR / BDN** → globally optimized relay delivering shreds with 30–50+ ms gains vs default propagation. However, according to our tests, Jito performs better than bloXroute OFR (as of summer 2025).

{% hint style="success" %}
RPC Fast integrates the feeds requested by the client, based on most efficient performance and client’s specific requirements.
{% endhint %}

**Note:** A smart routing for whichever feed delivers first happens automatically – all data feeders (Jito ShredStream, bloXroute OFR) push shreds to the Solana node in addition to p2p (Turbine in Solana). The node uses the data that arrived the fastest. However, there has been a trend to replace the "Solana node + Yellowstone gRPC" pair with ShredStream gRPC, so as not to wait for the Solana node.

#### 3. Transaction submission – land first, not last <a href="#id-3.-transaction-submission-land-first-not-last" id="id-3.-transaction-submission-land-first-not-last"></a>

* [RPC Fast Beam](https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta) transaction sending service (SWQoS via the partners' network).
* **Jito's** [Low Latency Transaction Send](https://docs.jito.wtf/lowlatencytxnsend/) (or Jito Block Engine transaction submission) → direct, priority transaction submission with bundle support for MEV-aware trading.
* **bloXroute Trading API** → RPC Fast partnered with bloXroute to bring SWQoS benefits to our clients. The [Solana Trading API](https://bloxroute.com/products/solana-trader-api/) provides blazing-fast transaction propagation on Solana network (83% of transactions land first compared to public RPC), as well as additional features, such as MEV protection.
* **Colocation Peering** → servers are placed in the right spots to minimize latency to leaders.

{% hint style="success" %}
**Result:** transactions arrive earlier at the leader and get a better shot at first-slot inclusion.
{% endhint %}

#### 4. Trade-offs to keep in mind <a href="#id-4.-trade-offs-to-keep-in-mind" id="id-4.-trade-offs-to-keep-in-mind"></a>

* **Centralization & MEV:** Relying on Jito/bloXroute means aligning with their relay ecosystems.
* **Cost:** Bare-metal, colocation, and premium feeds are not cheap – but for HFT, speed is profit.
* **Complexity:** RPC Fast abstracts this away with full DevOps + infrastructure management.

### Recommended Setup (Step-by-Step) <a href="#recommended-setup-step-by-step" id="recommended-setup-step-by-step"></a>

1. Provision bare-metal high-performance server in leader-adjacent DCs (handled by RPC Fast).
2. Use Shredstream or Aperture gRPC to obtain the fastest data.
3. Use Yellowstone gRPC for structured feeds.
4. Route transactions via Jito Block Engine, [Beam](https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta) or bloXroute Trader API.
5. RPC Fast engineers will assist in continuous benchmarking & performance tuning via dedicated communication channels.
6. Scale horizontally with multi-region redundancy, if needed.

With RPC Fast handling infra + optimization, HFT teams can focus entirely on strategy and execution, knowing their Solana connection is as fast, stable, and tuned as physics allows.

### Parallel Submission <a href="#parallel-submission" id="parallel-submission"></a>

Broadcasting a single signed transaction to **multiple RPC/relay endpoints in parallel** increases the probability that (a) at least one path delivers it quickly to the current leader and (b) it avoids single-path congestion or transient RPC failures – as long as you handle blockhash expiry, deduplication, and monitoring correctly.

{% hint style="success" %}
RPC Fast provides several options for sending transactions and we recommend combining various approaches for more efficient performance.
{% endhint %}

#### Why parallel submission helps <a href="#why-parallel-submission-helps" id="why-parallel-submission-helps"></a>

* **Multiple network paths → lower tail latency.** Different RPC providers and relays have different peering, geographic placement, and routing to validators/leaders. Sending to several reduces p95/p99 propagation time to the leader (race-to-leader effect). The transaction will only go through using one path (and fail/reverse in others) and will be free of charge. Yet, be aware of RPC rate limits regardless of success.
* **Different relayer ecosystems catch different leaders.** Some relays (Jito, bloXroute OFR, private relayers) have direct/private routes to leaders or trader-focused routing; sending to them in parallel exploits whichever has the fastest path to the current leader.
* **Race improves inclusion odds vs. queueing/MEV competition.** If there’s contention for a slot, the node that reaches the leader first (or the relay that hands higher-priority tx to a block-builder) has the advantage. Broadcasting broadly turns latency into a competitive edge.

{% hint style="info" %}
**Note:** The tools for sending transactions provided by RPC Fast differ by application. Dedicated node’s **RPC endpoint** allows to send thousands of transactions per second "for free", **bloXroute trading API** is efficient for medium-cost transactions, **Jito Block Engine** – for top transactions (since RPS limits are low). The difference between bloXroute and Jito Block Engine may not correspond to reality.
{% endhint %}

#### Quick checklist to try this today <a href="#quick-checklist-to-try-this-today" id="quick-checklist-to-try-this-today"></a>

1. Pick 3–5 endpoints (include at least one leader-aware relay: Jito or bloXroute).
2. Implement parallel fan-out of the same signed tx to all endpoints.
3. Listen for `sendTransaction` acceptance + `getSignatureStatuses`. Stop after first accepted and track finalization.
4. Repeat under different network conditions and collect p50/p95/p99.
5. Add durable nonce if you require multi-minute retry windows.

#### Risks & trade-offs <a href="#risks-and-trade-offs" id="risks-and-trade-offs"></a>

* **Cost & rate limits:** Broadcasting to many paid endpoints increases usage & cost and may hit RPC rate limits. Budget accordingly.
* **Increased attack surface / centralization:** Over-reliance on a single relay provider undoes redundancy goals; diversify relays. Also be explicit about MEV exposure – some relayers may reorder or insert MEV-enabled behavior. [DEV Community](https://dev.to/btcmiles/types-of-quantitative-trading-on-solana-iah)
* **False positives on “accepted”:** Some RPCs report accepted locally but may drop the tx before it reaches the leader (always follow up with network status checks). [Medium](https://medium.com/%40yhl125/solana-transaction-c277de3cd6ec)


# Self-Hosted Cluster of Nodes

Boost your Web3 project setup with own HA dedicated infrastructure.

For mid- and large-sized businesses, VCs and Web3 projects, we offer [high-availability clusters of nodes](https://rpcfast.com/dedicated-cluster) (2+) on almost **any chain of your choice,** whether your goal is to run a validator, RPC nodes for blockchain analytics and [HFT](https://rpcfast.com/solana-trading-node), or archive nodes for data ETL solutions.

## Self-Hosted Cluster on a Blockchain of Your Choice

The self-hosted cluster offers advantages such as load balancing, autoscaling, speed optimization, geo-distribution, and HFT-focused tools, based on the client's business goals.

{% hint style="info" %}
Deployment and maintenance of EVM-based blockchain nodes will most likely take place in the cloud, mainly in GCP.
{% endhint %}

***

## Pricing

We spin up a minimum of two nodes within the high-availability node cluster. In the case of the cluster of validator nodes, we spin up one standby node in addition to the main node, to ensure 99-100% uptime and stable performance.

* For a cluster of 2+ bare-metal servers, the monthly price for our services (setup and maintenance) starts from **$2,000/month + server cost.** The server price depends on geolocation and load profile and server specs, plus any custom tools/requests placed.
* Adding one more blockchain to a cluster of nodes: **+ $1,000/month** (setup and maintenance).
* The load balancer is an additional feature depending on a data center's underlayer.
* Add-on fee (one-time, for extra expenses): **$200-400** per every setup up to 8 nodes.

{% hint style="info" %}
Contact our [Sales Team](https://telegram.me/dysnix_rpc) on Telegram to request a final quote based on your tech requirements.
{% endhint %}

***

## Terms

**Setup timeline: \~5-7 working days** (after the server is delivered from the data center, which normally happens within 72hrs).

**Minimum contract length:** **3 months,** with the possibility of extension for an additional 3–12 months. We kindly ask for a **2-4 weeks notice** in the event of contract cancellation, to allow us sufficient time to make the necessary arrangements on our end.

**Payment:** **A flat monthly prepayment.** Both crypto and bank payments are accepted.

**Billing period:** Starts upon receipt of the server from the data center.

{% hint style="success" %}
RPC Fast provides a fallback service (such as automated traffic rerouting to a healthy node during downtime or scheduled maintenance) with a load balancer.
{% endhint %}

## Case Studies

* [x] [HA self-hosted cluster of two nodes for quantitative trading and real-time data tracking on Solana](https://rpcfast.com/blog/hft-company-solana-nodes-case-study).
* [x] [Dedicated node on Solana + self-hosted cluster on Base: Real-time data, analytics, and trading across two blockchains](https://rpcfast.com/blog/mizar-dysnix-case-study).
* [x] [Mizar Case study (Solana, Base): Full Breakdown by OVHcloud](https://www.ovhcloud.com/en-gb/case-studies/dysnix/).


# SLA for Self-Hosted Cluster of Nodes

RPC Fast offers a self-hosted HA infrastructure setup along with optional tools such as Transaction Simulator, Mempool Data Stream, PredictKube, JSON RPC Caching Proxy, and others.

***

## Service Level Agreement (SLA) for Self-Hosted Cluster of Nodes

**The Setup Includes:**

* Initial configuration: servers setup, blockchain node integration.
* Testing and validation: pre-launch testing, functional validation.
* Monitoring and alerting deployment: real-time monitoring, alert configuration.
* Performance optimization: node configuration for high throughput and low latency.
* Additional tools/solutions setup and configuration: on request (TBD with the Client).

**The Maintenance Includes(\*):**

* Basic node monitoring: real-time monitoring, alert systems.
* Node upgrades: software updates, hard forks.
* Sync and network health: blockchain syncing, network performance tuning optimized for high network loads.

(\*) What is not included: services not directly connected with the functioning of the above.

**Scheduled Maintenance**

In the event of scheduled maintenance, the Client is promptly notified as soon as the need arises. Notifications are sent via the designated communication channel, along with a proposed maintenance window, to ensure minimal disruption to the Client’s operations.

***

### Support Schedule & SLA

We provide direct communication with our DevOps Engineers via a dedicated channel on Slack.

**Service Level Agreement (SLA)**

{% hint style="success" %}
Guaranteed uptime of 98%, with typical availability exceeding 98-99%.
{% endhint %}

* **Priority Level 1:** Critical issues response time is up to 4 hours (\*).\
  Update of server-side software in case of detecting critical vulnerability.

{% hint style="success" %}
RPC Fast provides a fallback service (such as automated traffic rerouting to a healthy node during downtime or scheduled maintenance) with a load balancer.
{% endhint %}

* **Priority Level 2:** Non-critical issues response time is up to 1 business day (\*).\
  Install, or update, or tune the server-side software, including required by Client’s application.

<details>

<summary>(*) Support hours covered by SLA are Mon-Fri 8:00-19:00 CET.<br>All requests outside of support hours are handled under a "Best Effort" SLA.</summary>

</details>

The support service is off during the public holidays in Ukraine:

* Independence Day of Ukraine (August 24);
* Christmas & New Year holidays (December 25 – January 5).

**Maximum Initial Response Time**

Requests from a Client’s contact person will be answered within a **guaranteed time frame** (see above). Support requests will be acknowledged within the maximum time listed, although actual response time may be faster. This does not include the total time required to resolve the request.

A **shared dedicated channel** between RPC Fast and the Client shall be used for reporting issues or bugs and for all written communication between the RPC Fast and Client teams. Critical issues must be reported through the dedicated channel. All business and financial communications shall be conducted via email.

**Escalation Path:** In the event that the primary point of contact is unavailable or unable to resolve a critical issue, please contact the Project Manager in the designated Slack channel or via email.

***

### Important Context on SLA Design

As a dedicated infrastructure provider (not a SaaS provider for this matter), our SLA times are designed to reflect hands-on, system-level issue resolution – not just API-level service guarantees.

That said, our track record **since 2018** shows:

* **Zero recorded incidents** of actual service interruption.
* All critical or potentially critical issues **resolved immediately or within minimal time**, often proactively before any impact occurred.

We treat infrastructure uptime as the core of our service promise and implement failover strategies even for single-node deployments to ensure uninterrupted availability.


# Archive Nodes

RPC Fast API serves clients with the fastest archive nodes on the market.

## Archive Node Offering

{% hint style="info" %}
RPC Fast offers archive nodes on Ethereum, BNB Chain, and other selected blockchains within the [Self-Hosted Cluster](/self-hosted-cluster/self-hosted-cluster-of-nodes) offering.
{% endhint %}

**Archive nodes** store information about previous operations on the particular blockchain and its historical statements. It will help you when you need access to earlier blocks’ data. Running an archive node takes more time and storage capabilities than a typical one. It usually stores a massive amount of data and needs more time for processing.

### Archive Data on ETH

Once, your cluster of nodes set, request archive data for your dApp via one of the JSON-RPC methods:

* eth\_getBalance
* eth\_getProof (only available on BSC)
* eth\_getCode
* eth\_getStorageAt
* eth\_call
* eth\_estimateGas
* eth\_getTransactionCount

***

## Request a Quote

Contact our [Sales Team](https://telegram.me/dysnix_rpc) on Telegram to request a quote based on your tech requirements.


# Introduction

Blockchains: Ethereum, Base, Polygon, BSC, Arbitrum.

## **RPC Fast API Access**

The RPC Fast API gives instant access over HTTPS and WebSockets to **Ethereum** and a few selected EVM blockchains, such as **Base, BSC, Arbitrum,** and **Polygon**.

We provide a high level of security, stable connection, and an intuitive control panel.

* **Standard Interface:** Get access to our JSON-RPC endpoint and 100% healthy nodes on production.
* **Stable Connection:** Geo-distributed infrastructure makes it run smoothly without harming the UX. The software updates automatically and saves your time.
* **High-level Security:** JSON Web Token application is available for the Enterprise plan. The architecture is error-proofed and consistent. Great for smart contracts.
* **Auto-scaling Infrastructure:** AI-based PredictKube mechanism autoscales the node pool to get your project ready for any traffic amount.
* **Control Panel:** RPC Fast dashboard is intuitive. Here you will find automatically-built reports about your blockchain hosting state.


# Getting Started

Welcome to RPC Fast! Create your first dApp for free in three simple steps.

## How to Start Using RPC Fast

#### Sign Up / Sign In

1. Start your registration on the [main page](https://rpcfast.com/). Use "Log In" button in the right side of the header.

   <figure><img src="/files/kghy5Y3eiCbYBGGVR7KX" alt=""><figcaption></figcaption></figure>
2. Enter your email and password. Otherwise, you can continue with your Google account.

   <figure><img src="/files/1w9gA1se0GI5VPaBOKWs" alt="sign up rpc fast"><figcaption><p>RPC Fast registration</p></figcaption></figure>
3. That’s all. Now you are signed up in our system.

#### First dApp Creation

Creating a project-based unit is your first step in sending RPC requests on our API. After entering the account, a user can see three apps for three different blockchain types that were created automatically. A user can choose one of existing apps or create a new one by following the instructions below.

1. Tap the button "Create app".

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

2. Choose one of the chains available (Ethereum, Base, BSC, Polygon, or Arbitrum). \
   Name your app. Give it a description (optionally).

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

3. After tapping "Create", you will see the dashboard with information about requests, success rate, and other statistics.

#### Find API Endpoints

You will see the unique API Key in the "API Key" section. This information is strictly confidential, and anyone else should not see it. There are also Https and Websocket endpoints for your use.

#### Sending Requests

An API Key allows you to send requests on RPC Fast. Check out the limits of the [Free Plan](/rpc-fast-saas-evm/pricing-and-plans).


# Pricing and Plans

Currently, there are two plans available for EVM-based networks – **Free** and **Growth**.

### Free Plan

There is a limited Free plan available for **ETH, Base, Polygon, BSC,** and **Arbitrum.**

We offer our free subscription for those who start building and are trying the blockchain abilities. A Free plan gives you access to healthy nodes and the basic features of our API service. All you need to do is sign up via email; **no credit card is required** to start using RPC endpoints.

For better understanding and transparency, we reject the pay-per-request approach – instead, we use the CU logic. On Free plan, there is no overusage fee. If you are exceeding CU limits, the request simply won’t get processed, and you will be notified about it (check out [Compute Units](/rpc-fast-saas-evm/compute-units-cus)).

### Free vs Growth

The [Growth](/rpc-fast-saas-evm/pricing-and-plans/growth-plan) plan is recommended for more advanced builders.

| Plan / Feature | Free                   | Growth                 |
| -------------- | ---------------------- | ---------------------- |
| Apps           | Up to 5 apps           | Up to 15 apps          |
| Rate limits    | 300,000,000 CU         | 500,000,000 CU         |
| API            | Https & Websockets API | Https & Websockets API |
| Region         | EU                     | EU, Asia               |

### Billing, Payments, and Terms of Use

By creating an account, joining the waitlist, accessing the dashboard, or using the Service, you agree to be bound by our [Terms of Service](https://docs.rpcfast.com/legal/terms-of-service). If you do not agree, you must not use the Service.

Subscription plans include a defined monthly allocation of Compute Units (CU) and are billed in advance at the start of each billing cycle using your selected payment method.

You authorize RPC Fast (or its third-party payment processor) to charge all applicable fees, taxes, and overage charges to your payment method.

RPC Fast uses Stripe to process payment card transactions and generate invoices. By making a payment, you agree to the applicable terms and policies of the relevant payment provider.

{% hint style="warning" %}
All fees are **non-refundable** unless required by applicable law.
{% endhint %}

Read more about the subscription plans, credits & billing, applicable taxes, as well as general usage restrictions, refund policy, and abuse prevention & fair use policy in the [Terms of Service](https://docs.rpcfast.com/legal/terms-of-service).

***

## Dedicated Self-Hosted Infrastructure

For mid- and large-sized companies and Web3 projects, we offer custom approach – [dedicated Solana nodes](https://rpcfast.com/dedicated-solana-nodes) and [high-availability clusters of nodes](https://rpcfast.com/dedicated-cluster) (2+) on a specific blockchain of your choice, whether your goal is to run a validator, RPC nodes for [DeFi](https://rpcfast.com/defi-infrastructure), trading, and/or blockchain analytics, or archive nodes for data ETL solutions.

The self-hosted cluster offers premium advantages such as load balancing, autoscaling, speed optimization, geo-distribution, and HFT-focused tools, based on the business goals.

{% hint style="info" %}
Contact our [Sales Team](https://telegram.me/dysnix_rpc) on Telegram to discuss your technical brief for a dedicated setup.
{% endhint %}


# Growth Plan

Best option for dedicated developers, providing higher throughput and extended usage abilities.

**Growth plan includes:**

* Up to 15 apps
* 500,000,000 CU
* Https & Websockets API
* Dashboard & Statistics
* AI-based predictive autoscaling
* Region: EU, Asia

### How to Upgrade to Growth Subscription

1. Log in on the RPC Fast website and go to the Billing and Usage section.

   <figure><img src="/files/E6dJBLmjvjU6yPKjH4Ey" alt="rpc fast dashboard"><figcaption></figcaption></figure>
2. Tap ‘Upgrade to Growth’.

   <figure><img src="/files/EZf7DiTS192YzoGeysnT" alt="rpc fast billing"><figcaption></figcaption></figure>
3. Fill out your credit card information and country.

   <figure><img src="/files/2puLVIlieInq0IHxDXSO" alt="upgrade account rpc fast"><figcaption></figcaption></figure>
4. Confirm the payment information. A payment is **monthly recurring.**
5. Congrats! Now you have upgraded your plan to the Growth subscription.

***

## Custom Setup: Dedicated Self-Hosted Infrastructure

For mid- and large-sized companies and Web3 projects, we offer custom approach – [dedicated Solana nodes](https://rpcfast.com/dedicated-solana-nodes) and [high-availability clusters of nodes](https://rpcfast.com/dedicated-cluster) (2+) on a specific blockchain of your choice, whether your goal is to run a validator, RPC nodes for blockchain analytics and [HFT](https://rpcfast.com/solana-trading-node), or archive nodes for data ETL solutions.

The self-hosted cluster offers advantages such as load balancing, autoscaling, speed optimization, geo-distribution, and HFT-focused tools, based on a client business goals.

{% hint style="info" %}
Contact our [Sales Team](https://telegram.me/dysnix_rpc) on Telegram to discuss your technical brief for a dedicated setup.
{% endhint %}


# Compute Units (CUs)

We use Compute Units as an alternative to the ‘pay-per-click’ method. It provides greater flexibility and cost savings.

### Compute Units (CU) balance

The **CU balance** allows you to use methods with a specific price for the application. It enables you to optimize your spending and calculate the usage more precisely. Summing up, you only pay for the methods you use. **Free plan has 300M CUs available.**

### RPC Methods Cost in CU

We calculate the cost of each method based on the computational capacity, time, and CPU spent on each action.

### Supported Methods

**BSC, Ethereum, and Polygon**

|                                          |      |
| ---------------------------------------- | ---- |
| eth\_call                                | 25   |
| trace\_get                               | 17   |
| web3\_sha3                               | 15   |
| trace\_call                              | 75   |
| eth\_chainId                             | 5    |
| eth\_getCode                             | 19   |
| eth\_getLogs                             | 65   |
| eth\_syncing                             | 5    |
| net\_version                             | 5    |
| trace\_block                             | 24   |
| erigon\_forks                            | 24   |
| eth\_accounts                            | 5    |
| eth\_gasPrice                            | 19   |
| eth\_getProof                            | 21   |
| trace\_filter                            | 75   |
| eth\_newFilter                           | 20   |
| eth\_subscribe                           | 10   |
| net\_listening                           | 5    |
| erigon\_issuance                         | 24   |
| eth\_getBalance                          | 19   |
| trace\_callMany                          | 75   |
| eth\_blockNumber                         | 5    |
| eth\_estimateGas                         | 75   |
| eth\_unsubscribe                         | 10   |
| eth\_getStorageAt                        | 17   |
| eth\_getFilterLogs                       | 75   |
| trace\_transaction                       | 26   |
| eth\_getBlockByHash                      | 21   |
| eth\_newBlockFilter                      | 20   |
| web3\_clientVersion                      | 5    |
| eth\_uninstallFilter                     | 10   |
| erigon\_getLogsByHash                    | 24   |
| eth\_getBlockByNumber                    | 16   |
| eth\_getBlockReceipts                    | 500  |
| eth\_getFilterChanges                    | 20   |
| trace\_rawTransaction                    | 75   |
| erigon\_getHeaderByHash                  | 24   |
| eth\_sendRawTransaction                  | 200  |
| eth\_getTransactionCount                 | 26   |
| parity\_getBlockReceipts                 | 500  |
| trace\_replayTransaction                 | 2800 |
| alchemy\_getTokenBalances                | 26   |
| alchemy\_getTokenMetadata                | 16   |
| erigon\_getHeaderByNumber                | 24   |
| eth\_getTransactionByHash                | 17   |
| alchemy\_getAssetTransfers               | 150  |
| alchemy\_getTokenAllowance               | 19   |
| eth\_getTransactionReceipt               | 15   |
| eth\_sendPrivateTransaction              | 250  |
| eth\_cancelPrivateTransaction            | 250  |
| trace\_replayBlockTransactions           | 2800 |
| alchemy\_getTransactionReceipts          | 250  |
| eth\_newPendingTransactionFilter         | 20   |
| eth\_getBlockTransactionCountByHash      | 20   |
| eth\_getBlockTransactionCountByNumber    | 20   |
| eth\_getTransactionByBlockHashAndIndex   | 15   |
| eth\_getTransactionByBlockNumberAndIndex | 15   |

**Ethereum only**

<table><thead><tr><th width="374">Method</th><th>CUs</th></tr></thead><tbody><tr><td>eth_protocolVersion</td><td>5</td></tr><tr><td>eth_createAccessList</td><td>10</td></tr><tr><td>eth_feeHistory</td><td>10</td></tr><tr><td>eth_maxPriorityFeePerGas</td><td>10</td></tr><tr><td>eth_getUncleByBlockHashAndIndex</td><td>15</td></tr><tr><td>eth_getUncleByBlockNumberAndIndex</td><td>15</td></tr><tr><td>eth_getUncleCountByBlockHash</td><td>15</td></tr><tr><td>eth_getUncleCountByBlockNumber</td><td>15</td></tr></tbody></table>

**Polygon API**

<table><thead><tr><th width="373">Method</th><th>CUs</th></tr></thead><tbody><tr><td>bor_getAuthor</td><td>15</td></tr><tr><td>bor_getCurrentProposer</td><td>15</td></tr><tr><td>bor_getCurrentValidators</td><td>15</td></tr><tr><td>bor_getRootHash</td><td>15</td></tr><tr><td>bor_getSignersAtHash</td><td>15</td></tr><tr><td>eth_getTransactionReceiptsByBlock</td><td>250</td></tr></tbody></table>

**Transaction Simulation:** All simulations have a fixed price of **2000 CU.**

#### Ran Out of CU?

If you spend all CU' monthly quota, the request will fail and return an `HTTPS 429 error` with an error code `-32005`.

```
{"error":"invalid or empty api key"}
```

### Billing

We count all requests received from each single account. Each payment plan has its limitations. Regardless of their number, we charge you by calculating the whole number of CUs for all apps.


# CUPS (Rate Limit)

We count Compute Units per second instead of counting requests. It is our way to achieve a stable connection and keep costs low without affecting the client's UX

## How CUPS Works and Why We Use It as Rate Limit

### What Is CUPS?

The way of measuring CUs we apply is called CUPS (Compute Unit Per Second). CUPS helps us to measure the rate limit and implement suitable algorithms. As we explained in the Compute Units article, each method costs a different number of CUs. It makes the CUPS limitation system more efficient than counting requests per second. There are various limitations to different pricing plans.

### Why Do We Apply Rate Limits?

They allow us to ensure that clients use our services fairly and make connections stable and sustainable. We set speed limitations per second. For example, if the API returns the ‘rate limits error’ during retries, it will handle your request the next second. In general, it ultimately doesn’t affect the UX but makes the service accessible for everyone.


# JSON Web Token (JWT)

RPC Fast operates with JSON Web Token. Here we explain the way it works

### JSON Web Token (JWT) **in simple words**

It is a JSON object defined in the RFC 7519 open standard. It is a safe method of exchanging information and representing claims with a high level of security. If you enable it, only authorized requests will proceed.

{% hint style="info" %}
JSON Web Token (JWT) is available within the [Self-Hosted Cluster of Nodes](/self-hosted-cluster/self-hosted-cluster-of-nodes) offering.
{% endhint %}

### Apply JWT

Follow our step-by-step instructions to send JWT requests on RPC Fast.

#### Generate RSA-256 keys

RS256 is an asymmetrical key. After creating one, you receive both public and private keys. You will use the private one to create a signature and the public one to check its authenticity.

```
# generate rsa key
openssl genrsa -out jwtRSA256-private.pem 2048
openssl rsa -in jwtRSA256-private.pem -pubout -outform PEM -out jwtRSA256-public.pem
```

#### Enable JWT in RPC Fast

1. Login -> Dashboard -> App Page -> Settings
2. Tap ‘Add token’ in the JWT Token section and type the public RS256 key from the previous step.
3. Clicking on ‘Add’ to get a public ID

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

#### Generate the JSON Web Token

You should add JWT to all headers of requests to enable its work. To create a full-fledged JSON Web Token, you must fill out HEADER, PAYLOAD, and SIGNATURE cells.

| Field | Description                              | Example                              |
| ----- | ---------------------------------------- | ------------------------------------ |
| alg   | Write the signing algorithm you apply    | RS256                                |
| typ   | Fill out the token type                  | JWT                                  |
| kid   | Write your key id from the previous step | 10e03c88-098d-47cb-b451-a67f2137fqcf |

#### Payload

| Field | Description                                             | Example     |
| ----- | ------------------------------------------------------- | ----------- |
| aud   | Who can operate with this token                         | rpcfast.com |
| exp   | The validity time in a unix format (24 hours maximally) | 1656907527  |

{% hint style="info" %}
Use an epoch converter to receive a UNIX timestamp from a human-readable one or apply a unified command.
{% endhint %}

#### Signature

1. Encode a header.
2. Encode a payload.
3. Encode an algorithm from the title.
4. Take it all together and sign via the specific command.

```
# To encode a signature
sig=`echo -n "$header.$payload" | openssl dgst -sha256 -binary -sign jwtRSA256-private.pem  | openssl enc -base64 | tr -d '\n=' | tr -- '+/' '-_'`
```

#### JSON Web Token

Now you have your JSON Web Token! It looks like an encoded header, signature, and payload.

```
# JWT = header.payload.signature
jwt=`echo $header.$payload.$sig`
echo $jwt
```

You will need a debugger to verify it.

### Sending requests with JSON Web Token

Add JWT to the request header entry to proceed with it correctly.

### What should I do with a wrong JWT?

If you try sending requests with a wrong JWT or without it after enabling, a program will show the error 401 status code (security troubles). Disable JWT or enter the right one to continue operations.

```
{"error":"invalid payload or JWT configuration"}
```

### Key rotation support

PRC Fast is OK with key rotation. All you need to do is to upload a new one.


# Ethereum API

Take a closer look at the Compute Units system and see the methods available in the RPC Fast Ethereum API. Each of them costs a different number of CUs

## **Supported Methods for Ethereum API**

{% content-ref url="/pages/w22karbgF707uILHof8h" %}
[eth\_accounts - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_accounts-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/tDXBYKzzcpy3xdaWlQf0" %}
[eth\_blockNumber - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_blocknumber-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/AljAMB6k7lmADYAwqEgU" %}
[eth\_call - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_call-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/IJBsX6GDnWfzlRGQLcDT" %}
[eth\_chainId - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_chainid-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/Q6ixOUicbMC9NzNRf6QP" %}
[eth\_estimateGas - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_estimategas-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/N7MHaNhIIl1ypKjlMgQm" %}
[eth\_gasPrice - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_gasprice-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/PMmAAQepZEW4IQDYxEOM" %}
[eth\_getBalance - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getbalance-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/QljLJ0ZdU6DlE17Gfhtg" %}
[eth\_getBlockByHash - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getblockbyhash-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/YfCXNbtYjIHXmfsellwV" %}
[eth\_getFilterChanges - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getfilterchanges-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/8obw61NMcEzNe8eJgFf1" %}
[eth\_getBlockByNumber - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getblockbynumber-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/icj9Rkr2X3qQ186dhlvl" %}
[eth\_getBlockTransactionCountByHash - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getblocktransactioncountbyhash-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/RClZY5h3VC5gKxh8Xhbh" %}
[eth\_getBlockTransactionCountByNumber - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getblocktransactioncountbynumber-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/rsc4GqjO9ytVCirWCr8C" %}
[eth\_getCode - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getcode-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/LbPr79zVQgmdD880SIMs" %}
[eth\_getFilterLogs - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getfilterlogs-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/U9kUu3Dt9z8PYBKd3poy" %}
[eth\_getLogs - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getlogs-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/uLwcazFKDKodaIT12QLo" %}
[eth\_getProof - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getproof-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/a2ixM2OqVr3P3UWRvUKx" %}
[eth\_getStorageAt - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getstorageat-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/gQy0yyhoago6Jngbih1j" %}
[eth\_getTransactionByBlockHashAndIndex - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_gettransactionbyblockhashandindex-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/8prNG5Dlk9lao9L3Eb2r" %}
[eth\_getTransactionByBlockNumberAndIndex - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_gettransactionbyblocknumberandindex-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/6hHQhfnQJsrjDAa0KU7b" %}
[eth\_getTransactionByHash - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_gettransactionbyhash-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/lg750HWd32EfcXkiBYoi" %}
[eth\_getTransactionCount - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_gettransactioncount-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/G3VcBw3rjSAffUbay80g" %}
[eth\_getTransactionReceipt - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_gettransactionreceipt-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/2a1KvfJsVOvN1EIrliPT" %}
[eth\_getUncleByBlockHashAndIndex - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getunclebyblockhashandindex-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/6Wcw8VcGej15dbmvHPYX" %}
[eth\_getUncleByBlockNumberAndIndex - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getunclebyblocknumberandindex-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/ZJRIwOVVaKep1TlyOp0V" %}
[eth\_getUncleCountByBlockNumber - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getunclecountbyblocknumber-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/dvCUYm8iumRkcYm77Jpu" %}
[eth\_getUncleCountByBlockHash - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_getunclecountbyblockhash-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/kamL59oqDiMXn1v3oxuy" %}
[eth\_newBlockFilter - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_newblockfilter-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/J1epay0rkGv4D2XTkW6p" %}
[eth\_newFilter - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_newfilter-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/i8CVEWwdqCjsiVqCFcqW" %}
[eth\_newPendingTransactionFilter - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_newpendingtransactionfilter-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/nzz3fPkb4aOF8eEFJ1lI" %}
[eth\_sendRawTransaction - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_sendrawtransaction-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/C66zNKpNub1sgXZOTaoO" %}
[eth\_subscribe - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_subscribe-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/0hmzbneKAR6yORJIiyAj" %}
[eth\_syncing - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_syncing-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/1ttp8G2G48k0E2JFU9Tg" %}
[eth\_uninstallFilter - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_uninstallfilter-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/UdVJ45KVtzF4CE7xdqup" %}
[eth\_unsubscribe - Ethereum](/rpc-fast-saas-evm/ethereum-api/eth_unsubscribe-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/MrCbXkRoJUN8gcGlpGdm" %}
[net\_listening - Ethereum](/rpc-fast-saas-evm/ethereum-api/net_listening-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/5UcM94tzHZW7fL0iKiuK" %}
[net\_version - Ethereum](/rpc-fast-saas-evm/ethereum-api/net_version-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/xQ5iuE7z4aSYNqVgma6E" %}
[web3\_clientVersion - Ethereum](/rpc-fast-saas-evm/ethereum-api/web3_clientversion-ethereum)
{% endcontent-ref %}

{% content-ref url="/pages/pVxjJcp7lQrNbRjrCP3X" %}
[web3\_sha3 - Ethereum](/rpc-fast-saas-evm/ethereum-api/web3_sha3-ethereum)
{% endcontent-ref %}


# eth\_accounts - Ethereum

Use it to receive addresses that a client owns

## How to Use the eth\_accounts Method

### Parameters

No parameters

### What you receive

Array of DATA in 20 Bytes – it holds the list of addresses that belong to a client.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```
{"jsonrpc":"2.0","id":1,"result":[]}
```


# eth\_blockNumber - Ethereum

Shows you the number of the last block

## How to Use the eth\_blockNumber Method

### Parameters

No parameters

### What you receive

BLOCK NUMBER: a hexadecimal code that presents an actual block that the client is currently working with.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":0}' 
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{"jsonrpc":"2.0","id":1,"result":"0xec8c24"}
```


# eth\_call - Ethereum

Proceeds the next message call momentarily. You don’t have to create a new transaction on the blockchain

## How to Use the eth\_call Method

You will use this call frequently to read the data of blockchains with actual smart contracts but with no new publications. This call is not Ether-consuming.

The API has a limit of 1000% of the current gas limit for eth\_estimateGas and eth\_call methods to prevent abuse.

### Parameters

TRANSACTION CALL OBJECT \[necessary]

* from: 20 Bytes - the address where the transaction originated from.
* to: 20 Bytes - the address where the transaction is sent to.
* gas: \[variable] - the gas provided for the transaction execution (integer). eth\_call doesn’t consume gas, but some executions require stating this parameter.
* gasPrice: \[variable] the gasPrice applied for each paid gas (integer).
* value: \[variable] the value sent with a stated transaction
* data: \[variable] Hash of the method signature and encoded parameters. Check Ethereum Contract ABI for more details.

BLOCK PARAMETER \[necessary] - the string "latest", "earliest" or "pending", or an integer block number.

### What you receive

RETURN VALUE - the recalled value of the proceeded contract method.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_call","params": [{"from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","gas": "0x76c0","gasPrice": "0x9184e72a000","value": "0x9184e72a","data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"}, "latest"],"id":1}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x"
}
```


# eth\_chainId - Ethereum

Recalls the new configured chain id, which value will come in handy for replay-protected transaction realization as in EIP-155 suggestions

## How to Use the eth\_chainId Method

The received chain ID must fit the information in the actual known head block. It ensures that the user can apply the information for transactions’ assignment.

### **Parameters**

No parameters.

### **What you receive**

QUANTITY - large integer of the current chain id.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{"jsonrpc":"2.0","id":1,"result":"0x1"}
```


# eth\_estimateGas - Ethereum

Counts and presents the necessary gas amount for a successful transaction. This transaction will not appear on blockchain

## How to Use the eth\_estimateGas Method

### **Parameters**

TRANSACTION CALL OBJECT \[necessary]

* from: \[variable] 20 Bytes - What address are you sending transactions from.
* to: 20 Bytes - Which address should receive your transaction.
* gas: \[variable] How much gas do you need to proceed a transaction (as an integer). eth\_estimateGas doesn’t require gas at all, but with some actions you will need this parameter.
* gasPrice: \[variable] Present gasPrice for each gas you paid for as an integer.
* value: \[variable How much ETH do you send by this transaction.
* data: \[variable] Method signature and encoded parameters’ hash. Check Ethereum Contract ABI to see details.

### What you receive

QUANTITY - how much gas did you use.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
-X POST \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{ "id":1, "jsonrpc": "2.0", "result": "0x5208" // 21000 }
```


# eth\_gasPrice - Ethereum

Shows how much each gas currently costs in wei

## How to Use the eth\_gasPrice Method

### Parameters

No parameters

### What you receive

QUANTITY - an actual gas price presented in wei as an integer.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":0}'
```

{% endtab %}
{% endtabs %}

#### **Outcome**

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": "0x12a05f200"
}
```


# eth\_getBalance - Ethereum

Shows a balance of an account on the chosen address in wei

## How to Use the eth\_getBalance Method

### Parameters

1. DATA, 20 Bytes - an address which balance you are checking.
2. QUANTITY|TAG - the string "latest", "earliest" or "pending", or an integer block number.

### What you receive

QUANTITY - the chosen address’ balance in wei presented as an integer.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0xc94770007dda54cF92009BFF0dE90c06F603a09f", "latest"],"id":0}'
```

{% endtab %}
{% endtabs %}

#### Sample

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": "0x7c2562030800"
}
```


# eth\_getBlockByHash - Ethereum

Recalls the data about a block by hash

## How to Use the eth\_getBlockByHash Method

### **Parameters**

* DATA, 32 Bytes - Block’s hash.
* Boolean - In true cases – presents the full objects of a transaction. In false cases – recalls transactions’ hashes.

```json
params: [
    '0xc0f4906fea23cf6f3cce98cb44e8e1449e455b28d684dfa9ff65426495584de6',
    true
]
```

### **What you receive**

Object - A block object with all the fields below, or null if the block cannot be found:

* number: QUANTITY - the number of a block. in case of a pending block, it returns null.
* hash: DATA, 32 Bytes - block’s hash. in case of a pending block, it returns null.
* parentHash: DATA, 32 Bytes - parent block’s hash.
* nonce: DATA, 8 Bytes - the generated proof-of-work’s hash. in case of a pending block, it returns null.
* sha3Uncles: DATA, 32 Bytes - he uncles data’s SHA3.
* logsBloom: DATA, 256 Bytes - the logs of the block’s bloom filter. in case of a pending block, it returns null.
* transactionsRoot: DATA, 32 Bytes - the transaction trie’s root.
* stateRoot: DATA, 32 Bytes - the final state trie’s root.
* receiptsRoot: DATA, 32 Bytes - the receipts trie’s root.
* miner: DATA, 20 Bytes - the beneficiary's address that you are sending mining rewards to.
* difficulty: QUANTITY - block’s difficulty level presented as an integer.
* totalDifficulty: QUANTITY - the total chain’s difficulty level up tol this block presented as an integer.
* extraData: DATA - a field for additional data in this block.
* size: QUANTITY - integer the size of this block in bytes.
* gasLimit: QUANTITY - the maximum amount of gas which is suitable in this block.
* gasUsed: QUANTITY - the total amount of gas used for transactions in this block.
* timestamp: QUANTITY - the collation time of the block presented as a unix timestamp.
* transactions: Array - Array that includes objects for transactions, or 32 Bytes transaction hashes that depends on the last parameter you give.
* uncles: Array - Array consisting of uncle hashes.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xc0f4906fea23cf6f3cce98cb44e8e1449e455b28d684dfa9ff65426495584de6", true],"id":0}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "difficulty": "0x2d50ba175407",
    "extraData": "0xe4b883e5bda9e7a59ee4bb99e9b1bc",
    "gasLimit": "0x47e7c4",
    "gasUsed": "0x5208",
    "hash": "0xc0f4906fea23cf6f3cce98cb44e8e1449e455b28d684dfa9ff65426495584de6",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "miner": "0x61c808d82a3ac53231750dadc13c777b59310bd9",
    "mixHash": "0xc38853328f753c455edaa4dfc6f62a435e05061beac136c13dbdcd0ff38e5f40",
    "nonce": "0x3b05c6d5524209f1",
    "number": "0x1e8480",
    "parentHash": "0x57ebf07eb9ed1137d41447020a25e51d30a0c272b5896571499c82c33ecb7288",
    "receiptsRoot": "0x84aea4a7aad5c5899bd5cfc7f309cc379009d30179316a2a7baa4a2ea4a438ac",
    "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "size": "0x28a",
    "stateRoot": "0x96dbad955b166f5119793815c36f11ffa909859bbfeb64b735cca37cbf10bef1",
    "timestamp": "0x57a1118a",
    "totalDifficulty": "0x262c34a6fd1268f6c",
    "transactions": [
      "0xc55e2b90168af6972193c1f86fa4d7d7b31a29c156665d15b9cd48618b5177ef"
    ],
    "transactionsRoot": "0xb31f174d27b99cdae8e746bd138a01ce60d8dd7b224f7c60845914def05ecc58",
    "uncles": []
  }
}

```

###


# eth\_getBlockByNumber - Ethereum

Gives you the data about the block if you enter the block number

## How to Use the eth\_getBlockByNumber Method

### **Parameters**

* DATA, 32 Bytes - Block’s hash.
* Boolean - In true cases – presents the full objects of a transaction. In false cases – recalls transactions’ hashes.

```json
params: [
    '0x11a6c2c',
    true
]
```

### **What you receive**

Object - A block object with all the fields below, or null if the block cannot be found:

* number: QUANTITY - the number of a block. in case of a pending block, it returns null.
* hash: DATA, 32 Bytes - block’s hash. in case of a pending block, it returns null.
* parentHash: DATA, 32 Bytes - parent block’s hash.
* nonce: DATA, 8 Bytes - the generated proof-of-work’s hash. in case of a pending block, it returns null.
* sha3Uncles: DATA, 32 Bytes - he uncles data’s SHA3.
* logsBloom: DATA, 256 Bytes - the logs of the block’s bloom filter. in case of a pending block, it returns null.
* transactionsRoot: DATA, 32 Bytes - the transaction trie’s root.
* stateRoot: DATA, 32 Bytes - the final state trie’s root.
* receiptsRoot: DATA, 32 Bytes - the receipts trie’s root.
* miner: DATA, 20 Bytes - the beneficiary's address that you are sending mining rewards to.
* difficulty: QUANTITY - block’s difficulty level presented as an integer.
* totalDifficulty: QUANTITY - the total chain’s difficulty level up tol this block presented as an integer.
* extraData: DATA - a field for additional data in this block.
* size: QUANTITY - integer the size of this block in bytes.
* gasLimit: QUANTITY - the maximum amount of gas which is suitable in this block.
* gasUsed: QUANTITY - the total amount of gas used for transactions in this block.
* timestamp: QUANTITY - the collation time of the block presented as a unix timestamp.
* transactions: Array - Array that includes objects for transactions, or 32 Bytes transaction hashes that depends on the last parameter you give.
* uncles: Array - Array consisting of uncle hashes.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":0}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "difficulty": "0x2d50ba175407",
    "extraData": "0xe4b883e5bda9e7a59ee4bb99e9b1bc",
    "gasLimit": "0x47e7c4",
    "gasUsed": "0x5208",
    "hash": "0xc0f4906fea23cf6f3cce98cb44e8e1449e455b28d684dfa9ff65426495584de6",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "miner": "0x61c808d82a3ac53231750dadc13c777b59310bd9",
    "mixHash": "0xc38853328f753c455edaa4dfc6f62a435e05061beac136c13dbdcd0ff38e5f40",
    "nonce": "0x3b05c6d5524209f1",
    "number": "0x1e8480",
    "parentHash": "0x57ebf07eb9ed1137d41447020a25e51d30a0c272b5896571499c82c33ecb7288",
    "receiptsRoot": "0x84aea4a7aad5c5899bd5cfc7f309cc379009d30179316a2a7baa4a2ea4a438ac",
    "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "size": "0x28a",
    "stateRoot": "0x96dbad955b166f5119793815c36f11ffa909859bbfeb64b735cca37cbf10bef1",
    "timestamp": "0x57a1118a",
    "totalDifficulty": "0x262c34a6fd1268f6c",
    "transactions": [
      "0xc55e2b90168af6972193c1f86fa4d7d7b31a29c156665d15b9cd48618b5177ef"
    ],
    "transactionsRoot": "0xb31f174d27b99cdae8e746bd138a01ce60d8dd7b224f7c60845914def05ecc58",
    "uncles": []
  }
}
```


# eth\_getBlockTransactionCountByHash - Ethereum

Shows you the number of transactions that have proceeded in this block after you enter its hash

## How to Use the eth\_getBlockTransactionCountByHash Method

### **Parameters**

DATA, 32 Bytes - transactions’s hash

```json
params: [
    "0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"
]
```

### **What you receive**

BLOCK TRANSACTION COUNT - a hex code of the integer representing the number of transactions in the provided block an integer that shows the number of transactions for the needed block encoded in the HEX format.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0x8243343df08b9751f5ca0c5f8c9c0460d8a9b6351066fae0acbd4d3e776de8bb"],"id":0}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x50"
}
```


# eth\_getBlockTransactionCountByNumber - Ethereum

Shows you the number of transactions that have proceeded in this block after you enter its number

## How to Use the eth\_getBlockTransactionCountByNumber Method

### **Parameters**

BLOCK PARAMETER \[necessary] - a block number, or one of the following strings ("latest", "earliest" or "pending"). Check the [default block parameter](https://github.com/ethereum/wiki/wiki/JSON-RPC#the-default-block-parameter) for more information.

### What you receive

BLOCK TRANSACTION COUNT - a hex code of the integer representing the number of transactions in the provided block an integer that shows the number of transactions for the needed block encoded in the HEX format.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["latest"],"id":0}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x50"
}
```


# eth\_getCode - Ethereum

Shows a smart contract code, compiled, related to an address you give

## How to Use the eth\_getCode Method

### **Parameters**

* DATA, 20 Bytes - a given address.
* QUANTITY|TAG - the string "latest", "earliest" or "pending", or an integer block number. Check the[ default block parameter](https://eth.wiki/json-rpc/API#the-default-block-parameter) for details.

### What you receive

DATA - the smart contract code related to a stated address.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xb59f67a8bff5d8cd03f6ac17265c550ed8f33907", "latest"],"id":0}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": "0x606060405236156100965763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166306fdde0381146100a557806313af40351461012f57806318160ddd1461014e578063313ce5671461017357806370a082311461019c57806375ad319a146101bb5780638da5cb5b146101ee57806395d89b411461021d578063a9059cbb14610230575b34156100a157600080fd5bfe5b005b34156100b057600080fd5b6100b8610252565b60405160208082528190810183818151815260200191508051906020019080838360005b838110156100f45780820151838201526020016100dc565b50505050905090810190601f1680156101215780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561013a57600080fd5b6100a3600160a060020a0360043516610289565b341561015957600080fd5b61016161030f565b60405190815260200160405180910390f35b341561017e57600080fd5b610186610315565b60405160ff909116815260200160405180910390f35b34156101a757600080fd5b610161600160a060020a036004351661031a565b34156101c657600080fd5b6101da600160a060020a0360043516610335565b604051901515815260200160405180910390f35b34156101f957600080fd5b61020161038e565b604051600160a060020a03909116815260200160405180910390f35b341561022857600080fd5b6100b861039d565b341561023b57600080fd5b6101da600160a060020a03600435166024356103d4565b60408051908101604052601881527f444f5420416c6c6f636174696f6e20496e64696361746f720000000000000000602082015281565b60005433600160a060020a039081169116146102a457600080fd5b600054600160a060020a0380831691167f70aea8d848e8a90fb7661b227dc522eb6395c3dac71b63cb59edd5c9899b236460405160405180910390a36000805473ffffffffffffffffffffffffffffffffffffffff1916600160a060020a0392909216919091179055565b60015481565b600381565b600160a060020a031660009081526002602052604090205490565b33600160a060020a03811660009081526002602052604081206001015490919060ff16151561036357600080fd5b5050600160a060020a031660009081526002602052604090206001908101805460ff19168217905590565b600054600160a060020a031681565b60408051908101604052600381527f444f540000000000000000000000000000000000000000000000000000000000602082015281565b33600160a060020a03811660009081526002602052604081205490919083908190101561040057600080fd5b33600160a060020a03811660009081526002602052604090206001015460ff16151561042b57600080fd5b85600160a060020a031633600160a060020a03167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef8760405190815260200160405180910390a3600160a060020a033381166000908152600260205260408082208054899003905591881681522080548601905560019350505050929150505600a165627a7a72305820228dfae3e67abcdc7f73fb3f83a7d23f45acd853774acad9d2e1ac83b940fbe90029"
}

```


# eth\_getFilterChanges - Ethereum

A data collecting method that shows a logs array appeared since last data collection

## How to Use the eth\_getFilterChanges Method

### **Parameters**

QUANTITY - an id of the filter.

### What you receive

Array which contains log objects. In case if nothing has changed since the last poll you’ll receive an empty one.

* If filters were created via eth\_newBlockFilter the outcome is block hashes (DATA, 32 Bytes), such as \["0x3454645634534..."].
* If filters were created via eth\_newPendingTransactionFilter the outcome is transaction hashes (DATA, 32 Bytes), e.g. \["0x6345343454645..."].
* If filters were created via eth\_newFilter logs will be presented as objects with parameters stated below:
  * removed: TAG - true in case of the log removal, because of a chain reorganization. false if it's an existing actual log.
  * logIndex: QUANTITY - the log index position presented as an integer. returns null in case of a pending log.
  * transactionIndex: QUANTITY - the transactions index position log was created from, has an integer form. null in case of a pending log.
  * transactionHash: DATA, 32 Bytes - transactions’ hash that has created this log. returns null in case of a pending log.
  * blockHash: DATA, 32 Bytes - the block’s hash where this log was located. returns null in case of a pending log.
  * blockNumber: QUANTITY - the block’s number where this log was located. returns null in case of a pending log.
  * address: DATA, 20 Bytes - the log’s origination address.
  * data: DATA - a param with the log’s non-indexed arguments.
  * topics: Array of DATA - contains from 0 to 4 32 Bytes DATA with indexed log arguments. (In solidity: The first topic is the hash of the signature of the event (such as Deposit(address,bytes32,uint256)), unless the event declaration is with the anonymous specifier.)

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0xd1bdcf5b6141c7ec379531c851cb91d3"],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": [{
    "logIndex": "0x1", // 1
    "blockNumber":"0x1b4", // 436
    "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d",
    "transactionHash":  "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf",
    "transactionIndex": "0x0", // 0
    "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d",
    "data":"0x0000000000000000000000000000000000000000000000000000000000000000",
    "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"]
    },{
      ...
    }]
}
```


# eth\_getFilterLogs - Ethereum

Shows you an array which contains all logs that suit the filter with the stated id

## How to Use the eth\_getFilterLogs Method

The size of response for getFilterLogs method varies due to your block range:

* **Block range > 50K:** unavailable
* **Block range <= 100:** No limitations
* **Block range between 100 and 50K:** No more than 50K records can be responded

### **Parameters**

QUANTITY - an id of the filter.

### What you receive

Look at eth\_getFilterChanges for understanding.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0xd1bdcf5b6141c7ec379531c851cb91d3"],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```
Same as for eth_getFilterChanges.
```


# eth\_getLogs - Ethereum

Shows you an array which contains all logs that suit the filter with the stated filter objects

## How to Use the eth\_getLogs Method

The size of response for getFilterLogs method varies due to your block range:

* **Block range > 50K:** unavailable
* **Block range <= 100:** No limitations
* **Block range between 100 and 50K:** No more than 50K records can be responded

### **Parameters**

Object - The following available filter options:

* address \[variable] - a string that shows the address (20 bytes) which balances you want to look up
* fromBlock \[variable, default is "latest"] - the string "latest", "earliest" or "pending", or an integer block number
* toBlock \[variable, default is "latest"] - the string "latest", "earliest" or "pending", or an integer block number"
* topics\[variable] - Array of 32 Bytes order-dependent DATA topics.
* blockhash:\[variable] If you add EIP-234, blockHash will restrict the logs returned to the single block with the 32-byte hash blockHash. Using blockHash has the same meaning as fromBlock = toBlock = the block number with hash blockHash. If blockHash you add in the filter criteria, then neither fromBlock nor toBlock won’t be available.

### What you receive

LOG OBJECTS - Array with log objects in it. In case if nothing has changed since the last poll you’ll receive an empty one.

* logs will be presented as objects with parameters stated below:
  * removed: TAG - true in case of the log removal, because of a chain reorganization. false if it's an existing actual log.
  * logIndex: QUANTITY - the log index position presented as an integer. returns null in case of a pending log.
  * transactionIndex: QUANTITY - the transactions index position log was created from, has an integer form. null in case of a pending log.
  * transactionHash: DATA, 32 Bytes - transactions’ hash that has created this log. returns null in case of a pending log.
  * blockHash: DATA, 32 Bytes - the block’s hash where this log was located. returns null in case of a pending log.
  * blockNumber: QUANTITY - the block’s number where this log was located. returns null in case of a pending log.
  * address: DATA, 20 Bytes - the log’s origination address.
  * data: DATA - a param with the log’s non-indexed arguments.
  * topics: Array of DATA - contains from 0 to 4 32 Bytes DATA with indexed log arguments. (In solidity: The first topic is the hash of the signature of the event (such as Deposit(address,bytes32,uint256)), unless the event declaration is with the anonymous specifier.)

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"address": "0xb59f67a8bff5d8cd03f6ac17265c550ed8f33907","topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"],"blockHash": "0x8243343df08b9751f5ca0c5f8c9c0460d8a9b6351066fae0acbd4d3e776de8bb"}],"id":0}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```
{
    "jsonrpc": "2.0",
    "id": 73,
    "result": [{
        "address": "0xb5a5f22694352c15b00323844ad545abb2b11028",
        "blockHash": "0x99e8663c7b6d8bba3c7627a17d774238eae3e793dee30008debb2699666657de",
        "blockNumber": "0x5d12ab",
        "data": "0x0000000000000000000000000000000000000000000000a247d7a2955b61d000",
        "logIndex": "0x0",
        "removed": false,
        "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", "0x000000000000000000000000bdc0afe57b8e9468aa95396da2ab2063e595f37e", "0x0000000000000000000000007503e090dc2b64a88f034fb45e247cbd82b8741e"],
        "transactionHash": "0xa74c2432c9cf7dbb875a385a2411fd8f13ca9ec12216864b1a1ead3c99de99cd",
        "transactionIndex": "0x3"
    }, {
        "address": "0xe38165c9f6deb144afc9c32c206b024817e1496d",
        "blockHash": "0x99e8663c7b6d8bba3c7627a17d774238eae3e793dee30008debb2699666657de",
        "blockNumber": "0x5d12ab",
        "data": "0x0000000000000000000000000000000000000000000000000000000025c6b720",
        "logIndex": "0x3",
        "removed": false,
        "topics": ["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", "0x00000000000000000000000080e73e47173b2d00b531bf83bc39e710157125c3", "0x0000000000000000000000008f6cc93795969e5bbbf07c66dfee7d41ad24f1ef"],
        "transactionHash": "0x9e8f1cb1facb9a11a1cf947634053a0b2d557399f926b12127aa10497a2f0153",
        "transactionIndex": "0x5"
    }
}

```


# eth\_getProof - Ethereum

Shows the storage- and the account-values of the required account with the Merkle-proof on this list

## How to Use the eth\_getProof Method

### **Parameters**

DATA, 20 bytes - account or contract address

ARRAY, 32 Bytes - array that consists of storage-keys that must be proofed and included. More information at eth\_getStorageAt.

QUANTITY|TAG - the string "latest", "earliest" or "pending", or an integer block number.

### What you receive

Recalls Object - An account object:

* balance: QUANTITY - the account’s ETH balance. For more info, check out eth\_getBalance
* codeHash: DATA, 32 Bytes - the account’s code hash. If there is an account with no code Account, it will return "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470"
* nonce: QUANTITY, - the account’s nonce. Check eth\_getTransactionCount for more info.
* storageHash: DATA, 32 Bytes - the StorageRoot’s SHA3. The storage delivers MerkleProof that starts with this rootHash.
* accountProof: ARRAY - rlp-serialized MerkleTree-Nodes, that starts with the stateRoot-Node which follows the path of the SHA3 (address) as key.
* storageProof: ARRAY - requested storage-entries. Each entry is presented as a object with the following properties:
  * key: QUANTITY - the requested storage key
  * value: QUANTITY - the storage value
  * proof: ARRAY - rlp-serialized MerkleTree-Nodes, that starts with the stateRoot-Node which follows the path of the SHA3 (address) as path.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_getProof","params":["0x1234567890123456789012345678901234567890",["0x0000000000000000000000000000000000000000000000000000000000000000","0x0000000000000000000000000000000000000000000000000000000000000001"],"latest"],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "address": "0x1234567890123456789012345678901234567890",
    "accountProof": [
      "0xf90211a090dcaf88c40c7bbc95a912cbdde67c175767b31173df9ee4b0d733bfdd511c43a0babe369f6b12092f49181ae04ca173fb68d1a5456f18d20fa32cba73954052bda0473ecf8a7e36a829e75039a3b055e51b8332cbf03324ab4af2066bbd6fbf0021a0bbda34753d7aa6c38e603f360244e8f59611921d9e1f128372fec0d586d4f9e0a04e44caecff45c9891f74f6a2156735886eedf6f1a733628ebc802ec79d844648a0a5f3f2f7542148c973977c8a1e154c4300fec92f755f7846f1b734d3ab1d90e7a0e823850f50bf72baae9d1733a36a444ab65d0a6faaba404f0583ce0ca4dad92da0f7a00cbe7d4b30b11faea3ae61b7f1f2b315b61d9f6bd68bfe587ad0eeceb721a07117ef9fc932f1a88e908eaead8565c19b5645dc9e5b1b6e841c5edbdfd71681a069eb2de283f32c11f859d7bcf93da23990d3e662935ed4d6b39ce3673ec84472a0203d26456312bbc4da5cd293b75b840fc5045e493d6f904d180823ec22bfed8ea09287b5c21f2254af4e64fca76acc5cd87399c7f1ede818db4326c98ce2dc2208a06fc2d754e304c48ce6a517753c62b1a9c1d5925b89707486d7fc08919e0a94eca07b1c54f15e299bd58bdfef9741538c7828b5d7d11a489f9c20d052b3471df475a051f9dd3739a927c89e357580a4c97b40234aa01ed3d5e0390dc982a7975880a0a089d613f26159af43616fd9455bb461f4869bfede26f2130835ed067a8b967bfb80",
      "0xf90211a0395d87a95873cd98c21cf1df9421af03f7247880a2554e20738eec2c7507a494a0bcf6546339a1e7e14eb8fb572a968d217d2a0d1f3bc4257b22ef5333e9e4433ca012ae12498af8b2752c99efce07f3feef8ec910493be749acd63822c3558e6671a0dbf51303afdc36fc0c2d68a9bb05dab4f4917e7531e4a37ab0a153472d1b86e2a0ae90b50f067d9a2244e3d975233c0a0558c39ee152969f6678790abf773a9621a01d65cd682cc1be7c5e38d8da5c942e0a73eeaef10f387340a40a106699d494c3a06163b53d956c55544390c13634ea9aa75309f4fd866f312586942daf0f60fb37a058a52c1e858b1382a8893eb9c1f111f266eb9e21e6137aff0dddea243a567000a037b4b100761e02de63ea5f1fcfcf43e81a372dafb4419d126342136d329b7a7ba032472415864b08f808ba4374092003c8d7c40a9f7f9fe9cc8291f62538e1cc14a074e238ff5ec96b810364515551344100138916594d6af966170ff326a092fab0a0d31ac4eef14a79845200a496662e92186ca8b55e29ed0f9f59dbc6b521b116fea090607784fe738458b63c1942bba7c0321ae77e18df4961b2bc66727ea996464ea078f757653c1b63f72aff3dcc3f2a2e4c8cb4a9d36d1117c742833c84e20de994a0f78407de07f4b4cb4f899dfb95eedeb4049aeb5fc1635d65cf2f2f4dfd25d1d7a0862037513ba9d45354dd3e36264aceb2b862ac79d2050f14c95657e43a51b85c80",
      "0xf90171a04ad705ea7bf04339fa36b124fa221379bd5a38ffe9a6112cb2d94be3a437b879a08e45b5f72e8149c01efcb71429841d6a8879d4bbe27335604a5bff8dfdf85dcea00313d9b2f7c03733d6549ea3b810e5262ed844ea12f70993d87d3e0f04e3979ea0b59e3cdd6750fa8b15164612a5cb6567cdfb386d4e0137fccee5f35ab55d0efda0fe6db56e42f2057a071c980a778d9a0b61038f269dd74a0e90155b3f40f14364a08538587f2378a0849f9608942cf481da4120c360f8391bbcc225d811823c6432a026eac94e755534e16f9552e73025d6d9c30d1d7682a4cb5bd7741ddabfd48c50a041557da9a74ca68da793e743e81e2029b2835e1cc16e9e25bd0c1e89d4ccad6980a041dda0a40a21ade3a20fcd1a4abb2a42b74e9a32b02424ff8db4ea708a5e0fb9a09aaf8326a51f613607a8685f57458329b41e938bb761131a5747e066b81a0a16808080a022e6cef138e16d2272ef58434ddf49260dc1de1f8ad6dfca3da5d2a92aaaadc58080",
      "0xf851808080a009833150c367df138f1538689984b8a84fc55692d3d41fe4d1e5720ff5483a6980808080808080808080a0a319c1c415b271afc0adcb664e67738d103ac168e0bc0b7bd2da7966165cb9518080"
    ],
    "balance": "0x0",
    "codeHash": "0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470",
    "nonce": "0x0",
    "storageHash": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "storageProof": [
      {
        "key": "0x0000000000000000000000000000000000000000000000000000000000000000",
        "value": "0x0",
        "proof": []
      },
      {
        "key": "0x0000000000000000000000000000000000000000000000000000000000000001",
        "value": "0x0",
        "proof": []
      }
    ]
  }
}

```


# eth\_getStorageAt - Ethereum

Shows you the statement of the contract’s storage at the requested address when you cannot proceed this operation via contract’s methods

## How to Use the eth\_getStorageAt Method

### **Parameters**

ADDRESS \[necessary] - a string that presents the storage’s address (20 bytes).

QUANTITY \[necessary] - a hex code which represents the position in the storage

BLOCK PARAMETER \[required] - the string "latest", "earliest" or "pending", or an integer block number, check the [default block parameter](https://github.com/ethereum/wiki/wiki/JSON-RPC#the-default-block-parameter) for details.

### What you receive

STORAGE VALUE - a hex code that represents the integer indicating the value of the storage position at the given address.

```json
{
    "jsonrpc":"2.0",
    "id":1,
    "result":"0x000000000000000000000000000000000000000000000000000000000000162e"
}
```

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
    "jsonrpc":"2.0",
    "id":1,
    "result":"0x000000000000000000000000000000000000000000000000000000000000162e"
}
```


# eth\_getTransactionByBlockHashAndIndex - Ethereum

This method recalls the transaction data after you enter block hash and transaction index position

## How to Use the eth\_getTransactionByBlockHashAndIndex Method

### **Parameters**

DATA, 32 Bytes - block’s hash.

QUANTITY - the transaction index position presented as an integer. params:

```
[ 
    '0xc0f4906fea23cf6f3cce98cb44e8e1449e455b28d684dfa9ff65426495584de6', 
    '0x0' // 0 
]
```

### **What you receive**

TRANSACTION - An object of transaction, or returns null in case no transaction was found.

* hash: 32 Bytes - the transaction’s hash.
* nonce: how many transactions were sent from one address before the current one.
* blockHash: DATA, 32 Bytes - the block’s hash where this transaction was located. returns null in case of a pending log.
* blockNumber: the number of a block related to the chosen transaction. null when its pending.
* transactionIndex: integer of the transactions index position in the block. returns null in case of a pending log.
* from: 20 Bytes - the sender’s address.
* to: 20 Bytes - the receiver’s address. returns null if a transaction relates to smart contract creation.
* value: value represented in Wei.
* gasPrice: gas price that the sender did provide. represented in Wei.
* gas: gas amount that the sender provided.
* input: which data was sent along the transaction.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0xc0f4906fea23cf6f3cce98cb44e8e1449e455b28d684dfa9ff65426495584de6", "0x0"],"id":0}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "blockHash": "0xc0f4906fea23cf6f3cce98cb44e8e1449e455b28d684dfa9ff65426495584de6",
    "blockNumber": "0x1e8480",
    "from": "0x32be343b94f860124dc4fee278fdcbd38c102d88",
    "gas": "0x51615",
    "gasPrice": "0x6fc23ac00",
    "hash": "0xc55e2b90168af6972193c1f86fa4d7d7b31a29c156665d15b9cd48618b5177ef",
    "input": "0x",
    "nonce": "0x1efc5",
    "to": "0x104994f45d9d697ca104e5704a7b77d7fec3537c",
    "transactionIndex": "0x0",
    "value": "0x821878651a4d70000",
    "v": "0x1b",
    "r": "0x51222d91a379452395d0abaff981af4cfcc242f25cfaf947dea8245a477731f9",
    "s": "0x3a997c910b4701cca5d933fb26064ee5af7fe3236ff0ef2b58aa50b25aff8ca5"
  }
}
```


# eth\_getTransactionByBlockNumberAndIndex - Ethereum

The method enables access to information about a transaction after entering a block number and its index

## How to Use the eth\_getTransactionByBlockNumberAndIndex Method

### **Parameters**

QUANTITY|TAG - the string "latest", "earliest" or "pending", or an integer block number, as you can see in the default block parameter.

QUANTITY - the transaction index position.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["latest", "0x0"],"id":0}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "blockHash": "0xc0f4906fea23cf6f3cce98cb44e8e1449e455b28d684dfa9ff65426495584de6",
    "blockNumber": "0x1e8480",
    "from": "0x32be343b94f860124dc4fee278fdcbd38c102d88",
    "gas": "0x51615",
    "gasPrice": "0x6fc23ac00",
    "hash": "0xc55e2b90168af6972193c1f86fa4d7d7b31a29c156665d15b9cd48618b5177ef",
    "input": "0x",
    "nonce": "0x1efc5",
    "to": "0x104994f45d9d697ca104e5704a7b77d7fec3537c",
    "transactionIndex": "0x0",
    "value": "0x821878651a4d70000",
    "v": "0x1b",
    "r": "0x51222d91a379452395d0abaff981af4cfcc242f25cfaf947dea8245a477731f9",
    "s": "0x3a997c910b4701cca5d933fb26064ee5af7fe3236ff0ef2b58aa50b25aff8ca5"
  }
}

```


# eth\_getTransactionByHash - Ethereum

The method recalls the transaction data after you enter its hash

## How to Use the eth\_getTransactionByHash Method

### **Parameters**

DATA, 32 Bytes - a transaction’s hash params:

```
[
    "0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"
]
```

### **What you receive**

Object - An object of transaction, or returns null in case no transaction was found:

* blockHash: DATA, 32 Bytes - the block’s hash where this transaction was located. returns null in case of a pending log.
* blockNumber: the number of a block related to the chosen transaction. null when its pending.
* from: 20 Bytes - the sender’s address.
* to: 20 Bytes - the receiver’s address. returns null if a transaction relates to smart contract creation.
* gasPrice: gas price that the sender did provide. represented in Wei.
* gas: gas amount that the sender provided.
* input: which data was sent along the transaction.
* hash: 32 Bytes - the transaction’s hash.
* nonce: how many transactions were sent from one address before the current one.
* transactionIndex: integer of the transactions index position in the block. returns null in case of a pending log.
* value: value represented in Wei.
* v: QUANTITY - ECDSA recovery id
* r: DATA, 32 Bytes - ECDSA signature r
* s: DATA, 32 Bytes - ECDSA signature s

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":0}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "hash": "0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b",
    "blockHash": "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2",
    "blockNumber": "0x5daf3b",
    "from": "0xa7d9ddbe1f17865597fbd27ec712455208b6b76d",
    "gas": "0xc350",
    "gasPrice": "0x4a817c800",
    "input": "0x68656c6c6f21",
    "nonce": "0x15",
    "r": "0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea",
    "s": "0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c",
    "to": "0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb",
    "transactionIndex": "0x41",
    "v": "0x25",
    "value": "0xf3dbb76162000"
  }
}
```


# eth\_getTransactionCount - Ethereum

Shows the number of transactions that were sent from one stated address

## How to Use the eth\_getTransactionCount Method

### **Parameters**

DATA, 20 Bytes - sender’s address.

QUANTITY|TAG - the string "latest", "earliest" or "pending", or an integer block number, as you can see in the default block parameter. params:

```
[
    '0xc94770007dda54cF92009BFF0dE90c06F603a09f',
    'latest' // state at the latest block
]
```

### **What you receive**

QUANTITY - how many transactions were sent from the stated address, presented as an integer.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0xc94770007dda54cF92009BFF0dE90c06F603a09f","latest"],"id":0}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": "0x219"
}

```


# eth\_getTransactionReceipt - Ethereum

Shows a receipt of a transaction with a transaction’s hash entered. It won’t be shown in cases of pending transactions

## How to Use the eth\_getTransactionReceipt Method

It is a useful call if you need to track the transaction’s status as far as it shows null until the successful result appears. Another function is an ability to see the contact address if you need to create a smart contact.

### **Parameters**

DATA, 32 Bytes - hash of a transaction params:

```
[ 
    '0xab059a62e22e230fe0f56d8555340a29b2e9532360368f810595453f6fdd213b' 
]
```

### **What you receive**

Object - A receipt of the transaction or null if the transaction was not finished:

* transactionHash: DATA, 32 Bytes - the transaction’s hash.
* transactionIndex: QUANTITY - integer of the transactions index position in the block.
* blockHash: DATA, 32 Bytes - hash of the block where this transaction was located.
* blockNumber: QUANTITY - the number of a block where this transaction took place.
* from: DATA, 20 Bytes - the sender’s address.
* to: DATA, 20 Bytes - address of the receiver. returns null if it is a contract creation transaction
* cumulativeGasUsed: QUANTITY - The total amount of gas used in this block at the moment when the transaction was finished
* gasUsed: QUANTITY - How much gas did this single transaction consume.
* contractAddress: DATA, 20 Bytes - An address of a contract, if it was a contract creation transaction, or null in all other cases.
* logs: Array - Array of log objects generated by this transaction.
* logsBloom: DATA, 256 Bytes - Bloom filter for light clients for retrieving related logs in a fast manner.

It can also return:

* root : DATA 32 bytes of post-transaction stateroot (pre Byzantium)
* status: QUANTITY either 1 (success) or 0 (failure)

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xab059a62e22e230fe0f56d8555340a29b2e9532360368f810595453f6fdd213b"],"id"

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "transactionHash": "0xab059a62e22e230fe0f56d8555340a29b2e9532360368f810595453f6fdd213b",
    "blockHash": "0x8243343df08b9751f5ca0c5f8c9c0460d8a9b6351066fae0acbd4d3e776de8bb",
    "blockNumber": "0x429d3b",
    "contractAddress": null,
    "cumulativeGasUsed": "0x64b559",
    "from": "0x00b46c2526e227482e2ebb8f4c69e4674d262e75",
    "gasUsed": "0xcaac",
    "logs": [
      {
        "blockHash": "0x8243343df08b9751f5ca0c5f8c9c0460d8a9b6351066fae0acbd4d3e776de8bb",
        "address": "0xb59f67a8bff5d8cd03f6ac17265c550ed8f33907",
        "logIndex": "0x56",
        "data": "0x000000000000000000000000000000000000000000000000000000012a05f200",
        "removed": false,
        "topics": [
          "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef",
          "0x00000000000000000000000000b46c2526e227482e2ebb8f4c69e4674d262e75",
          "0x00000000000000000000000054a2d42a40f51259dedd1978f6c118a0f0eff078"
        ],
        "blockNumber": "0x429d3b",
        "transactionIndex": "0xac",
        "transactionHash": "0xab059a62e22e230fe0f56d8555340a29b2e9532360368f810595453f6fdd213b"
      }
    ],
    "logsBloom": "0x00000000040000000000000000000000000000000000000000000000000000080000000010000000000000000000000000000000000040000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000010100000000000000000000000000004000000000000200000000000000000000000000000000000000000000",
    "root": "0x3ccba97c7fcc7e1636ce2d44be1a806a8999df26eab80a928205714a878d5114",
    "status": null,
    "to": "0xb59f67a8bff5d8cd03f6ac17265c550ed8f33907",
    "transactionIndex": "0xac"
  }
}

```


# eth\_getUncleByBlockHashAndIndex - Ethereum

Shows the ‘Uncle’ and its index position after you enter the block’s hash

## How to Use the eth\_getUncleByBlockHashAndIndex Method

### **Parameters**

QUANTITY|TAG - the string "latest", "earliest" or "pending", or an integer block number., as it is shown in the default block parameter.

QUANTITY - the uncle's index position.

### **What you receive**

Object - A block object with the following fields, or null when no block was found:

* number: QUANTITY - the block number. null when its pending block.
* hash: DATA, 32 Bytes - hash of the block. null when its pending block.
* parentHash: DATA, 32 Bytes - the parent block’s hash.
* nonce: DATA, 8 Bytes - hash of the generated proof-of-work. null in case its a pending block.
* sha3Uncles: DATA, 32 Bytes - SHA3 of the uncles data.
* logsBloom: DATA, 256 Bytes - the bloom filter for the logs in this block. returns null in case it's a pending block.
* transactionsRoot: DATA, 32 Bytes - the root of the transaction trie.
* stateRoot: DATA, 32 Bytes - the root of the final state trie of the block.
* receiptsRoot: DATA, 32 Bytes - the root of the receipts trie related to this block.
* miner: DATA, 20 Bytes - the address of the beneficiary that received the mining rewards.
* difficulty: QUANTITY - the block’s difficulty rate.
* totalDifficulty: QUANTITY - the total chain difficulty until this block presented as an integer. extraData: DATA - field for extra data about this block..
* size: QUANTITY -measuring the block size in bytes.
* gasLimit: QUANTITY - the maximum gas amount possible in this block.
* gasUsed: QUANTITY - the total gas used for proceeding all transactions in this block.
* timestamp: QUANTITY - the unix timestamp showing the block collation time.
* transactions: Array consisting of transaction objects, or 32 Bytes transaction hashes that will depend on the last given parameter.
* uncles: Array of uncle hashes.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xab059a62e22e230fe0f56d8555340a29b2e9532360368f810595453f6fdd213b"],"id"

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "difficulty": "0xbf93da424b943",
    "extraData": "0x65746865726d696e652d657539",
    "gasLimit": "0x7a121d",
    "gasUsed": "0x79ea62",
    "hash": "0x824cce7c7c2ec6874b9fa9a9a898eb5f27cbaf3991dfa81084c3af60d1db618c",
    "logsBloom": "0x0948432021200401804810002000000000381001001202440000010020000080a016262050e44850268052000400100505022305a64000054004200b0c04110000080c1055c42001054b804940a0401401008a00112d80082113400c10006580140005011a40220020000010001c0a00082300434002000050840010102082801c2000148540201004491814020480080111a0300600000003800640024200109c00202010044000880000106810a1a010000028a0100000422000140011000050a2a44b3080001060800000540c108102102600d000004730404a880100600021080100403000180000062642408b440060590400080101e046f08000000430",
    "miner": "0xea674fdde714fd979de3edf0f56aa9716b898ec8",
    "mixHash": "0x0b15fe0a9aa789c167b0f5ade7b72969d9f2193014cb4e98382254f60ffb2f4a",
    "nonce": "0xa212d6400b89b3f6",
    "number": "0x5bad54",
    "parentHash": "0x05e19fb68d9ec798073808e8b3170875cb327d4b6cde7d6f60fe194677bb26fd",
    "receiptsRoot": "0x90807b32c4aa4610c57289de57fa68ba50ed53f14dd2c25f1862aa049029dcd6",
    "sha3Uncles": "0xf763576c1ea6a8c61a206e16b1a2451bec5cba1c7545d7ff733a1e8c78715569",
    "size": "0x216",
    "stateRoot": "0xebc7a1603bfffe0a14bdb89f898e2f2824abb40f04579beb7b920c56d6e273c9",
    "timestamp": "0x5b54143f",
    "transactionsRoot": "0x7562cba41e067b364b933e7b566fb2444f6954fef3964a5a487d4cd79d97a56c",
    "uncles": []
  }
}

```


# eth\_getUncleByBlockNumberAndIndex - Ethereum

Shows information about the block’s Uncle and its position after you enter the index

## How to Use the eth\_getUncleByBlockNumberAndIndex Method

### **Parameters**

QUANTITY|TAG - the string "latest", "earliest" or "pending", or an integer block number, check out the default block parameter for details.

QUANTITY - the uncle's index position. params:

```
[
   '0x29c', // 668
   '0x0' // 0
]
```

### **What you receive**

The result is similar to an eth\_getBlockByHash method. Pay attention that you won’t get transactions of the uncle block by using this method.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":0}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "difficulty": "0x57f117f5c",
    "extraData": "0x476574682f76312e302e302f77696e646f77732f676f312e342e32",
    "gasLimit": "0x1388",
    "gasUsed": "0x0",
    "hash": "0x932bdf904546a2287a2c9b2ede37925f698a7657484b172d4e5184f80bdd464d",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "miner": "0x5bf5e9cf9b456d6591073513de7fd69a9bef04bc",
    "mixHash": "0x4500aa4ee2b3044a155252e35273770edeb2ab6f8cb19ca8e732771484462169",
    "nonce": "0x24732773618192ac",
    "number": "0x299",
    "parentHash": "0xa779859b1ee558258b7008bbabff272280136c5dd3eb3ea3bfa8f6ae03bf91e5",
    "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "size": "0x21d",
    "stateRoot": "0x2604fbf5183f5360da249b51f1b9f1e0f315d2ff3ffa1a4143ff221ad9ca1fec",
    "timestamp": "0x55ba4827",
    "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "uncles": []
  }
}

```


# eth\_getUncleCountByBlockNumber - Ethereum

Gives you the quantity of uncles that fit the block number you enter

## How to Use the eth\_getUncleCountByBlockNumber Method

### **Parameters**

QUANTITY|TAG - the string "latest", "earliest" or "pending", or an integer block number, check out the default block parameter for details.

### **What you receive**

QUANTITY - the number of uncles in the given block presented as an integer.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": "0x0"
}
```


# eth\_getUncleCountByBlockHash - Ethereum

Gives you the quantity of uncles that fit the block hash you enter

## How to Use the eth\_getUncleCountByBlockHash Method

### **Parameters**

DATA, 32 Bytes - a chosen block’s hash. params:

```
[
 '0xb3b20624f8f0f86eb50dd04688409e5cea4bd02d700bf6e79e9384d47d6a5a35'
]
```

### **What you receive**

QUANTITY - the number of uncles in the given block presented as an integer.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0xb3b20624f8f0f86eb50dd04688409e5cea4bd02d700bf6e79e9384d47d6a5a35"],"id":0}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 0,
  "result": "0x1"
}
```


# eth\_newBlockFilter - Ethereum

This method builds up a node filter for notifications about new blocks. You can check out for statement changes by calling the eth\_getFilterChanges method

## How to Use the eth\_newBlockFilter Method

### **Parameters**

No parameters.

### **What you receive**

QUANTITY - A filter id.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x8fb7f13924ab605fd23f3ddd6d193egh"
}
```


# eth\_newFilter - Ethereum

Builds up a filter object which notifies you every time the state changes. A filter object is based on filter options and shows changes via the command eth\_getFilterChanges

## How to Use the eth\_newFilter Method

### **Parameters**

Object - The filter options:

* fromBlock: QUANTITY|TAG - (variable, default statement: "latest") the string "latest" or "pending", or an integer block number for the last mined block, returns "earliest" if the transaction wasn’t mined yet.
* toBlock: QUANTITY|TAG - (variable, default statement: "latest") the string "latest" or "pending", or an integer block number for the last mined block, returns "earliest" if the transaction wasn’t mined yet.
* address: DATA|Array, 20 Bytes - (variabel) An address of a contract or a list of addresses from which logs should originate.
* topics: Array of DATA, - (variable) Array of 32 Bytes DATA order-dependent topics. Each topic can also contain DATA Arrays with "or" options.

### **What you receive**

QUANTITY - A filter id.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x0000000000000000000000000000000000000000000000000000000012341234"]}],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x7185030cb5dabae60f32b996a4ab04a3"
}
```


# eth\_newPendingTransactionFilter - Ethereum

This method builds up a node filter for notifications about new pending transactions. You can check out for statement changes by calling the eth\_getFilterChanges method

## How to Use the eth\_newPendingTransactionFilter Method

### **Parameters**

No parameters.

### **What you receive**

QUANTITY - A filter id.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x1"
}
```


# eth\_sendRawTransaction - Ethereum

Creates new message call transaction or a contract creation for signed transactions

## How to Use the eth\_sendRawTransaction Method

### **Parameters**

DATA – the data of the signed transaction.

### **What you receive**

DATA, 32 Bytes - the transaction hash, the method returns the zero hash if the transaction is not available yet.

You can get contract addresses via the eth\_getTransactionReceipt, after mining the transaction, when you created a contract.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":["0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331"
}
```


# eth\_subscribe - Ethereum

Builds up a new subscription fitting certain events. Works only for websockets

## How to Use the eth\_subscribe Method

### **Parameters**

* SUBSCRIPTION TYPE NAME \[necessary]
  * newHeads - append a new header to the chain to receive notifications timely.
  * logs - shows logs included in new imported blocks and fit the stated filter criteria.
  * address (variable) - can be presented as an address or an array of addresses.
  * topics (variable) - presented as logs which match the defined topics.
  * newPendingTransactions - shows the hash for all transactions added to the pending state and signed with an available key.
  * syncing - an indicator of node synchronization.

### **What you receive**

SUBSCRIPTION ID - ID of the latest new subscription created on the node

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```
// newHeads
{"jsonrpc":"2.0", "id": 1, "method": "eth_subscribe", "params": ["newHeads"]}

// logs
{"jsonrpc":"2.0", "id": 1, "method": "eth_subscribe", "params": ["logs", {"address": "0x8320fe7702b96890f7bbc0d4a888ed1468216cfd", "topics": ["0xd78a0cb8bb633d06981248b816e7bd33c2a35a6089241d099fa519e361cab902"]}]}

// newPendingTransactions
{"jsonrpc":"2.0", "id": 1, "method": "eth_subscribe", "params": ["newPendingTransactions"]}

// syncing
{"jsonrpc":"2.0", "id": 1, "method": "eth_subscribe", "params": ["syncing"]}
```

{% endtab %}
{% endtabs %}

#### Outcome

```
// newHeads
{
  "jsonrpc": "2.0",
  "method": "eth_subscription",
  "params": {
    "result": {
      "difficulty": "0x15d9243a23aa",
      "extraData": "0xd983010305544765746887676f312e342e328777696e646f7773",
      "gasLimit": "0x44e7c4",
      "gasUsed": "0x38358",
      "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "miner": "0xf8b483dba2c3b7176a3da541ad41a48bb3121069",
      "nonce": "0x084149928194cc5f",
      "number": "0x1348c9",
      "parentHash": "0x7736fab72105dc611604d22470dadad26f56fe494421b5b333de816ce1f25701",
      "receiptRoot": "0x2fab35823ad00c7bc328595cb46652fe7886e00660a01e867824d3dceb1c8d36",
      "sha3Uncles": "0x1dcc4de8dec75sjt5b85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
      "stateRoot": "0xb3346685172db67de23fd8765c43c31009d0eb3bd9c501c9be3229203f15f378",
      "timestamp": "0x56ffesf8",
      "transactionsRoot": "0x0167ffa60e3ebc0b1dt7db95f7c0087dd6c0e61413140e39d94d3468d7c9689f"
    },
    "subscription": "0x9ce59a13059e237087c02d3236a0b1cc"
  }
}

// logs Subscription
{
    "jsonrpc":"2.0",
    "method":"eth_subscription",
    "params": {
        "subscription":"0x4a8a4c0517236924f9838102c5a4dcb7",
        "result": {
            "address":"0x8320fe7702b96808ftbbc0d4a888ed1468216cfd","blockHash":"0x61cdb2a09ab99abf791d474f20c2ea89bf8de2923a2d42bb49944c8c993cbf04",
            "blockNumber":"0x29387","data":"0x00000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000003",
            "logIndex":"0x0",
            "topics":["0xd78a0cb8bbfe3d06981248b816e7bd33c2a35a6089241d099fa519e361cab902"],"transactionHash":"0xe044554a0a55067caafd07f8020ab9f2af60bdfe337e395ecd84b4877a3d1ab4",
            "transactionIndex":"0x0"
        }
    }
}

// newPendingTransaction Subscription
{
    "jsonrpc":"2.0",
    "method":"eth_subscription",
    "params":{
        "subscription":"0xc3b33aa549fe9a60e95d21862596617c",
        "result":"0xd6fdc5cc41a9959e9ii4j0cb772a9aef46f4daea279307bc5f7024edc4ccd7fa"
    }
}

// syncing subscription
{
    "jsonrpc":"2.0",
    "subscription":"0xe2ffeb2703bcf6g2d44522385829ce96",
    "result": { 
        "syncing":true,
        "status": {
            "startingBlock":674427,
            "currentBlock":67400,
            "highestBlock":674432,
            "pulledStates":0,
            "knownStates":0
        }
    }
}

```


# eth\_syncing - Ethereum

Shows the synchronization status or returns false

## How to Use the eth\_syncing Method

### **Parameters**

No parameters.

### **What you receive**

Object|Boolean, An object with synchronization status data or FALSE, if not syncing:

* startingBlock: QUANTITY - the first block where import starts (resets only after the sync reaches his head)
* currentBlock: QUANTITY - The actual block, given the same recall as eth\_blockNumber
* highestBlock: QUANTITY - The estimated highest block

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    startingBlock: '0x384',
    currentBlock: '0x386',
    highestBlock: '0x454'
  }
}
```


# eth\_uninstallFilter - Ethereum

Deletes the filter with the stated id. Call it out every time you don’t need the watch anymore. Filters can timeout if you don’t recall them via eth\_getFilterChanges for a certain time

## How to Use the eth\_uninstallFilter Method

### **Parameters**

QUANTITY - The filter id.

### **What you receive**

Boolean - true in case of successful uninstalls, otherwise returns false.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":1}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": true
}
```


# eth\_unsubscribe - Ethereum

Cancels subscriptions via a regular RPC call. You should state eth\_unsubscribe as a method and write a subscription id in the place of the first param. Works only for websockets

## How to Use the eth\_unsubscribe Method

### **Parameters**

SUBSCRIPTION ID.

### **What you receive**

Boolean, true in case of successful uninstallment.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"eth_unsubscribe","params":["0x9cef478923ff08bf67fde6c64013158d"],"id":1}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": true
}
```


# net\_listening - Ethereum

Shows the true boolean result if the client listens actively for network connections

## How to Use the net\_listening Method

### **Parameters**

No parameters.

### **What you receive**

Boolean - true when the client is listening, in other cases returns false.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 67,
  "result": true
}
```


# net\_version - Ethereum

Recalls an actual network id

## How to Use the net\_version Method

### **Parameters**

No parameters.

### **What you receive**

* String - An actual network id.
  * 1: Ethereum Mainnet
  * 56: BSC Mainnet

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"net_version","params":[],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "56"
}
```


# web3\_clientVersion - Ethereum

Shows you an actual client version

## How to Use the web3\_clientVersion Method

### **Parameters**

No parameters.

### **What you receive**

String - An actual client version.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}'

```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "Geth/v1.1.5-8ff7d531/linux-amd64/go1.16.4"
}
```


# web3\_sha3 - Ethereum

Shows you Keccak-256 (which is not the standard SHA3-256) of the stated data

## How to Use the web3\_sha3 Method

### **Parameters**

DATA - the data you want to convert into a SHA3 hash.

### **What you receive**

DATA - The SHA3 result of the stated string.

### Sample

Here is a typical appliance example.

#### Call

{% tabs %}
{% tab title="Curl" %}

```bash
curl https://eth-mainnet.rpcfast.com/?api_key=<key> \
    -X POST \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":1}'
```

{% endtab %}
{% endtabs %}

#### Outcome

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad"
}
```


# How to Add RPC Fast Endpoints to MetaMask

A guide on connecting MetaMask to RPC Fast

## The best way to connect RPC Fast to MetaMask

### The MetaMask browser extension

MetaMask is a well-designed browser extension enables you to create and manage your Ethereum account and interact with the blockchain. Add this extension to your browser to receive your private key and transact within minutes. It works on Google Chrome, Firefox, Opera, and Brave.

Once installed, you’re able to buy, sell, receive and send crypto tokens across any dApp platform or marketplace, as well as use it to swap your crypto variants from one to another.

### MetaMask tutorial: One-click login

#### Step 1: The registration form alteration

Regarding a login flow itself, the modified register form will require no further information, except for a specific public address and nonce — no email address or phone number — unless you want to put a traditional login in addition to login with MetaMask, in this case, you can keep the common username, email, and password fields as well.

When signing up, the public address will be an essential field. Luckily, users will not have to type their public address manually every time they sign up, as it will be fetched automatically.

#### Step 2: The generation of nonces

Every time users send their public addresses, we should provide them with a randomly generated code that they can see in the nonce field.

#### Step 3: Receiving nonces by users

If they have MetaMask, we can request to receive the current MetaMask account’s public address. As soon as users click on a login button, we make an API call to the back end to obtain a specific nonce related to their public addresses. If no results, the current public address might not be signed up yet, so we should create a new account, transferring the public address to the frame of request. If we have got a result — save its nonce.

#### Step 4: Signing the nonces

Upon receiving nonce by the front end, present a confirmation popup with nonce in it so that the user understands what he or she will sign. When the user signs it, the front end makes one more API call, passing the user’s signature and public address.

#### Step 5: Proof of Ownership

As soon as the back end receives all the necessary data such as nonce, public address, and signature, it can cryptographically verify that the public address is indeed under the exact user’s ownership.

#### Step 6: Prevent sending the same nonce

To avoid users logging in with the same signature, we have to ensure that every time a user wants to log in, he or she signs a new nonce. This can be done by generating another nonce for a particular user and ensuring this one is saved in the database.

### Create an Account on RPC Fast

Running your own gas-free RPC node can be a great burden since it takes up a lot of time and effort that are so urgently needed for the product itself. RPC Fast was created to fix this pain.

This is a Web3 developer software allowing everyone requiring a fast and secure blockchain service—a start-up or a large company—to get endpoints and instantly access the blockchains such as Ethereum, Binance Smart Chain, and Polygon without having to run their own gas-free RPC node.

RPC Fast is the perfect choice for those who are going to save on infrastructure and get gas-free RPC node elsewhere. To get started with RPC Fast, follow the steps below:

1. Go to RPC Fast's website and hit any Login or Try it For Free buttons. Log in with Google or go through the simplest registration. Voila, you’re inside!
2. Choose the plan that works best for your business to get started. The free trial version is available for you eternally if it fits your needs.
3. Opt for the preferred network and blockchain from the given list and contact us if you would like to include some specific features or discuss the Enterprize plan.

That is done! You have a fully working blockchain for the needs of your business.

### Create a MetaMask API Key for the desired network

An API key is an alphanumeric key that consists of a sequence of numbers and letters. It identifies your MetaMask account, which allows you to interact with it on the blockchain by creating transactions. Each network has its own unique MetaMask API keys that are different from one another, so make sure you don't share authenticator codes with anyone else. But how to create it if I do not have one?

* You will be asked to select four parameters. To begin creating a MetaMask API key for the desired Network, first and foremost, try to divide your project into several apps. This is done to prevent the disorder of the full project if one of its parts fails.
* If you start with a front-end production, you should name it respectively.
* You’ll need to write a short description for your app, for instance, the front end of my app.
* Choose your app’s environment whether it already works, is still being tested, or probably, keeps on developing. In the current case, you’d rather choose the development environment because you don’t test or start the production.
* You will be asked to choose your desired network. Select one.
* Upon completing all the necessary fields, you can create your app. As soon as it’s done, voila, click on the View Key button to copy your HTTP or WebSocket API key.

### How to Add RPC Fast Endpoints to MetaMask?

MetaMask is a secure cryptocurrency wallet accessible either as a MetaMask app that you can run on your desktop and mobile device or as a browser extension. MetaMask includes many advanced features such as MetaMask connecting to multiple blockchain networks and letting you interact with DApps directly from the browser. Let’s walk through the MetaMask tutorial on adding MetaMask Custom RPC:

1. Once you have created your account on RPC Fast and a private MetaMask API key for your network, go to your MetaMask wallet. At the top of its home page, you will see the current network you are connected to. Usually, the Ethereum Mainnet is set up by default, click on it so that you will be provided with more options.

   <figure><img src="/files/ZsfK1zya4tXBuxHLapYA" alt="metamsk ethereum mainnet"><figcaption></figcaption></figure>
2. To enable adding a new network, opt for MetaMask Custom RPC at the very bottom of the dropdown.

   <figure><img src="/files/DsvBqBCtDPqq5YLx8wHL" alt="metamask custom rpc"><figcaption></figcaption></figure>
3. You will be moved to another window, where you have to put in all the necessary details including your newly created MetaMask API key in their respective fields.
4. Click on the Save button to approve your decision to add MetaMask Custom RPC.

Here we go, you got connected MetaMask to RPC Fast. Enjoy!


# How to Add Polygon to MetaMask

Step-by-step guide for dApp developers on adding Polygon to MetaMask.

This guide will teach you key features of the Polygon chain and how to add Polygon to MetaMask. You’ll also be able to configure your wallet to interact with your dApp on the Polygon mainnet or testnet and add custom tokens to MetaMask.

### Installing and setting up MetaMask

Millions of users trust MetaMask as their crypto wallet of choice. It serves as a gateway to dApps, with the browser extension connecting Web2 and Web3 to create seamless transactions. Before you can add Polygon to MetaMask, set up a wallet with these simple steps:

**Step 1** - Download MetaMask for your browser of choice from the [official website](https://metamask.io/download/). BE CAUTIOUS and ensure you get the real extension and avoid phishing sites.

<figure><img src="/files/QJCsADQkQboihRVIulU0" alt="install metamask"><figcaption></figcaption></figure>

**Step 2** - Start configuring your wallet. Note that whether you agree to share data or not won’t affect your experience.

<figure><img src="/files/MfATOWpsp4Phrl9rtjKO" alt="metamask configure wallet"><figcaption></figcaption></figure>

**Step 3** - Create a new wallet and come up with a password. Write it down or use a robust password manager.

<figure><img src="/files/91m6agEDCWbe64Lij7Vz" alt="metamask creating a wallet"><figcaption></figcaption></figure>

**Step 4** - Get your secret recovery phrase and ensure you store it securely. Remember that it cannot be restored if you lose it.

<figure><img src="/files/4mCeXwLtcCsz471KTr1Z" alt="metamask setting recovery phrase"><figcaption></figcaption></figure>

**Step 5** - After you confirm your recovery phrase, your MetaMask is all set.

<figure><img src="/files/oqASeKOVVYVcwRZRBk8T" alt="metamask recovery phrase confirmed"><figcaption></figcaption></figure>

However, you’ll be connected to Ethereum mainnet by default. From here, you need to add Polygon network to MetaMask:

### **Configuring the Wallet**

Time to make the wallet use RPC Fast. Navigate to the top and add a new network to your list:

<figure><img src="/files/5HBeec5ls2lRNy7lSJnr" alt="metamask add a new network"><figcaption></figcaption></figure>

Now, log into your [RPC Fast Dashboard](https://control.rpcfast.com/) to find your API key and endpoint. It will look like this:

<figure><img src="/files/oLBa5p13QNogyaSX14y3" alt="rpc fast dashboard"><figcaption></figcaption></figure>

Copy the endpoint with your API key and use it as the RPC URL. Add details to MetaMask:

* Network Name: Polygon Mainnet
* New RPC URL: <https://polygon-mainnet.rpcfast.com?api\\_key=YOUR\\_KEY>
* Chain ID: 137
* Currency symbol: MATIC
* Block explorer URL: <https://polygonscan.com/>

Your final result will look like this:

<figure><img src="/files/MIwVWoGfWR57Sgn8UNpJ" alt="add polygon to metamask"><figcaption></figcaption></figure>

#### **Alternative Ways to Add Main Chain & Testnet**

If you want to connect directly to Polygon, use <https://polygon-rpc.com> or press the "Add Polygon Network" button in the footer of the [Polygonscan ](https://polygonscan.com/)website.

<figure><img src="/files/JWgVIn5hE3yY9aCyu4TL" alt="metamask notification"><figcaption></figcaption></figure>

To connect to the Mumbai Testnet, use the RPC <https://rpc-mumbai.maticvigil.com/> with Chain ID 80001, MATIC currency, and <https://mumbai.polygonscan.com/> in the block explorer field.

<figure><img src="/files/UO9JybFbKTNCK1QTv8kr" alt="add a network manually"><figcaption></figcaption></figure>

Your Polygon network MetaMask link is in place. Now you can use the wallet to interact directly with your dApp both on the mainnet and in testnet environments.

### **Adding Polygon tokens to MetaMask**

After adding Polygon to MetaMask, you will already see MATIC tokens in your wallet. MetaMask also makes it easy to add new tokens, for example, if you’re minting your own in a dApp. Here’s how you can do it in two steps:

1. Navigate to the bottom of your wallet and hit Import Tokens.

   <figure><img src="/files/gTHdXEr40Db3dOF6tAIV" alt="import tokens"><figcaption></figcaption></figure>
2. Specify your address, token symbol, and decimal. In this case, it’s TST on a test contract.

   <figure><img src="/files/eYB1WNaNMxE6ilTqs7Ii" alt="import tokens"><figcaption></figcaption></figure>

Now that you’ve finished the Polygon MetaMask setup, you can allow users to interact with your dApp directly and unlock the full potential of Web3 with the help of RPC Fast.

**Сonclusion**

Setting up Polygon on MetaMask allows you to bridge the gap between Web2 and Web3, interacting with your dApp from a browser extension. All you need to do is create a wallet, connect it to your RPC Fast API, and add any tokens you plan to work with.

From now on, you can interact with the chain and build amazing things with the help of Polygon’s robust scaling and lightning-fast transaction speed.


# Support –> Other Blockchains

RPC Fast SaaS – ETH, BSC, AR, Polygon, Velas.

{% hint style="warning" %}
Dedicated support is **not available** for SaaS users on blockchains other than Solana.
{% endhint %}

If you encounter a **technical issue** related to SaaS, please post your question in our [community chat](https://telegram.me/+RX05NAHuiwZjNWQy). We will get back to you within the chat within 24-48 hrs.

For **billing-related inquiries**, you can contact us via email at <contact@rpcfast.com> or by using the [Contact form](https://rpcfast.com/contact-form) on our website.


# Contact Us

RPC Fast is developed by Dysnix, a Ukrainian team with a legal entity based in Estonia.

<https://rpcfast.com/>\
<https://dysnix.com/>

#### Business & Partnership Enquiries

Email us at <contact@rpcfast.com> or use the [Contact form](https://rpcfast.com/contact-form).

#### Sales Enquiries

If you interested in Solana dedicated nodes, DevOps-as-a-Service, white-label/custom infrastructure solutions, or self-hosted cluster setup on **any blockchain of your choice**, reach out to our [SDR representative](https://telegram.me/dysnix_rpc) on Telegram or use the [Contact form](https://rpcfast.com/contact-form).

***

#### Follow Us

**Telegram**

<https://t.me/rpc_fast> – Solana RPC Community support & updates\
[Dysnix Web3 DevOps Community](https://t.me/web3_infra/) – A dedicated space to discuss blockchain infra and Web3 DevOps challenges (all networks)

**X**\
<https://x.com/rpcfast>\
<https://x.com/dysnix>

**Discord**

<https://discord.com/invite/WYMDrbfUhq>

**GitHub**\
<https://github.com/dysnix>

**LinkedIn**\
<https://www.linkedin.com/company/rpcfast/>\
[https://www.linkedin.com/company/dysnix/](https://www.linkedin.com/company/dysnix/about/)

**Medium** (blog by Daniel Yavorovych, СTO & Co-Founder at Dysnix / RPC Fast)\
<https://yavorovych.medium.com/>


# Terms of Service

Last updated: 9/07/2026

These Terms of Service (“Terms”) constitute a legally binding agreement between you (“User”, “you”, or “Customer”) and **Ituum OÜ**, a company incorporated under the laws of Estonia, a developer of the **RPC Fast SaaS** platform (“RPC Fast”, “we”, “us”, or “our”).

These Terms govern your access to and use of:

* The RPC Fast SaaS platform
* RPC API endpoints and related infrastructure services
* Dashboard, billing system, and account management tools
* Documentation available at [https://docs.rpcfast.com](https://docs.rpcfast.com/)
* Website located at [https://rpcfast.com](https://rpcfast.com/) and related subdomains

(collectively, the “Service”).

{% hint style="info" %}
By creating an account, joining the waitlist, accessing the dashboard, or using the Service, you agree to be bound by these Terms. If you do not agree, you must not use the Service.
{% endhint %}

***

### 1. Eligibility

You represent and warrant that:

* You are at least 18 years of age (or the legal age in your jurisdiction);
* You have the legal capacity to enter into a binding agreement;
* If acting on behalf of a company, you are authorized to bind that entity.

***

### 2. Account Registration & Security

To access certain features, you must create an account.

You agree to:

* Provide accurate, complete, and current information;
* Maintain the confidentiality of login credentials and API keys;
* Be fully responsible for all activities conducted under your account.

You must immediately notify RPC Fast of any unauthorized access or security breach. RPC Fast is not liable for losses resulting from unauthorized use of your credentials.

***

### 3. Description of the Service

RPC Fast provides subscription-based access to RPC infrastructure and related services delivered as Software-as-a-Service (SaaS).

The Service may include:

* Shared or dedicated RPC endpoints;
* CU-based usage allocation;
* Usage analytics and dashboard tools;
* Support services depending on selected plan.

We reserve the right to modify, update, or discontinue parts of the Service at any time.

***

### 4. Subscription Plans, Credits & Billing

#### 4.1 Billing Cycle

Each billing period is **thirty (30) days**, unless otherwise specified in your selected plan.

Your subscription begins on the date you activate or select a plan and renews automatically every thirty (30) days unless canceled.

#### 4.2 Overage Usage

Usage exceeding the included monthly Compute Units allocation will be charged at the applicable overage rate during the active billing period.

You are fully responsible for all overage charges incurred under your account.

#### 4.3 Plan Changes

You may upgrade or downgrade your subscription plan via the Billing section of the dashboard.

* **Upgrades** take effect immediately. After a new plan price is paid, the billing period is re-calculated to thirty (30) days from the date of payment.
* **Downgrades** become effective at the end of the then-current billing period.

#### 4.4 Fees & Payment

Subscription plans include a defined monthly allocation of Compute Units (CU) and other services within defined plan limits and are billed in advance at the start of each billing cycle using your selected payment method.

You authorize RPC Fast (or its third-party payment processor) to charge all applicable fees, taxes, and overage charges to your payment method.

RPC Fast uses [Stripe](https://stripe.com/) to process payment card transactions and generate invoices.

RPC Fast supports cryptocurrency payments (currently, for **Solana RPC** subscriptions only) through [CoinGate](https://coingate.com/), which acts as a third-party payment processor for supported digital assets. Read more about cryptocurrencies supported and the processing fees applied [here](https://docs.rpcfast.com/rpc-fast-saas-solana/billing/payments).

By making a payment, you agree to the applicable terms and policies of the relevant payment provider.

{% hint style="warning" %}
All fees are **non-refundable** unless required by applicable law. For exceptions, see section **4.7 Refund Policy.**
{% endhint %}

#### 4.5 VAT & Taxes

**All fees are exclusive of applicable taxes.** Any taxes required by law will be calculated and charged at checkout. Customers are responsible for all applicable taxes associated with their purchase and use of the Service.

RPC Fast runs under a company registered and VAT-liable in Estonia (EU). All prices for individual (non-business) customers are subject to Estonian VAT at the applicable local rate.

**Why Estonian VAT applies to EU customers:** Under EU VAT rules, digital service providers whose annual cross-border B2C sales remain below the EU-wide OSS registration threshold are permitted to apply their home country’s VAT rate rather than the customer’s local rate. Hence, Estonian VAT applies to all individual customers regardless of their EU country of residence.\
This approach is compliant with Council Directive 2006/112/EC of 28 November 2006 on the common system of value added tax (as amended by Council Directive (EU) 2017/2455 of 5 December 2017 regarding VAT obligations for supplies of digital services and the introduction of the OSS threshold).\
\
**Business customers (B2B):** If you are purchasing on behalf of a VAT-registered business in another EU country, please contact our support and provide your valid VAT ID. The reverse charge mechanism will apply and no Estonian VAT will be charged.

#### 4.6 Failed Payments

If a payment attempt fails, RPC Fast will automatically retry the charge using the payment method on file.

* RPC Fast will make up to three (3) additional payment attempts over a period of approximately six (6) days. During this period, access to the subscribed plan will continue uninterrupted.
* If all payment attempts are unsuccessful, RPC Fast reserves the right to suspend paid features and downgrade the account to the free **Start** plan.&#x20;
* Any outstanding fees incurred prior to the downgrade remain payable by the Customer.

Customers are responsible for maintaining valid and up-to-date payment information and ensuring sufficient funds are available to cover subscription fees and applicable charges.

#### 4.7 Refund Policy

Access to the Services is provided immediately upon successful payment. By purchasing a subscription, the Customer expressly requests immediate access to the Services and acknowledges that, to the extent permitted by applicable law, any statutory *right of withdrawal or cancellation* that would otherwise apply is waived once access to the Services has begun.

Accordingly, all fees paid for the Services are generally **non-refundable.**

Notwithstanding the above, the Company may, at its sole discretion, grant a full or partial refund on an exceptional basis if:

* the Customer submits a refund request within **three (3) calendar days** from the date of purchase; and
* the Customer demonstrates that the Services failed to perform substantially as described due to a verified quality or technical issue attributable to the Company.

We will investigate each request individually. Refunds will not be granted for reasons including, but not limited to, changes in the Customer's business needs, lack of usage, configuration errors, incompatibility with third-party software or infrastructure outside the Company's control, or issues caused by the Customer's own systems or actions.

Any decision to issue a refund outside the circumstances described above is made solely at the Company's discretion and does not create an obligation or precedent for future cases.

***

### 5. Acceptable Use

#### 5.1 General Usage Restrictions

You agree not to:

* Use the Service for unlawful or fraudulent purposes;
* Interfere with, disrupt, or overload RPC Fast infrastructure;
* Attempt to reverse engineer, decompile, or exploit the Service;
* Circumvent rate limits, security controls, or usage restrictions;
* Use the Service to attack, exploit, or harm third parties.

RPC Fast reserves the right to suspend or terminate access for violations of this section.

#### 5.2 Abuse Prevention & Fair Use

**Users are prohibited from abusing the platform infrastructure,** including but not limited to excessive spam transaction generation, persistent failed bundle submissions, artificial traffic amplification, or any activity that negatively impacts platform stability, SWQoS partners, or other users of the service.

**We reserve the right to introduce protective measures against abusive behavior,** including temporary throttling, reduced rate limits, account suspension, traffic shaping, or other technical restrictions designed to preserve infrastructure integrity and service availability.

{% hint style="warning" %}
Accounts identified as engaging in abusive or spam-related activity are **not eligible** for refunds, chargebacks, or money-back requests for purchased subscription plans, including cases where restrictions or penalties are applied as a result of such behavior.
{% endhint %}

However, unless otherwise determined by us, affected users may continue using their active subscription during or after the penalty period if they return to **compliant and fair-use behavior.** Penalty measures are automatically removed after a sustained period of normal activity, and applicable service limits will gradually return to the standard levels associated with the subscription plan.

Because our sender service is currently provided in Beta, our abuse-detection systems, fair-use thresholds, rate limits, and enforcement policies may change at any time without prior notice. We reserve the right to make enforcement decisions at our sole discretion when necessary to protect the platform, infrastructure providers, or other users.

#### 5.3 Trial period (valid for Solana subscriptions only)

RPC Fast offers a complimentary **24-hour trial endpoint on Solana mainnet** to allow prospective customers to evaluate the Service. Trial access may be extended for up to 48-72 hours at RPC Fast's sole discretion.

To ensure fair access to trial resources, RPC Fast reserves the right to deny, limit, suspend, or terminate trial access if it reasonably determines that a user is attempting to circumvent trial limitations or otherwise abuse the trial program. Such activity may include, but is not limited to, creating multiple accounts, using multiple identities, repeatedly registering for additional trials, or otherwise attempting to obtain trial access beyond the intended evaluation period.

{% hint style="warning" %}
RPC Fast reserves the right to determine, in its sole discretion, whether activity constitutes **abuse of the trial program** and to take appropriate action without prior notice.
{% endhint %}

***

### 6. API Keys & Usage Limits

You are responsible for:

* Securing API keys;
* All API requests made using your credentials;
* Monitoring your own usage to prevent unintended overage.

We may impose rate limits, usage thresholds, or other technical safeguards to protect system stability.

***

### 7. Suspension & Termination

We may suspend or terminate your access to the Service if:

* Payment is overdue;
* You breach these Terms;
* Your usage presents a security risk or legal exposure;
* Required by law.

Upon termination:

* Access to the Service will cease;
* Outstanding fees become immediately due;
* We may delete account data in accordance with our data retention policies.

You may **cancel your subscription** at any time via the dashboard. Cancellation will take effect at the end of the current billing period.

***

### 8. Intellectual Property

All rights, title, and interest in and to the Service, including software, APIs, documentation, branding, and trademarks, are owned by RPC Fast.

Users are granted a limited, non-exclusive, non-transferable, revocable license to use the Service solely in accordance with these Terms.

No ownership rights are transferred to users.

***

### 9. Data & Privacy

Your use of the Service is subject to our **Privacy Policy** and **Cookies Policy**, which are incorporated by reference.

You retain ownership of your application data. RPC Fast does not claim ownership of blockchain data processed through the Service.

***

### 10. Service Disclaimer

The Service is provided on an “AS IS” and “AS AVAILABLE” basis.

RPC Fast makes no warranties, express or implied, including but not limited to:

* Fitness for a particular purpose;
* Non-infringement;
* Uninterrupted or error-free operation.

Blockchain networks are inherently unpredictable. RPC Fast is not responsible for failures or delays caused by the blockchain network or other third-party infrastructure.

***

### 11. Limitation of Liability

To the maximum extent permitted by law:

RPC Fast shall not be liable for any indirect, incidental, special, consequential, or punitive damages, including loss of profits, revenue, data, or business opportunities.

Our total aggregate liability under these Terms shall not exceed the total fees paid by you to RPC Fast during the three (3) months preceding the event giving rise to the claim.

***

### 12. Indemnification

You agree to indemnify and hold harmless RPC Fast, its officers, directors, employees, and affiliates from any claims, damages, liabilities, and expenses arising out of:

* Your use of the Service;
* Your violation of these Terms;
* Your violation of applicable laws or third-party rights.

***

### 13. Force Majeure

RPC Fast shall not be liable for delays or failures caused by events beyond its reasonable control, including but not limited to:

* Natural disasters;
* Government actions;
* Internet or infrastructure outages;
* Blockchain network disruptions.

***

### 14. Governing Law & Jurisdiction

These Terms are governed by the laws of the Republic of Estonia.

Any disputes arising out of or relating to these Terms shall be resolved in the courts of Estonia.

***

### 15. Modifications to Terms

We may update these Terms from time to time.

If material changes are made, we will provide notice via the website or dashboard. Continued use of the Service after updates constitutes acceptance of the revised Terms.

***

### 16. Contact Information

For legal notices or questions regarding these Terms:

<contact@rpcfast.com> or via form at [https://rpcfast.com/contact-form](https://rpcfast.com/contact-formhttps://rpcfast.com/contact-form)


# Privacy Policy

Last updated: 12/02/2026

RPC Fast SaaS platform is developed by Ituum OÜ, a company incorporated under the laws of Estonia (“RPC Fast”, “we”, “us”, or “our”). We value your privacy and committed to protecting your personal data. This Privacy Policy explains how we collect, use, store, and share information when you:

* Visit [https://rpcfast.com](https://rpcfast.com/) and related subdomains
* Access our RPC Fast SaaS platform and APIs
* Join the waitlist, subscribe, or submit a contact form
* Interact with documentation at [https://docs.rpcfast.com](https://docs.rpcfast.com/)
* Communicate with support

By using our Services, you agree to the terms of this Privacy Policy and our Terms of Service.

An extended version of Privacy Policy is available at <https://rpcfast.com/privacy>.

***

### 1. Data Controller

The data controller for your personal information is:

**Ituum OÜ**\
Tallinn, Vesivärava str 50-201, 10152, Estonia.\
Email: <contact@rpcfast.com>\
Website: [https://rpcfast.com](https://rpcfast.com/)

If you reside in the European Union, Ituum OÜ acts as the data controller for the personal data collected through the Service.

***

### 2. Information We Collect

#### 2.1 Information You Provide Directly

We may collect personal data when you:

* Fill out forms (contact, waitlist, support)
* Create an account for RPC SaaS access
* Subscribe to updates
* Provide billing or payment details

Examples include your name, email, company name, username, and payment information (processed by third-party providers). Providing this information is voluntary but necessary for certain services.

#### 2.2 SaaS Usage Data

For the SaaS platform, we collect:

* Account identifiers and API keys
* Subscription plan and credit (CU) usage
* API request metrics (requests per second, response times, compute units)
* System logs, errors, and technical performance

This information is used to operate, secure, and improve the Service.

#### 2.3 Automatically Collected Data

When you visit our website or use the dashboard, we collect:

* IP address, device type, and browser information
* Pages visited, time spent, and navigation paths
* Referring URLs and session activity

We use this data for analytics, performance improvement, and security.

#### 2.4 Payment Information

We use **Stripe** as our third-party payment processor to handle subscription and overage charges. When you make a payment, your payment card information is transmitted directly to Stripe. RPC Fast does not store full payment card numbers on its systems. Stripe processes payment information in accordance with its own privacy policy, available here: <https://stripe.com/privacy>.

***

### 3. Cookies and Tracking Technologies

We use cookies and similar technologies to enhance your experience:

* **Essential Cookies:** Required for login, dashboard access, and basic functionality
* **Functionality Cookies:** Remember preferences and language settings
* **Analytics & Performance Cookies:** Aggregate usage metrics and site performance
* **Targeting/Advertising Cookies:** Optional, for personalized ads or marketing
* **Social Media Cookies:** Track interactions with social media content
* **Web Beacons:** Track page visits or email engagement (no personal data collected)

You can control cookies through your browser, though some features may not work if cookies are disabled.

***

### 4. How We Use Your Information

We process data for:

* **Service Provision:** Account management, SaaS operation, API access, billing
* **Communication:** Responding to inquiries, support, updates
* **Security:** Detecting fraud, preventing misuse, monitoring system integrity
* **Analytics & Improvement:** Aggregated statistics, performance monitoring, Service enhancement
* **Marketing (optional):** Only with your consent

We do not sell personal data to third parties.

***

### 5. Legal Basis for Processing (GDPR)

If you are in the EEA, we process data based on:

* **Contractual necessity:** To provide the SaaS and fulfill subscriptions
* **Legitimate interests:** To improve, secure, and operate the Service
* **Legal obligations:** Compliance with applicable laws
* **Consent:** For optional communications or marketing

***

### 6. Data Sharing

We may share data with:

* **Service Providers:** Hosting, analytics, payment processors, and support tools
* **Legal Authorities:** When required by law or safety regulations

We do not share personal data for third-party marketing purposes.

***

### 7. Data Retention

Data is retained only as long as necessary to:

* Provide the Service
* Comply with legal and accounting obligations
* Resolve disputes or enforce agreements

Upon account termination, data may be deleted or anonymized according to these retention policies.

***

### 8. Your Rights

Depending on your jurisdiction, you may:

* Access or correct personal data
* Request deletion or restriction of processing
* Object to processing
* Request data portability
* Withdraw consent (where applicable)

To exercise your rights, contact <contact@rpcfast.com> or via <https://rpcfast.com/contact-form>. Verification may be required.

***

### 9. Security

We implement reasonable technical and organizational measures:

* Access controls and authentication
* Data encryption where appropriate
* Monitoring and logging for system integrity
* Secure hosting environments

Users are responsible for protecting their credentials and API keys.

***

### 10. Children’s Privacy

The Service is not intended for individuals under 16 (or the minimum age in your jurisdiction). We do not knowingly collect personal data from children.

***

### 11. International Transfers

Your data may be processed outside your country of residence. We implement safeguards for cross-border transfers in compliance with applicable laws. We use Strip for card payments

***

### 12. Changes to This Privacy Policy

We may update this Privacy Policy. Material changes will be posted on our website or in the Docs. Continued use of the Service constitutes acceptance of updated terms.

***

### 13. Contact

Questions about privacy or your personal data:

Email: <contact@rpcfast.com>\
Website: [https://rpcfast.com](https://rpcfast.com/)


# Cookies Policy

Last updated: 10/02/2026

This Cookies Policy explains what cookies are, how RPC Fast uses them on <https://rpcfast.com/> and related domain properties, and your choices regarding cookies.

***

### 1. What Are Cookies?

Cookies are small text files stored by your browser that help websites remember information about your visit and your device.

Cookies help us to enhance user experience and make this website work better for you. You support our Cookies Policy by staying on this page and downloading our apps.

***

### 2. How We Use Cookies

We use cookies for:

**a) Essential Cookies**\
Cookies necessary for login, dashboard sessions, and security.

**b) Performance & Analytics**\
To understand how users interact with the site, duration of visits, and page performance.

**c) Functional Cookies**\
To remember preferences and settings.

**d) Marketing & Advertising**\
Optional cookies to tailor promotions and marketing content.

***

### 3. Third-Party Cookies

We may allow cookies set by third-party services (e.g., analytics, billing processors). These cookies are subject to the third parties’ privacy policies.

***

### 4. Your Choices

You can control cookies via your browser settings. You can delete cookies individually or block them entirely — however, blocking certain cookies may affect the Service’s core functionality.

***

### 5. Contact

Questions about cookies? Reach us at <contact@rpcfast.com> or via <https://rpcfast.com/contact-form>.


# Compliance

RPC Fast Regulatory Position Statement

### RPC Fast Is a Blockchain Infrastructure Provider, Not a Crypto-Asset Service Provider

RPC Fast provides technical infrastructure that enables developers and businesses to interact with public blockchain networks.

Our services include:

* RPC endpoint access;
* transaction propagation;
* network performance optimization;
* blockchain infrastructure services.

RPC Fast does not provide custody, exchange, brokerage, trading, investment, wallet, staking, or asset management services.

#### Customer Control

RPC Fast customers retain exclusive control over their crypto-assets, wallets, and private keys at all times.

Customers independently:

* create transactions;
* determine transaction parameters and fees;
* authorize transactions;
* sign transactions using their own wallets and applications;
* decide whether and when transactions are submitted to a blockchain network.

RPC Fast cannot access, move, transfer, exchange, or otherwise control customer crypto-assets.

#### No Custody

RPC Fast does not:

* hold customer crypto-assets;
* hold customer private keys;
* create custodial wallets;
* maintain control over customer funds.

Customers remain the sole custodians of their assets.

#### No Execution of Transactions on Behalf of Customers

RPC Fast does not execute transactions on behalf of customers.

All blockchain transactions transmitted through RPC Fast are created and cryptographically signed by customers using customer-controlled wallets and applications before being submitted to RPC Fast infrastructure.

RPC Fast does not determine transaction intent, modify transaction instructions, or exercise discretion over customer activity.

#### Infrastructure and Network Layer Only

RPC Fast acts solely as a technical infrastructure and networking layer between customers and public blockchain networks.

When transmitting blockchain transactions, RPC Fast transports customer-signed messages to blockchain infrastructure and validator networks. RPC Fast does not act as a counterparty, intermediary, broker, agent, or custodian.

Any transfer of crypto-assets occurs directly on the underlying blockchain network based exclusively on instructions authorized by the customer.

#### No Investment or Financial Services

RPC Fast does not provide:

* investment advice;
* portfolio management;
* brokerage services;
* exchange services;
* trading venue services;
* financial intermediation.

RPC Fast provides infrastructure services only.

#### Summary

RPC Fast is a blockchain infrastructure provider that enables access to decentralized networks. Customers maintain exclusive control over their assets, wallets, private keys, and transaction decisions. RPC Fast does not custody assets, execute transactions on behalf of customers, or provide financial services.

Our role is limited to providing reliable, high-performance infrastructure for accessing and communicating with public blockchain networks.