Skip to content

RPC Node Hosting

In short

RPC node hosting is the managed operation of the RPC endpoints every blockchain application depends on, together with full, light, and archive nodes, with load balancing, caching, monitoring, and SLA-grade uptime.

99.95%
uptime delivered
+240%
developer growth
30,000+
monthly active devs
4B+
node requests monthly
Trusted by teams building on-chain

RPC node hosting is the managed operation of the RPC endpoints every blockchain application depends on (the Remote Procedure Call API that wallets, dApps, and backends call to read on-chain state and broadcast transactions), together with the full, light, and archive nodes behind them. An RPC endpoint is only as reliable as the node serving it and the operations around it: load balancing, caching, monitoring, and uptime.

Most teams underestimate that gap until developers start filing complaints about a flaky public RPC. Protofire provides high-performance, customized RPC endpoints for networks, platforms, protocols, and event organizers, and operates the nodes that serve them. Running RPC nodes goes far beyond hosting a server: it is a whole mindset of providing accessible RPC and API to the community, gathering their feedback, and continuously improving the service to keep it fast and reliable under real traffic. We do this in production today, including the Glif RPC layer for Filecoin.

We work with chains, foundations, and protocols that are scaling mainnet traffic, launching an ecosystem, or simply tired of unreliable blockchain RPC. We run your endpoints and nodes as a managed, SLA-oriented service so your core team stays on protocol work instead of babysitting infrastructure.

The managed RPC stack - from nodes to endpoints to SLA

Every layer from raw node hardware to developer-facing endpoint is owned, monitored, and tuned by one team.

01

Blockchain nodes

Full, light, and archive nodes provisioned and sized to your query mix (state reads vs. historical/archive queries), synced and maintained per network client requirements.
02

Load balancing & caching

Requests distributed across the node fleet with caching in front; no single node is a point of failure, and frequently accessed data is served without re-querying the chain.
03

RPC endpoint layer

High-performance, customized JSON-RPC and WebSocket endpoints exposed to consumers with one-line integration; chain-specific method quirks validated before production.
04

Monitoring & observability

Proteus Shield instruments every deployment with request volumes, error rates, latency percentiles, and per-endpoint demand - readable from the first request.
05

SLA operations

Incident response and uptime management at Standard, Full-time, or Extended coverage; one team accountable for uptime rather than a status page you check after it has already failed.
01

What RPC node hosting is

What RPC node hosting is, and what an RPC endpoint actually does

An RPC node is a blockchain node that exposes the chain's data and transaction-submission methods over a Remote Procedure Call API, typically JSON-RPC over HTTPS or WebSocket. The RPC endpoint it serves is the front door every developer walks through: it is where a wallet reads a balance, a dApp queries contract state, and a backend broadcasts a signed transaction.

If the endpoint is slow, rate-limited, or down, every application on top of it degrades at the same time. Managed RPC node hosting is the discipline of running those endpoints and the nodes underneath them as a service: provisioning the right node types, putting load balancing and caching in front, and monitoring the whole path so it stays fast under real demand.

The work is operational, not one-off: accessible APIs, community feedback loops, and continuous tuning, with one team accountable for the endpoint developers actually call.

What types of nodes does Protofire operate?

A full node stores current state and recent blocks and independently validates transactions against consensus rules, but prunes older history to save disk. An archive node keeps the entire historical state of the chain, so it can answer queries about a balance or contract storage at any past block.

It needs far more storage and is what most indexers, explorers, and analytics tools depend on. A light node keeps only headers and verifies on demand. We deploy and operate all three, sized to what your RPC consumers actually query, and put high-performance, customized RPC endpoints in front of them with load balancing, caching, and one-line integration, so consumers can swap to your endpoint without touching their stack.

Running an archive node well is its own engineering problem (we wrote up how in "Tame the Behemoth: how to run an archive blockchain node"); we treat node type, sync strategy, and storage as deliberate choices, not defaults.

How does Protofire monitor and guarantee RPC uptime?

Reliability you cannot measure is luck. We instrument every RPC deployment with monitoring, observability, and usage analytics from day one (request volumes, error rates, latency percentiles, and per-endpoint demand), so capacity and cost decisions are driven by data instead of guesswork.

We run our own internal tooling for this: Proteus Shield for usage analytics, billing, caching, and monitoring. The three metrics we manage against are the ones that matter for an endpoint: number of users, infrastructure cost, and uptime. Engagements run as an SLA-oriented operations partnership at the coverage level you need: Standard, Full-time, or Extended coverage and user support, with prompt support on demand.

You get a stable, robust set of APIs to share with your users, customized curated environments that are continuously improved, and a dedicated team accountable for the endpoint rather than a status page you check after it has already failed.

