> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # ウォレット所有権ウィジェット: トラベルルールの管理証明 > Diditのホスト型ウィジェットは、メッセージ署名、サトシテスト、スクリーンショット、自己申告のいずれかで、顧客が暗号資産ウォレットを管理していることを証明します。トラベルルール対応に利用できます。 ウォレット所有権ウィジェットは、顧客が特定の暗号資産ウォレットアドレスを管理していることを証明するホスト型ページです。EU TFRでは、VASPはサンライズしきい値を超える資金をセルフホスト型(アンホステッド)ウォレットとの間で送受信する前に、そのウォレットの所有権を検証しなければなりません。このウィジェットを使えば、署名フローを自前で構築しなくても、Diditがその証明を収集します。 証明が検証されると、対応する[ウォレットアドレス帳のエントリ](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md#ウォレットのアドレス帳)が`is_ownership_verified: true`としてマークされ、紐づく[トラベルルール送金](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md)が`UNCONFIRMED_OWNERSHIP`から次の状態へ進めるようになります。 ## Diditが自動で発行する場合 セッションを自分で発行する必要はほとんどありません。 [トラベルルールの設定](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md#セットアップ)で`auto_wallet_verification`が有効な場合(デフォルト)、送金にエンドユーザーによるウォレットを管理していることの証明が必要になると、Diditは取引の作成時にウィジェットセッションを自動で発行します。 * 送金が`UNCONFIRMED_OWNERSHIP`の状態にある場合。これは、送信時に取引相手のウォレットが[セルフホスト型として申告された](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md#申告されたセルフホスト型ウォレット)ことを意味します。 * 送金が送信方向で、かつ`COUNTERPARTY_VASP_NOT_FOUND`の状態にある場合。取引相手のVASPを特定できなかったため、完了に至る残りの手段は所有権の証明です。 自動発行されたセッションは取引の`action_required`ブロック(`type: "wallet_ownership"`、開くための`url`付き)で返され、[クライアント側からの送信](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md#ユーザーに必要なアクション)時にはSDKが自動的に起動します。 Diditが代わりに作成する受信方向の送金(サンライズ登録、受信方向の`TRP`照会、`INTERNAL`レールの受信側レッグ)には、`UNCONFIRMED_OWNERSHIP`の状態になった場合でも、セッションが自動発行されることはありません。 送金が存在する前にウォレットを事前検証したい場合、`auto_wallet_verification`を無効にしている場合、または上記の受信方向の送金のいずれかに対しては、`POST /v3/travel-rule/widget-session/`で手動で発行してください。 ## 証明できること ウィジェットでは最大4種類の証明方式を提供します。どの方式が表示されるかは、セッションのミント方法と[トラベルルールの設定](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md#セットアップ)によって決まります。 | 方式 | 仕組み | 提供される条件 | | - | - | - | | `MESSAGE_SIGNING` | 顧客は、Diditが発行したチャレンジ文字列にウォレットで署名します。EVM、Solana、Bitcoin、Tronのウォレットに対応しています（Bitcoinではレガシー、ネステッドSegWit、ネイティブSegWit、Taprootの各アドレスに対応）。Diditは署名をアドレスと照合して検証します。検証対象とは別のアカウントで署名した場合は拒否され、アカウントの切り替えを促すわかりやすいメッセージが表示されます。EVMのスマートコントラクトアカウント（ERC-4337スマートウォレット）でも署名できます。Diditは、ウォレットに指定されているチェーン上で、そのアカウント自身のコントラクトに署名が有効かどうかを問い合わせます（ERC-1271）。まだデプロイされていないアカウントについては、ウォレットが返すERC-6492署名を確認します。その際、アカウントをデプロイすることも、取引を送信することもありません。スマートコントラクトアカウントは、対応するすべてのEVMチェーンで確認されます。後述の[メッセージ署名の検証仕様](#メッセージ署名の検証仕様)を参照してください。顧客のブラウザにインストールされているウォレットはEIP-6963およびWallet Standardプロトコルで検出されるため、拡張機能ごとに個別の署名オプションとして表示されます。QRコードなどで別のモバイルウォレットアプリとペアリングする機能は、現時点では利用できません。 | 対応するチェーンファミリーでは常に提供されます。 | | `SATOSHI_TEST` | 顧客は、ウォレットから貴社が管理する入金アドレスへ、ごく少額をオンチェーンで送金します。Diditの監視機能が、送金元（EVMのスマートコントラクトアカウントの場合は、ERC-4337バンドラーが取引を送信したときも含めてアカウント自体）、金額、および入金がオンチェーンで確定したことを確認し、確定した時点で自動的に証明を完了します。後述の[Satoshiテストの検証仕様](#satoshiテストの検証仕様)を参照してください。 | ミント時に`satoshi_deposit_address`を渡し、かつチェーンがEVM、Bitcoin、Solanaのいずれかである場合のみ提供されます。そのため、自動ミントされたセッションでは提供されません。 | | `SCREENSHOT` | 顧客は、アドレスが表示されたウォレットのスクリーンショットをアップロードします（JPEG/PNG/WebP、最大10MB）。他の方式とは異なり、自動で検証されることはありません。貴社のコンプライアンスチームがスクリーンショットのレビューキュー（[`GET /v3/travel-rule/wallet-proofs/`](https://docs.didit.me/ja/management-api/travel-rule/list-wallet-proofs)）で確認して承認または拒否する（[`POST .../decision/`](https://docs.didit.me/ja/management-api/travel-rule/decide-wallet-proof)）か、コンソールの取引の**トラベルルール**タブ、または[`POST .../travel-rule/ownership/`](https://docs.didit.me/ja/management-api/travel-rule/confirm-ownership)で送金を確認します（`UNCONFIRMED_OWNERSHIP`状態の送金、または保留中の受信送金が対象）。 | 設定で`allow_screenshot_proof`が`true`の場合のみ提供されます。 | | `SELF_DECLARATION` | 顧客が暗号学的な証明なしに所有を宣言します。法域が認める場合に限った最終手段です。 | `allow_self_declaration`が`true`で、かつ[`ownership_validation_mode`](https://docs.didit.me/ja/transaction-monitoring/travel-rule#所有権検証モード)が紐づく送金について宣言を受け入れる場合のみ提供されます。`FULL`では提供されず、`SIMPLIFIED`では`simplified_validation_threshold`未満の場合のみ提供されます。モードが受け入れない宣言を開始すると`403`が返されます。 | ### メッセージ署名の検証仕様 署名を送信すると、ウォレットの管理権限が証明された時点で`status: "VERIFIED"`とともに`200`が返されます。 証明できない場合は、以下のいずれかの`code`値とともに`400`が返されます。証明はオープンのまま残るため、顧客は再度署名できます。 | `code` | 意味 | | - | - | | `SIGNATURE_INVALID` | 署名がウォレットの管理を証明していません。別のアカウントまたは鍵で署名されたか、メッセージが異なります。スマートコントラクトアカウントの場合は、そのコントラクトが自身の署名ではないと応答しました。 | | `SIGNATURE_UNSUPPORTED_SCHEME` | ウォレットが、Diditが検証しない形式で署名しました。たとえばBitcoinのマルチシグやBIP-322のフル署名です。 | | `SIGNATURE_LOOKUP_FAILED` | ウォレットがスマートコントラクトアカウントである可能性があり、現時点でそのチェーンを確認できませんでした。この応答で証明が検証済みになることはありません。再度署名すると、改めて確認が行われます。 | ### Satoshiテストの検証仕様 Satoshiテストの入金の検証は非同期で行われます。取引がオンチェーンで検出され、その後確定する必要があるためです。 入金の`txid`を送信すると、入金がまだオンチェーンで確定していない間は`status: "PENDING"`とともに`200`が返されます。このとき`txid`は破棄されず保持されます。 入金が確定すると、`status: "VERIFIED"`とともに`200`が返されます。 入金が明らかに誤っている場合は、`status: "REJECTED"`とともに`400`が返されます。該当するのは、別のウォレットから送金された場合、入金アドレスへの送金額が想定と異なる場合、チャレンジより前の取引である場合、またはすでに別のウォレットの証明に使われた取引である場合です。この証明はクローズされますが、セッションに試行回数が残っていれば、顧客は新しい証明を開始できます。 まだインデックスされていない入金の場合も`status: "PENDING"`とともに`200`が返されます。また、Didit側で照会に失敗した場合は、コード`DEPOSIT_LOOKUP_FAILED`とともに`400`が返されます。いずれの場合も証明はオープンのまま残り、Diditが確認を続けます。 有効な入金が検出される前にテスト期間が終了した場合は、`410`が返されます。 `txid`が送信されると、バックグラウンドジョブが保留中の入金を5分ごとに再確認し、取引の確定後に証明を完了します。そのため、顧客が`txid`を再送信する必要はありません。 `satoshi_deposit_address`を渡した場合、ウィジェットセッション自体の`expires_at`は、Satoshiテストの24時間の期間以上になるよう延長されます。これにより、セッション自体が期限切れになる前に入金が確定する時間を確保できます。 ## フロー **1. ウィジェットセッションを発行する** 検証が必要なウォレットを指定して`POST /v3/travel-rule/widget-session/`を呼び出します。必要に応じて送金に紐付けると、所有権が証明された時点でその送金が自動的に進みます。 **2. 返されたURLを開く** 顧客をレスポンスの`url`に誘導します。顧客はそこで証明を完了します。DiditのアカウントやAPIキーは不要で、URL内のトークンが認証になります。 **3. 完了を検知する** 証明が検証されると、ウィジェットはアドレス帳エントリを検証済みにし、セッションが送金に紐付いている場合はその送金を進めます。`travel_rule.status.updated`(紐付けた送金の場合)を監視するか、ウィジェットコンテキストをポーリングしてください。 ### ウィジェットセッションを発行する この例では、トラベルルールガイドの[申告済みのセルフホスト型送金](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md#申告されたセルフホスト型ウォレット)にセッションを紐付けるため、`wallet_address`はその送金の送金先ウォレットです。 送金に紐付けたセッションは、その送金の取引相手のウォレットに対する証明のみを受け付けます。 ```bash theme={null} curl -X POST https://verification.didit.me/v3/travel-rule/widget-session/ \ -H "x-api-key: YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9", "chain": "ETH", "holder_name": "Jane Doe", "vendor_data": "user-042", "transaction_id": "99999999-aaaa-bbbb-cccc-dddddddddddd", "satoshi_deposit_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F", "callback_url": "https://yourapp.example/wallet-verified", "expires_in_minutes": 60 }' ``` | フィールド | 型 | 説明 | | - | - | - | | `wallet_address` | string | 検証するウォレットアドレス。 | | `chain` | string | アドレスのチェーン識別子(例: `ETH`、`BTC`、`SOL`)。送金で使用しているものと同じトークンを使用してください(`ethereum`ではなく`ETH`)。ウィジェットはこの`chain`でアドレス帳エントリを保存するため、別のチェーン上の送金とは一致しません。メッセージ署名には、Diditが認識するチェーンが必要です。 | | `holder_name` | string | ウォレット保有者の名前。受取人の名前照合に使用されます。 | | `vendor_data` | string | 保有者を表す貴社の内部識別子。作成されるアドレス帳エントリに引き継がれます。 | | `transaction_id` | string (uuid) | 任意。証明が検証されたときに進めるトラベルルール送金の、DiditトランザクションUUID。不明なUUIDの場合は`404`が返され、送金の取引相手のウォレット以外のウォレットに対する証明は`400`で拒否されます。ウォレットを単独で検証する場合は省略してください。 | | `satoshi_deposit_address` | string | 任意。貴社が管理する入金アドレス。指定すると`SATOSHI_TEST`メソッドが有効になります。 | | `callback_url` | string | 任意。完了後にウィジェットが顧客を戻す先。 | | `expires_in_minutes` | integer | 任意。発行されるリンクの有効期間(分)。`5`から`10080`まで(デフォルトは`60`)。`satoshi_deposit_address`を指定した場合は、24時間のSatoshiテスト期間以上に自動的に引き上げられます。 | ```json theme={null} { "widget_session_id": "77777777-8888-9999-aaaa-bbbbbbbbbbbb", "token": "3s9x...urlsafe", "url": "https://verify.didit.me/wallet-ownership/3s9x...urlsafe", "expires_at": "2026-07-07T13:00:00Z" } ``` レスポンスで返された`url`は必ずそのまま開いてください。自分で組み立ててはいけません。 ### 返されたURLを開く > [!WARNING] > > **このリリースでは、ウィジェットはWeb専用です。`url`はシステムブラウザまたはカスタムタブで開いてください。Diditモバイル SDKのWebView内では絶対に開かないでください。** > > メッセージ署名は、顧客のブラウザにインストールされたウォレットで動作し、ウィジェットはEIP-6963およびWallet Standardプロトコルを通じてそれらを検出します。 > QRコードなどで別のモバイルウォレットアプリとペアリングする機能は現在利用できないため、ウィジェットが別のアプリに処理を引き渡すことはありません。 > Didit Web/Flutter/React Native/iOS/Android SDKのWebViewなどのアプリ内WebViewからは**顧客のブラウザウォレットにアクセスできない**ため、そこで開いたウィジェットでは顧客が署名する手段がなくなります。 > > モバイルでは、`url`をWebViewで表示するのではなく、OSのブラウザ(`SFSafariViewController` / Chrome Custom Tabs、またはデフォルトブラウザ)で起動してください。Webでは、通常のタブまたはポップアップで問題ありません。 ### 完了を検知する ウィジェットは、トークンをキーとする公開の読み取りエンドポイントを提供しています。これをポーリングして進捗を確認するか、セッションが送金に紐付いている場合はWebhookを利用してください。 ```bash theme={null} curl https://verification.didit.me/v3/travel-rule/widget/{token}/ ``` ```json theme={null} { "vasp_name": "Origin CASP SL", "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9", "chain": "ETH", "holder_name": "Jane Doe", "allowed_methods": ["MESSAGE_SIGNING", "SCREENSHOT", "SATOSHI_TEST", "SELF_DECLARATION"], "transfer_status": "UNCONFIRMED_OWNERSHIP", "callback_url": "https://yourapp.example/wallet-verified", "expires_at": "2026-07-07T13:00:00Z", "completed_at": null, "proofs": [ { "proof_id": "88888888-9999-aaaa-bbbb-cccccccccccc", "method": "SATOSHI_TEST", "status": "PENDING", "wallet_address": "0xd3b62acb76fb27a7f8961ec40fa11746b113aca9", "chain": "ETH", "deposit_address": "0x71C7656EC7ab88b098defB751B7401B5f6d8976F", "expected_amount": "0.000042817305521963", "expires_at": "2026-07-07T13:05:00.412731+00:00", "created_at": "2026-07-06T13:05:00.412731Z" } ], "customization": null } ``` * 証明が検証されると、`completed_at`がnull以外の値になります。 * `proofs`の各エントリには、そのメソッドに必要なフィールドが含まれます。`SATOSHI_TEST`の証明には`deposit_address`、`expected_amount`、および独自の`expires_at`が追加され、`MESSAGE_SIGNING`の証明には顧客が署名する文字列である`challenge`が追加されます。 * `SATOSHI_TEST`の証明は、入金がオンチェーンで検出されたものの未承認の間、`status: "PENDING"`のままになることがあります。貴社や顧客の対応は不要です。上記の[Satoshiテストの検証仕様](#satoshiテストの検証仕様)を参照してください。 * `transaction_id`を指定してセッションを発行した場合、証明が検証されると紐付けた送金が進み、本番環境のアプリケーションでは[`travel_rule.status.updated`](https://docs.didit.me/ja/integration/webhooks#イベントタイプ)のWebhookが発火します。 ポーリングよりもWebhookを優先してください。 受信側の`TRP`照会は送信元に承認が返され、その承認が配信されると`COMPLETED`に移行します。 その他の`UNCONFIRMED_OWNERSHIP`の送金(または`ON_HOLD`の受信送金)は`COMPLETED`に移行し、受取人の名前がウォレット保有者と一致しない場合は`COUNTERPARTY_MISMATCHED_DATA`に移行します。また、決済済みのサンライズ入金が完了すると、さらに`FINISHED`に進みます。 `COUNTERPARTY_VASP_NOT_FOUND`の送信側送金は`COMPLETED`に移行します。 * `SCREENSHOT`の証明は、所有権を確認した後も、このコンテキストでは`status: "PENDING"`のままです。 承認には[`POST .../travel-rule/ownership/`](https://docs.didit.me/ja/transaction-monitoring/travel-rule#ウォレット所有権の確認)を使用しますが、これは所有権確認待ちの送金のみを受け付けます。 そのため、送金が紐付いていないセッションや、`COUNTERPARTY_VASP_NOT_FOUND`の送信側送金に紐付いたセッションでは、スクリーンショットを承認する手段がありません。これらのセッションでスクリーンショットを提供してはならない場合は、`allow_screenshot_proof`をオフにしてください。 * 証明が拒否された後も、試行回数が残っている間はセッションで新たな試行を受け付けます。 `max_attempts`、`attempts_used`、`attempts_remaining`が回数を示し、拒否された証明には`rejection_reason`が含まれます。`attempts_remaining`が`0`のときに別の証明を開始すると`409`が返されるため、新しいセッションを発行してください。 * コンテキストエンドポイントは、不明なトークンに対しては`404`を、セッションが完了せずに期限切れになった後は`410`を返します。 > [!NOTE] > > ここには一度きりの処理に依存する箇所はありません。ウィジェットと貴社のバックエンドはどちらも同じ永続的な状態(検証済みのアドレス帳エントリと送金ステータス)に収束するため、Webhookが届かなかった場合やタブが閉じられた場合でも、送金またはウィジェットコンテキストを再取得すれば必ず復旧できます。 ## ローカライズとブランディング ウィジェットは**54言語**で表示され、リンクの言語パス(またはブラウザーの既定言語)に従います。 アプリケーションでホワイトラベルが有効になっている場合、ウィジェットは認証フローのブランディングを自動的に引き継ぎます。対象はロゴ、ブランドカラー、ボタンとパネルのスタイル、カスタムフォント、ファビコン、そしてタイトルに表示されるアプリの公開名です。 個別の設定は不要です。KYCセッション用に設定したカスタマイズがそのまま適用されます。 すでに完了したリンクに戻ったユーザーには、完了画面が再度表示されます。`callback_url`を渡している場合、ウィジェットはユーザーをそのURLに戻します。 期限切れのリンクでは、ブランディングが適用された期限切れ画面が表示され、新しいリンクをリクエストするよう案内されます。 そのユーザーのために`POST /v3/travel-rule/widget-session/`で新しいセッションを発行してください。`action: "resend"`で送金を再送しても、新しいセッションは発行されません。 ## 次のステップ > [card] [トラベルルール](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md) > > 取引のライフサイクル全体、送金レール、設定、受取フロー。 > [card] [ウォレットアドレス帳](https://docs.didit.me/ja/transaction-monitoring/travel-rule.md#ウォレットのアドレス帳) > > 管理しているウォレットを登録し、受信した送金をそのウォレットに照合できるようにします。 > [card] [Webhook](https://docs.didit.me/ja/integration/webhooks.md) > > travel\_rule.status.updatedを購読し、証明によって送金が進んだときに対応します。 > [card] [ネイティブSDK](https://docs.didit.me/ja/integration/native-sdks/overview.md) > > ウィジェットのURLは、SDKのWebViewではなくシステムブラウザーで開いてください。 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.