@amadeus-protocol/wallet-sdk

中文文档
0.1.7发布于 2026/10/23MITTypeScriptES Module构建来源已验证近 30 天下载 2692

Shared dApp <-> wallet connection layer for Amadeus Protocol: BLS API-key tokens, transaction signing, message/connect signing, and the typed provider contract. One audited implementation for the wallet, the extension, and every dApp.

原始使用文档
文档目录5 节
  1. What's in this release
  2. Why unify the API-key token first
  3. Security notes
  4. Develop
  5. Roadmap

@amadeus-protocol/wallet-sdk

One audited home for the Amadeus dApp ↔ wallet connection layer. The wallet (mobile + extension) and every dApp import the same crypto and protocol code, so the two sides can never drift — which is the entire point.

Built on top of @amadeus-protocol/sdk (key derivation, encoding, TransactionBuilder). This package adds only the connection layer.

Status: v0.1 — crypto + protocol core. Transports (deep link / QR / bridge) and React hooks are not in this release. See "Roadmap" below.

What's in this release

AreaExports
API-key tokensgenerateApiKey, verifyApiKey, decodeApiKey
TransactionssignTransaction, submitTransaction
Connection authsignConnect, verifyConnect, buildConnectTranscript
Session encryptiongenerateSessionKeypair, deriveSharedKey, seal, open
Provider contractAmadeusProvider, getAmadeusProvider, isProviderAvailable, event/response types
Wire validationzod schemas: signTransactionRequestSchema, generateApiKeyRequestSchema, connectTranscriptSchema, addressSchema, originSchema
Binary argsencodeBinaryValues, decodeBinaryValues, describeBinaryValues
Constantsall DSTs, byte lengths, event names, PROTOCOL_VERSION

Why unify the API-key token first

It was hand-rolled in three places (the extension, hub, and prime-hub), all of which must stay byte-identical to the kbs.ama.one backend. generateApiKey here reproduces that exact token — base58( json{aud,exp} ‖ pubkey48 ‖ sig96 ) signed over sha256(json ‖ pubkey) under the _APIKEY_ DST — and a test asserts byte-for-byte equality with the original recipe. Consumers can now delete their copies.

import { generateApiKey, verifyApiKey } from '@amadeus-protocol/wallet-sdk'

const { apiKey } = generateApiKey({ seed, aud: 'amadeus', expIn: 7 * 24 * 3600 })
// ... later, on any verifier:
const result = verifyApiKey(apiKey, { aud: 'amadeus' })
if (result.valid) console.log(result.address)

The token's address is the public key of the seed you pass in. A recovery phrase can open two different addresses (the standard eip2333 derivation, and the legacy raw-BIP39 seed used by wallets created with older extension and app builds), so don't assume one. Resolve the seed with resolveCandidateForAddress (sdk ≥ 1.6.0), which returns the candidate whose publicKey equals the user's wallet address, or null if neither derivation opens it (it throws on an invalid phrase). Otherwise the token silently belongs to a different account.

import { resolveCandidateForAddress } from '@amadeus-protocol/sdk'
import { generateApiKey } from '@amadeus-protocol/wallet-sdk'

const candidate = resolveCandidateForAddress(phrase, walletAddress)
if (!candidate) throw new Error('This phrase does not open that address')
const { apiKey } = generateApiKey({ seed: candidate.seed, aud: 'amadeus', expIn: 3600 })

Security notes

  • Distinct DSTs (_TX_, _APIKEY_, _CONNECT_) make a signature from one context cryptographically unusable in another.
  • Connect auth signs the full transcript — origin + both session keys + challenge + request id — not just the nonce, which closes the key-substitution MITM.
  • No arbitrary message-signing oracle: connection proof only ever signs a structured, length-prefixed transcript.
  • Session box uses x25519 + XChaCha20-Poly1305 via @noble (Hermes-safe; no tweetnacl "no PRNG" issue) and fails closed on any tamper.

Develop

bun install
bun run test        # vitest
bun run typecheck
bun run build       # tsdown -> dist/

Roadmap

  1. Transports — deep link / Universal Link ingress, QR pairing, and a self-hosted encrypted bridge, all speaking one envelope.
  2. /react — WalletProvider + useWallet() so dApps stop copy-pasting provider glue (and the amadeus#initialized vs amadeus-wallet#initialized bug gets fixed once).
  3. Adoption — migrate the extension, hub, and prime-hub off their hand-rolled crypto onto this package.

版本与发布记录

@amadeus-protocol/wallet-sdk 共发布 6 个版本,首次发布于 2026/08/11;过去 12 个月发布了 6 个版本。最新版本附带 npm provenance 构建来源证明,可追溯到公开的 CI 构建记录。

版本发布日期距今
0.1.7latest2026/10/2315 天前
0.1.62026/10/2315 天前
0.1.52026/10/021 个月前
0.1.42026/08/202 个月前
0.1.12026/08/112 个月前
0.1.02026/08/112 个月前

关于 @amadeus-protocol/wallet-sdk 的常见问题

@amadeus-protocol/wallet-sdk 是什么?

Shared dApp <-> wallet connection layer for Amadeus Protocol: BLS API-key tokens, transaction signing, message/connect signing, and the typed provider contract. One audited implementation for the wallet, the extension, and every dApp.

如何安装 @amadeus-protocol/wallet-sdk?

在项目目录运行 npm install @amadeus-protocol/wallet-sdk,或使用 pnpm add / yarn add / bun add。它还需要宿主项目提供 peer 依赖:@amadeus-protocol/sdk(^1.3.0)。npm 7 及以上与 pnpm 8 及以上默认会自动安装必需的 peer 依赖,Yarn 需要手动安装。

@amadeus-protocol/wallet-sdk 支持 TypeScript 吗?

支持。包内自带 TypeScript 类型声明(package.json 声明了 types 入口),安装后即可获得类型提示,无需再安装 @types 包。

@amadeus-protocol/wallet-sdk 支持 ESM 还是 CommonJS?

以 ES Module 形式发布,推荐使用 import 引入。在 CommonJS 项目中,Node.js 20.19+ / 22.12+ 可以直接 require() 不含顶层 await 的 ES Module,更早的版本需要改用动态 import()。

@amadeus-protocol/wallet-sdk 需要什么版本的 Node.js?

package.json 的 engines 字段要求 Node.js >=20.0.0。版本不符时 npm 默认只给出警告,开启 engine-strict 后会拒绝安装。

@amadeus-protocol/wallet-sdk 可以商用吗?

@amadeus-protocol/wallet-sdk 使用 MIT 许可。宽松许可:允许商业使用、修改和再分发,通常只需在分发时保留原版权与许可声明。以上为概括,不构成法律意见,请以许可原文为准。

@amadeus-protocol/wallet-sdk 的下载量有多少?

根据 npm 官方下载统计,@amadeus-protocol/wallet-sdk 在 2026/10/06 – 2026/11/04 这 30 天内被下载 2,692 次,日均约 90 次。下载量会把 CI 构建、镜像同步和作为其他包依赖的安装一并计入,适合横向比较热度,不能直接等同于使用人数。

@amadeus-protocol/wallet-sdk 还在维护吗?

最新版本 0.1.7 发布于 2026/10/23(15 天前);至今共发布 6 个版本,其中过去 12 个月发布了 6 个;首次发布于 2026/08/11。发布频率只是参考信号:功能稳定的工具可能很少需要更新,建议结合源码仓库的 issue 和提交记录判断。