TapeAPI 1.4.0

中文

TapeAPI 1.4.0：在 1.x 基础上只做新增，按 1.0 文档写的代码无需修改。新的一致模式是实验性的，默认关闭。

新增

• TAP-10 一致模式（解析路径，实验性）：createTapeAPI({ conform: 'tap10' })，另有 pin: 'tap10' 和只读的 api.siteStatus(目标)。TapeOut 官方在 TapeOutProtocol/TAPs 发布了 TAP-10，我们提交的 TAP 草稿一律按它写，这个模式让参考实现跟上。
  • 一次解析钉在同一个区块上（按各家运营方的头块取第 Q 高再减 2，按块差判断过期，不用本机时钟），区块哈希仍由各节点确认。
  • 站点存储与付费合约的实现在这个区块上读取，不在已知列表里就拒绝。
  • 读取 isOpened 与名字的激活状态；没有开通或没有激活，会得到新的错误码 SITE_STATUS（data.status 为 not-opened 或 unpaid）。
  • 接受 #4246@0、tape://4246.0/、0x…#ID 等输入写法。
  • 激活检查只作用在解析和 siteStatus 上：未激活容器的通道密钥和 TapeSend 密钥照常可读（TAP-10 §12.2）。
  • 默认行为不变。 我们拿旧版本做了差分测试：1,098 个用例、7,271 次请求，除名字范围外逐字相同。
• 诊断工具和监控都会报告名字的激活状态：tapeapi-doctor 增加第 14 项检查；监控报告到期日与剩余天数。未激活只是警告，不会让监控变红。
• 新增诊断脚本 node scripts/tap10-gap.mjs：把 TAP-10 自带的测试用例跑在 SDK 上，打印哪里一致、哪里不一致（23 个可离线判断的用例：12 个一致、11 个已知差距）。

变更与修复

• 名字范围（勘误，所有模式）：#ID 不超过 10^18，处理器号不超过 10^9（TAP-10 §3.1）。超出的名字在链上本来就不可能存在，现在不发任何请求就直接拒绝。
• tapesend：跨链发送时，收件方端点现在建在收件方所在的链上，新增可选参数 toChainId（默认等于原来的行为）。以前跨链消息会被 TAP-10 客户端判为损坏。官方的跨链消息 ID 向量能逐字复现。
• 我们自己的规范文件改名为 TAPI-1、TAPI-20 到 TAPI-27，TAP 编号交给 TapeOut 的编辑分配；其中“服务身份与清单”已合并为 TAP-11（作为 Draft）。

你会注意到的变化

• 在一致模式下，我们自己的两个服务 11.1013.tape 和 12.1013.tape 会得到 unpaid，因为它们的名字还没有激活。这只约束开启一致模式的客户端，默认模式不受影响。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.4.0/tapeapi-sdk-1.4.0.tgz

如果要单独安装 server，先装同一版本的 SDK tgz。完整变更见 CHANGELOG。本项目未经第三方审计。

感谢 @Theairresearch 提出最初的想法。

---

English

TapeAPI 1.4.0 is additive over 1.x: code written against the 1.0 docs keeps working unchanged. The new conformance mode is experimental and off by default.

Added

