學會用事件 topic、交易收據和區塊高度交叉核對，不把前端列表當成唯一事實。
事件不是合約儲存
Solidity 的 event 會寫入交易收據中的 logs，供索引器和應用程式快速查詢；它不等同於合約 storage，也不會改變狀態變數的讀取方式。事件通常包含簽名 topic、indexed 參數和 data。前端顯示的轉帳或鑄造列表，往往是第三方索引器整理後的結果，可能延遲或漏掉重組中的區塊。
先以交易收據為準
要核對一筆操作，先取得交易 hash、所在區塊和 receipt status，再看 logs 的 address 是否為預期合約。對 ERC-20 Transfer 事件，檢查 from、to、value 的解碼型別與 token 合約地址；不要只看代幣名稱或圖示。若交易失敗，事件通常不會被視為最終有效狀態，但索引服務可能暫時保留快取。
topic 的閱讀順序
事件第一個 topic 通常是事件簽名的雜湊；indexed 參數會各自佔一個 topic，未 indexed 的參數則位於 data。不同 ABI 或代理合約可能令解碼結果不同，所以要以已驗證原始碼和 ABI 為基準。複製地址時保留大小寫或使用檢查碼，避免把相似字串誤當成同一地址。
重組和確認數
區塊重組可能讓短時間內的 logs 從某個高度消失，索引器需要重新整理。高價值操作應等待足夠確認，再把事件納入對帳。跨鏈橋還要分別核對來源鏈鎖定事件、訊息傳遞和目的鏈鑄造事件，三段都完成才代表流程完整。
給海外讀者的實務做法
把 UTC 時間、區塊高度、交易 hash、合約地址和瀏覽器 URL 一起保存。若交易所或錢包的歷史紀錄與鏈上 logs 不同，先確認網路和代幣合約，再詢問官方支援；不要因客服訊息要求提供私鑰或遠端控制而妥協。
快速檢查
取得 receipt；比對 status、block number 和 logs address；按 ABI 解碼 topics/data；等待確認；把索引器結果與原始節點或可信瀏覽器交叉核對。
補充核對筆記
補充核對時，請把瀏覽器的解碼畫面與原始 receipt 一起下載保存。若事件參數是 indexed address，先確認零填充與大小寫，再比對合約的 ABI 版本。當索引器更新緩慢時，使用只讀 RPC 查詢同一區塊範圍，並記下節點、查詢時間和返回結果。這種可重現的記錄能幫助你分辨鏈上事實、介面快取和人工標註，對海外帳務或申訴都更可靠。