在 Solana 移动应用中验证 Seeker…

当需要向 Seeker 设备持有者开放内容或奖励、验证用户持有 Seeker Genesis Token（SGT）、为 Solana 移动应用添加反女巫检查，或实现每设备一次领取逻辑时使用。

适用场景

解决思路

1. 验证必须同时完成两半，缺一不可：1）用 Sign-in-with-Solana（SIWS）证明用户控制该钱包；2）检查该钱包的 Token-2022 mints 以证明其持有 SGT。只做第二半，任何人都能提交真实 Seeker 持有者的公钥地址并通过；只做第一半只能证明钱包控制权，无法证明设备。
2. 绝不在客户端决定权限。客户端可被篡改，客户端的 hasSGT 布尔值毫无价值。客户端只负责收集签名，服务器负责验证并持有结果。
3. 准备一个你控制的、能发起 Solana mainnet RPC 调用的后端；准备 nonce 和领取记录的存储；准备一个 RPC 端点（付费提供商更好，因为检查可能枚举大量 token 账户），该密钥只保留在服务端，绝不要放进 EXPO_PUBLIC_* 变量。
4. 前置条件：应用需已有可用的钱包连接（若没有，先用 solana-mobile-wallet 技能，本技能假设 useMobileWallet() 可用）。测试需要一台真实的 Seeker 设备，模拟器无法持有 SGT；需规划一条无需真机即可执行的代码路径，例如开发环境下的服务端 allowlist。
5. 第 1 步：由服务器签发完整的 SIWS payload（不只是 nonce），并以 nonce 为键、带短 TTL 存储。客户端提供的每个字段都是攻击者可选择的，且每个字段都会直接进入签名校验，因此必须在签发时全部固定。示例：const issuedAt = new Date(); const nonce = crypto.randomBytes(16).toString('hex'); const payload = { chainId: 'solana:mainnet', domain: 'yourdapp.com', expirationTime: new Date(issuedAt.getTime() + 300_000).toISOString(), issuedAt: issuedAt.toISOString(), nonce, statement: 'Sign in to verify Seeker ownership', uri: 'https://yourdapp.com', version: '1' }; await store.put(nonce, payload, { ttlSeconds: 300 }); return payload。
6. nonce 必须由服务器生成、一次性使用且短时效。客户端生成或可复用的 nonce 会让签名可重放，从而使整个验证失去意义。
7. address 是服务器唯一无法填写的字段，由客户端在第 2 步添加。
8. chainId 故意固定为 solana:mainnet，而不是取自钱包的 chain：SGT 只存在于 mainnet，作用域为 devnet 的签名无法证明任何设备信息。由服务端签发才能把这一点变成保证而非注释。
9. 第 2 步：在客户端签名。使用钱包 hook 的 signIn，它在一次提示中完成授权并证明所有权。展开已签发的 payload 并加入 address：import { useMobileWallet } from '@wallet-ui/react-native-kit'; const { signIn } = useMobileWallet(); const issued = await fetch('https://yourdapp.com/api/siws/nonce', { method: 'POST' }).then((response) => response.json()); const address = account.address.toString(); const output = await signIn({ ...issued, address }); await fetch('https://yourdapp.com/api/siws/verify', { body: JSON.stringify({ address, nonce: issued.nonce, signature: Array.from(output.signature), signedMessage: Array.from(output.signedMessage) }), headers: { 'Content-Type': 'application/json' }, method: 'POST' })。
10. 只提交上述四个字段。不要提交 output.account，服务器也绝不能接受来自客户端的 account 对象或公钥——用于校验签名的密钥必须从服务器即将操作的 address 推导出来。nonce 在这里只是查找键，真正起绑定作用的是签名校验。
11. 使用完整指定的 payload，而非简短的 signIn 形式。domain、nonce 和 version 是让签名不可重放并绑定到你的应用的关键，且必须由服务器签发才能成立。solana-mobile-wallet 技能涵盖两种形式及各自适用场景。
12. 第 3 步：在服务器验证签名。安装依赖：npm install @solana/kit @solana/wallet-standard-util。实现 verifySiws(issued, { address, signature, signedMessage })：先做形状检查——if (!Array.isArray(signature) || signature.length !== 64) throw new Error('Malformed signature.'); if (!Array.isArray(signedMessage)) throw new Error('Malformed signed message.'); 然后从 address 推导验证密钥，绝不从请求体取：const publicKey = getBase58Encoder().encode(address); if (publicKey.length !== 32) throw new Error('Malformed address.'); 最后 return verifySignIn({ ...issued, address }, { account: { address, chains: [], features: [], publicKey }, signature: new Uint8Array(signature), signedMessage: new Uint8Array(signedMessage) })。
13. 三项形状检查必须放在最前面，因为这些值都是攻击者可选择的。没有它们，畸形输入会先到达 new Uint8Array() 再进入 ed25519 校验，结果不一致：过短的签名会抛出关于字节长度的库错误，而非数组的 signedMessage 会被强制转换为空数组并返回普通的 false。按形状拒绝能让两种情况得到统一明确的答案，且不依赖你无法控制的内部实现。
14. verifySignIn 会把你传入的字段与签名文本中的字段比对，然后用 account.publicKey 验证签名，但它从不检查密钥与地址是否一致。若从请求体取该密钥，任何一次性密钥对都能签署一条指定任意地址的消息：签名是真实的，但并非该地址持有者的签名。
15. 由于 issued 由服务器签发，domain 和 chainId 在构造上已被固定，客户端副本不会进入校验，因此无需单独比较 domain。若仍想加防御性断言，应针对 issued.domain（存储的副本）断言，绝不要用请求中的值。
16. 第 4 步：检查钱包是否持有 SGT。参见 references/sgt-verification.md 获取完整实现，它确认 Token-2022 mint 的三个属性——mint authority、metadata pointer 和 token group membership——三者必须全部匹配。
17. 第 5 步：正确组合各项检查。verifySignIn 不把账户密钥绑定到签名消息中的地址，因此服务器必须自行完成绑定：从即将操作的 address 推导密钥，并用同一 address 查询 SGT。实现 verifySeekerUser({ address, nonce, signature, signedMessage })：1）原子地消费 nonce——先读后标记会留下窗口，两个并发请求都看到未使用，导致同一签名被接受两次；Redis 用 GETDEL，SQL 用 DELETE FROM nonces WHERE nonce = $1 RETURNING payload：const issued = await store.consume(nonce); if (!issued) throw new Error('Invalid, reused, or expired nonce.'); 2）签名必须对我们签发的 payload 和该 address 有效：if (!verifySiws(issued, { address, signature, signedMessage })) throw new Error('Invalid signature.'); 3）针对刚刚验证过签名的 address 检查 SGT：const { hasSGT, mintAddress } = await checkWalletForSGT(address); return { address, hasSGT, mintAddress }。
18. 若针对其他地址检查 SGT，调用者就能用自己的签名提交真实 Seeker 持有者的地址并获得访问权限。
19. 反女巫：每设备一次领取。SGT 是按设备发放的，因此 mint address 就是设备身份。存储 mint address 而非钱包地址——钱包之后可能持有不同的 SGT，而设备的 SGT 也可能在钱包间转移。
20. 用 UNIQUE 约束而非应用代码来强制一次领取：CREATE TABLE claims ( claimed_at timestamptz NOT NULL DEFAULT now(), mint_address text NOT NULL UNIQUE, paid_at timestamptz );
21. 插入时先插入并让约束裁决：const { address, hasSGT, mintAddress } = await verifySeekerUser(request.body); if (!hasSGT) throw new Error('No Seeker Genesis Token found.'); try { await claims.insert({ claimedAt: new Date(), mintAddress }) } catch (error) { if (error.code === '23505') throw new Error('This device has already claimed.'); throw error }。先查询是否存在再插入是双重领取漏洞：两个并发请求都会查不到记录。
22. 只有在插入落地后才发放奖励：await grantReward(address); await claims.markPaid(mintAddress)。在插入前发放的任何东西都可能被发放两次。
23. 插入与发放是两次独立写入，需决定第二次失败时的处理方式。按当前写法，若 grantReward 在行提交后抛错，该设备将无法重试：约束会以已领取为由拒绝它。要么基于 paid_at 为 null 的行驱动重试，要么让 grantReward 对 mintAddress 幂等，使重放无副作用。这属于健壮性问题而非安全问题：做错会拒绝真实持有者的奖励，但不会让任何人重复领取。
24. 让 checkWalletForSGT 返回 mint address 而非裸布尔值——参见参考文件末尾。

适用边界 · 注意事项

• 需要先有可用的钱包连接（useMobileWallet()），否则应先用 solana-mobile-wallet 技能。
• 测试需要真实的 Seeker 设备，模拟器无法持有 SGT。
• 需要你控制的、能发起 Solana mainnet RPC 调用的后端，以及 nonce 和领取记录的存储；付费 RPC 提供商更好，且密钥必须仅保留在服务端。