• TAP-10 conformance mode (resolution path, experimental): createTapeAPI({ conform: 'tap10' }), plus pin: 'tap10' and the read-only api.siteStatus(target). TapeOut published TAP-10 in TapeOutProtocol/TAPs and our TAP drafts follow it; this mode brings the reference implementation in line.
  • A resolution is pinned to one block (each operator's head, the Q-th highest minus 2, staleness by block distance, no local clock); the block hash is still confirmed by the nodes.
  • The site store's and the payment contract's implementations are read at that block and refused when they are not on the known list.
  • isOpened and the name's activation are read; a name that is not opened or not activated fails with the new code SITE_STATUS (data.status is not-opened or unpaid).
  • The input forms #4246@0, tape://4246.0/ and 0x…#ID are accepted.
  • Activation is judged by resolve and siteStatus only: an unactivated container's channel key and TapeSend key are still read (TAP-10 §12.2).
  • The default behaviour is unchanged. We ran a differential test against the previous version: 1,098 cases and 7,271 requests, identical except for the name range.
• The doctor and the monitor report a name's activation: tapeapi-doctor has a 14th check; the monitor reports the paid-until date and days left. Not activated is a warning and does not turn the monitor red.
• node scripts/tap10-gap.mjs runs TAP-10's own Test Cases through the SDK and prints where it conforms and where it does not (23 cases judgeable offline: 12 conform, 11 known gaps).

Changed and fixed

• Name range (erratum, all modes): #ID up to 10^18 and processor number up to 10^9 (TAP-10 §3.1). Larger names cannot exist on chain; they are now refused without a request.
• tapesend: for a cross-chain message the recipient endpoint is now built on the recipient's chain, through the optional toChainId (default: the old behaviour). Before, a TAP-10 client read such a message as damaged. The official cross-chain message-ID vector reproduces.
• Our own spec files are renamed TAPI-1 and TAPI-20 to TAPI-27, leaving TAP numbers to TapeOut's editors; the service identity and manifest was merged as TAP-11 (as a Draft).

What you will notice

• In conformance mode, our own 11.1013.tape and 12.1013.tape answer unpaid, because their names are not activated yet. It binds only clients that turn the mode on; the default mode is unaffected.

Install

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.4.0/tapeapi-sdk-1.4.0.tgz

To install the server package on its own, first install the SDK tgz from the same release. The full list of changes is in the CHANGELOG. Nothing here has had a third-party audit.

Thanks to @Theairresearch for the original idea.

TapeAPI 1.3.0

中文

TapeAPI 1.3.0：在 1.x 基础上只做新增，按 1.0 文档写的代码无需修改。新功能都标为实验性，默认关闭。发布前又做了四路实测排查和两轮独立审查，查出的问题都已修复，并补了回归测试。

新增

• 默克尔证明模式（借鉴波卡轻客户端的思路）：createTapeAPI({ pin: true, proofs: true | 'strict' })。
  • 做法：SDK 取回电路持有人、处理器登记、清单文件信息的 eth_getProof 证明，对照多家独立运营方共同确认的区块状态根，自己核验，不再只凭节点给出的答案。
  • 严格模式：即使所有节点串通给出同一个假答案，也会被识破。
  • 挡不住的情况：TapeOut 升级合约（那是真实的链上状态），以及所有运营方一起伪造区块头。
  • 独立审查：变异测试用例 7.7 万多个、对整个解析流程做攻击模拟，都没有找到伪造证明的路径。
  • 提供证明的默认节点（2026-09-30）：BSC 有 Alchemy，Base 有 dRPC，X Layer 暂时没有，要在 X Layer 上用严格模式，请自己加入能出证明的节点。
• 服务方目录：https://tapeapi.fun/directory/
  • 服务方通过 tapeapi-doctor 的检查后，自己提 PR 上架。
  • 每天自动做一次只读复核，不需要任何密钥。
  • 上架只代表通过了自动检查，不代表推荐、担保或审计。 不排名、不收费、不自动下架；TapeAPI 不替任何人上架，也不代付任何费用。

修复（来自 1.2.0 在三条主网上的实测）

• 限流：节点限流不再被误判为"节点分歧"。Base 上 Coinbase、dRPC 的限流回答以前会报 RPC_DISAGREE。
• 落后节点：节点落后、还没有被钉住的区块时，按"没有作答"处理。
• 钉块时限按实测调整：X Layer 放宽到 600 秒，BSC 收紧到 120 秒。
• 断线重试：连接断开的请求会重试一次，默认间隔 250 毫秒。X Layer 只有两家独立运营方，以前一次连接重置就会失败。
• 格式 2 群聊（实验性）：
  • 群主换钥时，复用未变成员的核验结论，128 人的群从 127 次核验降到 0 次；
  • 格式 2 的快照改为 v: 2，旧版会明确拒绝，不会再把群拆成两半；
  • 同一身份在两台设备上使用时，会给出明确提示。
• tapeapi-doctor：给出的下一条命令与运行方式一致；按地址检查时，探测的是你输入的地址；诊断提示更对症；补上了 Windows（PowerShell）写法。
• 文档与网站：第 0 步先运行 npm ci；文档写明公共中继只用于测试和小规模使用；公开源码里不再出现内部文件名。

默认情况下你会注意到的变化

• 连接断开的请求会自动重试一次，最多多等 250 毫秒。
• 用格式 2 建群的群主升级到 1.3.0 后，快照不能再回退给 1.2.0 使用（会明确报错）。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.3.0/tapeapi-sdk-1.3.0.tgz

如果要单独安装 server，先装同一版本的 SDK tgz。完整变更见 CHANGELOG。本项目未经第三方审计。

感谢 @Theairresearch 提出最初的想法。

---

English

TapeAPI 1.3.0 is additive over 1.x: code written against the 1.0 docs keeps working unchanged. Everything new is experimental and off by default. Before this release we ran four live test sweeps and two independent reviews; every finding is fixed, each with a regression test.

Added

• Merkle proof mode (the light-client idea, borrowed from Polkadot): createTapeAPI({ pin: true, proofs: true | 'strict' }).
  • How it works: the SDK fetches eth_getProof proofs for the circuit holder, the processor registry and the manifest's file info, and checks them itself against a block state root that several independent operators agree on, instead of relying only on what nodes answer.
  • Strict mode: it catches a false answer even when every node gives the same one.
  • What it cannot catch: an upgrade of TapeOut's contracts (that is real on-chain state), or every operator forging a block header together.
  • Independent review: over 77,000 fuzzed cases and attack simulations against the whole resolution found no way to forge a proof.
  • Default nodes that serve proofs (2026-09-30): Alchemy on BNB Smart Chain and dRPC on Base; none yet on X Layer. To use strict mode on X Layer, add a node that serves proofs.
• Provider directory: https://tapeapi.fun/directory/
  • A service lists itself by pull request once tapeapi-doctor passes.
  • Every entry is rechecked once a day, read-only and with no key.
  • A listing only means the automated checks passed; it is not a recommendation, an endorsement or an audit. There is no ranking, no fee and no automatic removal. TapeAPI lists nobody itself and pays for nothing.

Fixed (from testing 1.2.0 on three mainnets)

• Rate limits: a rate-limited node is no longer mistaken for a disagreement. On Base, rate-limit answers from Coinbase and dRPC used to fail with RPC_DISAGREE.
• Lagging nodes: a node that has not yet reached the pinned block counts as not answering.
• Pin age limits, set from measurements: 600 s on X Layer (was 300 s) and 120 s on BNB Smart Chain (was 180 s).
• Broken connections: a request whose connection breaks is retried once, after 250 ms by default. X Layer has only two independent operators, so a single reset used to fail the read.
• Groups, format 2 (experimental):
  • When the owner starts a new epoch, it reuses the checks of members that did not change: a 128-member group goes from 127 checks to 0.
  • Format-2 snapshots are now v: 2, which older versions refuse with a clear error instead of splitting the group.
  • One identity used on two devices is now flagged.
• tapeapi-doctor: the next command it suggests matches how you ran it; URL mode probes the address you gave; diagnoses are more specific; PowerShell forms are included.
• Docs and website: step 0 runs npm ci first; the docs say the public relay is for testing and small-scale use; the public source no longer names internal files.

What you will notice by default

• A request whose connection breaks is retried once, adding at most 250 ms.
• A format-2 group owner that upgrades to 1.3.0 cannot hand its snapshot back to 1.2.0 (1.2.0 refuses it with a clear error).

Install

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.3.0/tapeapi-sdk-1.3.0.tgz

To install the server package on its own, first install the SDK tgz from the same release. The full list of changes is in the CHANGELOG. Nothing here has had a third-party audit.

Thanks to @Theairresearch for the original idea.

TapeAPI 1.2.0

中文

TapeAPI 1.2.0：在 1.x 基础上只做新增，按 1.0 文档写的代码无需修改。本版新功能都标为实验性，默认关闭或只给出警告。发布前经过两轮独立审查，查出的 18 个问题都已修复，并补了回归测试。

AI 中转站：从零到上线，每一步都能自检

• 本地试跑：在仓库检出里先运行 npm ci，再运行 node examples/relay-trial/trial.mjs。不需要密钥，不需要电路，也不花钱，就能看到签名回答、回执核验，以及一个字节被篡改后当场被识破。
• tapeapi-doctor：随 SDK 安装的新命令行工具，按顺序检查一个 AI 服务的 13 项，从名字、电路、容器、清单、委托剩余天数，到端点、TLS、CORS、回执。每项失败都给出中英双语的修复提示。
  • 退出码可直接用于 CI。
  • 用 --key-env 做真实调用时，密钥只发往被检查的主机，只走 https，并且在所有输出中都显示为 ***。
• 指南开头新增“从零到上线”清单：每一步写明谁付钱、用什么命令检查。所有 42.1013.tape 的示例都注明了是示例名。
• TapeAPI 不托管任何人的旁路，也不代付电路、容器或 gas。

安全加固（借鉴波卡的共享安全思路，不造链、不发币）

• pin：一次解析的全部读取都钉在同一个区块上，这个区块由多家运营方共同确认；区块过旧时报 RPC_STALE。
• 身份根哨兵：检查 TapeOut 核心合约（DeWebHub、SiteRegistry）的实现是否是已知版本，并在本地推导容器地址做交叉核对。能发现升级，阻止不了升级。
• 可选的清单内容签名（TAP-20 §3.10）：开启 requireContentSig 后，能写站点的人无法在委托有效期内悄悄改掉 ai.baseUrl 或价格。
• 矛盾证据（ContradictionRecord v1）：提供者对同一请求给出互相矛盾的签名回答时，会留下任何人都能核验的证据。另外提供随机抽查（默认关闭）和委托下限。

更大的群聊（实验性）

• 成员核验改为并行：32 人的群冷启动，在每个请求 280 ms 的条件下，从约 45 秒降到约 6 秒。
• TAP-27 §3.8 新增格式 2：一个群最多 128 人。成员核验改为按需进行，尚未核验的发送者会被标为“未核验”。
  • 默认仍是格式 1，字节布局不变。
  • 旧版客户端遇到格式 2 的群，会收到明确的 GROUP_INVALID 错误。

默认情况下你会注意到的变化

• 哨兵默认只警告：如果 TapeOut 将来升级了核心合约，在 SDK 更新之前，每个客户端会为每个合约各打印一次 console.warn，解析本身不受影响。不想要这个警告，可以设置 sentinel: 'off'。
• 首次解析（冷启动）的请求数：对本链合约的一次冷启动解析，从 12 个请求增加到 18 个。多出来的是哨兵读取实现槽的请求，结果缓存 300 秒，轮数不变。
• 读取钉在具体区块上时（包括 rpc.call 传入十六进制块号），如果某个节点还没同步到该区块，它会被当作“没有作答”，不再判为节点分歧。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.2.0/tapeapi-sdk-1.2.0.tgz

如果要单独安装 server，先装同一版本的 SDK tgz。完整变更见 CHANGELOG。本项目未经第三方审计。

感谢 @Theairresearch 提出最初的想法。

---

English

TapeAPI 1.2.0 is additive over 1.x: code written against the 1.0 docs keeps working unchanged. Everything new in this release is experimental and is either off or warn-only by default. Two independent reviews ran before release; all 18 findings are fixed, each with a regression test.

AI relays: from nothing to live, with a check at every step

• Local trial: in a checkout, run npm ci, then node examples/relay-trial/trial.mjs. With no key, no circuit and no cost, you see signed answers, verified receipts, and a one-byte tamper caught.
• tapeapi-doctor: a new command installed with the SDK. It checks an AI service in 13 ordered steps, from name, circuit, container, manifest and days left on the delegation to endpoints, TLS, CORS and receipts. Each failure comes with a fix in English and Chinese.
  • The exit status is usable in CI.
  • With --key-env, the key goes only to the checked host, only over https, and shows as *** in every output.
• The AI providers guide now opens with "From zero to live": each step, who pays, and the command that checks it. Every 42.1013.tape example is marked as an example name.
• TapeAPI hosts nobody's sidecar and pays for nobody's circuits, containers or gas.

Security hardening (ideas from Polkadot's shared security; no chain, no token)

• pin: every read of one resolution is pinned to one block confirmed by several operators; a block that is too old is refused with RPC_STALE.
• Identity-root sentinel: checks that TapeOut's core contracts (DeWebHub, SiteRegistry) run known implementations, and cross-checks the container address against a local derivation. It notices an upgrade; it cannot prevent one.
• Optional holder-signed manifest content (TAP-20 §3.10): with requireContentSig, whoever can write the site cannot quietly change ai.baseUrl or prices while the delegation is valid.
• Contradiction evidence (ContradictionRecord v1): when providers sign conflicting answers to the same request, they leave evidence anyone can check. Also included: spot checks (off by default) and a delegation floor.

Larger groups (experimental)

• Member checks run in parallel: a 32-member cold start at 280 ms per request goes from about 45 s to about 6 s.
• TAP-27 §3.8 format 2: up to 128 members in one group. Member checks happen on demand, and senders not yet checked are marked "unverified".
  • Format 1 stays the default, and its byte layout is unchanged.
  • Older clients that meet a format-2 group get a clear GROUP_INVALID error.

What you will notice by default

• The sentinel only warns by default. If TapeOut upgrades its core contracts, every client prints one console.warn per contract until the SDK is updated; resolution itself is not affected. To turn the warning off, set sentinel: 'off'.
• Requests on a cold resolve. A cold resolve on the chain's own contracts now sends 18 requests instead of 12. The extra requests are the sentinel's implementation-slot reads; the result is cached for 300 s, and the number of rounds is unchanged.
• When a read is pinned to a specific block (including rpc.call with a hex block number), a node that has not reached that block yet counts as not answering, not as a disagreement.

Install

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.2.0/tapeapi-sdk-1.2.0.tgz

To install the server package on its own, first install the SDK tgz from the same release. The full list of changes is in the CHANGELOG. Nothing here has had a third-party audit.

Thanks to @Theairresearch for the original idea.

TapeAPI 1.1.0

中文

TapeAPI 1.1.0：在 1.0 基础上只做新增，按 1.0 文档写的代码无需任何修改。

新增

• LiteLLM Proxy 一键签名（examples/litellm-sidecar/）：一个 docker-compose 包，把签名旁路放在 LiteLLM Proxy 前面。用 LiteLLM 的 AI 中转站不用改代码，每个回答都会带上可核验的回执。旁路由你自己运行，TapeAPI 不托管。

修复

• 中继：一帧的 Durable Object 写入落地之前，任何人都读不到它；写入失败时撤回这一帧，客户端的重试就是唯一的一份，不会再出现重复帧。
• RPC：批量请求遇到连接重置这类“没有回答”的失败，只暂停批量 5 分钟或 20 次调用。以前是在客户端整个生命周期里都不再批量。
• AI 回执：正确去掉 LiteLLM 以空 delta 形式发出的用量块。客户端没有要求用量时，就不会多收到一块。
• 监控：修复中继异步投递检查。
• 文档与网站的若干修正。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.1.0/tapeapi-sdk-1.1.0.tgz

单独安装 server 时，先装同一版本的 SDK tgz。完整变更见 CHANGELOG。本项目未经第三方审计。

感谢 @Theairresearch 提出最初的想法。

---

English

TapeAPI 1.1.0 is additive over 1.0: code written against the 1.0 docs keeps working unchanged.

Added

• One-command signing for LiteLLM Proxy (examples/litellm-sidecar/): a docker-compose package that puts the signing sidecar in front of LiteLLM Proxy. An AI relay running LiteLLM gets a verifiable receipt on every answer without code changes. You run the sidecar; TapeAPI does not host it.

Fixed

• Relay: a frame is readable only after its Durable Object write lands. If the write fails, the frame is taken back out, so the client's retry is the only copy and no duplicate frames appear.
• RPC: a batch failure that got no answer (such as a connection reset) now pauses batching to that node for 5 minutes or 20 calls, not for the client's lifetime.
• AI receipts: LiteLLM's usage chunk with an empty delta is stripped correctly, so a client that did not ask for usage does not receive an extra chunk.
• Monitor: fixed the relay async-delivery check.
• Various fixes to the docs and website.

Install

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.1.0/tapeapi-sdk-1.1.0.tgz

To install the server package on its own, install the SDK tgz from the same release first. The full list of changes is in the CHANGELOG. Nothing here has had a third-party audit.

Thanks to @Theairresearch for the original idea.

TapeAPI 1.0.0 — 第一个正式版 / First stable release

中文

TapeAPI 1.0.0 是第一个正式版（2026-09-29）。与 1.0.0-rc.5 相比，线上格式、SDK 与 server 的接口都没有变化；规范只改状态，
不改内容。

1.0 承诺什么

• 1.0 起遵循语义化版本。 按 1.0 文档写的代码在所有 1.x 版本里都能继续工作；破坏性修改只在 2.0。新增内容（新的可选参数、
  新字段、新错误码）可能出现在任何次版本里。
• 稳定： @tapeapi/sdk 与 @tapeapi/server 的全部导出、命令行工具 tapeapi-mcp 与 tapeapi-verify，以及公共服务
  （api.tapeapi.fun、relay.tapeapi.fun）的方法和结果格式，另有标注的除外。
• 实验性（@experimental，可能在 1.x 次版本里改变，每次改变都写进更新日志）：所有与付费有关的接口（TAP-22 付费通道、
  托管合约、凭证、api.payer()、maxPrice、api.tx 的通道构造函数、api.chain.escrow.*）、服务目录 ServiceDirectory，
  以及整个 @tapeapi/sdk/bus-privacy。从清单读取价格，以及错误码 PAYMENT_REQUIRED、BAD_VOUCHER、PRICE_CHANGED 是稳定的。
• 内部： 标注 @internal 或未导出的内容。

完整清单、从 0.x 的改动与错误码表见升级到 1.0。

规范状态（TAP-1 §4.1）

• TAP-20、TAP-21、TAP-23、TAP-26、TAP-27 自 2026-09-29 起为 Stable (v1)。 它们定义的字段、编码、签名域和错误码含义冻结；
  修订只能追加可选内容和非规范性文字；破坏性修改要作为 v2，并带自己的线上版本标记；v2 进入 Stable 满 12 个月之前不撤回 v1。
• TAP-20 §3.5（ServiceDirectory）整节为实验性，不在冻结范围内；以标签作解析输入、serviceOf 比对和 verifyDelegation
  同属实验性。按名称、容器或 (circuits, tokenId) 解析不需要目录。
• TAP-21 的错误码（包括 PAYMENT_REQUIRED、BAD_VOUCHER）随 TAP-21 一起冻结，虽然使用它们的付费流程在实验性的 TAP-22 里。
• 不变：TAP-22、TAP-25 为实验性，TAP-24 已撤回，TAP-1 为 Draft。TAP 编号仍是向 TapeKit 维护者提议的编号，尚未正式分配。

候选版要点（rc.1 到 rc.5）

• rc.1 接口冻结：新增 INVALID_ARGUMENT；TapeAPIError 顶层字段固定，细节放进 e.data；一批改名（service、
  relayClients / busClients、rpcTimeoutMs 等）；createVerifyingFetch 能核验官方 SDK 读取的流；补齐 TAP-20 §6.1 主网清单与
  TAP-23 §6 测试向量，Python 独立验证器由 159 项增至 249 项。
• rc.2 resolve() 由 7 轮 21 个请求降到 4 轮 12 个；修复同一张凭证可能被服务两次的问题。
• rc.3 网站内置的 SDK 放进按内容哈希命名的目录，发布时不会新旧模块混用。
• rc.4 最后两处错误码统一；写法不规范的计量路径改为拒绝，不再未经核验就放行。
• rc.5 Cloudflare 中继把房间存进 Durable Object 存储，空闲房间不再丢帧。

安装

先装 SDK，再装 server（server 依赖同一版本的 @tapeapi/sdk）：

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0/tapeapi-sdk-1.0.0.tgz
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0/tapeapi-server-1.0.0.tgz

从 1.0.0-rc.4 或 rc.5 升级不需要改代码。从 rc.1 到 rc.3 升级：没配 rpcUrls 的 server，以及 WebMCP 的 refresh() 和释放后的调用，
错误码改为 INVALID_ARGUMENT。从 0.x 升级见升级到 1.0。

如实说明

今天上线的一切都免费。付费托管合约没有部署，要先通过独立审计。所有代码和合约都没有经过第三方审计。TapeAPI 不发币。

点子来自 @Theairresearch；TapeAPI 未来任何收入的永久 10% 归提出者。

English

TapeAPI 1.0.0 is the first stable release (2026-09-29). Nothing on the wire and nothing in the interfaces of the SDK
and the server changed since 1.0.0-rc.5; the specifications change status, not content.

What 1.0 promises

• Semantic versioning from 1.0.0 on. Code written against the 1.0 documentation keeps working in every 1.x
  release; a breaking change comes only in 2.0. Additions (a new optional option, a new field, a new error code) may
  come in any minor release.
• Stable: every export of @tapeapi/sdk and @tapeapi/server, the command-line tools tapeapi-mcp and
  tapeapi-verify, and the methods and result shapes of the public services (api.tapeapi.fun, relay.tapeapi.fun),
  except what is marked otherwise.
• Experimental (@experimental; may change in a 1.x minor release, each change in the changelog): everything that
  pays (TAP-22 payment channels, the escrow, vouchers, api.payer(), maxPrice, the channel builders of api.tx,
  api.chain.escrow.*), the ServiceDirectory, and the whole @tapeapi/sdk/bus-privacy subpath. Reading prices from a
  manifest and the codes PAYMENT_REQUIRED, BAD_VOUCHER and PRICE_CHANGED are Stable.
• Internal: marked @internal, or not exported.

The full lists, what changed from 0.x and the error-code table: Upgrading to 1.0.

Specification statuses (TAP-1 §4.1)

• TAP-20, TAP-21, TAP-23, TAP-26 and TAP-27 are Stable (v1) since 2026-09-29. Every field, encoding, signature
  domain and error code they define keeps its meaning; a revision may add only optional content and non-normative
  text; a breaking change is a v2 with its own wire markers, and v1 is not withdrawn earlier than 12 months after v2
  becomes Stable.
• TAP-20 §3.5 (ServiceDirectory) is Experimental, outside the freeze, and so are a label as input to resolution, the
  serviceOf cross-check and verifyDelegation. Resolution by name, container or (circuits, tokenId) needs no
  directory.
• TAP-21's error codes, PAYMENT_REQUIRED and BAD_VOUCHER among them, are frozen with TAP-21, although the
  payment flow that uses them is in TAP-22, which is Experimental.
• Unchanged: TAP-22 and TAP-25 Experimental, TAP-24 Withdrawn, TAP-1 Draft. The TAP numbers are still proposals to the
  TapeKit maintainers, not yet assigned.

Release candidates, rc.1 to rc.5

• rc.1, the interface freeze: INVALID_ARGUMENT; fixed TapeAPIError top-level fields, details in e.data; a set
  of renames (service, relayClients / busClients, rpcTimeoutMs, ...); createVerifyingFetch verifies the
  streams the official SDKs read; the TAP-20 §6.1 mainnet manifest and TAP-23 §6 vectors (the independent Python
  verifier went from 159 to 249 checks).
• rc.2: resolve() in 4 round trips and 12 requests instead of 7 and 21; one voucher could be served twice (fixed).
• rc.3: the website's vendored SDK lives in a content-hashed directory, so a release never mixes old and new modules.
• rc.4: the last two error-code alignments; loosely written metered paths are refused instead of passed on
  unverified.
• rc.5: the Cloudflare relay keeps its rooms in Durable Object storage, so idle rooms no longer lose frames.

Install

Install the SDK first, then the server (the server depends on the same version of @tapeapi/sdk):

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0/tapeapi-sdk-1.0.0.tgz
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0/tapeapi-server-1.0.0.tgz

From 1.0.0-rc.4 or rc.5: nothing to change. From rc.1 to rc.3: a server without rpcUrls, and WebMCP's refresh()
and calls after dispose, now raise INVALID_ARGUMENT. From 0.x: Upgrading to 1.0.

Plainly

Everything live today is free. The paid-call escrow is not deployed and will be only after an independent audit.
Nothing here has had a third-party audit. TapeAPI issues no token.

Idea by @Theairresearch; a permanent 10% of any future
TapeAPI revenue goes to the originator.

v1.0.0-rc.5 — 修复中继空闲后丢失消息 / Relay no longer loses frames when idle

中文

v1.0.0-rc.5：修复公共中继在实例空闲后丢失消息的问题

问题：公共中继 relay.tapeapi.fun 把房间里的消息帧只放在 Cloudflare Durable Object 的内存里，而 Cloudflare 会在实例空闲十几秒后把它回收。结果：

• 按设计，房间应该保留 15 分钟，实际只能保留十几秒；
• 异步投递基本失败：群邀请、TAP-26 邀请、发给没在轮询的一方的消息，都可能丢；
• 发送方立即回读能读到，接收方稍晚读取却是 0 帧，并返回 epoch: null。

这个问题由第三方应用 TAPQQ 报告，我们在线上复现后确认：发送后闲置 30 秒，房间就已经不存在了。

修复：

• 房间写入 Durable Object 的持久存储，每一帧单独一个键；relaySend 在帧写入之后才返回。
• 实例被回收后再次加载时，房间原样恢复，epoch 和序号都不变，客户端的游标可以继续使用。
• 房间闲置 15 分钟（只有握手的房间为 10 分钟）后清除，连同存储一起删掉。
• 中继的方法、参数和返回都没有变化。

隐私：

• 消息帧（密文）、房间号、序号和时间戳，会存放在 Cloudflare 的 Durable Object 存储里，直到房间过期被清除；
• 投递来源（IP 或付款方）仍然只放在内存里，从不落盘；
• 隐私说明页已同步更新。

SDK 与服务端的接口与 rc.4 完全相同。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.5/tapeapi-sdk-1.0.0-rc.5.tgz
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.5/tapeapi-server-1.0.0-rc.5.tgz

---

English

v1.0.0-rc.5: the public relay no longer loses frames when its instance goes idle

Problem: relay.tapeapi.fun kept each room's frames only in Durable Object memory, and Cloudflare evicts an idle object within seconds. As a result:

• a room designed to live 15 minutes lived about ten seconds;
• asynchronous delivery mostly failed: group invites, TAP-26 invites, and messages to a peer that was not polling at that moment;
• the sender could read a frame back at once, while the recipient, a little later, got 0 frames and epoch: null.

Reported by the TAPQQ team and reproduced live: after 30 s idle, the room was gone.

Fix:

• Rooms are written to the object's Durable Object storage, one key per frame, and relaySend answers only after the frame is stored.
• A recycled object restores its room with the same epoch and indices, so clients' cursors keep working.
• Rooms expire after 15 minutes idle (10 for a handshake-only room), storage included.
• The relay's methods, parameters and answers are unchanged.

Privacy:

• Frames (ciphertext), room names, indices and timestamps are at rest in Cloudflare's Durable Object storage until the room expires.
• The source of a post (IP or paying consumer) stays in memory only and is never written.
• The privacy page says so.

The SDK and server interfaces are identical to rc.4.

v1.0.0-rc.4 — 审查遗留修复与错误码统一 / Review follow-ups and error-code alignment

中文

v1.0.0-rc.4：审查遗留问题修复，以及 1.0 前最后两处错误码统一

1.0 候选版审查剩下的小问题（P2）已逐条核实并修复，每条都有测试。另外有两处错误码按"参数或调用方状态错误一律报 INVALID_ARGUMENT"的规则统一。这是接口上的小改动，所以观察期从这一版重新计算。

错误码（1.0 前最后的统一）

• @tapeapi/server：没有配置 rpcUrls 时报 INVALID_ARGUMENT，原来是 INTERNAL；消息里写明怎么改。
• WebMCP：在未暴露任何工具时调用 refresh()、释放后调用 refresh()、释放后再调用工具，都报 INVALID_ARGUMENT，原来是 BAD_REQUEST。AI 代理传入格式错误的参数时，仍然报 BAD_REQUEST。

修复

• 严格模式拒绝计量路径的变体：例如 /v1//chat/completions、/v1/chat/%63ompletions。三处都会拒绝：旁路返回 400，createVerifyingFetch 在发送前报错，tapeapi-verify --strict 返回 400。这类路径以前会被不带回执地转给上游。
• 开发模式只看 createProvider({ dev: true })：清单里的 dev 字段彻底不再起作用。
• 报错消息里的升级说明链接指向线上手册；没配 rpcUrls 时给出具体改法。
• 清理了残留的死代码，以及对已弃用错误字段别名的读取。
• 浏览器冒烟测试：新覆盖"我的服务"等 5 个页面；另外修好了一组自 0.5.0 起一直失败的签名检查。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.4/tapeapi-sdk-1.0.0-rc.4.tgz
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.4/tapeapi-server-1.0.0-rc.4.tgz

---

English

v1.0.0-rc.4: review follow-ups, and the last two error-code alignments before 1.0

The remaining P2 findings of the 1.0 review were checked one by one and fixed, each with a test. Two error codes were brought in line with the rule that a caller's own mistake is INVALID_ARGUMENT. That is a small interface change, so the observation window restarts with this release.

Error codes

• @tapeapi/server without rpcUrls: INVALID_ARGUMENT (was INTERNAL), and the message says how to fix it.
• WebMCP: refresh() with nothing exposed or after dispose, and a tool called after dispose, are INVALID_ARGUMENT (was BAD_REQUEST). Malformed input from the agent stays BAD_REQUEST.

Fixed

• Strict mode refuses metered-path variants such as /v1//chat/completions and /v1/chat/%63ompletions, in all three places: the sidecar answers 400, createVerifyingFetch refuses before sending, and tapeapi-verify --strict answers 400. Such paths used to reach the upstream with no receipt.
• Dev mode comes only from createProvider({ dev: true }). A manifest's dev field no longer does anything.
• Error messages link to the online upgrade guide; a missing rpcUrls comes with the fix.
• Dead code and reads of deprecated error-field aliases are gone.
• Browser smoke test: now covers "My services" and four more pages, and a group of signature checks that had been failing since 0.5.0 is fixed.

v1.0.0-rc.3 — 发版不再混用新旧开发包 / No mixed SDK modules after a release

中文

v1.0.0-rc.3：发版后不再出现新旧混用的开发包

接口与 rc.1、rc.2 完全相同，没有破坏性修改。

• 根治 rc.2 没解决的问题：调试台、核验页、"我的服务"加载的开发包，现在放在按内容哈希命名的目录里，例如 playground/vendor/a85b126b36/。开发包任何一个文件变化，目录名都会变，浏览器不可能再把新旧文件混在一起用，也不再依赖 Cloudflare 的缓存设置。
• 目录里的文件与 SDK 源码、@noble 库逐字节相同，"页面代码可以直接核验"的承诺不变。
• rc.2 发布说明里那条没有生效的缓存设置，已在更新日志里如实更正。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.3/tapeapi-sdk-1.0.0-rc.3.tgz
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.3/tapeapi-server-1.0.0-rc.3.tgz

---

English

v1.0.0-rc.3: a release can no longer mix old and new SDK modules in the browser

The interfaces are identical to rc.1 and rc.2; nothing breaks.

• The fix rc.2 did not deliver: the vendored SDK behind the playground, the receipt checker and "My services" now lives in a content-hashed directory (for example playground/vendor/a85b126b36/). Any change to any file changes the directory name, so a browser can never mix old and new modules, whatever the CDN's cache settings.
• The files are byte for byte what sdk/src and @noble hold, so the page code stays directly verifiable.
• The rc.2 changelog entry that did not take effect is corrected.

v1.0.0-rc.2 — 观察期优化与修复 / Observation-window optimisations and fixes

中文

v1.0.0-rc.2：1.0 观察期的优化与修复

接口与 rc.1 完全相同，没有破坏性修改。从 0.x 升级请读升级说明。

• 解析服务更快：api.resolve() 从 7 轮串行往返、21 个请求，降到 4 轮、12 个请求。
  • 用默认 BSC 节点实测（中位数）：新客户端从 2.77 秒降到 1.79 秒；同一客户端再次解析从 2.00 秒降到 0.68 秒。
  • 多节点一致规则、文件长度与哈希校验、容器重新推导、委托核验都没有变。缓存只保留处理器和容器地址的查询结果，最多 300 秒，不跨链；持有人和清单每次都重新读取。
• 付费路径修复：同一张凭证在并发调用下可能被服务两次，现已修复。付费托管合约尚未部署，今天没有任何线上调用受影响。
• 首页更快：字体从样式表拆成独立文件，阻塞渲染的样式表从 58 KB 降到 6 KB（压缩后），慢速 4G 下首次显示提前约 140 毫秒；外观逐像素不变。
• 更正（发布后实测）：这一版给调试台、核验页、"我的服务"加载的开发包设置了"每次重新验证"的缓存头，但上线后实测没有生效：Cloudflare 站点层面的浏览器缓存设置会把 .js 文件的缓存强制改为 4 小时。所以发版后的 4 小时内，回访用户仍可能拿到新旧混用的开发包。这个问题从 0.x 就存在。下一个候选版会根治：开发包目录按内容哈希命名，一有变化网址就变。在此之前，遇到页面异常请强制刷新。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.2/tapeapi-sdk-1.0.0-rc.2.tgz
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.2/tapeapi-server-1.0.0-rc.2.tgz

---

English

v1.0.0-rc.2: optimisations and fixes during the 1.0 observation window

The interfaces are identical to rc.1; nothing breaks. Upgrading from 0.x: see the upgrade guide.

• Faster api.resolve(): 4 round trips and 12 requests instead of 7 and 21.
  • Measured against the default BSC nodes (medians): a new client goes from 2.77 s to 1.79 s, and the same client again from 2.00 s to 0.68 s.
  • The quorum, the file length and hash checks, container re-derivation and the delegation check are unchanged. Only processor and container lookups are cached, for at most 300 s and per chain; the holder and the manifest are read every time.
• Paid path: one voucher could be served twice under concurrent calls. Fixed. The escrow is not deployed, so no live call was affected.
• Faster homepage: the fonts are separate files, so the render-blocking stylesheet drops from 58 KB to 6 KB (brotli). First paint on Slow 4G comes about 140 ms sooner, and the page looks the same pixel for pixel.
• Correction (measured after release): this release sets a revalidate-every-load cache header on the vendored SDK, but it does not take effect: the site's Cloudflare browser-cache setting forces 4 hours on .js files. For up to 4 hours after a release, a returning visitor can still run a mix of old and new SDK files, as has been possible since 0.x. The next candidate fixes it at the root by naming the vendor directory after its content hash. Until then, force-reload if a page misbehaves.

v1.0.0-rc.1 — 1.0 候选版 / Release candidate for 1.0

中文

v1.0.0-rc.1：1.0 候选版

这是 1.0 之前的最后一个候选版：接口已按 1.0 冻结。观察期约一周，这期间只修问题、不改接口；没有问题就发布 1.0.0。1.0 之后，破坏性修改只会出现在 2.0。

从 0.x 升级：请先读升级说明，约 20 条破坏性修改，每条都写了改法。

重点

• 严格核验不能被绕过：
  • 流式回答必须在流结束前核验通过回执，否则流会报错 RECEIPT_INVALID。无论是 [DONE]、最终事件还是上游断开，都算流结束。
  • 发往计量路径、却对不上清单端点的请求，会在发送前报错。
  • 非流式回答核验失败时返回一个不可重试的 502（x-should-retry: false），官方 SDK 不会自动重试，不会重复付费。
  • 以上都用官方 openai 与 @anthropic-ai/sdk 实测过。
• 流式回答不再多等：回执核验通过后立即放出最后一段，不再等上游关闭连接。非严格模式不扣留。
• 接口统一：
  • 参数或配置错误统一报 INVALID_ARGUMENT；
  • 错误对象的顶层字段固定，其余信息放进 data；
  • svc 改为 service；
  • 群聊投递参数改为 relayClients / busClients；
  • timeoutMs 改为 rpcTimeoutMs；
  • 开发模式只能由 dev: true 显式打开。
• 稳定级别：接口分为 Stable、Experimental、Internal 三级，只有 Stable 进入 1.0 的承诺。付费相关接口和通道读取隐私（bus-privacy）标为实验性。
• 规范：
  • TAP-1 定义了四种状态：Draft、Stable (v1)、Experimental、Withdrawn；
  • TAP-20/21/23/26/27 将在 1.0 当天转为 Stable (v1)；TAP-22、25 为实验性，TAP-24 已撤回；
  • 新增 TAP-20 主网清单与 TAP-23 两家一致的测试数据，独立 Python 实现核对 249 项。
• 新首页与 README：按读者分入口，示例都实际跑过。
• 服务端包：@tapeapi/server 也随 Release 发布，先装 SDK，再装 server。

安装

npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.1/tapeapi-sdk-1.0.0-rc.1.tgz
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.0.0-rc.1/tapeapi-server-1.0.0-rc.1.tgz

未经第三方审计。回执证明的是谁回答了哪些字节、声称的用量和价格，不证明实际跑的是哪个模型。

---

English

v1.0.0-rc.1: release candidate for 1.0

The last candidate before 1.0: the interfaces are frozen for 1.0. During the observation window (about a week) only fixes land. After 1.0, breaking changes come only in 2.0. Upgrading from 0.x: read the upgrade guide, about 20 breaking changes, each with its fix.

Highlights

• Strict receipt checks cannot be skipped.
  • A stream must verify its receipt before it ends ([DONE], the final event or the upstream closing), or it errors with RECEIPT_INVALID.
  • A request to a metered path that does not match the manifest endpoint is refused before it is sent.
  • A whole answer that fails verification returns a non-retryable 502 (x-should-retry: false), so the official SDKs do not retry and do not pay twice.
  • All of this was tested with the official openai and @anthropic-ai/sdk.
• No added latency on streams: the last event is released as soon as the receipt verifies, with no waiting for the upstream to close. Non-strict mode holds nothing back.
• One vocabulary:
  • INVALID_ARGUMENT for configuration and argument mistakes;
  • a fixed error shape, with everything else in data;
  • svc → service;
  • relayClients / busClients for group delivery;
  • timeoutMs → rpcTimeoutMs;
  • dev mode only through dev: true.
• Stability levels: Stable, Experimental and Internal. Only Stable is in the 1.0 promise. Payments and bus-privacy are Experimental.
• Specs:
  • TAP-1 defines the Draft, Stable (v1), Experimental and Withdrawn statuses;
  • TAP-20/21/23/26/27 become Stable (v1) at 1.0; TAP-22 and TAP-25 are Experimental; TAP-24 is withdrawn;
  • new vectors (the TAP-20 mainnet manifest and TAP-23 two-provider agreement), with 249 checks by an independent Python implementation.
• New homepage and READMEs, organised by reader, with every example run.
• @tapeapi/server now ships with the release: install the SDK first, then the server.

No third-party audit. A receipt proves who answered which bytes and the claimed usage and price, not which model actually ran.