誤ったネットワーク・アドレスへ送金したときの確認順

誤ったnetworkやaddressへ送ったかもしれない。そう思ったら、追加送金、bridge、知らないnetworkの追加、回収代行への連絡をいったん止めます。 最初にするのは、tx hashと送信したchainを固定することです。

同じ0xから始まるaddressでも、Ethereum、Base、Arbitrum、BNB Smart Chainなどのstateは別です。一方で、別networkに見えても同じ秘密鍵で管理するEOA addressなら、送ったchain上で残高を確認できる場合があります。addressの形だけで「紛失」「回収可能」のどちらにも決められません。

この記事は、個別の資産回収を保証しません。wallet接続、署名、transaction、bridge、追加送金は行わず、read-onlyの証拠から確認先を分けます。

結論：status → chain → 送付先の管理主体

誤送金を疑ったときにtransaction status、送信chain、送付先の管理主体、assetの証拠、次の確認先へ進む5段階フロー

現在の状態	chain上で分かること	次に見る場所
broadcast前	chain上のtransactionはまだない	署名前画面のchain、to、asset、amountを再確認して止める
pending	その観測元では未確定。元hashが確定・置換される可能性がある	receipt、from、nonce、replacement hash
confirmed-failed	blockには入ったがEVMのstate変更はrevert。network feeは使われ得る	receipt、failure data、同一nonceの別hash
confirmed-success	送ったchainでstate変更が成功	native transferなら`to`、tokenならTransfer logのrecipientとcontract

Successは「意図したnetwork・相手・tokenへ正しく届いた」という総合判定ではありません。送ったchainで、そのtransactionの処理が成功したという証拠です。

pending、dropped候補、replacedの詳しい判定はtransaction状態の確認フローへ分けています。MetaMaskの送信画面や基本操作から確認する場合はMetaMaskの送金が反映されないときの確認、すでに取引所へ送って残高だけが未反映ならTxID・confirmations・Memoの確認手順も使ってください。

最初に保存する10項目

walletの履歴を消したり、同じ送金を繰り返したりする前に、次をテキストで保存します。

確認日時とtimezone
tx hash / TxID（なければ未発行と記録）
sent network / chain ID
intended network / chain ID
receipt statusとblock number
from address
native transferのto、またはtoken Transfer logのrecipient
asset名とsent chain上のtoken contract
raw amount / 表示amount
送付先の種類と、誰がsent chain上の鍵・accountを管理するか

スクリーンショットだけでなく文字列も残します。ただし、Secret Recovery Phrase、private key、password、2段階認証code、QR code、wallet全体の残高は保存・共有しません。

1. broadcast前・pending・confirmedを分ける

MetaMaskの公式案内も、wrong networkやwrong addressの前に、transactionがconfirmedかを確認する順番です。

tx hashが発行されていない

署名前、シミュレーション失敗、wallet内で拒否した状態など、chainへbroadcastしていないならon-chainの誤送金はまだ成立していません。chain、to、asset、amountに疑問がある状態で、新しいtransactionを作らないでください。

pending

pending中はconfirmedではありません。speed upやcancelは、同じnonceを使うreplacementをnetworkへ採用してもらう試みです。元transactionが先に確定する場合もあり、成功は保証されません。

MetaMaskの現行Helpでも、cancelはnetwork上でpendingの間だけ試せ、confirmed後はreverseできないと説明しています。本記事ではfeeやnonceを手入力する手順へ進まず、元hash、from、to、nonce、観測時刻を保存してreceipt・nonceの判定手順へ移ります。

confirmed-failed

EVMのreceiptがrevertedなら、transactionはpendingではありません。通常、そのcallによるstate変更はrevertしますが、実行に使われたnetwork feeは戻らない場合があります。単純な送金とcontract callを混同せず、receiptとlogsを保存します。

confirmed-success

ここからwrong networkとwrong addressを分けます。native assetの送金ならtransactionのtoとvalue、ERC-20等のtokenなら対象token contractのTransfer logにあるrecipientとamountを見ます。token送金ではtransactionのtoがtoken contractになり得るため、transaction欄だけで受取人を決めません。

2. wrong networkとwrong addressは別の事故

EIP-155ではchain IDをtransaction署名へ含め、別chainで同じtransactionがそのまま再生されることを防ぐ仕組みが定義されています。address文字列だけでは、どのchainへ送ったか分かりません。 tx hashをsent chainのExplorerで開き、chain IDとreceiptを固定します。

