ERC-20 转账有 Transfer 事件可扫，ETH 转账却常年没有日志，合约钱包入金容易被索引工具漏掉。EIP-7708 提议让每笔带值的调用都自动生成一条与 ERC-20 同形的日志。本文按提案文本讲清它补什么洞、目前处于什么阶段，以及现在查 ETH 流水该靠什么。

区块头的布隆过滤器只会回答“肯定没有”和“可能有”，长区间查日志时几乎帮不上忙。EIP-7745 提议用一棵全局序号的索引树取而代之：假阳性恒定低、命中给出精确位置、还能带默克尔证明。本文按草案原文讲结构、对用户意味着什么、以及它还离落地多远。

解释交易回执（Receipt）与事件日志Logs的结构：状态、gas用量、合约地址、主题与数据区，说明区块浏览器代币转账列表如何由Transfer事件日志生成，并给出用Logs核对真实转账、识别合约噪声的实操方法。

ERC-2309 允许合约用一条 ConsecutiveTransfer 事件记录连续编号代币的批量铸造或转移，而不是逐个发 Transfer 事件。本文解释这条标准的字段规则、它省了什么成本，以及为什么只看 Transfer 事件的钱包和面板会漏掉这类代币。

交易回执的status=1只说明EVM顶层执行没有回滚，不代表用户业务一定达成。合约可能捕获内部失败、返回false、发出意外事件，或把资产送到错误对象；因此inclusion、execution与businessoutcome必须分层验收。能依据一手来源判断eth_g

以太坊事件日志把发出合约写在address，把事件签名和indexed参数放进topics，其余参数编码进data。本文用Transfer事件拆解字段，并说明eth_getLogs位置过滤、动态类型哈希与链重组处理。

以太坊交易哈希查到的交易对象描述用户提交了什么，交易回执则记录它在哪个区块执行、成功或失败、实际用了多少Gas以及产生了哪些事件。本文解释status、gasUsed、effectiveGasPrice、contractAddress和logs，并说明为何status为1仍不等于业务结果符合预期。