USDC入金確認2026 チェーンとバウンティの検証方法

USDCの入金は、合意したチェーンの公式トークンの転送で確認します。受取アドレスと数量が一致している必要があります。取引の成功とブロックのファイナリティも別途確認してください。募集要項の報酬額やハッシュだけでは、バウンティの支払いを認めることはできません。

アドレスとチェーン IDは、Circle・Ethereum・Baseの公式ドキュメントで再確認してください。（確認値 Ethereum Mainnet: チェーン ID 1、USDCコントラクト 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48。Base Mainnet: チェーン ID 8453 0x2105 , USDCコントラクト · 出典 developers.circle.com · 2026-10-23 確認）

チェーン別のUSDCコントラクトアドレスとチェーン ID

EthereumとBaseのUSDCは、それぞれ異なるコントラクトアドレスを使用します。チェーン IDはネットワークを区別する番号です。トークンコントラクトアドレスは、そのチェーン上でトークンを識別します。受取アドレスは、代金を受け取るウォレットやアカウントのアドレスです。

執筆・ドキュメント確認日は2026年10月23日です。以下の表は、メインネットのCircle発行USDCを対象としています。メインネットは、実際に価値のある資産を使用するネットワークです。

コントラクトアドレスの根拠は、CircleのUSDC contract addressesです。Ethereumのチェーン IDは、EIP-155に明記されています。Baseのチェーン IDは、Baseのeth_chainIdドキュメントで確認できます。

受取アドレスの文字列が同じでも、チェーンが異なれば別の記録です。Ethereumでの入金がBaseの残高に自動で合算されるわけではありません。SepoliaなどのテストネットのUSDCは、実際の代金として集計しないでください。

受取アドレスと取引を確認する手順

支払い条件を先に確定しておくと、別の取引を代金と誤認しにくくなります。この手順は、公開された取引記録を読み取る作業です。エクスプローラーでの照会に、ウォレットの接続や署名は必要ありません。

1. 支払いに関する合意で、ネットワークとトークンを確認してください。募集要項のドル表示と、実際に支払われるUSDCの数量を区別してください。
2. 受取先のウォレットで、該当ネットワークの受取アドレスをコピーしてください。取引所を利用する場合は、そのサービスの入金画面を基準にしてください。サービスの対応ネットワークも確認してください。
3. CircleのMainnetの表で、該当チェーンのコントラクトアドレスを探してください。トークン名やロゴだけで判断しないでください。
4. 該当チェーンのエクスプローラーでtxHashを検索してください。txHashは取引を見つけるための識別値です。検索結果がなければ、ネットワークとハッシュを再度照合してください。
5. 取引詳細のステータスとトークン転送記録を確認してください。続いてLogsタブで、実際のTransferイベントを照合してください。

検索で見つからないハッシュは、まだ入金の証拠にはなりません。ただし、検索できないという理由だけで、相手の詐欺と断定することはできません。まずはチェーンの間違いやハッシュのコピー時の誤りを確認してください。

Transferイベントで確認する項目

受け取ったかどうかは、USDCコントラクトが残したTransferイベントで判定します。取引上部のToは、呼び出されたコントラクトの場合があります。トークンを受け取ったアドレスは、イベント内のtoで確認してください。

ERC-20標準では、転送イベントを次のように規定しています。

トークンが転送される際には、値がゼロの転送も含め、必ず発生させる必要があります。

出典: ERC-20: Token Standard、Transferの項目

この規定には、数量が0の転送も含まれます。そのため、イベントが存在するだけで、対価の支払いがあったと認めてはいけません。原文はERC-20: Token Standardで確認できます。

支払い代行コントラクトがトークンを送る場合もあります。そのため、取引の送信者と雇用主のアドレスが常に同じとは限りません。作業番号と支払い明細も併せて照合してください。アドレスだけで、実際の支払者の身元を確定することはできません。

生ログの読み方

生ログでは、アドレスと数量がエンコードされています。topics[0]は、イベントシグネチャのハッシュです。標準USDC Transferの送信元アドレスは、topics[1]にあります。受取アドレスは、topics[2]に格納されています。

• アドレス: 該当するtopicの末尾20バイトをアドレスとして解釈します。
• 数量: dataを符号なし整数として解釈します。
• 小数桁数: 公式コントラクトのdecimals()の値を使って数量を換算します。
• 承認イベント: Approvalは使用権限の承認記録です。

EthereumとBaseの該当USDCは、小数点以下6桁を使用します。生の数量を1,000,000で割り、USDC単位で読み取ります。ETHの小数桁数をそのまま適用しないでください。ログ画面の構造は、EtherscanのEvent Logsで確認できます。

取引の成功とファイナリティの違い

Successは、取引の実行が成功したことを意味します。ブロックが最終確定したという意味ではありません。ファイナリティとは、合意ルール上でブロックが確定した状態を指します。この記事で最終確認済みとする入金は、ファイナリティまで確認した記録です。

Base内の転送とEthereumへの出金では、手順が異なります。出金の待機期間をBase内の入金にそのまま適用しないでください。Baseでは、ブロックへの格納とL1バッチのファイナリティを区別しています。根拠はBaseのTransaction Finalityです。

エクスプローラーでファイナリティが明確でない場合

ファイナリティの表示がなければ、確認状態を保留にできます。開発者は、該当チェーンの信頼できるRPCで再検証できます。RPCは、ブロックチェーンのノードにデータを要求するインターフェースです。