分類	例	確認の焦点
wrong network	recipient文字列は意図どおりだが、Baseへ送る予定をEthereumで送った	sent chain上で同じrecipientを誰が管理するか
wrong address	chainは意図どおりだが、recipient文字列が別人・別contract	そのdestinationのcontrollerと返送可能性
wrong asset	chainとrecipientは合うが、同名の別token contractを送った	sent chain上のtoken contractとTransfer log
display only	chain・recipient・assetは合うがwallet一覧に表示されない	Explorer balance、token contract、walletの表示設定
複合	networkもaddressも違う、または送付先の管理主体が不明	分かった項目だけ記録し`unknown`を残す

「BEP-20」「ERC-20」という表示だけでも不十分です。token規格、送信chain、token contract、受取serviceの対応networkは別項目です。

3. 誰がdestinationを管理するかで境界が変わる

送付先をself-custody、custodial service、第三者、contractまたはunknownに分け、確認先とできないことを示す図

self-custodyのEOA候補

自分または相手が同じprivate keyでsent chain上のEOA addressを管理しているなら、sent chainのExplorerでそのaddressとasset balanceを確認できる場合があります。MetaMaskのwrong-place案内も、EVM-compatible network間では同じaddressを使うcaseを説明しています。

ただし、次を確認するまで回収可能とは書けません。

destinationが本当に同じEOA keyから導出されたaddressか
hardware wallet・imported keyを含め、recipientがsent chainで署名権限を持つか
smart accountやcounterfactual addressではなく、別chainでも同じcontrol条件か
sent chain上に正しいtoken contractとbalanceがあるか
token自体にtransfer制限や悪意ある仕様がないか

0x形式が同じ、walletへnetworkを追加できた、token名が表示された、という事実だけでは署名権限を証明しません。Secret Recovery Phraseを別のwalletや「recovery tool」へ入力して確認しないでください。

custodial service・取引所

deposit addressの秘密鍵を取引所やserviceが管理している場合、利用者が同じaddressをwalletへ追加することはできません。sent chainとassetをserviceが技術的に扱えても、accountへ割り当てるか、返還するか、手数料が必要かはserviceの運用判断です。

次を現在の公式supportへ提出できる形にします。

tx hashとsent chain
receipt status、block、timestamp
asset名とsent chain上のtoken contract
Transfer logのrecipientとamount
serviceが発行したdeposit address、Memo・Tag
送信時と確認時の対応network表示
account内の入出金IDとsupport ticket ID

復旧可否や所要時間を外部記事で断定しません。同じ送金を再実行せず、取引所入金の確認手順でchain状態とservice内処理を分けます。

第三者のEOA

意図しない個人・組織がdestinationを管理している場合、protocolが強制的に返送させる機能はありません。所有者を正当に確認できるなら、返送を依頼する余地はありますが、相手が応じる保証はありません。返送は相手が作る新しいtransactionです。

addressから個人情報を推測して公開したり、SNSで資産額をさらしたりしないでください。相手を名乗るDMへ追加送金や秘密情報を渡すことも避けます。

contract address・管理主体不明

contract addressへnative assetやtokenを送っても、そのcontractに返却functionがあるとは限りません。verified source、current implementation、admin・role、受領したTransfer log、公式project情報をread-onlyで確認します。

function名がrecoverTokenやsweepでも、誰が呼べるか、どのtokenが対象か、proxy implementationが何かを読まずにWriteしません。verified contract・ABI・シミュレーションの確認順は調査方法の参考になりますが、回収手順や成功保証ではありません。

管理主体を分類できない場合はunknownのまま止めます。「誰かが鍵を持っているはず」という推測を、回収可能へ読み替えないでください。

4. tokenが見えないだけかをread-onlyで確認する

confirmed-successでdestinationも自分のaddressなのにwalletへtokenが出ない場合、表示設定だけが原因のことがあります。

tx hashをsent chainのExplorerで開く
Transfer logのtoken contract、recipient、raw amountを確認する
recipient addressのtoken balanceをsent chainで確認する
project公式情報とtoken contractを照合する
walletがそのnetworkとtokenを表示できるか公式案内を確認する

MetaMaskのtoken表示案内では、自動検出されないtokenをcontract addressから表示へ追加できます。ただし、custom tokenの追加は残高の表示設定であり、別chainへの移動、tokenの変換、bridgeではありません。 偽tokenやairdropを表示しても安全性は上がりません。

custom network情報も検索広告やDMからコピーしません。chain ID、RPC、Explorerをnetworkの公式資料で照合し、追加してもtransactionを送らずbalanceだけを確認します。

5. bridgeは確認ではなく新しい資産移動

sent chain上でcontrolとbalanceを確認できても、intended chainへ移すにはbridge等の別transactionが必要になる場合があります。これは「表示を直す操作」ではありません。

bridge contract・route・対応asset・送付先を新たに信頼する
approvalや署名が発生し得る
gas用native assetが必要になり得る
wrapped asset、canonical asset、third-party bridgeでtoken実体が変わり得る
fee、minimum、停止、流動性、finality条件がある

