取引所への入金が反映されないときのTxID・confirmations・Memo確認手順

ウォレットや送信元取引所に「完了」と表示されても、受取取引所の残高へすぐ反映されるとは限りません。先に、chain上のtransactionと取引所内の入金処理を別の状態として確認します。

最初に保存するのは、TxID、asset、network、deposit address、amount、Memo・Tag、確認時刻です。画面を更新する前にテキストで記録し、同じ送金を推測だけで再実行しないでください。

追加送金より先に証拠を保存

未反映の原因が分からないまま少額を追加送金しても、誤networkやMemo漏れを繰り返す可能性があります。秘密鍵、シードフレーズ、password、2段階認証code、API secretは、取引所supportにも共有しません。

MetaMask側でpending・failed・replacedを判定する場合は、先にtransaction状態の確認フローを使ってください。送金操作全体はMetaMaskの送金が反映されないときの確認へ分けています。

結論：5段階を順番に分ける

段階	確認する証拠	次の判断
1. 送信元	TxIDが発行されたか	未発行なら、chainへ送信されていない可能性を送信元で確認
2. chain	Explorerのstatus、block、receipt	pending・failed・successを分ける
3. 確定度	confirmations、finality、取引所の必要条件	現在数と取引所の必要数を混同しない
4. 入金条件	asset、network、address、Memo・Tag、minimum、入金停止	送金内容と現在の入金画面を照合
5. 取引所	未検出、processing、審査中、credited	chainではなく取引所内の処理として追う

chainでSuccessでも、取引所がその入金を検知し、accountへ割り当て、審査し、残高へ計上したことまでは証明しません。

最初に記録する8項目

確認日時とtimezone
asset名とtoken contract（tokenの場合）
network / chain
TxID / transaction hash
送信元address
deposit address
amount（network fee控除後も確認）
Memo / Tag / Messageと取引所履歴status

TxIDと取引所の受付番号は同じとは限りません。たとえばbitFlyerの現行FAQでは、ログイン後の「お取引レポート」から入出金のTXIDを確認する案内があります。送信元の「注文ID」「出庫申請ID」しかない場合は、chainへbroadcast済みかを送信元serviceで確認します。

addressやTxIDは公開chain上の情報ですが、account名、email、残高、QR codeを含む画面を公開投稿しないでください。supportへ提出する場合も、取引所の公式domainにある安全な問い合わせ画面だけを使います。

1. TxIDを正しいExplorerで検索する

TxIDがある場合、送ったnetworkに対応する公式または信頼できるExplorerで検索します。Ethereumのhashを別chainのExplorerへ貼り、not foundだけで未送信と判断しないでください。

Explorerの表示	chain上の意味	取引所側で見る前にすること
not found	別chain、未broadcast、index遅延、dropped候補など	network、送信元履歴、複数の観測元を確認
pending	まだblockへ含まれていない観測	receiptが出るまで元hashを追う
failed / reverted	blockへ含まれたが処理失敗	EVMではstate変更はrevert。受取側未反映とは分ける
success	blockへ含まれ、receiptが成功	to、token transfer、amount、confirmationsへ進む

EVMのtoken送金では、transactionのtoがtoken contractや別contractになる場合があります。ExplorerのSuccessだけでなく、Transfer logのtoken contract、from、to、amountを照合します。receiptとlogsの読み方は失敗transactionを解析する手順で確認できます。

2. confirmationsとfinalityを取引所の必要数から分ける

Ethereum.orgのtransaction lifecycle資料では、transactionはpoolからblockへ入り、そのblockがjustified、finalizedへ進みます。Explorerのconfirmationsは、transactionを含むblockの後ろへblockが積み重なった深さを表す表示です。protocolのfinalityや、取引所が残高反映に使う必要数とは同じ用語ではありません。

EVM RPCで現在のblock深度を読む例は次のとおりです。

const [receipt, latestBlock] = await Promise.all([
  publicClient.getTransactionReceipt({ hash }),
  publicClient.getBlockNumber(),
])

const blockDepth =
  latestBlock >= receipt.blockNumber
    ? latestBlock - receipt.blockNumber + 1n
    : 0n

console.table({
  status: receipt.status,
  transactionBlock: receipt.blockNumber,
  latestBlock,
  blockDepth,
})

これは選択したEVM RPCから見た現在のblock深度です。取引所の必要confirmations、Ethereumのfinalized判定、別chainの確定条件を置き換えません。

bitFlyerの暗号資産預入FAQは、一定数以上の承認後に手続きし、必要承認回数を変更する可能性や、安全確認で遅れる場合があると案内しています。Krakenのprocessing timesもassetごとに必要数と推定時間を分けています。

そのため、「平均block時間 × 必要数」を到着保証にしません。次の3つを確認日時付きで記録します。

1. Explorerの現在confirmationsまたはfinality
2. 取引所が現在のasset・networkに示す必要条件
3. 取引所入金履歴の現在status

3. asset・network・addressを現在の入金画面と照合する

同じtickerや同じ0x形式でも、assetとnetworkの組み合わせが違えば取引所が受け付けるとは限りません。ERC-20はtoken規格であり、すべてのEVM networkを受け付けるという意味ではありません。

項目	照合する内容	未反映につながる例
asset	token名だけでなくcontract address	同名token、旧contract、非対応asset
network	送信chainと入金画面の対応network	Ethereum向けへ別EVM chainから送信
address	送信時のtoと、発行されたdeposit address	古いaddress、別assetのaddress、入力違い
transfer形式	native送金、token transfer、contract経由への対応	取引所が特定の入金形式へ非対応
入金受付	deposit enabled、maintenance、取扱終了	受付停止中に送信

