eth_getBalance如何查历史余额？ 图 1
eth_getBalance如何查历史余额？ · 图 1

eth_getBalance 返回指定地址在某个区块状态下的原生币余额，结果是以 Wei 表示的十六进制整数。重建历史余额必须固定区块号，并使用能读取该历史状态的节点。

请求固定高度的余额

    {"jsonrpc":"2.0","id":21,"method":"eth_getBalance","params":["0xde0B295669a9FD93d5F28D9Ec85E40f4cb697BAe","0x12D687"]}

假设返回 {"result":"0xde0b6b3a7640000"}，十六进制转十进制是 1000000000000000000 Wei，再除以 10^18 得 1 ETH。程序中使用 bigint 或十进制定点库，不能用 JavaScript Number 承载大额余额。

latest 与历史快照不同

latest 会随新区块变化，适合当前余额；审计报告应保存 block number、block hash、chainId、节点端点和原始 result。远古区块若报 missing trie node 或供应商限制，说明需要 archive 能力，不应把失败解释成余额为零。还可先请求区块哈希，确保第二次查询仍处于预期分叉。

这不是 ERC-20 查询

eth_getBalance 只查询账户原生币。ERC-20 要对 token 合约调用 balanceOf，并读取 decimals 做换算；代理或重基代币还可能需要额外解释。同一地址的 ETH 和 USDC 不能用一个 RPC 方法混算。

余额差异排查还要区分区块执行前后的状态。eth_getBalance 的区块参数指向该区块执行后的状态；若要解释某笔交易造成的变化，应比较相邻区块并结合交易回执、内部调用和费用支出。仅用一条 transfer 事件无法重建原生币全部变化。

eth_getBalance：当前证据的停止位置

不同RPC的链头、裁剪和负载均衡可能产生时点差异，比较余额时必须固定区块哈希或编号。

eth_getBalance：一手资料能确认的三件事

  1. eth_getBalance按地址和区块参数返回原生ETH余额，结果是十六进制Wei数量。
  2. 换算展示值应保留原始整数并按10的18次方换算；该接口不返回ERC-20、NFT或其他合约内部余额。
  3. latest余额随新区块变化，历史余额依赖archive能力或节点保留状态；读取成功也不证明地址私钥可用或资金可花费。（有限确认）

eth_getBalance：把搜索问题拆成四层

  • 要问：请求与十六进制是否与当前环境一致？ 验收目标：用请求与十六进制直接回答搜索意图并形成可执行核验信息。
  • 要问：Wei换算表是否与当前环境一致？ 验收目标：用Wei换算表直接回答搜索意图并形成可执行核验信息。
  • 要问：原生币与代币边界是否与当前环境一致？ 验收目标：用原生币与代币边界直接回答搜索意图并形成可执行核验信息。
  • 要问：历史查询能力是否与当前环境一致？ 验收目标：用历史查询能力直接回答搜索意图并形成可执行核验信息。

eth_getBalance最容易出现的误判

不能因为请求与十六进制看起来正常，就省略Wei换算表和原生币与代币边界。界面成功、请求被接收和业务完成是三种状态，各自需要证据。

eth_getBalance的证据出处

与eth_getBalance直接相邻的站内主题

执行eth_getBalance相关操作前，应重新打开对应版本的原始资料。