Sphere SDK

为自主经济代理提供身份、钱包、私密通信及点对点结算能力。

Star 数
★ 5.4k
最近更新
1 天前
License
MIT
主语言
TypeScript

30 秒速览

运行形态
代码库 / SDK命令行工具
可在哪里用
通用 · 跨平台
费用
免费,无需付费服务
上手难度
中 · 需要几步配置
开始前需要
TypeScript 或 JavaScript 运行时npm用于 Node.js 使用的 wsShell / 命令行网络访问
典型场景
开发浏览器钱包或 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 工具。

  1. 开发浏览器钱包或 dApp 的团队,可使用 ConnectClient / ConnectHost、IndexedDB 或 localStorage,以及 Sphere 扩展弹窗通信来连接钱包。
  2. 构建自主交易代理的开发者,可为每个代理创建本地密钥身份,通过 nametag 或 DIRECT:// 地址寻找收款方,并调用 sphere.payments.send() 完成结算。
  3. 运行 Node.js 服务或命令行批处理的团队,可采用文件存储和稳定的 deviceId,显式调用 receive() 排空邮箱并恢复未完成的转账。
  4. 需要收款流程的应用,可通过 sphere.payments.requests 发送带加密备注的请求,并监听 pending、settling、paid、rejected 和 expired 状态。
  5. 需要代理间通信的产品,可使用 NIP-17 加密私信,或启用 NIP-29 群聊、私有邀请、未读计数和管理员或版主操作。
  6. 测试 Unicity v2 资产流程的团队,可在 testnet/testnet2 上自铸代币,验证多地址、转账恢复和收件箱投递逻辑。

如何安装或部署这个 Agent?

安装 SDK:

npm install @unicitylabs/sphere-sdk

Node.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?

FollowAgents 源码审查 · FARS-2.1
缺口较多
53/ 100 五分制 2.7 / 5
信任安全 12/29
可靠稳定 8/14
适用触发 12/18
规范维护 10/18
有效结果 7/13
证据核验 4/8
查看各维度的扣分理由
信任安全12 / 29 · 2.1/5

证据显示:SDK 采用模块化端口设计,密钥本地保存,服务器托管代币,但未提供用户确认机制(如发送前确认)。数据流透明性较好,文档明确说明支付走 wallet-api 而非 Nostr,并公开了测试网 API 密钥。敏感数据处理:支持密码加密(PBKDF2),但未详细说明密钥存储细节。依赖安全:依赖 noble 加密库,但未提供依赖审计或漏洞扫描证据。外部影响:支付和消息发送有明确的外部效果,但未提供撤销或回滚机制。来源归属:发布者未验证,但仓库有明确的作者和许可证。扣分原因:缺少用户确认、回滚机制,依赖安全证据不足。

可靠稳定8 / 14 · 2.9/5

证据显示:文档和代码示例一致,错误处理明确(如 CERTIFICATION_UNCONFIRMED 不可重发)。依赖可用性:依赖多个外部服务(网关、中继),但未提供离线或降级方案。失败消息:提供了详细的错误码和恢复指导。扣分原因:依赖外部服务可用性未充分说明。

适用触发12 / 18 · 3.3/5

证据显示:面向浏览器、Node.js、CLI 和 dApp 集成,场景覆盖支付、消息、群聊等。能力边界清晰:明确区分支付和消息通道。触发精度:事件驱动,如 transfer:incoming。环境适配:支持浏览器和 Node.js,但未提及移动端。扣分原因:未提供移动端支持。

规范维护10 / 18 · 2.8/5

证据显示:README 结构清晰,安装说明详细,命名稳定(如 createBrowserProviders)。示例丰富,包括快速入门和 E2E 测试。已知限制:文档提到 mainnet/dev 仍为 v1 协议,支付会失败。许可证为 MIT。版本化:有版本号,但未提供 CHANGELOG。维护责任:发布工作流存在,但未明确维护者。扣分原因:缺少 CHANGELOG 和明确的维护者信息。

有效结果7 / 13 · 2.7/5

证据显示:输出可用性高,提供清晰的 API 和事件。边际价值:为自主经济代理提供身份、钱包和支付能力,具有独特价值。成本效益:依赖多个外部服务,可能增加部署成本。扣分原因:成本效益证据不足。

证据核验4 / 8 · 2.5/5

证据显示:README 中的声明与代码示例一致,测试文件提供了 E2E 验证。交叉来源:文档和测试相互印证,但未提供独立第三方验证。事实与推断分离:文档明确区分事实(如网络配置)和推断(如安全性)。扣分原因:交叉来源证据有限。

风险与缓解建议
  • 源码中未见:执行前用户确认开启或自行加上执行前确认;先在沙箱或测试环境跑通,确认行为后再接入真实数据。
  • 发布者未验证,使用前需自行评估信任风险。
  • 支付操作不可回滚,且 CERTIFICATION_UNCONFIRMED 错误不可重发,需谨慎处理。
  • 依赖多个外部服务(网关、中继),需确保其可用性和安全性。
  • 测试网 API 密钥公开,但主网密钥需保密。
证据充分度:低 评估于 2026年8月11日 审查版本 96565ba55c55 评估后仓库已有新提交,评分可能未覆盖最新改动
查看完整评分方法 →

最近版本

来自该项目 GitHub Releases 的最新发布记录,说明为上游原文摘录,未经本站改写或测试。

  1. 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 查看 ↗
  2. v0.2.4
    发布说明摘录
    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 查看 ↗

常见问题

密钥和代币分别存放在哪里?
私钥保留在客户端存储中,不会交给后端;代币库存则由 wallet-api 后端托管。浏览器可使用 localStorage 或 IndexedDB,Node.js 可使用文件存储。
deliveryPending 是否表示付款失败?
不是。status === 'completed' 表示发送成功;deliveryPending === true 仅表示已经完成链上认证,但向接收方 wallet-api 邮箱的投递被延后,SDK 会自动重试。
遇到 CERTIFICATION_UNCONFIRMED 可以重试发送吗?
不可以创建新的 send()。该交易可能已经完成链上认证,SDK 会保留原 intent 并以同一 transferId 恢复;重新发送可能让接收方收到两笔款项。
当前哪些网络可以执行付款和自铸?
testnet 是 testnet2 的别名,并使用 networkId 4 的 v2 网关。文档明确说明 mainnet 和 dev 尚指向 v1 时代聚合器,因此其 send 和 mint 当前会失败。
Nostr 是否承载付款?
不承载。Nostr 用于 nametag、NIP-17 私信和 NIP-29 群聊;付款经 v2 代币引擎认证,并通过 wallet-api 的存储和邮箱轨道传输。
在 GitHub 查看 ↗ 安装 ↓

对比同类 Agent

用同一套 FARS 评审,横向比较这个 Agent 所属的短名单。

相关 Agents