Why Choose FluxRPC?
FluxRPC is high-performance RPC infrastructure for Solana and Fogo built around a different architecture from the traditional validator-based RPC stack.
Instead of requiring the full validator stack to serve RPC requests, FluxRPC separates RPC serving and state processing into independently scalable infrastructure. FluxRPC live-ingests network data, processes it across redundant data and state layers, and serves applications through dedicated HTTP, WebSocket and streaming infrastructure.
This separation isn't only about performance. It creates a different failure path from RPC infrastructure that depends on the full validator stack, providing applications with meaningful infrastructure redundancy when issues occur within that stack.
FluxRPC combines this architecture with stale-state protection, workload isolation, cross-region redundancy, bandwidth-based pricing, local account-state caching through Lantern, and real-time data access through WebSockets and Yellowstone gRPC.
Solana RPC Without the Full Validator Stack
A traditional Solana RPC implementation commonly runs RPC services as part of the broader validator stack.
FluxRPC separates those responsibilities.
FluxRPC live-ingests shreds from the Solana network and uses the required Agave processing components to reconstruct and process blockchain state without requiring the complete validator stack on every RPC server.
From there, data is processed across independent data shards and state-processing infrastructure before requests are served through FluxRPC's HTTP and WebSocket layers.
This allows the infrastructure responsible for serving RPC workloads to scale independently from the full validator stack.
Why Separate RPC Infrastructure From Validators?
Validators and RPC infrastructure solve different problems.
Validators participate in the Solana network and consensus. RPC infrastructure answers application requests, retrieves account state, queries programs, submits transactions and delivers real-time blockchain data.
Separating these workloads gives FluxRPC greater control over how RPC data is processed, replicated and served.
It also means scaling RPC capacity does not require scaling the entire validator stack alongside it.
A Different Failure Path for Real RPC Redundancy
Having two RPC endpoints does not necessarily mean having two independent failure paths.
If primary and backup RPC infrastructure ultimately depend on the same underlying architecture or validator-stack components, an issue affecting that shared layer can affect both.
FluxRPC is designed differently.
By separating RPC serving and state processing from the full validator stack, FluxRPC provides an alternative failure path for RPC workloads.
Its redundancy extends across multiple layers:
- Data sources
- Data shards
- State processing
- HTTP and WebSocket serving
- Geographic regions
If one processing path becomes unavailable or falls behind, another path can continue processing and serving current state.
FluxRPC also uses cross-region replication so infrastructure in another region can take over when a regional failure occurs.
For teams using multiple RPC providers, this makes FluxRPC useful not only as another endpoint, but as an architecturally different RPC path that can reduce exposure to failures within validator-dependent RPC infrastructure.
FluxRPC is still dependent on the Solana network as the source of blockchain data. The difference is the failure domain of the RPC serving infrastructure, not independence from Solana itself.
Designed to Protect Against Stale RPC Data
RPC performance isn't only about how quickly a response arrives. The state being returned also needs to be current.
FluxRPC processes blockchain data across redundant infrastructure and can verify data across multiple nodes. When a processing path falls behind, stale data can be discarded in favour of current state.
This approach helps prevent an application from receiving an apparently fast response containing outdated blockchain state.
For trading systems, token analysis, account monitoring and other state-sensitive applications, data freshness is part of RPC performance.
Workload Isolation for Demanding RPC Requests
Not every Solana RPC request places the same demands on infrastructure.
A small getBalance response is fundamentally different from a large getProgramAccounts query that scans and returns substantial amounts of account data.
Large workloads can create a noisy-neighbour problem when many customers share the same infrastructure.
FluxRPC is designed with per-user workload isolation so expensive requests from one customer do not have to degrade RPC performance for everyone else.
This is particularly important for applications that rely heavily on methods such as getProgramAccounts.
Transaction Delivery Built Into the RPC Infrastructure
Reading blockchain state is only one side of RPC infrastructure. Applications also need to get transactions to the network.
FluxRPC uses proactive Solana leader tracking and maintains connections to suitable validators for transaction delivery.
Instead of relying exclusively on stake-weighted QoS, FluxRPC can identify upcoming leaders and route submitted transactions toward validators responsible for upcoming blocks.
This transaction-delivery logic is built into FluxRPC rather than requiring developers to build and maintain their own leader-tracking and delivery system.
Bandwidth-Based Solana RPC Pricing
FluxRPC prices RPC usage based on bandwidth rather than request credits or compute units.
The model is straightforward: usage is based on the amount of data transferred.
A small account lookup consumes little bandwidth. A large getProgramAccounts response consumes more. Developers can therefore understand and optimize RPC costs using a familiar resource rather than calculating different credit costs for individual RPC methods.
Current monthly plans include:
| Plan | Price | Included Bandwidth | Requests/sec |
|---|---|---|---|
| Free | $0 | 10 GB | 15 |
| Developer | $38/month | 250 GB/month | 100 |
| Scale | $349/month | 3 TB/month | 300 |
| Pro | $849/month | 15 TB/month | 750 |
Additional pay-as-you-go bandwidth is available at $6 per 100 GB.
For developers evaluating Solana RPC costs, this makes the relationship between application data usage and infrastructure cost explicit.
See FluxRPC Pricing for the full plan comparison.
Lantern: Local Solana Account-State Caching
Even a fast remote RPC request still requires a network round trip.
For applications repeatedly requesting the same account state, FluxRPC provides Lantern, a local account-state caching layer.
Lantern keeps selected Solana account state close to the application and supports commonly used methods including:
getAccountInfogetMultipleAccountsgetProgramAccountsgetBalance
When requested state is available locally, supported reads can be served from the local cache rather than requiring another remote RPC round trip.
Lantern is not a replacement for FluxRPC. It extends the RPC architecture by allowing applications to keep frequently accessed state locally while using remote infrastructure when necessary.
Read the FluxRPC Lantern documentation for installation, configuration and supported methods.
JSON-RPC, WebSockets and Yellowstone gRPC
JSON-RPC is designed for request-response workloads where an application needs specific blockchain state.
WebSockets allow applications to subscribe to changes rather than continuously polling RPC endpoints.
Yellowstone gRPC provides high-throughput real-time blockchain data streams for applications that need continuous access to transactions, accounts, slots and other network data.
This allows developers to choose the interface appropriate to the workload rather than forcing every data-access problem through repeated JSON-RPC requests.
Built for Real Solana Workloads
FluxRPC is built by a team that also operates production applications on Solana.
That provides real workloads for testing RPC performance, account-state access, bandwidth consumption, transaction processing and real-time data infrastructure.
The FluxRPC team publishes technical work and developer guides covering areas such as getProgramAccounts, Base58 optimization, transaction processing, Yellowstone gRPC and local state access.
FluxRPC won the Infrastructure Track at the 2025 Colosseum Breakout Hackathon.
Where independent performance data is available, point developers to the underlying data rather than relying solely on performance claims.
Which FluxRPC Product Should I Use?
- Use FluxRPC JSON-RPC when your application needs standard Solana RPC methods and account-state queries.
- Use WebSockets when your application needs subscriptions to account, program, signature or slot changes.
- Use Yellowstone gRPC when your application needs high-throughput, real-time blockchain streams.
- Use Lantern when your application repeatedly reads selected account state and can benefit from keeping that state locally.
- Use FluxRPC as a redundant RPC path when you want infrastructure with a different failure path from RPC systems tied to the full validator stack.
Get Started With FluxRPC
FluxRPC supports developers building on Solana and Fogo with RPC, WebSocket and real-time data infrastructure.
The Free plan includes 10 GB of bandwidth with no credit card required. Applications can then scale through bandwidth-based paid plans as their data requirements increase.
Frequently Asked Questions
What Is FluxRPC?
FluxRPC is RPC infrastructure for Solana and Fogo. It provides JSON-RPC, WebSocket and Yellowstone gRPC access using an architecture that separates RPC serving and state processing from the full validator stack.
FluxRPC also provides bandwidth-based pricing and Lantern, a local account-state caching layer for supported RPC methods.
How Is FluxRPC Different From a Traditional Solana RPC?
FluxRPC separates RPC serving and state processing from the full Solana validator stack.
It live-ingests network data and processes it through independently scalable data shards and state-processing infrastructure before serving application requests.
This gives FluxRPC a different infrastructure architecture and failure path from RPC systems whose serving infrastructure depends directly on the full validator stack.
Does FluxRPC Require a Solana Validator to Serve RPC Requests?
FluxRPC does not require the full validator stack on each RPC server.
It ingests Solana network data and uses the required processing components to reconstruct and serve blockchain state through independently scalable RPC infrastructure.
FluxRPC still ultimately receives blockchain data from the Solana network. Validator-decoupled does not mean independent of Solana or its validators as the source of network data.
Can FluxRPC Be Used as a Backup Solana RPC Provider?
Yes. FluxRPC can be used as a primary RPC provider or as part of a multi-provider redundancy strategy.
Because FluxRPC separates its RPC serving infrastructure from the full validator stack, it can provide an architecturally different failure path from validator-dependent RPC infrastructure.
That distinction matters when the objective is reducing correlated infrastructure failures rather than simply adding another endpoint.
How Does FluxRPC Protect Against Stale Data?
FluxRPC processes blockchain data across redundant infrastructure and can verify state across multiple nodes.
If a processing path falls behind, stale data can be discarded in favour of current state. The architecture also incorporates redundant data shards, state processing and cross-region replication.
How Does FluxRPC Pricing Work?
FluxRPC uses bandwidth-based pricing rather than charging different request credits or compute units for individual RPC methods.
The Free plan includes 10 GB. Paid plans increase included bandwidth and throughput, and additional bandwidth is available at $6 per 100 GB.
This means RPC cost is tied directly to the amount of data an application transfers.
What Is FluxRPC Lantern?
FluxRPC Lantern is a local account-state caching layer.
It allows supported Solana account-state requests to be served locally when the required state is available, reducing the need for repeated remote RPC round trips.
Supported methods include getAccountInfo, getMultipleAccounts, getProgramAccounts and getBalance.
Does FluxRPC Support getProgramAccounts?
Yes. FluxRPC supports Solana's getProgramAccounts method and provides documentation for filters, dataSlice, bandwidth optimization and supported query patterns.
Applications repeatedly accessing selected account state can also use Lantern for supported local getProgramAccounts workloads.
Does FluxRPC Support Yellowstone gRPC?
Yes. FluxRPC provides Yellowstone gRPC for applications requiring high-throughput real-time Solana data streams.
FluxRPC also supports standard JSON-RPC and WebSockets, allowing developers to select the interface appropriate to each workload.
Does FluxRPC Support WebSockets?
Yes. FluxRPC supports Solana WebSocket subscriptions for applications that need real-time notifications rather than repeated RPC polling.
Does FluxRPC Support Fogo?
Yes. FluxRPC provides infrastructure for both Solana and Fogo.
Is FluxRPC the Fastest Solana RPC?
RPC performance depends on location, method, payload, network conditions and workload, so a permanent universal 'fastest' claim is not particularly useful.
FluxRPC is architected specifically for high-performance RPC workloads. Where independent benchmark data is available, developers should compare current measurements for the methods and regions relevant to their applications.