dflow-proof-kyc について
dflow-proof-kycは、SolanaアプリにKYC確認を導入する開発者向けのスキルです。DFlow Proofで検証済みの本人情報をウォレットに結び付ける方法や、状態確認、署名付きリンク、復帰後の処理を説明します。
主な機能
- 01公開エンドポイントでウォレット状態を確認
- 02署名付きディープリンクで認証を開始
- 03ユーザー復帰後に状態を再確認
- 04生メッセージ署名に対応するウォレットを利用
- 05キャッシュとサーバー側検証の注意点を説明
活用シーン
- 01KYCが必要な機能へのアクセスを制限
- 02未認証時に認証への導線を表示
- 03埋め込みウォレットを本人確認フローに接続
MCP 対応
署名コード、パラメーター、ユーザーフローの資料を参照するため、DFlow docs MCPの利用が必要です。MCPは連携時のリファレンスとして使われます。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ dflowprotocol/ dflow-skills --skill dflow-proof-kycインストール後、Claude Code で/dflow-proof-kycを入力して読み込まれたか確認します。
詳細
DFlow Proof
Proof は、Solana ウォレット向けの DFlow の本人確認プリミティブです。Stripe Identity が一度だけ本人確認を行い、Proof はその確認済みの本人情報を 1 つ以上のウォレットアドレスに紐付けます。開発者は公開エンドポイントに問い合わせて、ステータスを確認できます。
Proof を使って、ご自身のアプリに独自の利用制限を設けましょう。本人確認ベースの KYC が必要な製品(管轄区域によって利用が制限される DeFi、規制対象のトークン販売、本人確認済みであることを証明したうえでのアクセスなど)であれば、すぐに利用できるプリミティブとして Proof を活用できます。
前提条件
- DFlow docs MCP(
https://pond.dflow.net/mcp)— リポジトリの README に従ってインストールしてください。このスキルは手順書で、MCP はリファレンスです。search_d_flow/query_docs_filesystem_d_flowで、ディープリンクの署名コード、すべてのパラメーター一覧、ユーザージャーニーの図を確認してください。推測しないでください。
ご自身のアプリに利用制限を設ける
ご自身のアプリで KYC が必要な場合に使用します。
本人確認ステータスを確認する
GET https://proof.dflow.net/verify/{address} → { "verified": boolean }。公開されており、認証は不要です。 機能の利用制限、「本人確認する」CTA を表示するかどうかの判断、または制限されたアクションを事前に終了するために使用します。
ユーザーを本人確認にリダイレクトする(ディープリンク)
ウォレットが本人確認済みでない場合は、Proof のホスト型フローにユーザーをリダイレクトします。ディープリンクには署名済みの所有権証明が含まれており、Proof は確認済みの本人情報にウォレットを自動的に紐付けることができます。
- URL:
https://dflow.net/proof?wallet=<addr>&signature=<sig>×tamp=<ms>&redirect_uri=<url> - 省略可能:
email、projectId。 - 署名:ユーザーはウォレットを使い、正確なメッセージ
Proof KYC verification: {timestamp}(Unix ミリ秒、13 桁)に署名します。バイト列を base58 でエンコードしてください。 - 署名の完全なコード例とパラメータ表 → docs MCP を参照するか、直接
/proof/partner-integrationをご覧ください。
リダイレクト後の処理
ユーザーは redirect_uri に戻ります。ステータスを確認するため、/verify/{address} に再度問い合わせてください。verified: true の場合は処理を続行します。それ以外の場合は、「本人確認中/失敗」などの適切なメッセージを表示してください。
埋め込みウォレット(Privy、Turnkey など)
Proof が必要とするウォレット機能は、所有権メッセージへの署名 1 つだけです。次の機能を提供するウォレットであれば、
signMessage: (message: Uint8Array) => Promise<Uint8Array>
ディープリンクフローを変更せずに利用できます。埋め込みウォレット SDK(Privy、Turnkey など)は Phantom/Solflare と同様にこの機能を提供するため、埋め込みウォレット専用の Proof フローはありません。
- ステータスの確認にウォレットは不要です。
GET /verify/{address}は公開されており、アドレスのみを受け取るため、ウォレットの保管方法にかかわらず、利用制限/CTA のロジックは同じです。 - 所有権署名の生成でのみウォレットが関与します。
Proof KYC verification: {timestamp}(Unix ミリ秒、13 桁)を生成し、UTF-8 でエンコードしてから、プロバイダーの署名機能で生のバイト列に署名し、結果を base58 でエンコードします。その値をディープリンクのsignatureとして渡してください。
import bs58 from "bs58";
const timestamp = Date.now(); // Unix ms, 13 digits
const messageBytes = new TextEncoder().encode(`Proof KYC verification: ${timestamp}`);
const signatureBytes = await wallet.signMessage(messageBytes); // Privy / Turnkey embedded signer
const signature = bs58.encode(signatureBytes); // base58 — NOT hex, NOT JSON.stringify
// → build https://dflow.net/proof?wallet=<pubkey>&signature=<signature>×tamp=<timestamp>&redirect_uri=<url>
- 確認すべき唯一の前提条件: プロバイダーがバイト列に対する生メッセージ署名を提供している必要があります。SDK がトランザクションにしか署名できず(
signMessageがない場合)、所有権証明を生成できません。Proof を埋め込みウォレットプロバイダーに接続する前に、必ず確認してください。
ユーザーに確認すること(および確認しないこと)
不足している場合は確認してください:
- ウォレットの公開鍵 — 本人確認/ステータス確認を行うアドレス。
- アプリのコールバック URL(
redirect_uri)— 本人確認後に Proof がユーザーを戻す先。 - Web またはネイティブモバイル — リダイレクト URI の案内が変わります(モバイルではユニバーサルリンク/アプリリンクを使用します。「注意点」を参照してください)。
確認しないでください:
- API キー —
/verify/{address}は公開されており、認証は不要です。Proof 自体に API キーの概念はありません。
つまずきやすい点(docs MCP では教えてくれません)
- DFlow のスポットスワップに Proof は不要です。「DFlow のすべての取引に KYC が必要」と述べないでください。必要ありません。
- **Proof では年齢を確認できません。**Stripe Identity では氏名、住所、メールアドレス、政府発行の身分証明書を取得しますが、Proof は現在、生年月日を確認も公開もしていません。年齢制限には Proof を使わないでください。必要な情報は得られません。
- **開発環境と本番環境の両方で適用されます。**開発環境は保護されていないと思い込むエージェントは多いですが、保護されています。
- リダイレクト URI のスキームには制限があります。Proof がリダイレクトするのは
https:、chrome-extension:、moz-extension:の URL のみです。カスタムスキーム(myapp://callback)は何も通知されずに失敗します。リダイレクトもエラーもありません。ネイティブモバイルアプリでは、アプリへのディープリンクに使うhttps:URL であるユニバーサルリンク(iOS)/アプリリンク(Android)を使用してください。 - 公開エンドポイントの結果は真偽値に集約されます。
/verify/{address}は{ verified: true | false }を返します。pending/failed/unverifiedの区別はありません。未確認の状態はすべてfalseにまとめられます。UX でこれらの状態を区別する必要がある場合は、公開チェックではなく、ユーザーが Proof から戻ってきたかどうかなど、自前のセッション状態から判断してください。 - **キャッシュするのは
trueであり、falseではありません。**一度確認されたウォレットは確認済みのままなので、キャッシュすればチェックの繰り返しを避けられます。一方、未確認の状態は変わりやすいため、決してキャッシュしないでください。ユーザーがフローを完了した時点で状態が切り替わります。 - **自分のアプリでアクセス制限を設ける場合は、サーバー側で確認してください。**バックエンドが KYC を条件とする機能を適用する場合、クライアントにキャッシュされた状態を信用しないでください。制限対象の操作を許可する前に、バックエンドから
/verify/{address}を再照会してください。 - **埋め込みウォレットも利用できます。**Privy、Turnkey などの場合も、バイト列に対する生の
signMessageがあれば十分です。署名コードは上記の埋め込みウォレットを参照してください。これらに固有の Proof フローはありません。 - **1 つの確認済み ID で、ウォレットを無制限に追加できます。**上限はありません。ウォレット A で確認を完了したユーザーは、ID とライブネスの確認をやり直すことなく、ウォレット B、C、D 以降もリンクできます。必要なのは、新しいウォレットごとの新たな所有権署名だけです。
- **無料で、内部では Stripe Identity を使用します。**開発者にもユーザーにも費用はかかりません。ユーザーは Stripe の書類確認とライブネス確認のフローを完了します。
- **Proof はジオブロッキングではありません。**KYC と管轄区域による制限は別のものであり、それぞれ異なる考慮事項です。
要件に合わない場合
詳細なリファレンスについては docs MCP を参照してください。特に次のページをご覧ください。
/proof/introduction— Proof の概要。利用するタイミング、ID グラフモデル、確認対象について説明します。/proof/partner-integration— ディープリンクのコード(署名の生成、URL の構築)、キャッシュのサンプル、エッジケースへの対応(署名の有効期限切れ、ユーザーによるキャンセル、ネットワークエラー)、セキュリティに関するガイダンス、リダイレクトスキームのデバッグ(#deep-link-parameters)を詳しく説明します。/proof/user-journeys— 新規ユーザーの直接フロー、新規ユーザーのパートナー経由フロー、再訪ユーザーのフローを図で説明します。/resources/proof-api/verify-address— 唯一の公開エンドポイントのリファレンスです。
関連スキル
dflow-spot-trading— Solana トークンのスワップ。Proof は一切不要です。dflow-market-data— ライブのスポット市場データストリーム。読み取り専用で、Proof は不要です。