Sphere SDK
为自主经济代理提供身份、钱包、私密通信及点对点结算能力。
- Star 数
- ★ 5.4k
- 最近更新
- 1 天前
- License
- MIT
- 主语言
- TypeScript
- FA 评分
- 53/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台
- 费用
- 免费,无需付费服务
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 开发浏览器钱包或 dApp 的团队,可使用
ConnectClient/ConnectHost、IndexedDB 或 localStorage,以及 Sphere 扩展弹窗通信来连接钱包。 - 不适合
- 需要完全自托管、自行保管代币库存的团队——钱包后端持有库存
- 要求主网或 dev 网络立即转账/铸造的团队——v1 网关会报 AGGREGATOR_ERROR
- 需要开箱即用、无需自备网关 API 密钥与 wallet-api 部署的项目
这个 Agent 能做什么,适合哪些场景?
Sphere SDK 是面向浏览器和 Node.js 的模块化 TypeScript 钱包 SDK,用于 Unicity 状态转换网络。它以 Sphere 为入口,组合身份、支付、付款请求、市场意图、Nostr 私信和 NIP-29 群聊等模块。钱包密钥保留在客户端,但代币库存由 wallet-api 后端托管;支付经 v2 代币引擎认证后投递至接收方的 wallet-api 邮箱。基础提供器负责存储、Nostr 传输和预言机配置,付款功能还必须通过 createWalletApiProviders 单独接入 wallet-api。SDK 支持浏览器存储、Node.js 文件存储、多 HD 地址和可替换的支付传输端口,适合需要把经济身份与结算能力嵌入代理、dApp、服务端应用或钱包界面的团队。
应用首先用 createBrowserProviders 或 createNodeProviders 创建存储、Nostr 传输和预言机基础层,再以 createWalletApiProviders 加入付款所需的 wallet-api 配置,并通过 Sphere.init 创建或载入钱包。SDK 使用 BIP39/BIP32 派生密钥和多个地址,可注册或恢复 nametag,并公开 DIRECT:// 主地址。sphere.payments 查询资产和历史、接收邮箱转账、自铸测试网代币,并通过持久化 transfer intent 执行 send();完成的 v2 CBOR 代币由引擎验证所有权及证明后才计入余额。sphere.payments.requests 创建、支付、拒绝和跟踪加密备注的付款请求;sphere.market 提供带签名、语义搜索和实时订阅的意图公告板。sphere.communications 通过 NIP-17 收发端到端加密私信,sphere.groupChat 则通过独立的 NIP-29 中继创建群组、管理邀请、发送消息和执行管理操作。SDK 还提供 Connect 协议、动态中继管理、钱包 JSON 导入导出、PBKDF2 密码加密以及金额、密钥、哈希和 Base58 工具。
- 开发浏览器钱包或 dApp 的团队,可使用
ConnectClient/ConnectHost、IndexedDB 或 localStorage,以及 Sphere 扩展弹窗通信来连接钱包。 - 构建自主交易代理的开发者,可为每个代理创建本地密钥身份,通过 nametag 或
DIRECT://地址寻找收款方,并调用sphere.payments.send()完成结算。 - 运行 Node.js 服务或命令行批处理的团队,可采用文件存储和稳定的
deviceId,显式调用receive()排空邮箱并恢复未完成的转账。 - 需要收款流程的应用,可通过
sphere.payments.requests发送带加密备注的请求,并监听pending、settling、paid、rejected和expired状态。 - 需要代理间通信的产品,可使用 NIP-17 加密私信,或启用 NIP-29 群聊、私有邀请、未读计数和管理员或版主操作。
- 测试 Unicity v2 资产流程的团队,可在 testnet/testnet2 上自铸代币,验证多地址、转账恢复和收件箱投递逻辑。
如何安装或部署这个 Agent?
安装 SDK:
npm install @unicitylabs/sphere-sdkNode.js 快速入门还要求安装 ws;README 未给出它的具体安装命令。命令行界面已经迁移到独立包,可按需安装:
npm install -g @unicity-sphere/cli
sphere --help实际付款还需要可访问的 v2 网关、wallet-api 部署,以及对应网络的预言机 API key。公开的 testnet2 key 可以用于客户端测试;mainnet key 必须作为机密保存在部署环境中。
如何使用这个 Agent?
浏览器初始化必须分两层配置。下面的调用创建基础提供器、附加 wallet-api,并初始化钱包:
import { Sphere } from '@unicitylabs/sphere-sdk';
import { createBrowserProviders } from '@unicitylabs/sphere-sdk/impl/browser';
import { createWalletApiProviders } from '@unicitylabs/sphere-sdk/impl/shared/wallet-api';
const base = createBrowserProviders({
network: 'testnet',
oracle: { apiKey: 'sk_ddc3cfcc001e4a28ac3fad7407f99590' },
});
const providers = createWalletApiProviders(base, {
baseUrl: 'https://wallet-api.unicity.network',
network: 'testnet2',
deviceId: 'my-stable-device-id',
});
const { sphere, created, generatedMnemonic } = await Sphere.init({
...providers,
autoGenerate: true,
});
if (created && generatedMnemonic) {
console.log('SAVE THIS RECOVERY PHRASE:', generatedMnemonic);
}
const result = await sphere.payments.send({
recipient: '@alice',
amount: '1000000',
coinId: 'UCT',
memo: 'hello',
});
console.log(result.status);
const { transfers } = await sphere.payments.receive();
console.log(transfers);
console.log(await sphere.payments.assets());金额必须使用十进制字符串,不能使用 JavaScript number。接收者必须已发布含 chain pubkey 的身份,否则发送会以 INVALID_RECIPIENT 失败。若结果为 status === 'completed' 且 deliveryPending === true,链上认证已经完成,只是邮箱投递延后,不应把它显示为付款失败。若抛出 CERTIFICATION_UNCONFIRMED,不得再次调用新的 send();原 intent 可能已经上链,SDK 会以相同的 transferId 自动恢复,否则可能造成双重付款。生产钱包应向 Sphere.init、Sphere.create 或 Sphere.load 提供用户密码,以免只依赖内置默认密钥进行静态混淆。
这个 Agent 有哪些优点和局限?
- 支付采用持久化服务端 intent,并在相同
transferId下恢复,可处理崩溃和部分提交结果,降低重复支付风险。 - 密钥保留在客户端,而代币库存及邮箱投递由 wallet-api 承担;收到的代币在计入余额前会完成证明和所有权验证。
- 同一 SDK 同时提供支付、付款请求、市场意图、NIP-17 私信、NIP-29 群聊、多地址和 Connect 协议。
- 浏览器与 Node.js 都有明确的提供器实现,支付端口和
paymentsV2Transport也允许测试或自定义宿主替换底层传输。 - 金额解析、钱包导入导出、密码加密、动态中继和可选 CoinGecko 价格数据等配套能力较完整。
- 付款不是纯客户端或自托管库存模型;它依赖 wallet-api 后端托管代币库存、会话和接收方邮箱。
- 初始化必须同时配置基础层和 wallet-api 层,并在两处提供网络;漏配任一处会触发
INVALID_CONFIG。 - mainnet 和 dev 仍指向 v1 时代聚合器,在切换到 v2 前,
send和mint会以AGGREGATOR_ERROR失败。 CERTIFICATION_UNCONFIRMED要求调用方实现特殊用户体验并严禁重新发送,否则原 intent 恢复后可能造成双重付款。- 不提供默认网关 API key;Node.js 还需要额外的
ws,实际运行依赖网关、wallet-api 以及一个或多个 Nostr 中继。 - 若不提供用户密码,种子只用内置默认密钥进行静态混淆,不适合存放真实价值。
这个 Agent 与同类方案有什么区别?
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Sphere SDK 当前 | 53 · 缺口较多 | 代码库 / SDK免费 | ★ 5.4k | 1 天前 | TypeScript | — |
| TanStack AI | 76 · 存在缺口 | 代码库 / SDK免费 + 模型费 | ★ 3.2k | 4 天前 | TypeScript | OpenAI API · Claude API |
| Deuz SDK | 69 · 存在缺口 | 代码库 / SDK免费 + 模型费 | ★ 563 | 2 天前 | TypeScript | OpenAI API · Claude API |
| TrueForge | 67 · 存在缺口 | 命令行工具免费 + 模型费 | ★ 6.3k | 今天 | TypeScript | OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent?
查看各维度的扣分理由
证据显示:SDK 采用模块化端口设计,密钥本地保存,服务器托管代币,但未提供用户确认机制(如发送前确认)。数据流透明性较好,文档明确说明支付走 wallet-api 而非 Nostr,并公开了测试网 API 密钥。敏感数据处理:支持密码加密(PBKDF2),但未详细说明密钥存储细节。依赖安全:依赖 noble 加密库,但未提供依赖审计或漏洞扫描证据。外部影响:支付和消息发送有明确的外部效果,但未提供撤销或回滚机制。来源归属:发布者未验证,但仓库有明确的作者和许可证。扣分原因:缺少用户确认、回滚机制,依赖安全证据不足。
证据显示:文档和代码示例一致,错误处理明确(如 CERTIFICATION_UNCONFIRMED 不可重发)。依赖可用性:依赖多个外部服务(网关、中继),但未提供离线或降级方案。失败消息:提供了详细的错误码和恢复指导。扣分原因:依赖外部服务可用性未充分说明。
证据显示:面向浏览器、Node.js、CLI 和 dApp 集成,场景覆盖支付、消息、群聊等。能力边界清晰:明确区分支付和消息通道。触发精度:事件驱动,如 transfer:incoming。环境适配:支持浏览器和 Node.js,但未提及移动端。扣分原因:未提供移动端支持。
证据显示:README 结构清晰,安装说明详细,命名稳定(如 createBrowserProviders)。示例丰富,包括快速入门和 E2E 测试。已知限制:文档提到 mainnet/dev 仍为 v1 协议,支付会失败。许可证为 MIT。版本化:有版本号,但未提供 CHANGELOG。维护责任:发布工作流存在,但未明确维护者。扣分原因:缺少 CHANGELOG 和明确的维护者信息。
证据显示:输出可用性高,提供清晰的 API 和事件。边际价值:为自主经济代理提供身份、钱包和支付能力,具有独特价值。成本效益:依赖多个外部服务,可能增加部署成本。扣分原因:成本效益证据不足。
证据显示:README 中的声明与代码示例一致,测试文件提供了 E2E 验证。交叉来源:文档和测试相互印证,但未提供独立第三方验证。事实与推断分离:文档明确区分事实(如网络配置)和推断(如安全性)。扣分原因:交叉来源证据有限。
- 源码中未见:执行前用户确认开启或自行加上执行前确认;先在沙箱或测试环境跑通,确认行为后再接入真实数据。
- 发布者未验证,使用前需自行评估信任风险。
- 支付操作不可回滚,且 CERTIFICATION_UNCONFIRMED 错误不可重发,需谨慎处理。
- 依赖多个外部服务(网关、中继),需确保其可用性和安全性。
- 测试网 API 密钥公开,但主网密钥需保密。
最近版本
来自该项目 GitHub Releases 的最新发布记录,说明为上游原文摘录,未经本站改写或测试。
-
v0.8.0 v0.8.0 — UXF Inter-Wallet Transfer Protocol + Profile-layer hardening
发布说明摘录
178 PRs promoted from integration/all-fixes to main. - Release PR: [#345](https://github.com/unicity-sphere/sphere-sdk/pull/345) - Tag points at: af41bea6fc36 - Period covered: ~4 months of accumulated profile-layer, UXF, recovery, and connectivity work since the previous release lineage (PRs #128–#130 → #303–#342). ⚠️ Breaking: UXF wire-shape default flip …在 GitHub 查看 ↗ -
发布说明摘录
Bug Fixes - CLI process exit: Fix CLI commands hanging ~10s after completion due to lingering Nostr WebSocket handles - Instant split change token: Fix sender losing change token when process.exit() killed background proof collection before completion Changes - InstantSplitExecutor.submitBackgroundV5 now returns a trackable Promise<void> instead of fire-and-forget - PaymentsModule tracks background promises and exposes waitForPendingOperations() for callers to await completion - CLI send command awaits pending background operations before exiting …在 GitHub 查看 ↗
常见问题
密钥和代币分别存放在哪里?
deliveryPending 是否表示付款失败?
status === 'completed' 表示发送成功;deliveryPending === true 仅表示已经完成链上认证,但向接收方 wallet-api 邮箱的投递被延后,SDK 会自动重试。遇到 CERTIFICATION_UNCONFIRMED 可以重试发送吗?
send()。该交易可能已经完成链上认证,SDK 会保留原 intent 并以同一 transferId 恢复;重新发送可能让接收方收到两笔款项。当前哪些网络可以执行付款和自铸?
testnet 是 testnet2 的别名,并使用 networkId 4 的 v2 网关。文档明确说明 mainnet 和 dev 尚指向 v1 时代聚合器,因此其 send 和 mint 当前会失败。