{
  "slug": "light-client-verify-wallet-balance",
  "title": "Who checks the balance your wallet shows you?",
  "searchTitle": "Light clients and wallet balances: verifying RPC responses",
  "category": "Checking the network",
  "accent": "#a8c78c",
  "diagram": "proof",
  "summary": "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.",
  "why": "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.",
  "overlap": "The existing RPC and node entries explain where data comes from. This guide follows an account proof from a server to a verified state root, including checkpoints, freshness and unverified display elements.",
  "related": [
    "ethereum-nodes-rpc",
    "ethereum-rpc-privacy",
    "simplified-payment-verification"
  ],
  "sections": [
    {
      "id": "server",
      "heading": "A clear display can still be someone else’s answer",
      "sourceIds": [
        "light",
        "1186"
      ],
      "paragraphs": [
        "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."
      ]
    },
    {
      "id": "proof",
      "heading": "A proof needs a trustworthy reference point",
      "sourceIds": [
        "1186",
        "helios"
      ],
      "paragraphs": [
        "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."
      ]
    },
    {
      "id": "balance",
      "heading": "Native coin balances and token balances take different paths",
      "sourceIds": [
        "1186",
        "erc20"
      ],
      "paragraphs": [
        "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."
      ]
    },
    {
      "id": "freshness",
      "heading": "A correct old answer can still be the wrong answer for today",
      "sourceIds": [
        "1186",
        "helios",
        "light"
      ],
      "paragraphs": [
        "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."
      ]
    },
    {
      "id": "limits",
      "heading": "Verified data does not make every label true",
      "sourceIds": [
        "light",
        "helios",
        "1186"
      ],
      "paragraphs": [
        "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."
      ]
    }
  ],
  "example": {
    "title": "The balance is verified. Is the dollar amount?",
    "paragraphs": [
      "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."
    ]
  },
  "table": {
    "headers": [
      "Displayed information",
      "What supports it",
      "What a balance proof does not establish"
    ],
    "rows": [
      [
        "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"
      ]
    ]
  },
  "checklist": [
    "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."
  ],
  "figure": {
    "title": "An answer becomes checkable when the pieces connect",
    "caption": "Conceptual account-proof verification. A matching proof is useful only when its reference root is justified for the intended chain.",
    "description": "A remote server supplies a balance and proof. A separately justified block header supplies the state root. Both enter a verification step, which returns a result scoped to a block."
  },
  "scopeDate": "2026-10-02",
  "authorship": "AI-authored for Degrees of Satoshi",
  "contentSha256": "440dce0bfb2f46489706a0007c734f110424a55415cdbc80c4a5421cebc50856",
  "status": "verified by separate automated source review",
  "sources": [
    {
      "id": "light",
      "title": "Light clients",
      "publisher": "Ethereum.org",
      "url": "https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/",
      "locator": "How do light clients work?; Light clients and the execution layer",
      "scope": "Verification with reduced data and remaining consensus assumptions; not full re-execution.",
      "retrieval": {
        "id": "light",
        "url": "https://ethereum.org/en/developers/docs/nodes-and-clients/light-clients/",
        "finalUrl": "https://ethereum.org/developers/docs/nodes-and-clients/light-clients/",
        "retrievedAt": "2026-10-02T21:37:36.811771+00:00",
        "httpStatus": 200,
        "status": "retrieved",
        "snapshot": "evidence/light.source",
        "sha256": "6e341dcc3d334d87d69640dd9f2fa7adba990f36777a7ef21a7de0bb8419035f",
        "text": "evidence/light.txt",
        "textSha256": "8d2dc61ebdeefb543c982643241361f934f8e5ee9e89923e3f27599e5d1fb14b"
      }
    },
    {
      "id": "1186",
      "title": "EIP-1186: RPC-Method to get Merkle Proofs - eth_getProof",
      "publisher": "Ethereum Improvement Proposals",
      "url": "https://eips.ethereum.org/EIPS/eip-1186",
      "locator": "Abstract; eth_getProof; Returns",
      "scope": "Account and storage proofs relative to a state root. Proposal status is distinct from method support in a client.",
      "retrieval": {
        "id": "1186",
        "url": "https://eips.ethereum.org/EIPS/eip-1186",
        "finalUrl": "https://eips.ethereum.org/EIPS/eip-1186",
        "retrievedAt": "2026-10-02T21:37:36.700685+00:00",
        "httpStatus": 200,
        "status": "retrieved",
        "snapshot": "evidence/1186.source",
        "sha256": "bcd9a26e1825e07d795da6b103c5178cc9e560a3b4d8b92214b23a1e4680931e",
        "text": "evidence/1186.txt",
        "textSha256": "6e76e5fbc153157fdd8a38dd4a3e5c2c2b633f0cd0e52c35c3b5da780cfb53b2"
      }
    },
    {
      "id": "helios",
      "title": "Helios README",
      "publisher": "a16z crypto / Helios contributors",
      "url": "https://raw.githubusercontent.com/a16z/helios/master/README.md",
      "locator": "Overview; Checkpoints; RPC endpoints",
      "scope": "One implementation's verification model and checkpoint requirements; not a certification or feature claim about every wallet.",
      "retrieval": {
        "id": "helios",
        "url": "https://raw.githubusercontent.com/a16z/helios/master/README.md",
        "finalUrl": "https://raw.githubusercontent.com/a16z/helios/master/README.md",
        "retrievedAt": "2026-10-02T21:37:36.916195+00:00",
        "httpStatus": 200,
        "status": "retrieved",
        "snapshot": "evidence/helios.source",
        "sha256": "bf5aedeac1b5ddb1124ff0ba42d3d3191d29cf715880fad9361d29db473512c8",
        "text": "evidence/helios.txt",
        "textSha256": "3300b55cf3b86f1d25270fb145251fc5449e4a2840f0666e9d4617c500d749c2"
      }
    },
    {
      "id": "erc20",
      "title": "ERC-20: Token Standard",
      "publisher": "Ethereum Improvement Proposals",
      "url": "https://eips.ethereum.org/EIPS/eip-20",
      "locator": "approve, allowance and transferFrom",
      "scope": "The token allowance interface, separate from account delegation.",
      "retrieval": {
        "id": "erc20",
        "url": "https://eips.ethereum.org/EIPS/eip-20",
        "finalUrl": "https://eips.ethereum.org/EIPS/eip-20",
        "retrievedAt": "2026-10-02T21:37:35.905459+00:00",
        "httpStatus": 200,
        "status": "retrieved",
        "snapshot": "evidence/erc20.source",
        "sha256": "98bda5e4707841a68684879878c4c165fdaa47d89ed69ebf232ab9be06ff050e",
        "text": "evidence/erc20.txt",
        "textSha256": "f8d11f24fa5eb68a9f5d50d07cd1cdf7b4a8809eb2b2245856957ee9bce040f8"
      }
    }
  ],
  "canonical": "https://degreesofsatoshi.com/guides/light-client-verify-wallet-balance/",
  "dates": {
    "published": "2026-10-02",
    "modified": "2026-10-02",
    "sourceScope": "2026-10-02",
    "verified": "2026-10-02T22:35:07.201Z"
  },
  "review": {
    "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.",
    "reviewer": "Separate automated AI source-review agent /root/review_six_guides",
    "checkedAt": "2026-10-02T22:35:07.201Z",
    "contentSha256": "440dce0bfb2f46489706a0007c734f110424a55415cdbc80c4a5421cebc50856"
  }
}