Who is RPC node hosting for?

This is for EVM L1/L2 chains and ecosystem foundations that want a professionalized public RPC as an ecosystem primitive; for protocols that need dedicated, reliable endpoints instead of a shared gateway; and for teams whose developers are complaining about RPC quality or rate limits. The common trigger is traffic: a mainnet launch, a usage spike, or an ecosystem campaign that turns "good enough" RPC into a strategic liability.

If you only need a node for a test environment with no real traffic, self-hosting is fine. Once uptime, latency, and developer experience become things you are judged on, managed hosting earns its keep. RPC and nodes are one slice of a network's operational layer. For validators, block explorers, indexing, and subgraphs, this RPC page routes up to our node infrastructure hub and the dedicated validators page.

02

How we operate your RPC

1

RPC-readiness review

We map your throughput and reliability targets, expected query mix (state reads vs historical/archive queries), and network/client requirements. Deliverable: an RPC-readiness review.
2

Architecture & provisioning

We choose node types (full / light / archive), sync strategy, and topology, and stand up the endpoints behind load balancing and caching.
3

Integration & bootstrapping

We validate client and network-specific quirks (JSON-RPC methods, WebSocket subscriptions, DNS, rate-limit policy) and bring the endpoint into production with one-line integration for consumers.
4

Monitoring configuration

We wire up observability and usage analytics so reliability is measurable from the first request.
5

Operate, support & tune

Ongoing maintenance, incident response, and SLA-oriented operations at your chosen coverage tier.
03

What teams come to us for

Managed public and dedicated RPC endpoints
Full, light, and archive node operation
Archive-node hosting for indexers, explorers, and analytics
Load balancing, caching, and rate-limit policy
RPC monitoring, observability & usage analytics
SLA-oriented uptime and incident response
One-line endpoint integration for consumers
Ecosystem-primitive RPC for chains and foundations
04

The team behind Filecoin's RPC

