CREATE2で生成された決定論的アドレスにトークンを送ってしまい、そのアドレスにデプロイされるはずのコントラクトが第三者宛てに固定されている場合、技術的に資金を回収する手段はほぼ存在しない。回収を試みるならオフチェーンの交渉か法的措置に限られる。
CREATE2アドレスに資金が閉じ込められるのはなぜか
CREATE2とは、イーサリアムなどのEVMチェーンでコントラクトをデプロイする前から、そのアドレスを計算できる仕組みだ。アドレスはデプロイヤーのアドレスとソルト、初期化コードのハッシュから一意に決まる。つまり、まだコードが存在しないアドレスにもトークンを送れてしまう。
誤送金が起きるのは、この計算上のアドレスに送金したのに、肝心のコントラクトがまだデプロイされていないケースだ。デプロイ前のアドレスにはコードがないため、資金を動かす関数が存在しない。しかしデプロイしてしまうと、今度は事前に書かれた送金先へ資金が流れることがある。
多くのプロキシ契約やフォワーダー契約では、資金の移動先がデプロイ時にハードコードされる。いったんデプロイすると、変更用の関数が存在しないか、あっても書き換え不能な設計が多い。その結果、デプロイと同時に第三者のアドレスへ資金が送られてしまう。
資金が本当に固定されているかを確認する手順
まず、送金先のアドレスにコードがデプロイ済みかどうかをブロックエクスプローラーで確認する。その上で、デプロイ済みのコードまたは予定されているコードに資金の移動先を変更できる余地があるかを調べる。確認は以下の順で進めると効率的だ。
- ブロックエクスプローラーで対象アドレスのコントラクトコード有無を確認する
- デプロイヤーアドレスとソルトが分かるなら、CREATE2の計算式でアドレスが一致するか検証する
- コードが既にある場合は、ソースを読むか逆コンパイラで関数を確認する
- 送金先が固定の書き込み専用になっていないか、変更関数の有無を調べる
- selfdestructや初期化競合など、資金を動かせる経路がないか専門的に検証する
ブロックエクスプローラー上で「コントラクト」と表示されればコードはデプロイ済みだ。EOA（通常のウォレットアドレス）であれば、まだデプロイされていないカウンターファクチュアルアドレスの可能性が高い。デプロイ前なら、そのまま放置するか、デプロイした場合の挙動をシミュレーションで確かめることになる。
技術的な回収手段がほぼ存在しない理由
堅牢に実装されたCREATE2コントラクトでは、デプロイ後のコードは不変で、資金の移動先もハードコードされている。この場合、EVMレベルで資金を別のアドレスへ向ける方法は数学的に存在しない。デプロイすれば固定先へ送られ、デプロイしなければ資金は永久に動かない。
スマートコントラクトのコードは一度デプロイすると変更できないのが原則だ。プロキシパターンでも、実装の差し替えが可能なのは管理者用の関数がある場合に限られる。書き込み専用の設計では、送金先の変更関数すら存在しない。
そのため「デプロイすれば資金が第三者に届く」という構造では、デプロイを避ければ資金は動かないが、動かす手段もない。デプロイすれば資金は固定先に送られる。これが技術的な袋小路であり、コントラクトが堅牢であればあるほど脱出は難しい。
取れる現実的な選択肢
技術的に回収が不可能でも、オフチェーンの交渉や法的手段で資金の返還を求められる場合がある。ただし、相手方が応じなければ実質的に回収は難しい。まずは証拠を揃え、冷静に選択肢を検討する。
最初に、送金先になっている第三者に連絡を取り、状況を説明して返還を求める。ブロックチェーンの取引履歴が客観的な証拠になる。相手が協力的なら、トークンを返してもらえる可能性がある。連絡手段が分からない場合は、その団体の公式窓口や過去の取引記録を手がかりにする。
相手が応じない場合は、管轄地域の法律に基づいて訴訟やADR（裁判外紛争解決手続き）を検討する。ただし、クロスチェーンや匿名性の高い相手の場合、特定と執行は非常に難しい。暗号資産に詳しい弁護士へ相談し、回収可能性を見極めることが現実的だ。
相手先が倒産や事業停止状態にある場合は、債権者として申し出る余地があるか確認する必要がある。いずれにせよ、回収の可能性は低いと認識しておくのが現実的だ。失った資金を回収するより、今後の事故を防ぐことに力を注ぐ方が建設的なケースが多い。
同じミスを防ぐための予防策
CREATE2アドレスへの誤送金は、送金前にアドレスの性質を確認する習慣で大半を防げる。テスト送金とホワイトリスト登録も有効だ。以下のチェックを日常的に行うことを推奨する。
- 送金先アドレスがコントラクトかEOAかをブロックエクスプローラーで確認する
- CREATE2アドレスかどうか分からない場合は少額でテスト送金する
- クロスチェーン送金では、送金先チェーンの同じアドレスにコントラクトがあるか確認する
- ウォレットのアドレス帳を活用し、承認済みアドレスのみに送る
特に、決済代行やフォワーダーを介した送金では、生成されるアドレスが決定論的であることを理解しておく。これにより、存在しないアドレスへの送金を未然に避けられる。暗号資産の送金は不可逆であり、事前確認がすべてと言っても過言ではない。
よくある質問
CREATE2で作られたアドレスに送ったトークンは自動的に動きますか？
いいえ、自動的には動かない。デプロイされていないアドレスにはコードがないため、トークンはその場に留まる。デプロイされるとコードが実行されるが、送金先が固定されている場合は第三者へ送られる。
デプロイ前のアドレスから資金を引き出す方法はありますか？
原則ない。コードが存在しないため、トークンを動かす関数を呼び出せない。デプロイヤーが何らかの救済用コントラクトをデプロイする可能性はあるが、通常は設計次第だ。
コントラクトのコードを後から変更して送金先を変えられますか？
通常はできない。スマートコントラクトは不変が原則で、プロキシを使っていても管理者関数がない限り変更できない。書き込み専用の設計ならなおさらだ。
法的措置を検討する場合、どこに相談すればよいですか？
暗号資産に詳しい弁護士に相談するのが現実的だ。日本では民事訴訟やADRの利用が考えられるが、相手の特定と管轄が大きな壁になる。証拠となる取引ハッシュやアドレス情報を整理して相談する。
このような事故は頻繁に起きていますか？
クロスチェーン送金や新しいプロトコルの利用時に散発的に発生する。決定論的アドレスの仕組みを理解していないユーザーほど陥りやすい。テスト送金と確認が最も有効な予防策だ。
この記事のポイント
- CREATE2の決定論的アドレスはデプロイ前でも送金できるため、誤送金が起こる
- デプロイ後のコードが第三者宛て固定なら、技術的な回収はほぼ不可能
- 回収はオフチェーンの交渉か法的手段に限られる
- 送金前のアドレス確認とテスト送金で大半の事故を防げる
「エミリーズ・クリプト・インサイダー」のリサーチ担当として、暗号資産の現場で日々生まれる疑問や悩みを丹念に追いかける。
Reddit や海外フォーラムに寄せられる声を読み解き、「初心者がつまずきやすいポイント」「経験者でも見落としがちな落とし穴
」を一つずつ記事として整理している。
専門的な話を誰もが理解できる言葉に置き換えることに全力を注ぐ。情報の正確さと読みやすさの両立を信条としている。