Field guide 06 · Checking the network
Who checks the balance your wallet shows you?
Many wallets ask a remote server for blockchain data. A light client can check selected answers against cryptographic evidence without downloading and executing the entire chain. The useful question is exactly which answer was verified, at which block, and under which assumptions.
An answer becomes checkable when the pieces connect
01
A clear display can still be someone else’s answer
When you open a wallet, it may request a balance from a remote node through an interface called RPC. The response can be fast and useful, but an ordinary response is still information supplied by that server. Attractive formatting does not make it independently checked.
A light client downloads less information than a full node and uses cryptographic evidence to check selected claims. It does not reproduce every job of a full node. The goal is to make a particular answer checkable while keeping the device’s resource requirements smaller.
For the reader, the key distinction is between “the server returned this number” and “my software verified this number against a sufficiently trusted chain reference.” Both may appear as the same balance on screen.
Source notes: Ethereum.org · light / Ethereum Improvement Proposals · 1186
02
A proof needs a trustworthy reference point
Ethereum’s state is summarized by a cryptographic value called a state root. A Merkle proof supplies a path that can connect an account or storage value to that root. If the data does not fit the root, the verification fails.
But a dishonest source could supply both an invented value and a matching invented root. You therefore need a justified way to obtain the root for the intended chain. Checking a proof without checking its reference point only solves part of the problem.
EIP-1186 describes the eth_getProof method for obtaining account and storage proofs. Helios is one implementation that combines light-client verification with access to remote execution data. Its documentation identifies a weak subjectivity checkpoint as a root of trust: a recent chain reference used to get started. A malicious checkpoint can lead the client to the wrong chain.
Source notes: Ethereum Improvement Proposals · 1186 / a16z crypto / Helios contributors · helios
03
Native coin balances and token balances take different paths
An Ethereum account record includes its native ETH balance. ERC-20 is a common interface used by Ethereum tokens. A token balance under that interface belongs to the token contract’s state and logic. A proof about your account’s ETH balance does not also prove the number shown for every token in your portfolio.
Verifying a token balance can require authenticating the relevant contract data and interpreting or executing its balance logic. Storage layouts differ, some contract addresses route requests to replaceable code, and not every value appears as a straightforward balance entry. Do not assume a wallet verifies every contract call because it supports one account-proof method.
The displayed value in dollars or another ordinary currency adds a separate dependency. Even if the token quantity has been checked, multiplying it by a market price does not verify that price, the token’s liquidity or what you could sell it for. A verified quantity and an estimated valuation should remain distinguishable.
Source notes: Ethereum Improvement Proposals · 1186 / Ethereum Improvement Proposals · erc20
04
A correct old answer can still be the wrong answer for today
Verification is tied to a particular chain state. A proof may accurately describe a balance at an older block while omitting a later payment. That makes the block reference and the client’s synchronization status useful parts of the result.
Ask whether the display uses the newest reported block or one with stronger confirmation assurances, how the client handles stale information, and whether an unavailable proof causes an error or a fallback to unverified data. Exact behavior depends on the implementation and network. A silent fallback can change the meaning of the screen without changing its appearance.
Light-client verification also relies on assumptions about how the network agrees on its history and on the client’s implementation. It should be described with those assumptions, not as a magic removal of trust. Keeping the software current and understanding its checkpoint source remain part of using it.
Source notes: Ethereum Improvement Proposals · 1186 / a16z crypto / Helios contributors · helios / Ethereum.org · light
05
Verified data does not make every label true
The owner name attached to an address, a scam warning, a token logo and a price chart may come from separate databases. A cryptographic check on chain data does not validate those editorial labels. Nor does it establish that a recipient is the person you intended to pay.
A remote provider can also fail to respond. Detecting a false answer and obtaining any answer are different capabilities. Verification helps with integrity; availability still needs a working data path, and privacy still depends on what requests the provider can observe.
Look for a wallet or client that explains the boundaries in terms you can inspect: verified method, block reference, checkpoint source and fallback behavior. You do not need to memorize the proof format to ask those four questions.
Source notes: Ethereum.org · light / a16z crypto / Helios contributors · helios / Ethereum Improvement Proposals · 1186
Worked example · fictional
The balance is verified. Is the dollar amount?
A fictional wallet verifies that an account holds 2 ETH at a particular block. Its interface separately obtains a hypothetical price of $3,000 per ETH and displays $6,000.
The multiplication is correct: 2 × $3,000 = $6,000. The account proof supports the 2 ETH quantity at that block, not the price feed or a promise that a sale would realize $6,000.
If the account later sends 0.5 ETH, the earlier proof can remain valid for the earlier block while being out of date for the current balance. “Valid proof” and “current answer” need separate checks.
| Displayed information | What supports it | What a balance proof does not establish |
|---|---|---|
| Native coin quantity | Account state at a block | A later balance or recipient identity |
| ERC-20 quantity | The token contract’s relevant state and logic | Universal token-method verification |
| Dollar estimate | Quantity multiplied by a price input | That the input price is reliable or realizable |
| Address label | A separate identification source | Ownership or attribution merely from a proof |
Use what you learned
What to check
- Find out which RPC responses are actually verified.
- Check the network, block reference and freshness of the result.
- Identify the checkpoint source and behavior when verification is unavailable.
- Treat currency prices and address labels according to their own evidence.
Why this may matter for years
More lightweight verification could make remote wallet data easier to check. Readers will still need to distinguish verified balances from prices, labels and other information supplied by services.
This is an editorial judgment about lasting usefulness, not measured search demand or a forecast of adoption.
Evidence and scope
These primary sources were retrieved and saved with content hashes. Specifications describe mechanisms; provider documentation describes a particular implementation. Neither is a certification of a product. The examples and checklists apply those mechanisms to fictional situations and practical questions.
Primary-source comparison completed by a separate automated reviewer on 2026-10-02. This is AI-authored content with automated verification; no human or expert approval is claimed.
- Light clients ↗
Ethereum.org · How do light clients work?; Light clients and the execution layer
Verification with reduced data and remaining consensus assumptions; not full re-execution.
Retrieval details
2026-10-02T21:37:36.811771+00:00 · HTTP 200
SHA-256 6e341dcc3d334d87d69640dd9f2fa7adba990f36777a7ef21a7de0bb8419035f
- EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof ↗
Ethereum Improvement Proposals · Abstract; eth_getProof; Returns
Account and storage proofs relative to a state root. Proposal status is distinct from method support in a client.
Retrieval details
2026-10-02T21:37:36.700685+00:00 · HTTP 200
SHA-256 bcd9a26e1825e07d795da6b103c5178cc9e560a3b4d8b92214b23a1e4680931e
- Helios README ↗
a16z crypto / Helios contributors · Overview; Checkpoints; RPC endpoints
One implementation's verification model and checkpoint requirements; not a certification or feature claim about every wallet.
Retrieval details
2026-10-02T21:37:36.916195+00:00 · HTTP 200
SHA-256 bf5aedeac1b5ddb1124ff0ba42d3d3191d29cf715880fad9361d29db473512c8
- ERC-20: Token Standard ↗
Ethereum Improvement Proposals · approve, allowance and transferFrom
The token allowance interface, separate from account delegation.
Retrieval details
2026-10-02T21:37:35.905459+00:00 · HTTP 200
SHA-256 98bda5e4707841a68684879878c4c165fdaa47d89ed69ebf232ab9be06ff050e