Coincheckの現行受取FAQは、assetごとに対応networkを示し、異なるchainでは残高反映や変換に対応できない場合があると説明しています。同じページでも対応assetやnetworkは変更されるため、過去のスクリーンショットではなく送信時と確認時の入金画面を保存します。

誤networkでも、取引所が秘密鍵を管理するaddressなのか、対象chainとassetを技術的・運用上扱えるのかで状況が変わります。回収可否、手数料、所要時間を外部記事だけで断定せず、追加送金を止めて公式supportへ確認します。

4. Memo・Tag・Messageはaddressとは別の割当情報

取引所が一つの受取addressを複数accountで使うchainでは、Memo、Destination Tag、Messageなどをaccountの識別に使う場合があります。

XRP Ledgerの公式資料は、Destination Tagを、取引所などが入金をどのcustomerへ割り当てるか示す情報として説明しています。Tagはaddressの一部と決めつけず、transactionに記録された値と取引所が発行した値を照合します。

2026年8月28日に確認したCoincheckの受取FAQでは、XRPに宛先Tag、XLMにMemoなど、asset別の追加項目が示されています。必要項目は取引所・asset・networkで異なるため、「XRPなら常に同じTag」「以前使ったMemoを再利用」と一般化しません。

Memo・Tagを忘れた、または値が違う場合は、次を保存して公式supportの案内へ進みます。

• TxIDとExplorer URL
• destination address
• transactionに記録されたMemo・Tagの有無と値
• 取引所がその入金用に発行したMemo・Tag
• asset、network、amount、送信日時

返還やaccountへの割当が可能とは限りません。SNSの返信や検索広告にある「recovery support」へ秘密鍵や追加送金を渡さないでください。

5. minimum depositと受取amountを確認する

最低入金額は、送信元で入力したamountではなく、取引所が対象networkで認識する受取amountを基準にする場合があります。送信手数料が差し引かれるserviceでは、受取額がminimumを下回る可能性も確認します。

Krakenのfees and minimumsは、assetごとにminimumが異なり、network fee控除後のamountを確認するよう案内しています。同ページの条件を他取引所へ当てはめず、送信した取引所のasset・network別条件を確認してください。

minimum未満の入金を後から別入金と合算するか、保留するか、反映しないかはserviceごとに異なります。「追加送金すれば必ず合算される」と推測しません。

6. 取引所の入金statusをchain statusと分ける

取引所履歴に表示があれば、少なくとも取引所systemが入金候補を検知した手掛かりになります。ただし、Processing、Credited、Successful、On holdなどの意味はserviceごとに異なります。

Krakenの例では、Pending/Processingはnetworkでconfirming中、Creditedは取引に使えてもwithdrawalはまだ使えない段階、On holdはsupportによる個別確認が必要な状態です。すべてのassetが同じ遷移を通るわけではないとも明記されています。

国内取引所でも、chain確定後に送金元情報の登録や審査が入る場合があります。Coincheckの現行FAQでは、未反映入金の送金元情報を登録し、審査後に受取完了へ進む流れが案内されています。chain上で成功していても、取引所画面の「要回答」「審査中」「メールをご確認ください」を見落とさないでください。

状態別の確認先

現在の状態	次に確認すること	避けること
TxIDがない	送信元の出庫status、broadcast有無	同じ送金を即時に繰り返す
Explorerでnot found	chain、hash、送信元、別RPC・Explorer	not foundだけで資産消失と断定
pending	block未収録、fee条件、network混雑	確定済みと思って取引所へだけ問い合わせる
failed / reverted	receipt、error、送信元残高、fee	受取取引所の残高反映待ちと扱う
success・必要数未満	現在confirmationsと取引所の現行条件	固定時刻で到着を保証する
success・必要数到達・履歴なし	asset、network、address、Memo・Tag、minimum、受付状態	回収を約束する非公式窓口へ連絡
取引所でprocessing	取引所status、更新時刻、maintenance	chain上のtransactionを再送する
取引所でon hold・要回答	公式画面の必要情報、support ticket	公開SNSへaccount情報を投稿する

問い合わせ前に用意する証拠

取引所へ問い合わせる場合は、次を一つのメモへまとめます。

1. asset名、token contract、network
2. TxIDと対応Explorer URL
3. Explorerのstatus、block、confirmationsまたはfinality、確認日時
4. 送信元addressとdeposit address
5. 送信amount、受取amount、network fee
6. Memo・Tag・Messageの有無と値
7. 送信元serviceの出庫IDとstatus
8. 取引所の入金履歴statusと最終更新時刻
9. 送信時に表示されていたminimum、対応network、maintenance情報

スクリーンショットは、account名、email、残高、他の履歴、QR codeをマスクします。公式の安全な問い合わせ画面で必要とされた場合だけ、該当transactionのfull addressを提出します。

support担当者が必要とするのはtransactionを特定する証拠です。シードフレーズ、秘密鍵、password、2段階認証code、remote access、追加送金は必要ありません。

最終チェックリスト

• TxIDと送信元の出庫IDを分けた
• 正しいchainのExplorerでstatusとblockを確認した
• token transferのcontract、to、amountを確認した
• 現在confirmationsと取引所の必要数を分けた
• assetとnetworkを現在の入金画面で照合した
• deposit addressを送信時のtransactionと照合した
• Memo・Tag・Messageの必要性と実際の値を確認した
• minimum depositとfee控除後のamountを確認した
• deposit停止、maintenance、審査・要回答を確認した
• 公式support用の証拠を保存した
• 秘密鍵や認証情報を共有していない

最短の確認方法は、「送信済み」「Success」「Processing」という一つの表示だけで待つことではありません。TxID、chain status、confirmations、入金条件、取引所statusを同じ時刻で記録することです。