An RPC node is a computer running blockchain client software that exposes an API endpoint — on EVM chains, JSON-RPC over HTTPS — so applications can read chain state and submit already-signed transactions without hosting the blockchain themselves. Your wallet is one of those applications: it stores your keys, not the chain, so every balance it displays comes from an RPC node and every transaction you send is handed to one for broadcast. The node never sees your private key and cannot alter a signed transaction; the worst a bad endpoint can do is serve stale data, delay or censor a broadcast, or log your IP address next to the addresses you query. Most wallets manage this plumbing for you — WATS, for example, maintains and fails over RPC connections across Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, while signing stays on your own device, because WATS is non-custodial and never holds a key.
Your wallet doesn't store the blockchain
A blockchain is hundreds of gigabytes of history replicated across thousands of machines. Your wallet, obviously, holds none of that. What it holds is your keys — and a list of phone numbers for computers that do hold the chain. Every balance you see and every transaction you send passes through one of those computers. They are called RPC nodes, and they are the least-discussed dependency in your entire crypto setup.
What an RPC node actually is
RPC stands for remote procedure call — a plain request-response protocol. An RPC node is a machine running full blockchain node software that exposes an API endpoint (a URL) where clients can ask questions and submit transactions. On EVM chains the interface is standardized as JSON-RPC, with methods for reading balances (eth_getBalance), querying contracts (eth_call), estimating gas and broadcasting signed transactions (eth_sendRawTransaction). When people configure a "network" in a wallet, the RPC URL is the part that matters: it decides which machine answers on behalf of the chain.
What happens when you check a balance or hit send
Opening your wallet fires a volley of RPC reads: the native coin balance for your address, token balances via contract queries, current fee levels. Sending is the more instructive flow: the wallet builds the transaction, signs it locally with your key, and only then hands the signed bytes to the RPC node to broadcast into the network. The division of labor is absolute — the node never sees your private key and cannot alter what you signed, because any edit would break the signature and the network would reject it. It is a courier, not a co-signer. That is the technical heart of self-custody: signing happens on your device, and everything past the signature is public information anyway.
Public vs private endpoints — and what they see
Chains ship with public RPC endpoints, and infrastructure providers run faster, more reliable ones; wallets typically default to a curated mix. The differences that matter are reliability (public endpoints rate-limit and lag under load) and privacy: whichever endpoint you use can observe your IP address together with every address you query — a linkage worth understanding, since your on-chain addresses are otherwise pseudonymous. A malicious or compromised endpoint still cannot steal funds, but it can serve stale data, censor your broadcasts, or log your metadata. Choosing RPC infrastructure is thus a trust decision, just a much smaller one than choosing who holds keys.
Does the RPC node set my fee?
No — and this is a common misreading. The node reports fee conditions (base fee, priority fee suggestions, gas estimates) and relays your transaction, but the price is set by the network's fee market and by what you sign. A different endpoint can give you a better estimate, or get your transaction out faster when a congested one is timing out, but it does not make the chain cheaper. Which token the fee is settled in can be changed at the account layer, but that is a separate mechanism from the endpoint URL you point at.
One wallet, many dialects
The tidy eth_* method set is an EVM story. JSON-RPC itself is not EVM-exclusive — Solana exposes a JSON-RPC API of its own — but the vocabularies are not interchangeable: Solana talks in accounts, slots and compute units, and TON's client APIs are different again. A wallet that spans ecosystems — see what a multi-chain wallet is — must maintain healthy connections to every network it supports, in each network's dialect, with failover when an endpoint degrades. That invisible fleet management is a real part of what separates a smooth multi-chain wallet from a frustrating one.
When RPC breaks: wrong balances and stuck sends
Most "where did my crypto go?" panics are RPC weather. A lagging endpoint shows a stale balance; an overloaded one times out mid-broadcast; a dropped connection makes a healthy wallet look empty. The reassuring physics: your funds live on the chain, controlled by your keys — never inside the endpoint. Switching RPC (or letting the wallet fail over) fixes the view without touching the money. If a dApp connection is the thing misbehaving instead, that is a different layer — covered in connecting your wallet to a dApp safely.
Where WATS sits in this picture
WATS sits on the user's side of everything described above. It maintains and fails over the RPC connections for Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON, so there are no endpoint URLs to paste in per chain — while signing stays strictly local: WATS is non-custodial, you hold your keys, and WATS never holds one. The same applies across the four WATS products (Chrome Extension, Mobile App, Hot Wallet and the NFC Metal Card, which authenticates by tap rather than storing any key).
The one thing WATS changes above the RPC layer is which token pays. Where classic wallets make you keep a separate gas coin on every network before a broadcast will succeed, WATS lets network fees be paid in one token, ATS, via an ERC-4337 paymaster on EVM chains and LayerZero OFT for omnichain movement, so a single ATS balance works everywhere WATS reaches. That is not a discount — the network still charges what it charges; it only removes the need to stockpile a different gas coin for every chain you touch. Collected ATS is burned, taking supply from 100M down to a 30M floor, and WATS is the first and only wallet to combine ERC-4337 and OFT single-token fees with that burn.
The practical takeaway: RPC is infrastructure you should never have to think about, so pick a wallet that treats it that way. If you are tired of pasting endpoint URLs, guessing which network is lagging, and topping up a different gas coin for each chain, WATS is a reasonable place to start — the fee mechanics are documented in full on the ATS fee page.
Frequently asked questions
What is an RPC node in simple terms?
An RPC node is a server running blockchain client software that stays synced with the chain and its current state, and exposes an API endpoint — a URL — where applications can query chain data and submit signed transactions. Wallets, block explorers and dApps all talk to the chain through RPC nodes rather than storing hundreds of gigabytes of history themselves. On EVM chains the interface is standardized as JSON-RPC; Solana and TON expose their own equivalents.
Does an RPC node hold my crypto?
No. An RPC node is a read-and-relay service: it answers queries about the chain and broadcasts transactions you have already signed. Your funds are controlled by your private keys, which never leave your device in a self-custody wallet. If an RPC endpoint goes down or misbehaves, your assets are untouched — only your view of the chain is affected.
Can a malicious RPC endpoint steal my funds?
It cannot spend your funds, because it never has your keys and cannot modify a signed transaction without invalidating the signature. What a bad endpoint can do is lie about balances, delay or censor your broadcasts, and log your IP address alongside the addresses you query — a privacy leak rather than a theft risk. Using reputable, redundant endpoints (or a wallet that manages failover for you) addresses both.
Do I have to configure RPC endpoints myself?
In WATS you do not: WATS maintains the RPC connections for every chain it supports — Ethereum, Arbitrum, Optimism, Base, Polygon, BNB Chain, Solana and TON — and fails over automatically when an endpoint lags or rate-limits, so there is no per-chain URL to paste in. Signing still happens locally on your device, since WATS is non-custodial and never holds a key. Wallets that expose raw RPC settings let you point at your own node instead, which is useful if you run one for privacy.
Why does my wallet show a wrong or zero balance sometimes?
Almost always because the RPC endpoint it queried is lagging, rate-limited or briefly offline — the blockchain itself still records your balance correctly. Refreshing after a moment, switching endpoints, or letting the wallet fail over to another node restores the correct view. It is a display-layer problem, not a funds problem.
Does switching RPC endpoints make transactions cheaper?
No. The RPC node relays your transaction and reports fee conditions, but the price is set by the network's fee market and by the fee parameters you sign. A better endpoint can improve estimates and reliability during congestion, not the underlying cost. What can change is which token pays: WATS uses an ERC-4337 paymaster on EVM chains so network fees are settled in ATS instead of each chain's native gas token — a change of payment token, not a discount.