Solana Infrastructure, Built — Not Rented.
Two colocated regions. A dedicated microservice for every class of RPC workload. No credit meters, no rate-limit games. Just fast data, served from hardware we own and tune ourselves.
A Different Kind of RPC Provider
Every major Solana RPC provider looks the same on the outside — a URL, an API key, a pricing tier. Behind that endpoint, though, the architecture tells a story. And for most of the industry, that story is the same: a few general-purpose validator nodes rented from a cloud provider, sharing a single process, metering every call against a credit budget, and outright blocking the queries that don't fit their capacity model.
Solana Vibe Station is not that. SVS runs its own physical hardware in two global regions — Atlanta and Amsterdam — and splits every part of the RPC surface into a dedicated microservice, each one engineered for the workload it serves. We don't charge per-call credits. We don't cap account queries. We don't hide behind third-party infrastructure we can't tune or debug. What we offer is the opposite of the hosted-Solana-node experience: infrastructure designed and operated specifically to deliver Solana data at the speed Solana moves.
No Credit System
Flat-rate tiers priced by bandwidth and concurrency. A getProgramAccounts costs the same as a getBlockhash — which is to say, nothing extra.
Self-Hosted Hardware
Real servers in real colocation facilities. We spec the NICs, patch the kernels, and run the firewalls. Not a VM on someone else's cloud.
Specialized Microservices
Every RPC method family runs on hardware tuned for that exact workload. A query storm on one service never starves another.
No Credit Meter. Ever.
Open the pricing page of almost any major Solana RPC provider and you'll find the same structure: a monthly subscription tier, a "credits" budget, and a per-method multiplier that makes the expensive calls cost 30x, 50x, or 100x more than a simple getBalance. One getProgramAccounts against a popular DEX can vaporize a week's worth of credits in a single request. Teams end up building elaborate caching layers just to survive their own provider's meter.
We looked at that model and made a different call. SVS tiers are priced by bandwidth and concurrency, not by credits. You pay for your tier, and within that tier, you query what you need. No math, no spreadsheets, no paying a premium every time your application asks a useful question.
The Credit Model
- Per-method multipliers punish the calls you actually need
- Usage anxiety forces aggressive caching and workarounds
- Unpredictable monthly bills as traffic spikes
- Expensive methods often capped or blocked entirely
The SVS Model
- Flat-rate tiers by bandwidth and concurrency
- Every method costs the same — query freely
- Predictable pricing that scales with real capacity
- Heavy methods are a feature, not a premium add-on
This pricing only works because of what's underneath it — and that's where the real engineering story begins.
Real Hardware. Real Control.
When you rent a VM from a hyperscaler to run a Solana validator, you inherit every decision that cloud provider has already made on your behalf: which NICs you get, which kernel version you run, how the hypervisor schedules your traffic, what the underlying network topology looks like. For ordinary workloads, those decisions are fine. For Solana RPC — which is network-bound, latency-sensitive, and throughput-hungry — they are limitations you cannot code around.
SVS owns the hardware outright. Our nodes live in premium colocation at Iron Mountain and partner facilities, on servers we specified, configured, and tune ourselves. In practice, that means:
We pick the NICs
Intel E810 cards for line-rate UDP processing, matched to the workload our validators actually generate.
We patch the kernel
Our UDP 4-tuple RSS patch was merged upstream into FreeBSD (PR #2057) after we found single-queue starvation in production.
We own the network path
BGP peering, carrier selection, TCP stack tuning (BBR, enlarged socket buffers) — the kind of control that turns p99 latency from a liability into a specification.
We run real validators
SVS-operated Frankendancer validators plus our SUNREN partner validator running the Jito BAM client — real stake weight powering our Staked RPC and SWQoS services. Not rented, not borrowed.
When a customer's application is slow, we don't open a support ticket with a cloud provider and wait. We log into the box, inspect the NIC ring buffers, check the IRQ affinity, and fix it. That operational depth is impossible on top of rented infrastructure — and it's the reason our tail-latency numbers are what they are.
One Stack, Six Purpose-Built Services
Here is where the architecture matters most. A Solana RPC node, as shipped by the protocol team, is a monolith. It serves every method — sendTransaction, getBlock, getProgramAccounts, accountSubscribe — from the same process, sharing the same memory, the same thread pool, the same queue. A spike of expensive account queries starves out transaction submissions. A burst of subscriptions pressures the block-serving path. Everything contends with everything.
SVS runs it differently. Each major method family is served by its own microservice, tuned for that family's workload, on hardware specified for that service's profile. Incoming requests are classified at the edge — by our load-balancer layer with consistent API-key hashing, then a method-aware routing layer — and dispatched to the service that handles that class of work.
The benefit is structural, not just theoretical. When every method family has its own resource budget, its own hardware profile, and its own tuning knobs, you can optimize each one independently. A getProgramAccounts storm doesn't hurt anyone else's sendTransaction latency. A surge of subscribers doesn't slow down historical block lookups. And because no service is over-provisioned to handle worst-case contention from unrelated workloads, the overall cost structure is lower — savings we pass directly to customers as flat-rate pricing.
Why This Lets Us Charge Less Per Call
A typical RPC provider runs a fleet of identical, general-purpose Solana nodes. Each node has to be big enough to survive the worst thing any customer might throw at it — a massive getProgramAccounts, a heavy subscription burst, an archival query. That worst-case sizing is baked into every machine, whether it's used or not. Providers then reclaim that cost the only way they can: credit meters that charge a large multiplier for the expensive methods, effectively billing you for the over-provisioning.
Our microservice split breaks that equation:
Right-sized hardware per workload
The account query service gets high-memory boxes. The transaction landing service gets low-latency NICs and stake weight. The archive gets dense storage. Nothing is sized for a workload it will never see.
Higher utilization, lower waste
Each service runs closer to its real capacity because its workload is predictable. Plain-RPC providers carry idle headroom on every node to absorb cross-workload contention.
Specialized > general-purpose performance
Hyperion serves getProgramAccounts hundreds of times faster than a generic node — at a fraction of the hardware cost per query. Specialized beats general, every time.
No credit-meter overhead
We don't need a credit system because we don't need to ration scarce capacity. Capacity is cheap when your architecture matches your workload. That means flat-rate, unlimited-call pricing.
The bottom line: Plain-RPC providers charge more because they have to — their architecture forces over-provisioning and their credit meter is the recovery mechanism. We built a different architecture and get to charge differently as a result. Better performance and lower cost is not a marketing claim; it's the natural outcome of the engineering choice.
A Network Effect on Shreds
Our microservices are only as fast as the data feeding them. Every service in the SVS stack — Hyperion's account indexes, the streaming gRPC feed, Lightspeed's transaction routing logic — ultimately depends on one thing: seeing new Solana state as early as possible. On Solana, that means receiving shreds — the small, erasure-coded fragments of blocks that validators gossip to each other during block production — as soon as humanly possible after a leader produces them.
A plain-RPC provider with one validator in one location is at the mercy of gossip propagation. Their data is only as current as the slowest hop between the leader and their single node. We've built a different model.
Partner Validators Peer Directly Into Our Edge
SVS operates a network of partner validators across both regions — independent operators who run their own Solana validators inside the same colocation facilities as our infrastructure. These partners peer directly into the SVS edge, forwarding shreds to us the moment they receive them. Because they're in the same facility (often the same rack row), the hop from partner validator to SVS microservices is measured in microseconds, not milliseconds.
Layered on top of that, we consume Jito's Shredstream, which aggregates shreds from Jito's global validator network and pushes them to subscribers with minimal latency. Between our partner peering and Shredstream, our microservices see new Solana state from multiple independent paths simultaneously — and take the fastest path on every slot.
The practical effect: every downstream microservice consumes data that is already at the leading edge of the network. Hyperion indexes new account writes before most providers have even seen the block. Lightspeed sees upcoming leader schedules with more lead time. Streaming subscribers receive updates with fewer intermediate hops between them and the source.
Interested in becoming a partner validator? We actively work with validator operators in both regions who want to monetize their infrastructure and contribute to a stronger regional shred network. If you're running a validator in ATL or AMS (or considering a location), we'd love to talk.
Two Regions, One Anycast-Style Experience
The microservice split happens inside each region. Globally, we run parallel deployments in Atlanta (ATL) and Amsterdam (AMS), fronted by a Cloudflare DNS-only load balancer using proximity and geo steering. Your requests resolve to the region closest to you, and if a pool goes unhealthy, Cloudflare stops advertising it within seconds — automatically.
Because each region runs the full service mesh, customers get regional redundancy for free: if the ATL edge has a problem, EU traffic keeps flowing through AMS and vice versa. Everything — Hyperion indexes, archival cluster, streaming feeds — is deployed end-to-end in both regions.
No Single Points of Failure. Anywhere.
Cross-region failover is the easy half of the story. The harder half — the one that quietly takes down most RPC providers when something goes wrong — is the redundancy inside a region. A single load balancer, a single edge firewall, a single upstream switch: any one of these can take the whole location offline, and retreating to the other region adds a long latency penalty for every user in between.
Every layer of every region at SVS is fully redundant. There is no single box, no single cable, no single service instance whose failure can take a region down. Traffic is shared across redundant pairs in active-active configurations; health checks shift load away from an unhealthy node in seconds.
Redundant Firewalls
HA firewall pairs with automatic failover. Session state is synchronized continuously, so a failover is invisible to in-flight connections.
Redundant Network Switching
Dual top-of-rack switches with multi-chassis link aggregation to every node. No single switch failure can isolate any piece of the stack.
Redundant Load Balancers
Active-active load balancer pairs using consistent API-key hashing. Rate limiting and routing state survive a node loss without dropping sessions.
Redundant Microservices
Every microservice — Hyperion, Lightspeed, streaming, archive — runs with multiple instances behind health-checked pools. No instance is a choke point.
Redundant RPC Nodes
Every service is backed by a cluster of Solana nodes, not a single validator. One node falling behind on slots or failing outright is routed around automatically.
Redundant Upstream Carriers
Multiple transit providers and BGP peering relationships at each facility. Network-level failures re-converge without customer action.
The result: a hardware problem that would take most providers' RPC endpoints offline is a non-event on SVS. The failing node stops receiving traffic, its peers absorb the load, and the operations team fixes it at leisure. Your application doesn't notice.
Slot-Lag-Aware Health Checking
Redundant hardware is table stakes. What actually determines whether a customer's query returns useful data is whether the node serving it is caught up with the tip of the Solana network. A node that's up, accepting connections, and answering requests but running 30 slots behind the leader is arguably worse than a node that's cleanly offline — because it returns stale data without telling you.
Most RPC providers use generic TCP or HTTP health checks: is the port open, does the process respond. SVS goes further. Every RPC node in our pools is probed continuously by a Solana-aware health checker that compares each node's current slot to the network tip and evaluates freshness alongside responsiveness.
The SVS slot-lag SLA: any node more than 15 slots behind the network tip is automatically removed from the serving pool. Traffic is redirected to healthy peers within seconds, and the lagging node is reinserted only after it has caught back up. In practice, this almost never fires on our stack — our validators and RPC nodes stay at the tip — but when it does, it protects customers from one of the most insidious classes of bad data: confidently wrong answers.
This is the kind of thing you can only build when you own your infrastructure end to end. A generic cloud health check can't tell you that a Solana node is unhealthy-but-responding. Solana-aware checks can — and ours do.
Three Services, Engineered Like Products
Most of what makes the SVS architecture different is invisible to the customer — load balancers, routing layers, partner peering, health checks. The three services below are what you actually consume. Each is built like an independent product in its own right.
Hyperion — The Crown Jewel
Of all the microservices in the SVS stack, Hyperion is the one we're most excited about — and it is the clearest example of what a purpose-built service can do that a monolithic RPC node fundamentally cannot.
Account query methods — getProgramAccounts, getTokenAccountsByOwner, getTokenLargestAccounts, getLargestAccounts — are the slowest, most expensive, and most frequently rate-limited calls in the entire Solana RPC spec. A standard RPC node treats every one as a full table scan across its account database. Responses routinely take 1–20 seconds. Many providers block the heaviest methods entirely rather than serve them.
Sub-Millisecond Account Queries
Hyperion serves these queries from purpose-built in-memory indexes fed by Yellowstone gRPC, bootstrapping from Solana snapshots and maintaining continuous state. The numbers are the story:
Full queries against tokens with 58,000 holders return in 61ms. Methods other providers refuse to serve — getLargestAccounts, getTokenAccountsByDelegate, getTokenLargestAccounts on USDC — run on Hyperion in single-digit milliseconds.
Hyperion already powers the account query layer for our shared RPC service in production, and it's available as a dedicated deployment for teams that need guaranteed performance — your own instance, configured for your programs, in a region of your choice. If your application is bottlenecked on account data, Hyperion eliminates that bottleneck.
Lightspeed — Transactions That Actually Land
Hyperion is what happens when you specialize the read path. Lightspeed is what happens when you specialize the write path. On Solana, getting a transaction confirmed isn't just about shipping bytes to an RPC endpoint — it's about getting those bytes to the right validator's TPU at the right moment in the leader schedule, with enough stake weight behind them to cut through network congestion.
A plain RPC node handles sendTransaction like any other call. It forwards the transaction to the current leader and hopes for the best. Under congestion, that's a recipe for transactions landing slowly, dropping entirely, or getting crowded out by higher-priority traffic — the "failed to land" experience every Solana user has had at least once.
Lightspeed is a dedicated, redundant fleet of optimized sendTransaction forwarders — purpose-built TPU clients that do nothing except take customer transactions and route them, as fast as physically possible, to the leaders they need to reach. They leverage our validator stake weight to bypass QUIC connection limits that throttle unstaked senders. They're distributed across both regions, fully redundant, and monitored continuously against live mainnet.
Live Performance Numbers — ATL Endpoint
We publish transaction landing metrics for all three of our send paths in real time on our Discord. The numbers below are a recent snapshot from our Atlanta (ATL) endpoint, showing 24-hour landing times from a live test sending transactions across each send path:
Live Performance Numbers — AMS Endpoint
The same specialized send architecture runs in our Amsterdam (AMS) region, serving European and Asian customers with the same dedicated forwarders, same stake-weighted routing, same redundancy. A live comparison across the three AMS send paths shows the pattern holds — if anything, the gap is even larger outside the US:
Landing Rate: The Metric That Actually Matters
Landing speed is meaningless if transactions don't actually confirm. Lightspeed's job is both — fast and reliable. Over the last 7 days of continuous testing at our ATL endpoint:
Over 1,950+ transactions landed consecutively across Lightspeed and Staked (SWQoS) in the 7-day sample, at 100% success. The unstaked path — for reference only — came in at 99.6%, with landing times up to 4x slower. This is the value of specialized send infrastructure, shown on a live production endpoint.
Full transparency: We publish these metrics continuously in our Discord, updated from live mainnet sends every 5 to 60 minutes. No curated screenshots, no cherry-picked time windows — whatever the numbers are, you can see them. Come check them yourself before you commit.
For arbitrage bots, MEV searchers, liquidation engines, and any application where transaction landing time is directly tied to P&L, Lightspeed is the send path that converts your strategy's edge into actual fills.
The Archive — Historical Data at Scale
Not every Solana workload needs sub-millisecond latency. Some need the opposite thing: a deep, queryable history of blocks, transactions, and account state going back years. That's what analytics providers, tax platforms, wallet trackers, forensic tools, and any backtesting system all have in common — they don't care about the current slot so much as they care about past slots.
Historical data is hard because it's big. Really big. And unlike current-state queries, which compress nicely into memory, historical queries require traversing slot ranges that might live anywhere across terabytes of block data. Most RPC providers either don't serve historical data at all, cap it at a small recent window, or charge a steep premium for access.
Deep-History Solana Archive, Production-Scale
SVS operates its own dedicated archival infrastructure — a petabyte-scale storage cluster purpose-built for the query patterns historical Solana data demands. The scale speaks for itself:
Any getBlock, getTransaction, or getSignaturesForAddress query for a slot from 300,000,000 onward is a normal request on our archive endpoint — that's the last two-plus years of Solana mainnet, fully indexed and queryable. No "too old" errors inside that window. No surprise charges. No "contact support" walls.
Why Scale Matters Here
Behind those numbers sits a lot of physical hardware. The SVS historical cluster is built out of more than 20 dedicated servers and over 500 enterprise-grade disks, holding north of a petabyte of raw storage and drawing close to 10 kilowatts of power at full load. That's not a number you hit by renting a few cloud instances — it's a commitment to a class of workload.
Peak outbound traffic from the archive regularly reaches 5 Gbps, with request-rate bursts hitting a thousand queries per second. That throughput isn't a benchmark stunt — it's what our customers actually generate on busy days. Serving it without falling over requires both the raw infrastructure scale above and a storage layer tuned specifically for the shape of Solana's ledger data.
For the teams whose business model is extracting insight from Solana's recent history, this is not a side feature — it's the whole product. And because our archive is a separate microservice from our current-state RPC pool, heavy historical workloads never impact latency on the hot path.
A note on cost: Many providers charge a premium for historical access, or tier it as an expensive add-on. Because the archive runs on our own hardware — not rented cloud storage — we pass the cost savings through. Historical queries are included in our standard tiers, with no per-query credit multiplier.
What This Means For You
The story we've told here is about how we chose to build. What matters for a customer is what that choice delivers:
Better performance, measured in ms
Queries that used to take seconds now take milliseconds. The queries your provider refuses to serve? They run on Hyperion.
Predictable flat-rate pricing
A tier that makes sense at the start of the month and still makes sense at the end. No credit anxiety, no surprise bills.
Global reach, regional control
Two full deployments with automatic geo-steering. Your users see their nearest region; your infrastructure team sees predictable latency.
Real humans, real stack
When something breaks — and in infrastructure, something eventually always breaks — you talk to the people who wrote the stack.
Who we serve: Active traders whose P&L depends on tail latency. Data and analytics providers whose dashboards require heavy account queries. Protocol teams shipping applications whose performance is directly visible to end users. Any team that has ever hit a wall with their current RPC provider and wondered if there was a better way.
Ready to Vibe?
If you're evaluating Solana RPC infrastructure — or frustrated with what you're already paying for — we'd love to show you what purpose-built looks like. Developer sandbox access is free to try.
Start Free Join our Discord