Connect the infrastructure your project needs
Dedicated nodes: choose a network and discuss your configuration. Current prices by network are on the product page.
A node provider is a company that runs blockchain nodes for you and gives your application access to them through an API endpoint, so your team does not install, sync and maintain node software itself. The same kind of service is also called a crypto node provider, an RPC provider or node-as-a-service.
What is a node provider?
A blockchain node is a server that runs the network's client software. It keeps a copy of the ledger, checks every new block against the protocol rules, answers queries about the chain and relays transactions to other nodes. An application cannot read a balance or submit a transaction without talking to a node, either its own or someone else's.
Applications talk to nodes through remote procedure calls (RPC). Bitcoin Core and Ethereum clients expose JSON-RPC: the application sends a method name such as getblockcount or eth_getBalance with its parameters and receives a JSON result. Some networks, Tron among them, expose their own HTTP APIs instead. For a closer look at the interface itself, see RPC nodes and blockchain endpoints.
A node provider takes over everything behind that interface: client software, disks, upgrades, monitoring and the capacity to serve requests. For standard JSON-RPC calls, moving from a local node to a provider usually means changing the URL and adding an API key to your requests.
A provider does not change how the network behaves. Finality, fees and the methods a client supports belong to the protocol and its client software: a provider can give access to them or restrict it, but not change them.
The other meaning: operators who host network hardware
In some networks the term means something else. On the Internet Computer, for example, node providers are independent operators who own and run the machines that host the network and are rewarded by the protocol for the work those machines do. This guide is about the more common meaning: a service that gives applications access to blockchain nodes.
Types of nodes a provider can run
Nodes differ in how much data they keep, and that decides which queries they can answer.
| Node type | What it keeps | Typical use |
|---|---|---|
| Full node | Validated blocks and the current state; older state may be pruned | Balances, fees, contract reads at the latest block, transaction broadcast |
| Archive node | Every historical state since the first block | Balances and contract state at a past block, analytics, indexing |
| Light client | Block headers; the rest is requested from full nodes | Verification on mobile and embedded devices |
| Validator or miner | What it needs to produce or attest blocks | Securing the network; usually not exposed to application traffic |
Choose the node type by the methods and history depth your product needs, not by the name of a plan. A wallet that shows current balances and broadcasts transactions works with full nodes. On Ethereum, a full node typically keeps state only for recent blocks, so a call against an older block fails without archive data. An analytics job that reads contract state at past blocks needs an archive node, or an index that recorded the state while the blocks were new. Archive access you never query is money spent on disks.
Running your own node vs using a provider
A node looks simple to run until it has to serve production traffic. The work that comes with it:
- Initial sync. A new node has to download and verify the chain before it can answer: from hours to weeks, depending on the network and the node type; archive nodes take longest.
- Storage that only grows. Archive nodes on large networks need terabytes of fast disk.
- Upgrades. Clients must be upgraded before a hard fork activates, or the node stops or follows the wrong chain.
- Lag. A node that falls behind still answers, but with an old latest block, so your application sees stale balances without any error.
- Heavy queries. Wide log ranges or traces can slow the node down or crash it.
- More than one node. Two nodes behind a load balancer can report different latest blocks, so consecutive requests seem to go back in time.
| Own node | Shared endpoint at a provider | Dedicated node at a provider | |
|---|---|---|---|
| Time to first request | Hours to weeks of sync | Minutes after sign-up | After the provider provisions the node |
| Sync, upgrades, monitoring | Your team | The provider | The provider, per its service terms |
| Capacity | What you buy and configure | A pool shared with other customers | A node that serves only you |
| Pricing model | Hardware, traffic and engineering time | Free tier, then plans by request volume | Fixed monthly price per node |
| Control over client and settings | Full | None | Limited to what the provider offers |
Your own node is justified when you need full control over the client, its version and its settings, or when your requirements forbid third-party infrastructure. Many teams end up with a mix of both; see self-hosted and managed infrastructure for how the pieces fit together.
Shared, dedicated and decentralized access
Once you decide to use a provider, the next choice is how your requests are served.
Shared endpoints
Many customers send requests to the same pool of nodes. This is how most providers offer free tiers and plans priced by volume, and it is the fastest way to start. The trade-off is neighbors: a traffic spike from another customer can raise your response times, and providers usually protect the pool with quotas.
Dedicated nodes
A node serves only your traffic. Response times no longer depend on other customers, and the price is usually a fixed monthly fee per node. Two things stay the same: provisioning a node takes time, and a single node can still fail, so you still need a fallback. See dedicated nodes.
Decentralized networks
Some services route requests through a gateway to independent node operators. This reduces your dependence on a single company. In exchange, response time and consistency depend on which operator answered a given request, and two consecutive calls may be served by nodes at different heights.
Who uses node providers
Wallets: balances, fees and broadcast
A wallet reads balances and history, estimates fees and submits transactions. Keys belong in the wallet or in a signing service, not at the provider: the transaction is signed locally, and only the signed payload goes to the node. At Settla, Bitcoin and Ethereum transactions are sent as signed hex, and a Bitcoin watch-only wallet is registered with an extended public key (zpub); that endpoint rejects private keys and seed phrases.
Exchanges and payment services: deposits and withdrawals
An exchange has to notice every deposit to thousands of addresses, count confirmations and send withdrawals on several networks. Polling every address spends requests on answers that have not changed; webhooks reverse the flow. At Settla a webhook sends a signed new_transaction event for Bitcoin, Ethereum and Tron addresses. On Ethereum it covers native ETH: an incoming ERC-20 payment such as USDT does not trigger it, so USDT deposits are tracked on Tron, where token transfers are decoded.
DeFi and dApps: contract reads and transactions
A dApp reads contract state with eth_call, estimates gas and submits signed transactions. It needs a provider that passes these standard methods through unchanged. The Settla Ethereum endpoint forwards standard JSON-RPC 2.0 requests to an Erigon node and returns the node's response as it is.
Explorers and analytics: indexing and history
Explorers and analytics tools read every block and store the result in their own database, because searching by address directly through node APIs is slow or impossible on most networks. Historical queries need archive state, or an index built while the blocks were new. The Settla Bitcoin explorer, Ethereum explorer and Tron explorer run on data from our own nodes.
How to choose a node provider
Most comparisons start with the number of networks and the price of the cheapest plan. Both matter less than whether the provider can serve your exact mix of requests, so go through these checks with a list of the methods your application calls.
Networks and environments
List every network you need, mainnet and testnet separately, including the ones you plan to add within a year. Then check each network against your list of methods: a provider can support a network and still lack the one method or testnet you depend on.
Methods, history and data format
Decide whether you need raw JSON-RPC, REST or indexed APIs such as token balances by address. Decide whether you need archive state, trace or debug methods. Ask about method allowlists, the maximum number of calls in a batch and the maximum block range for log queries: these limits can break an application long before raw throughput does.
Real-time data: WebSocket, webhooks or polling
If you react to new blocks or transactions, find out how the provider delivers them: WebSocket subscriptions, webhooks or polling only. For WebSocket, check the connection limit and what happens to a subscription when the connection drops. For webhooks, check retries and whether deliveries are signed.
Performance under your own load
Test with your own requests, from the region where your servers run. Measure p50 and p95 response time, the share of errors and how far the provider's latest block lags behind a reference source. Run the test long enough to include your peak hours. A published benchmark measures someone else's workload, not yours.
Limits and pricing units
Providers count usage in different units: requests per month, requests per second, compute units or credits, where a heavy method costs more than a light one. These units cannot be compared directly. The only fair comparison is your own traffic: take a month of requests broken down by method and work out what it would cost on each plan. Check separately what happens when you exceed the quota, and how archive access and WebSocket are priced.
Reliability, support and security
Read the history of the status page, not only the current status. An SLA counts only if it is written into your contract and states what you get when it is missed. Ask support a technical question before you sign up. For security, create separate keys for each environment, make sure you can rotate and disable keys yourself, and never send private keys to a provider.
If you are replacing a specific provider, our comparison of Infura, GetBlock and Tatum covers the usual reasons teams move.
What stays on your side
Moving nodes to a provider does not move every failure with them. Some things remain in your application no matter who runs the nodes:
- Set a timeout on every request and retry a limited number of times with a growing pause.
- After a timeout on a send, resend the same signed transaction instead of signing a new one: the first may already be in the mempool, and a second signature can become a second payment.
- Check the
errorfield of JSON-RPC responses even when the HTTP status is 200. - Confirm a broadcast by looking the transaction up, not by the response of the send call alone.
- Keep a second provider configured, and before switching reads to it, compare its latest block with the one you were using.
Settla: networks, access and plans
Supported networks
The shared Settla API covers Bitcoin, Ethereum and Tron. Dedicated nodes are available for Ethereum, Bitcoin, Tron and Solana, hosted in Europe. Solana is offered only as a dedicated node: there is no shared API for it. Every endpoint of the shared API talks to a mainnet node; there is no sandbox or testnet.
The network catalog lists more networks. Apart from the four above, they are available on request: nodes are set up for a specific project on terms agreed in advance.
Access and API keys
The API lives under https://settla.net/api/v1, with a prefix per network: /btc for a Bitcoin Core node, /eth for an Erigon node and /trx for a java-tron node together with our own Tron indexer. Requests carry an API key in the X-API-Key header. The key is 40 characters long and is shown once, when you create it. One key works for all three networks, and disabling a key in the dashboard takes effect on the next request.
Each network keeps its own interface:
- Bitcoin: JSON-RPC limited to read methods plus
sendrawtransactionandtestmempoolaccept. Wallet methods are rejected, and a batch holds up to 20 calls. - Ethereum: any valid JSON-RPC 2.0 request is forwarded to the node. The node holds no keys, so methods that need an account on the node, such as
eth_sendTransaction, fail; transactions are signed on your side. - Tron: REST endpoints for blocks, transactions, accounts and TRC20 balances. There is no JSON-RPC route.
Each network also has a health check, GET /api/v1/{coin}/health, that tells you whether the node behind the API is reachable. Official SDKs are available for PHP, Python, Go and Node.js, and the full API reference is published on docs.settla.net.
Shared plans
The Start plan is free: 100,000 requests a month and one API key. Paid plans are billed monthly or yearly; current prices and limits are on the pricing page. Usage is counted per key, so you can see which of your services sends what. Payment is currently accepted in cryptocurrency: BTC, ETH or USDT on Tron.
Dedicated nodes and node hosting
If you would rather rent a node than share one, Settla offers a dedicated Ethereum node, as well as dedicated nodes for Bitcoin, Tron and Solana. You order them in the dashboard, several at once if needed; after payment each node goes through a separate provisioning step. The dashboard then shows CPU and memory utilization, disk load and disk usage for each node, sampled every 15 minutes.
To decide whether you need a dedicated node, start from your own numbers: the dashboard shows each key's requests for the current month and a daily series for the last 31 days. Current prices are on the dedicated nodes page.
On this topic
A dedicated node under your traffic
Dedicated Ethereum, Bitcoin, Tron and Solana nodes hosted in Europe, with CPU, memory and disk monitoring in your dashboard.
See dedicated nodes