Protofire is a blockchain infrastructure and development company that has shipped 250+ projects since 2016, across 60+ networks and 95+ protocols. On infrastructure specifically: we are a Filecoin infrastructure partner since 2021 (our Glif RPC work was praised as a #1 project in Filecoin's Retro-PGF round), a top-3 indexer in The Graph ecosystem, an official Safe Guardian, and the maintainer of Solhint, the open-source Solidity linter used by 1M+ developers.

We operate RPC and node fleets across dozens of networks and run Proteus Shield, our own productized tooling for RPC analytics and monitoring that most node-hosting providers simply do not have. The proof is operational: 99.95%+ RPC uptime and a 240% jump in developer usage for Filecoin, plus a rebuilt Gnosis explorer holding 99.99% uptime across 300,000+ validated addresses. When we run an endpoint, it is one we already operate in production.

05

A real engagement: Filecoin's Glif RPC

When Filecoin, a network now handling 4+ billion node requests a month, needed its public RPC to keep pace with developer demand, the bottleneck was operational: inconsistent uptime, slow retrieval, and thin tooling. We optimized the node stack, built the Glif Nodes RPC API services that let dApps talk to Filecoin nodes, and deployed monitoring across the path.

The outcome was measured, not promised: uptime reached 99.95%+ across Glif-managed RPC endpoints, against the ~97-98% baseline typical of decentralized environments; retrieval latency dropped from 3-5 seconds on a standard Lotus node to under 800ms for frequently accessed content via optimized gateway layers; and monthly active developer calls grew +240%, reaching over 30,000 developers/month. We ship the infrastructure-as-code for it openly (the `glifio/filecoin-iac` and `glifio/filecoin-chart` repositories), and the work was recognized as a #1 project in Filecoin's Retro-PGF grant.

“Running RPC well is a mindset, not a server: accessible APIs, community feedback loops, and continuous tuning.”

Managed RPC in production
99.95% uptimeGlif RPC - public endpoint for a 4B+ req/month network

Optimized the Filecoin node stack and built Glif Nodes RPC API services, lifting uptime to 99.95%+ and growing monthly active developer calls by 240%.

FilecoinView project →

RPC infrastructure model

Self-hostProtofire managed RPC
Uptime guaranteeBest effort99.95%+ SLA-oriented operations
Load balancing & cachingYou provision and manageBuilt-in, monitored, tuned by Proteus Shield
Monitoring & analyticsManual tooling or custom buildProteus Shield observability, usage analytics, cost tracking from day one
Node type managementFull/light/archive decisions yours to optimizeSized to your query mix, replicated and load-balanced
Team overheadYour core team babysits infrastructureManaged service, your team stays on protocol work

FAQ

What is an RPC node?
An RPC node is a blockchain node that exposes a chain's data and transaction-submission methods over a Remote Procedure Call API, typically JSON-RPC over HTTPS or WebSocket. It is the endpoint that wallets, dApps, and backends call to read on-chain state and broadcast transactions: effectively the front door developers use to talk to a network. If that endpoint is slow, rate-limited, or down, every application built on top of it degrades at the same time. To stay fast and reliable under real traffic, a public RPC endpoint has to be load-balanced, cached, and monitored, and the node behind it has to be the right type (full, light, or archive) for the queries it serves. That operational layer is the difference between simply running a node and hosting RPC as a managed service, with one team accountable for request volumes, error rates, latency, and uptime.
What's the difference between a full node and an archive node?
A full node stores the current state and recent blocks, independently validates transactions against the network's consensus rules, and serves data to applications, but it prunes older historical state to save disk. An archive node is a full node that keeps the chain's entire historical state, so it can answer queries about a balance or contract storage at any past block. Archive nodes need far more storage and are what most indexers, explorers, and analytics tools depend on, since those workloads constantly read historical data. A light node keeps only block headers and verifies on demand. We deploy and operate all three, size each to the queries your RPC consumers make, and put load balancing and caching in front of them. Running an archive node well is its own engineering problem; we documented our approach in "Tame the Behemoth: how to run an archive blockchain node."
Should we use managed RPC nodes or self-host?
You can run your own nodes, but running them reliably under real traffic, with load balancing, caching, usage analytics, and SLA-style incident response, is a different capability than simply starting a node. Managed RPC hosting makes sense once uptime and latency become strategic, when there is real developer or user traffic to justify it, or when you would rather your core team stay focused on the protocol. If you only need a node for a test environment with no real traffic, self-hosting is fine. We instrument every deployment with monitoring from day one and manage to the three metrics that matter for an endpoint (number of users, infrastructure cost, and uptime), running Proteus Shield for usage analytics, billing, caching, and monitoring. The result is a stable set of APIs to share with your users, without you staffing a full SRE function around your endpoints.
Which networks and node types do you support?
EVM L1/L2 chains and ecosystem foundations are our core. We deploy and operate full, light, and archive nodes and the high-performance, customized RPC endpoints in front of them, with load balancing, caching, and one-line integration so consumers can swap to your endpoint without touching their stack. We run production infrastructure across dozens of networks, including the Glif RPC layer for Filecoin (a network handling 4+ billion node requests a month), where we hold 99.95%+ uptime. Before any rollout we validate client- and network-specific RPC requirements, so chain-specific JSON-RPC methods, WebSocket subscriptions, and quirks are handled in advance rather than discovered in production. Archive-node hosting in particular underpins the indexers, explorers, and analytics tools that query historical state. Where a network has unusual execution characteristics, we treat node type, sync strategy, and storage as deliberate engineering choices rather than defaults.
How long does it take to get an RPC endpoint live?
After the RPC-readiness assessment (where we map your throughput and reliability targets, expected query mix, and network and client requirements), a standard full-node-backed endpoint can go live quickly. An archive node takes longer, because it must sync the chain's full history before it can serve historical queries, and that sync time scales with the size of the chain. The work that follows assessment is architecture and node provisioning, integration and bootstrapping (validating JSON-RPC methods, WebSocket subscriptions, DNS, and rate-limit policy), monitoring configuration, then ongoing operation at your chosen coverage tier. We confirm the exact timeline against your node types, target network, and coverage level (Standard, Full-time, or Extended) on the first call, rather than quoting a generic number. Because we instrument observability from the first request, the endpoint is measurable for reliability as soon as it is live.
We're a chain or foundation. Can you run our public RPC as an ecosystem primitive?
Yes, this is a primary use case. We operate public and dedicated RPC endpoints as a managed ecosystem primitive for chains and foundations, so builders get reliable, well-documented endpoints and you close the tooling gap against competitor chains, without diverting your team from core protocol work. Running RPC as an ecosystem primitive is a whole mindset of providing accessible RPC and API to the community, gathering their feedback, and continuously improving the service under real traffic. We did exactly this for Filecoin's Glif RPC: optimizing the node stack, building the Glif Nodes RPC API services, and deploying monitoring across the path lifted uptime to 99.95%+ and grew monthly active developer calls by 240%. It runs as a dedicated, SLA-oriented operations partnership at Standard, Full-time, or Extended coverage, with the infrastructure-as-code shipped openly in the glifio repositories.

Reviewed by Arsenii Petrovich, Infrastructure & DevOps Lead at Protofire. Last reviewed: June 2026.

Book a call with Arsenii Petrovich

Schedule a call with our CTO to receive practical recommendations and a prompt proposal for upgrading your solution.

Protofire 2026. All rights reserved