暗号資産の送金方法：アドレス・承認・エクスプローラー確認

最初に確認するのは金額ではなく送金経路

送金経路は「資産＋ネットワーク＋トークン契約＋宛先仕様」の組です。たとえば同じtickerのトークンが複数ネットワークに存在し、bridge版や偽tokenが同じ名称を使うことがあります。送信元の出金画面と受信側の入金画面の双方で、対応ネットワーク、contract address、最小入金額、必要承認数、memo/tag、停止情報を確認します。片側だけの表示を信頼してはいけません。

取引所の内部振替はオンチェーン取引を伴わない場合があり、反対に自己保管ウォレット間はnetwork feeが必要です。受取先がスマートコントラクトの場合、単純送金を受け取れない、または送ったtokenを自動処理しないことがあります。初回、金額が大きいとき、アドレス変更後、ネットワークupgrade後は必ず少額テストを行います。

回収サービスがあっても成功・期間・費用は保証されません。

コピー＆ペースト後に、別経路で宛先を再照合する

アドレスは口座番号に似ていますが、ネットワークと形式が結び付き、入力ミスの取消し窓口がないことが一般的です。QRコードやコピーを使っても、clipboard malwareが文字列を置換する可能性があります。送信端末と受取端末を分け、先頭・末尾の複数文字、全長、checksum、アドレス帳ラベルを照合します。高額送金では、既知の少額テストtxから宛先を再利用する方が安全です。

ENS等の人間可読名は入力を簡単にしますが、名前解決が正しいnetworkとaddressを返すか、登録が期限切れでないか、似た文字がないかを確認します。memo/tagが必要な取引所では、addressが事業者共通でmemoが顧客識別子になる場合があります。memo欠落は台帳上の着金と口座反映を分離させる典型です。

署名画面で「誰に何を許可するか」を読む

単純送金の署名は宛先・数量・feeを承認しますが、token操作ではapprove、permit、contract callが混ざります。表示が「接続」でも、実際には広い支出権限を与えるメッセージ署名のことがあります。blind signingは人が読めないデータへの署名を許すため、対応アプリ、contract、function、spender、amountを別資料で確認します。未知の署名要求は拒否します。

nonceはEthereum系で同じaccountの取引順序を管理し、UTXOモデルではどの未使用出力を消費しchangeをどこへ返すかが重要です。wallet UIが自動選択しても、feeと受取額が期待どおりか確認します。署名済み取引がネットワークへ送られる前なら破棄できる場合がありますが、broadcast後の取消しはネットワーク仕様に依存し、成功を保証できません。

mempool・block inclusion・finality・口座反映を分ける

broadcastされた取引はノードへ伝播し、mempool等の未確定領域へ入ります。検証者がblockへ含めると一回以上の承認を得ますが、直近blockは再編成される可能性があります。ネットワークによって確率的finalityと明示的finalityが異なり、受取事業者は資産ごとに必要承認数を独自設定します。画面のpendingが長いからといって、同じ取引を無計画に作り直すと二重の意図を生むことがあります。

Bitcoinではfee率が低い取引が長く未確定になる場合があり、RBFやCPFP等の方法はwalletと取引条件に依存します。Ethereum系では同じnonceで高いfeeの置換取引を送る方法がありますが、誤操作すると意図しない取引が先に確定し得ます。必ずwalletの公式手順を使い、サポートを装う相手にシードや署名を渡さないでください。

• 送信済み: walletや取引所が処理を受け付けた状態。
• broadcast: transaction hashがnetworkへ伝播した状態。
• included: blockへ入った状態。
• finalized/深い承認: 変更可能性が設計上または経済的に下がった状態。
• credited: 受取事業者が内部口座へ反映した状態。

エクスプローラーで成功・失敗・宛先・feeを確認する

block explorerへtransaction hashを入力すると、status、block、timestamp、from、to、value、fee、confirmations、token transfers、contract logs等を確認できます。まず正しいnetworkのexplorerかを確認します。同じtx hash形式でも別networkのサイトでは見つかりません。contract interactionでは外側のtransactionがsuccessでも、期待したtoken移転がlogにない、swapがslippage条件でrevertした等を分けて読みます。

explorerは台帳を見やすくする第三者インターフェースです。表示障害やindexing遅延があり得るため、複数explorerやwalletのnode接続で照合します。受取事業者へ問い合わせるときは、tx hash、asset、network、時刻、数量、宛先、memo/tag、必要承認数を伝えます。秘密鍵、seed、二要素認証code、remote accessは不要です。

1. 01networkを選ぶ

   explorerのchain IDと送信networkを一致させる。

2. 02statusを読む

   pending、success、failed/revertedを区別する。

3. 03宛先と値を照合

   to、token transfers、internal actionsを確認する。

4. 04feeと承認を記録

   native単位と法定通貨換算時点を分ける。

5. 05受取側へ照合

   必要承認後も未反映なら証拠を添えて問い合わせる。

少額テストを本番と同じ条件で行い、台帳へ残す

テスト送金は本番と同じnetwork、asset contract、受取address、memo/tagを使い、受取側の最小入金額を上回る必要があります。テストだけ別networkや別walletを使えば、本番経路の検証になりません。テスト着金後、アドレス帳へ登録し、変更時には再テストします。大量送金は分割が安全性を高める場合がありますが、feeと税務記録件数が増えるため総コストを確認します。

SG Groupの金融テンプレートHubには、日時（timezone付き）、送信元/先ラベル、asset、network、contract、数量、native fee、換算rate、tx hash、status、purpose、証拠URLを記録できます。暗号資産の税務記録では、送金と処分を区別し、feeの扱いを地域ルールに合わせて保存する方法を扱います。

送金に価格変動を伴うCrypto CFDはオンチェーン送金ではなく差金決済契約です。点価値・必要証拠金はロット計算機、spread・commission・fundingは資産クラス別取引コストへ分け、現物送金のnetwork feeと混ぜないでください。