Ethereum取引は成功したのにトークンが届かない: 確認すること

Ethereumの取引が成功しただけでは、目的のERC-20トークンが目的の口座に届いたとは証明できません。 成功は、取引全体がリバートせずに完了したかどうかを示します。支払い完了と判断する前に、実行された操作、正確なトークンコントラクト、受取人、送金の証拠を確認してください。

Ethereum Mainnet上の元の取引ハッシュから始めます。古いままのウォレット表示を試すためだけに、もう一度送金しないでください。このガイドは、ブロックに取り込まれた取引を読み取り専用で調べる手順です。復旧サービスでも、新しい取引に署名するための説明でもありません。

成功が示す範囲を正しく読む

EIP-658では、レシートのステータスを最上位の呼び出しの結果と定義しています。ステータス1は成功、0は失敗を意味し、JSON-RPCでは0x1と0x0で表されます。これは実行についての情報であり、アプリで実現したかった結果がすべて満たされたという一覧ではありません。

コントラクトは、失敗した内部操作を処理し、取引全体をリバートさせずに済ませることがあります。ERC-20規格も、戻り値のfalseに呼び出し側が対応するよう明示しています。すべてのトークン実装が送金失敗をリバートで通知するとは考えないでください。

レシートのステータスは、トークンのメソッドが返すtrueやfalseではありません。レシートのリファレンスには取引のステータス、ブロック、ログが記載されていますが、ステータス欄が内部呼び出しの戻り値になるわけではありません。デコードした実行の詳細は役立つことがあります。ただし、トレースのエラーやメソッド名だけでは、操作全体の文脈に沿った解釈が必要です。

レシート全体がFailedなら、取引失敗とガスのガイドを参照してください。まだブロックに取り込まれていない場合は、保留中の取引のガイドを使います。ここでの確認対象は、取り込み済みでSuccessと表示されている取引です。

実際の操作が送金だったか確認する

アプリは、後の送金、スワップ、入金に先立って承認を求めることがあります。ERC-20のapproveは利用可能な上限額を設定するもので、その承認額を使用者へ送る操作そのものではありません。そのため、承認の取引が成功しても、トークン残高は変わらない場合があります。

操作内容と、利用できる場合はデコードした入力を確認します。取引の宛先コントラクトと、意図した操作を記録してください。取引のTo欄は、最終的なトークン受取人ではなく、ルーターなどのコントラクトを示す場合があります。この欄と、トークン送金に記録された受取人を同一視しないでください。

確認できたこと	分かること	まだ確認すること
レシートがSuccess	最上位の実行が成功した	意図した操作の結果
承認の成功	許可の操作が実行された	別の送金やプロトコル操作
一致するTransferログ	そのコントラクトが送金記録を出力した	対象の同一性、金額、結果の状態
現在のトークン残高	読み取り時点の口座の数量	ほかの取引と観測時点

各段階のハッシュを保存してください。成功した承認に続いて送金が行われたなら、記録は2つです。1つのSuccess表示で両方を代表させることはできません。また、アプリの完了メッセージだけでは、取引所が入金を反映したことや、ブリッジが別チェーンで完了したことは証明できません。それらには各サービスの記録とルールが必要です。

正確なトークンと受取人に送金記録を照合する

規格のTransferイベントは、送信者、受取人、金額を記録します。レシートのログで、その記録を出力したコントラクトのアドレスを確認し、デコードした各項目を意図した支払いと比べます。見慣れたシンボルだけでは不十分です。別のコントラクトが同じ名前を使ったり、似たイベントを出力したりすることがあります。

すでに信頼している情報源で、ネットワークとトークンコントラクトの完全なアドレスを確認します。受取人も、短縮表示の先頭と末尾だけでなく、アドレス全体を照合してください。ウォレットアドレスとトークンコントラクトのガイドでは、資産を識別するアドレスと口座を識別するアドレスの違いを説明しています。

イベントの有無だけでなく、金額も確認します。ERC-20には数量ゼロの送金もあるため、Transferイベントが見つかっても、正の金額の支払いがあったとは限りません。ログに生の整数が表示されている場合は、確認済みのトークンの小数桁数を使って解釈します。表示変換を二重に適用したり、メタデータがないときに桁数を推測したりしないでください。

たとえば、意図した支払いが25トークンだったとします。25トークンの承認が成功しても、その支払いではありません。ゼロトークンの送金記録も、その支払いではありません。別のコントラクトからの25トークンの記録があっても、目的の資産を受け取った証明にはなりません。これらは仮定の比較であり、実際のウォレットで観測した結果ではありません。

すべての変化をこのハッシュに帰さず状態を比較する

同じネットワーク上で、同じトークンコントラクトに対する受取人の残高を読み取ります。規格のbalanceOf(account)が返すのは口座のトークン残高であり、ある1件の取引が何を変えたかという説明ではありません。ウォレットの一覧表示や法定通貨換算のポートフォリオ総額は、更新が遅れていたり、別の内容を表していたりする場合があります。

読み取ったブロックまたは時刻を記録します。最新の残高には、確認対象の取引より後の送金が含まれることがあります。直前のブロックと、その取引を含むブロックの残高を比較しても、同じブロック内の別の取引が含まれる場合があります。ほかの動きを調べずに、1つの差分がこのハッシュだけの影響だと断定しないでください。

証拠が食い違う場合は、その食い違いを残します。独自のトークンの仕組み、非対応の読み取りツール、プロトコル内部の会計処理については、そのコントラクトの文書やサポートが必要な場合があります。コントラクトのログは、本物であることや安全性の証明書ではありません。残高の問い合わせ失敗は不明を意味し、残高ゼロではありません。

再送を決める前に記録を残す

信頼できる経路から、使い慣れたエクスプローラーやコントラクト読み取りツールを開きます。これらの公開情報の確認に、ウォレット接続、署名、承認、リカバリーフレーズは不要です。この手順は2026年10月26日に確認した一次資料に基づいています。本記事のために実際の取引で検証したものではありません。

1. 元の取引を特定する。 Ethereum Mainnet、完全なハッシュ、送信者、ブロック、レシート全体のステータスを保存します。
2. 実際の操作を特定する。 承認と、送金、スワップ、入金を区別します。一連の流れに含まれる別のハッシュも保存します。
3. トークンの証拠を照合する。 記録を出力したコントラクト、送金の送信者、受取人、金額とその単位を記録します。意図した資産と口座に照合します。
4. 結果の状態を確認する。 正確なトークン残高や該当するプロトコルの記録を読み取り、ブロックまたは時刻と、影響しうるほかの動きを記録します。
5. 未解決の点は未解決のまま残す。 ログの欠落、読み取り失敗、説明できない差異を記録します。別の取引が適切か判断する前に、公開されている取引情報を添えてウォレットやプロトコルの公式サポートに相談します。

何が成功し、意図した受領をどの証拠が裏付けるか説明できれば、確認は完了です。取引は成功していても支払いを検証できていないなら、そのように記録してください。Successの表示は有用な証拠ですが、資産、受取人、金額の確認を省いてよいという意味ではありません。