先确认要查哪种资料
“垃圾代币”是描述性称呼，不对应统一的合约接口或记录格式。查询前应确定所在网络、合约地址，以及要核对的字段。同名或同符号不足以确认是同一个代币。本文讨论以太坊及采用相应接口的场景，其他链需要核对其查询机制。
名称、符号、小数位属于 ERC-20 元数据接口涉及的信息；网页简介、图标、社交链接则未必存储在合约中。展示内容发生变化时，应先查清该字段的数据来源，才能确定去哪里寻找历史记录。
合约元数据能查到什么
OpenZeppelin 的 ERC-20 文档将 name、symbol、decimals 列为元数据扩展接口。其所述基础实现中，名称和符号在构造时设置，没有提供后续修改它们的公开接口。具体代币可能采用自定义实现，是否可改必须结合实际合约判断。
因此，页面名称变化并不能直接证明合约名称被修改；基础实现的行为也不能推广到所有代币。核查重点是同一地址在不同时间对应的实际返回值，以及展示端是否使用这些返回值。
怎样核对历史状态
以太坊 JSON-RPC 文档说明，eth_call、eth_getStorageAt、eth_getCode 等查询支持区块参数，可指定查询所对应的区块高度；交易、回执和区块查询则提供历史核对线索。
理解这些接口后，可以把查询分成两步：先比较目标字段在不同区块的状态，确认是否存在差异；再结合相关交易与回执缩小变化发生的范围。历史查询还取决于节点是否保留并提供所需数据，接口报错不能直接解释为字段从未改变。
两次读取结果不同，只能先说明两个区块对应的状态存在差异。要形成完整更新记录，还需进一步核实中间变化，不能把两个时间点的对比当成全部历史。
展示资料与常见查询误区
若目标是网站简介或图标，应核实展示平台是否公开版本记录、修改时间或历史快照。上述合约接口并未提供这些网页字段的通用编辑历史；缺少历史证据时，只能确认当前展示内容，不能补写此前版本。
转账日志也不能代替资料更新记录。Transfer 和 Approval 分别涉及代币转移与授权，并不是统一的元数据修改事件。没有找到专门的更新事件，仍需结合合约实现与历史状态判断。
整理查询结果时，可记录网络、合约地址、字段、区块高度、读取值和相关交易哈希。将已确认的状态差异与尚未核实的修改原因分开，才能让记录便于复核。