SSP Wallet v1.15.0 为 dApp 打开了更宽的大门。本次更新把 SSP Wallet API 拓展为一个通用接口，任何网站都可以与之对话：向钱包请求所需信息，并向用户提议钱包能够提供的操作——而始终不会触及密钥。最初只是 SSP Connect 里一个 pay 动作的东西，如今成长为一个真正的集成平台，公开规范文件 SSP_Wallet_API.md 让开发者今天就能开始构建。
从 Pay 到完整 API
SSP Connect 的第一个版本随 v1.1.0 一起发布，只新增了一个对外动作：pay。dApp 可以在某条链、向某个地址、按某个金额请求一次支付，钱包则在用户的两台设备上完成签名流程。范围有意收窄。它验证了边界——钱包负责签名，dApp 负责请求——也给了我们一些可以在实战中加以加固的东西。
v1.15.0 走出了下一步。钱包现在暴露一组更宽的 API，让网站可以与 SSP 用户配对、读取用户明确批准的部分信息，并请求钱包支持的动作。模型不变：钱包是权威，网站是调用方，按下绿色按钮的依然是用户。新的地方在于：接口不再是一个函数，而是一个有文档的接口面。
API 暴露了什么
扩展后的 API 聚焦于几乎所有 dApp 都需要知道才能为钱包用户提供价值的信息，以及钱包可以在不破坏其安全模型的前提下提供的动作。
在读取一侧，API 允许网站向钱包询问已连接用户的账户标识、钱包支持的链、以及用户愿意与该特定网站分享的地址。关键在于，「询问」从不意味着「自动获得」。每一次读取请求都会在钱包界面里弹出提示，用户可以授予、缩小范围或拒绝。
在动作一侧，API 保持着与原始 pay 流程相同的边界。可以请求钱包构造、审阅并联签一笔交易；dApp 永远看不到签名材料。多重签名不容协商：任何动用资金的支出仍然由 SSP 设置的两半——浏览器扩展和用户手机上的 SSP Key——共同签名，与手动发起的转账完全一致。没有任何 API 调用允许网站绕过这一流程，也没有任何「会话授权」会把钱包变成自动盖章。
完整的方法签名、请求结构和事件语义都活在 SSP_Wallet_API.md 规范里，这里是集成者的事实来源。
安全模型
钱包 API 的价值与其安全模型对等，因此值得明确说说 v1.15.0 强制执行的内容。
**Origin 检查。**每一次 API 调用都带着发起页面的 origin，钱包将该 origin 视为调用者的身份。权限按 origin 划定范围；授予一个站点的权限并不是授予同一浏览器里它邻居的权限。如果恶意页面试图复用其他站点的会话，请求会在抵达用户之前就被拒绝。
**显式用户批准。**读取和动作首次发生时都需要在钱包内弹出提示，而实质性动作——任何签名或花费——每次都需要一次新的提示。钱包不会默默批准交易，即便面对用户之前已连接过的站点也不会。dApp 无权决定什么是「足够可信」。
**签名永远在本地。**让 SSP 之所以是 SSP 钱包的核心——签名在两台设备本地完成、没有任何远程服务掌握未签名但可花费的密钥——并未改变。API 给了网站一条结构化的途径，向钱包请求一次签名；但没有给网站任何绕过用户取得签名、或绕过某一把密钥的途径。
多签不变量与钱包第一天上线时的不变量完全一致。API 是一个礼貌的敲门人，而不是万能钥匙。
如何对接
SSP_Wallet_API.md 规范是开始的标准位置。它描述了可用的方法、钱包在状态变更时发出的事件，以及 dApp 应当预期的错误码。请将其与 v1.15.0 的 GitHub 发布说明结合起来阅读，以获得本次发布的完整上下文。
对于来自其他钱包生态的开发者来说，模型很眼熟：基于会话的配对、按 origin 索引的权限、由事件驱动的状态。不同的地方在于「缺席的东西」——没有「批准该 dApp 未来所有交易」的旁门左道，也没有任何可能离开用户两台设备的密钥材料。
SSP Connect 的下一步
SSP Connect 不再只是一个协议，更像是钱包对外接口的一把伞。请期待更多文档化的方法、更多事件，以及对最常见集成形态更精炼的示例。第一目标并非成为加密世界最大的 API，而是最无聊的那一个——在最好的意义上：可预期、范围清晰、对网站能向钱包请求什么保持保守。
如果你在构建什么并想与 SSP 对话，规范就是那道门。