したがって、本記事はbridge先や操作方法を提示しません。sent chain上のcontrolを確認できない段階で、gas用資産を追加送金したり、検索結果のrecovery bridgeへ接続したりしないでください。

状態別の判定matrix

classification	確認する証拠と次の境界	保証しないこと
`pre-broadcast-stop`	tx hashなし。署名前のchain・to・assetを再確認し、transactionを作らない	送信成功
`pending-unconfirmed`	元hash、receiptなし、from・nonceを保存し、receiptとreplacementをread-only追跡	cancel・speed up成功
`confirmed-failed`	reverted receipt、blockを保存し、failure dataと同一nonceの別hashを確認	network fee返還
`controlled-address-delivery`	intended chain、controlled destination、正しいassetを確認し、token表示と実体を分ける	wallet表示だけで安全判定
`self-custody-sent-chain-access-candidate`	sent chain上のcontrolとbalanceを確認し、network・tokenをread-onlyで照合	bridge・回収成功
`custodial-support-only`	service deposit address、対応network、tx証拠を揃え、公式supportへ確認	credit・返還・所要時間
`third-party-return-only`	third-party destinationとconfirmed transferを確認し、controllerへ正当に連絡	強制返送
`contract-recovery-unknown`	code、implementation、roles、Transfer logを確認し、公式projectとsecurity reviewへ分ける	callableな回収function
`control-unverified`	destinationの管理主体を確定できる証拠が増えるまで停止	address形式からの回収判定

これらの分類は、架空のhashとaddressだけを入力する判定例で再現できます。判定結果は状態を返すだけで、write actionを許可しません。

const assessment = assessWrongNetworkTransfer({
  transaction: {
    state: 'confirmed-success',
    hash: '0x' + '12'.repeat(32),
    sentChainId: 8453,
    intendedChainId: 1,
    from: '0x' + '34'.repeat(20),
    to: '0x' + '56'.repeat(20),
    tokenContract: '0x' + '78'.repeat(20),
    amount: '1000000',
  },
  destination: {
    kind: 'self-custody',
    controlOnSentChain: true,
    receiverSupportsSentChain: null,
  },
  asset: {
    observedOnSentChain: true,
    tokenContractVerified: true,
  },
})

出力がcandidateでも、protocolReversalAvailable、recoveryGuaranteed、writeActionAuthorizedはすべてfalseです。

公式supportへ渡すもの・渡さないもの

渡す証拠

tx hashと正しいExplorer URL
sent chain / chain ID
receipt status、block、timestamp
from、destination、token contract、amount
deposit address、Memo・Tag、入出金ID
公式support ticket ID

渡さないもの

Secret Recovery Phrase・seed phrase
private key・keystore・password
2段階認証code・API secret
screen sharing・remote access
「検証料」「解除料」名目の追加送金

MetaMask公式は、未依頼DMでsupportを申し出ず、Secret Recovery Phraseを要求しないと明記しています。電話、WhatsApp、Telegram、XのDMなどで「必ず回収できる」と持ちかける相手を公式supportとして扱いません。

よくある質問

同じ`0x` addressなら別EVM networkでも必ず取り出せますか？

必ずではありません。同じEOA private keyでsent chain上のaddressを管理しているcaseはありますが、取引所のdeposit address、smart account、contract、別のkey derivationでは条件が異なります。sent chain上のcontrolとbalanceを別々に証明します。

networkをMetaMaskへ追加すれば資産は戻りますか？

network追加はwalletがそのchainを読み取る設定です。資産を移動・変換・返還しません。正しいofficial network情報を使い、追加後もtransactionを送らずExplorerとbalanceを照合します。

tokenをimportすれば別chainから移動できますか？

できません。custom token importは、選択中のchainにあるtoken contractをwallet一覧へ表示する操作です。token contractはchainごとに確認し、表示追加をbridgeと混同しません。

confirmed後でもcancelできますか？

できません。pending中のcancelは同じnonceのreplacementを先に確定させる試みです。confirmed transactionをreverseする命令ではありません。

取引所が秘密鍵を持つaddressなら必ず返還できますか？

保証できません。対応network、asset、wallet構成、account割当、security policy、法令対応、手数料などを取引所が判断します。公式supportへ証拠を提出し、その回答を記録します。

`recoverToken`というfunctionを見つけました。呼べば戻りますか？

名前だけでは判断できません。対象token、recipient、role、proxy implementation、pause、function bodyを確認する必要があります。一般利用者が呼べるとは限らず、不明なWriteは行いません。

最終チェックリスト

誤送金を疑ったときの最短ルートは、急いで「取り戻す」操作を探すことではありません。tx status、sent chain、destination control、asset evidenceを同じ時点で固定し、できないことを先に決めることです。