dflow-proof-kyc

DFlow Proof

Proof 是 DFlow 为 Solana 钱包提供的身份验证基础功能。Stripe Identity 只需验证一次用户身份；Proof 会将该已验证身份关联到一个或多个钱包地址。开发者可以查询公开端点来检查验证状态。

使用 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>&timestamp=<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 只依赖一项钱包功能：对所有权消息进行签名。任何提供

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>&timestamp=<timestamp>&redirect_uri=<url>

• 需要确认的唯一前提：提供方必须支持对字节进行原始消息签名。如果 SDK 只能对交易签名（没有 signMessage），它就无法生成所有权证明——在将 Proof 接入嵌入式钱包提供方之前，请先确认这一点。

需要向用户询问什么（以及不应询问什么）

如果缺少以下信息，请询问：

1. 钱包公钥——要验证 / 检查的地址。
2. 应用的回调 URL（redirect_uri）——Proof 在验证后将用户发送到的地址。
3. Web 还是原生移动端——这会影响 redirect_uri 指引（移动端使用通用链接 / 应用链接；参见注意事项）。

不要询问：

• API 密钥——/verify/{address} 是公开端点，无需身份验证。Proof 本身没有 API 密钥的概念。

注意事项（文档 MCP 不会主动提醒你）

• DFlow 现货兑换不需要 Proof。 不要声称“所有 DFlow 交易都需要 KYC”——并非如此。
• Proof 不会验证年龄。 Stripe Identity 会采集姓名、地址、电子邮件和政府签发的身份证件，但 Proof 目前不会检查或公开出生日期。不要使用 Proof 进行年龄门槛验证——你拿不到所需信息。
• 开发环境和生产环境都会强制执行。 许多 Agent 以为开发环境不受保护；事实并非如此。
• 重定向 URI 方案限制。 Proof 只会重定向到 https:、chrome-extension: 和 moz-extension: URL。自定义方案（myapp://callback）会静默失败——不会重定向，也不会报错。原生移动应用应使用通用链接（iOS）／应用链接（Android），这些都是可深度链接到应用的 https: URL。
• 公共端点会将状态简化为布尔值。 /verify/{address} 返回 { verified: true | false }。没有 pending／failed／unverified 之分——所有非已验证状态都会归为 false。如果用户体验需要这些状态，请根据你自己的会话状态推断（用户是否从 Proof 返回），而不是依赖公共检查。
• 缓存 true，不要缓存 false。 钱包一经验证就会保持已验证；缓存可以避免重复检查。但未验证状态具有时效性——绝不要缓存，因为用户完成流程后状态就会改变。
• 要在自己的应用中实施门槛验证，请在服务器端验证。 如果你的后端负责强制执行 KYC 门槛功能，不要信任客户端缓存的状态。在解锁受限操作之前，请从后端重新查询 /verify/{address}。
• 嵌入式钱包也能使用。 Privy、Turnkey 等均可——唯一要求是对字节执行原始 signMessage。签名代码片段请参阅上文的嵌入式钱包；它们不需要单独的 Proof 流程。
• 一个已验证身份 → 不限数量的钱包。 没有上限。已在钱包 A 上完成验证的用户，可以关联钱包 B、C、D 等，无需重新进行身份验证和活体检测——只需让每个新钱包提供新的所有权签名。
• 免费，底层使用 Stripe Identity。 构建者和用户均无需付费。用户会完成 Stripe 的证件验证和活体检测流程。
• Proof 不是地理封锁。 KYC ≠ 司法管辖区限制；二者是不同的问题。

遇到不符合预期的情况

完整参考资料请以文档 MCP 为准，具体包括：

• /proof/introduction — Proof 顶层概览：何时使用、身份图模型以及验证内容。
• /proof/partner-integration — 深度链接代码（签名生成、URL 构建）、缓存示例、边缘情况处理（签名过期、用户取消、网络错误）、安全指南和重定向方案调试（#deep-link-parameters）。
• /proof/user-journeys — 新用户直连、新用户从合作伙伴进入以及回访用户流程图。
• /resources/proof-api/verify-address — 唯一公共端点的参考资料。

相关技能

• dflow-spot-trading — Solana 代币兑换；始终不需要 Proof。
• dflow-market-data — 实时现货市场数据流；只读，不需要 Proof。