1. eth_chainIdで接続先のチェーンを確認してください。
2. eth_getTransactionReceiptでレシートを読み取ってください。status、ログ、ブロック番号とブロックハッシュを確認してください。
3. 同じブロック番号をeth_getBlockByNumberで照会してください。返されたハッシュがレシートのblockHashと同じか照合してください。
4. eth_getBlockByNumberにfinalizedとfalseを渡してください。返されたブロックの高さが、取引のブロックの高さ以上であることを確認してください。Baseの取引は、Base RPCのfinalizedブロックを基準に比較してください。

レシートがnullの場合、その応答ではブロックに格納されたかどうかを確認できません。finalizedの照会に対応していない応答も、成功の判定に使わないでください。latestや単純な確認数を、finalizedに置き換えて解釈してはいけません。メソッドは、Ethereum JSON-RPCとBaseのブロック照会ドキュメントで説明されています。

計算例: 架空の100 USDC入金

以下は実際の支払い事例ではなく、架空の検証例です。支払い条件はBaseでの100 USDCと仮定します。アドレスとログ番号は、説明のために作成した値です。例示したアドレスを実際の受取アドレスとして使用しないでください。

この条件での受取数量は100 USDCです。Hのブロックハッシュの一致も確認済みと仮定します。外部の支払者による作業代金であることを結び付ける根拠は、別途必要です。

受取アドレスが別のアドレスなら、本人への入金とは認めません。募集要項に100ドルとしか記載されていなければ、支払い数量も別途確認の対象です。100 USDCの受け取りは、現金100ドルの受領を意味するものではありません。

バウンティの状態別の入金証拠の比較

バウンティの進捗状況とウォレットの入金状態は、別々に記録してください。バウンティは、指定された作業に対する報酬です。以下の分類は、支払いの証拠を管理するための基準です。法的な債権や税務上の売上の確定に代わるものではありません。

エスクローは、条件が満たされるまで資金を別に保管する方式です。保管されているという事実だけでは、本人のウォレットに支払われたとはみなせません。プラットフォームの承認とERC-20のApprovalも、異なる概念です。

最終入金にも、作業番号や請求書を関連付けてください。取引記録だけでは、支払いの目的までは分かりません。同じ数量の別の入金と混同しないよう、支払日も照合してください。

新しい作業代金として誤って集計するよくあるミス

ウォレットに入ったUSDCを、すべて新しい作業代金として合算しないでください。受領の事実と経済的な目的は、別の項目です。以下のチェックリストは、運用上の入金台帳を整理するための基準です。

• 返金: 過去の支出が戻ってきた金額は、元の支出に関連付けてください。
• 自己振替: 自分が管理するウォレット間の移動を区別してください。
• ブリッジ移動: 自分の資産のチェーン間移動は、新たな顧客からの支払いと分けてください。
• スパムトークン: USDCという名前よりも、公式コントラクトアドレスを確認してください。
• ブリッジ表現トークン: コントラクトが異なる場合は、Circle発行USDCとは別の資産として記録してください。
• 数量0のイベント: Transferがあっても、対価の支払いとして加算しないでください。
• 重複照会: 同じイベントをエクスプローラーとAPIでそれぞれ加算しないでください。
• 証拠の再利用: すでに別の作業に関連付けた入金を、再度割り当てないでください。
• 自己循環: 同じ取引の出金と再入金を併せて確認してください。
• 事後の返還: 受け取った代金を返した場合は、元の受領記録に関連付けてください。

重複を防ぐ記録項目

イベントはchainId + txHash + logIndexで区別できます。同じ取引に、複数の転送イベントが含まれることがあります。そのため、txHashだけですべてのイベントを1つにまとめると、漏れが生じる可能性があります。

ファイナリティ到達前にブロックの再編成が発生した場合は、記録を再検証してください。削除されたログは、既存の暫定集計から除外する必要があります。作業代金の合計とウォレット残高は、別々に管理してください。残高には、以前からの保有分やその後の出金も反映されます。

5分検証表

この表は、約5分で確認する項目を整理したチェック表です。ブロックチェーンのファイナリティが完了するまでの時間を保証するものではありません。確認できない項目は、保留のままにしてください。

最初の確認では、支払いの根拠が不足している場合もあります。その場合は、不足しているチェーン名やtxHashを求めてください。別のアドレスに転送されていた場合は、不一致の項目を具体的に伝えてください。

よくある質問

txHashを受け取るだけで入金完了ですか？

ハッシュだけでは、入金完了を確認できません。成功した取引でも、別の受取アドレスが含まれることがあります。コントラクト・受取アドレス・数量・ファイナリティを併せて確認してください。

Successなのにウォレットの残高が表示されない場合はどうすればよいですか？

まず、イベントの受取アドレスと公式コントラクトを照合してください。一致している場合は、選択したネットワークとトークンの表示を確認してください。受取サービス内部での反映状況も、別途確認の対象です。

Baseの入金をEthereumで探してもよいですか？

Baseの取引は、Baseのエクスプローラーで照会してください。同じアドレスを使っていても、チェーンごとの記録は分かれています。Ethereumの検索結果だけで、Baseに入金されていないと判断しないでください。

取引上部に0 ETHと表示されていたら、入金はないということですか？

0 ETHの表示は、USDCが転送されていないことの証拠ではありません。取引のETH数量とERC-20トークンの数量は別です。TransferイベントのUSDC数量を確認してください。

最終確認済みの外部入金なら、新しい売上ですか？

外部からの入金だけでは、新しい作業の売上を確定できません。返金や別の目的の送金の場合もあります。請求書と支払い明細を使って、入金目的を関連付けてください。

入金の確認結果で税金を計算してもよいですか？

この手順は、オンチェーンでの受領の証拠を確認するためのものです。個人の納税結果を判断するものではありません。韓国の税務案内は、国税庁の総合所得税の概要で確認してください。