HostHostDeFi › Library › What is an RPC endpoint
What is an RPC endpoint?
Every balance your wallet shows, every quote a DEX returns, every transaction you broadcast — all of it goes through an RPC endpoint: a server that holds a synced copy of the chain and answers questions about it. This is the map of what that layer is and when the choice of endpoint actually matters.
RPC stands for remote procedure call — your software calls a function (getBalance, eth_call, sendTransaction) and a machine somewhere else executes it. That machine is a node: a server running the chain's client software, keeping a synced copy of the ledger, and exposing a JSON-RPC interface over HTTPS. The endpoint is simply its URL. When you see https://... in a wallet's network settings, that string is the entire relationship: whoever operates it reads your requests and decides what answers you get.
The mental model that matters: your wallet holds keys, not the chain. The blockchain is far too large and too live for a phone to keep locally, so every wallet delegates its view to an endpoint. Pressing "check balance" is a remote call. Signing happens on your device — the endpoint never sees your private key — but everything you are shown before you sign came through that one pipe.
What an endpoint actually does for you
Three jobs, in order of how often you use them:
Reads. Balances, token holdings, contract state, transaction history, the current slot or block height. Every screen in every crypto app is a bundle of reads resolved by an endpoint.
Simulation. Before a wallet sends your swap or approval, it typically asks the endpoint to dry-run the transaction against current state — what would this do, what would it cost, would it fail. The preview you skim is the endpoint's answer.
Broadcast. When you sign, the wallet hands the raw transaction to the endpoint, which gossips it into the network's mempool or leader pipeline. "Transaction sent" means one endpoint accepted it — propagation to a validator is a separate hop you never see.
Free endpoints vs paid lanes
Every chain has public keyless endpoints — servers run by foundations, infrastructure companies, or community operators that answer anyone. They are how the ecosystem onboards, and they share one honest property: no one promised you anything. Rate limits, throttling under load, and occasional silence are the deal's other half.
| Public / keyless | Keyed or paid lane | |
|---|---|---|
| Throughput | Shared quota — rate limits kick in fast | Dedicated budget sized to your traffic |
| Latency | Whatever the crowd leaves you | Consistent under load — the point of paying |
| Availability | Best effort; outages are silent | A commitment someone is accountable for |
| Data depth | Recent state, standard methods | Archive reads, priority landing, heavier calls |
| Who it suits | A person clicking in a wallet | Bots, backends, agents, anything production |
HostDeFi runs a public read relay of exactly this kind: one URL shape, dozens of chains, JSON-RPC reads answered from a ladder of keyless upstreams — the /rpc lane index lists every network it covers, and per-chain pages like /rpc/solana/ show the live upstream ladder each read falls back across. For machine-payed traffic the same surface exposes x402 lanes — paid reads where the 402 response carries the price and settlement rides the request itself. Free tier for humans, paid lane for things that cannot afford a silent stall.
The part nobody puts on the landing page: an endpoint is a trusted lens, not a neutral mirror. It sees every address you query and decides what to show you. Honest endpoints return the chain as it is; a dishonest one returns a chain that exists only for you.
Where endpoints fail — and where they lie
Failures are boring and visible: timeouts, HTTP 429 when you exceed the free quota, stale reads while the node resyncs. Your transaction is not broken — the lens is fogged. Retry, or ask a different endpoint.
Lies are the interesting failure. An endpoint controls two things you cannot see from the client: what it reports and what it forwards. A malicious operator can fabricate contract state so a scam token reads as liquid, delay or drop your transactions selectively, or simply log every address you look up and sell the reconnaissance. You cannot detect this from inside the relationship — the standard defense is cross-checking: the same read against an independent endpoint must return the same state. Mismatch means one of them is lying or broken, and either way you do not sign on that answer.
This is why "paste this RPC URL" posts are an attack surface. A wallet pointed at a hostile endpoint sees a parallel universe — our guide on reading an EVM transaction shows how to verify what actually moved rather than what a UI claims.
How to choose an endpoint for real work
For reading and browsing: any reputable public endpoint, and your wallet's default is usually already that. For a bot, a backend, or an agent: you need your own lane — a keyed tier from an established provider, a paid plan with a stated limit, or a relay like ours where the contract is a request and a price, not a signup. The decision rule is honest: if a silent stall or a rate limit costs you money, the endpoint is infrastructure — treat it like it.
And whatever you run, verify it behaves before you depend on it: our /networks index shows which chains we operate validators, nodes and relay lanes on, with live status probes — an endpoint operator who also runs on-chain infrastructure is holding itself to a standard you can check.
See a read happen
An RPC call is just HTTPS. This asks our relay for Solana's current slot — the same call every wallet makes constantly:
curl -X POST https://hostdefi.com/api/rpc/solana \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"getSlot"}'
Frequently asked
What is an RPC endpoint in crypto?
An RPC endpoint is the address of a node server your wallet or app talks to when it needs to read the blockchain or send a transaction. RPC stands for remote procedure call — a request like getBalance or eth_call answered by a machine that holds a synced copy of the chain. Your wallet never stores the chain itself; every balance and quote it shows came from an RPC endpoint.
Are free RPC endpoints safe to use?
A reputable free endpoint is safe for reads — balances, quotes, history. The risks are availability (rate limits, throttling at busy times) and honesty (a malicious endpoint can lie about chain state or snoop on your queries). For anything you sign, use an endpoint you trust; for high-throughput or production traffic, paid tiers exist precisely because free lanes make no promise about either.
Can a malicious RPC endpoint steal my crypto?
An endpoint cannot take your keys — signing happens locally in your wallet. What it can do is lie: show a fake balance, return doctored contract state, censor your transaction, or log which addresses you look up. The damage comes when you act on false state — buying a token whose "liquidity" the endpoint fabricated, or signing a transaction built on invented contract data. Verify against a second independent endpoint when the answer decides a trade.
What is the difference between a public and a private RPC endpoint?
A public endpoint is shared infrastructure — keyless, rate-limited, first-come-first-served, with no uptime promise. A private (keyed or paid) endpoint gives you a dedicated lane: higher throughput, a service commitment, and usually archive or priority reads. If you are a person clicking swap in a wallet, public is usually fine; if you are a bot, a backend, or anything latency-sensitive, you need your own lane.
How do I add a custom RPC endpoint to my wallet?
EVM wallets like MetaMask let you add a network with a custom RPC URL under network settings — paste the HTTPS endpoint and the correct chain ID. On Solana, some wallets expose a cluster/endpoint picker; many apps hardcode their provider. Only add endpoints from sources you trust — a hostile endpoint is a man in the middle for everything you read through it.
What does it mean when a transaction says RPC error or timeout?
Usually the endpoint is rate-limiting or overloaded, not that your transaction is invalid. Free endpoints shed load first — under congestion you get timeouts, stale reads, or dropped requests. Retrying on a different endpoint is the normal fix; a transaction that was broadcast is on the chain regardless of what one endpoint reports.