TapeAPI: signed BNB Chain reads

TapeAPI

A signed receipt for every AI call. Put a sidecar in front of your OpenAI- or Anthropic-compatible API, and every answer comes with a receipt anyone can check: who answered, to which request, with which bytes, and what usage and price were claimed. Your users keep their official SDKs and change only the base URL.

TapeAPI is the signed API layer of TapeOut. The same on-chain identity and signatures also cover MCP tools and end-to-end encrypted channels and groups, on BNB Chain, X Layer and Base.

中文说明 · Website · Docs · Guides · Specifications · Examples · Changelog · Roadmap · Upgrading to 2.0

2.0: standards by default. Pass no options and createTapeAPI() resolves a service the way TapeOut's official

TAPs say: TAP-10 v1.1 §3 to §7 and TAP-11 §2, every read at one pinned block, strict agreement of the nodes on the

chain and the owner, and a named status instead of a quiet success when a name was never opened (not-opened), is

not activated or its payment has run out (unpaid), or TapeOut's site store or payment contract runs an

implementation the SDK does not list (store-changed). TAP-11 and TAP-13 are drafts we wrote and submitted; the

editors merged both into the official repository as Drafts, and a merge into Draft is not adoption. TAP-10 and

TAP-11 are Drafts, so the default follows their text by one rule: a loosening or a new status name in a 2.x minor

release, a tightening first as an optional profile and the default in 3.0. The 1.x behaviour is one option away,

conform: false (deprecated, kept in all of 2.x). One known exception: without allChains, a processor

contract#ID is refused; see Upgrading to 2.0. Also in 2.0: private channels and groups

use the tape-channel/ and tape-group/ labels the TAPs editors asked for.

New in 2.0 · Upgrading to 2.0

Experimental, first public in 2.0: bounded agents. An AI agent may spend for a container, and the most it can lose

is fixed by an escrow contract and checkable on chain by anyone: one escrow channel per service, a one-off session key

for the agent, a limiter that never signs past the cap, and orders that resume after a restart with the keys and order

records kept encrypted. The limits, plainly: the escrow contract is not audited and not deployed, so none of

this works on mainnet today; it is checked on local chains and in tests only, and @tapeapi/sdk/agent is outside the

2.x compatibility promise. Bounded agents

Status: released, 2.4.0. Everything live today is free. TapeAPI follows semantic versioning: code written to the

2.0 docs keeps working in every 2.x release, and 1.x receives security fixes for 6 months after 2.0.0. Paid calls

(TAPI-22) are experimental and not deployed. Nothing here has had a third-party audit. Security note: on 1.0.0 to

1.4.0, streamed AI receipt verification could, under particular chunking, report a truncated or content-injected

stream as verified; it was fixed in 1.5.0

(release notes).

What it does

• Signed answers and receipts (Stable since 1.0). Every answer is signed by a key the circuit's holder delegated on chain and bound to its request; an AI call also gets a usage receipt, priced from the table on chain. Call a service · For AI providers
• Resolution as TapeOut's official TAPs say (the default since 2.0). A name is resolved as TAP-10 v1.1 and TAP-11 §2 (a Draft) say, at one pinned block, with a status from the TAPs (e.data.status) on every failure. Introduced in 1.4 as the opt-in conform: 'tap10'; conform: false keeps the 1.x resolution through 2.x. Its status names only grow, and they are experimental in 2.0. Upgrading to 2.0
• MCP tools (Stable since 1.0). Signed results with a receipt, and tool definitions pinned on chain by their hash: a public endpoint, a signing proxy for your own server, and tapeapi-mcp to check every answer locally. MCP
• Private channels and groups (Stable since 1.0; version 2 of their specs, with tape-channel/ and tape-group/ labels, is the default since 2.0). End-to-end encrypted, between containers, over a relay or ChannelBus. Channels · Groups
• Streamed AI receipts, with usage you can check (1.5 to 1.6). A streamed receipt fails when the stream was cut short or had content added; the opt-in requestUsage puts the usage of a streamed OpenAI Chat answer inside the signed stream so it is checked like a whole answer's (it does not prove the upstream's own count). Streamed usage: three ways
• Container agents (experimental). Phase 0 (1.7): a holder-signed mandate, a task thread from offer to acceptance, and a read-only payment check, with no new contract and no enforcement. Bounded agents (2.0): a mandate that names funds, enforced by escrow channels, on local chains and in tests only. Container agents · Bounded agents
• Prices in US dollars, paid in BEM, and reviews between containers (2.0, experimental). The reference implementations of two TAP drafts we submitted as pull requests (#52 and #54), not merged. No escrow is deployed, so no call is charged. Below

New in 2.0

2.0 has one theme: what we submitted to TapeOut's official TAP process, and what TapeOut itself specifies, is what the SDK does when you pass nothing, with one known exception (below). Every breaking change, with what to write instead, is in Upgrading from 1.x to 2.0; the wire formats and frozen constants of TAPI-20 to TAPI-27 do not change, so a 2.0 client verifies every 1.x manifest, delegation, signed response and receipt.

Standards by default

import { createTapeAPI, rpcUrlsFor } from '@tapeapi/sdk'

// 2.0: TAP-10 / TAP-11 §2 resolution, exactly what conform: 'tap10' did in 1.x const api = createTapeAPI({ rpcUrls: rpcUrlsFor(56) }) // 2.0: the 1.x resolution, request for request (deprecated; kept in all of 2.x; one onWarning when the client is made) const legacy = createTapeAPI({ rpcUrls: rpcUrlsFor(56), conform: false })

TAP-10 and TAP-11 were merged as Drafts (a merge is not an adoption), so their text can still change. When it does, a loosening or a new status name becomes the default in a 2.x minor release; a tightening is offered first as an optional new profile and becomes the default in 3.0. Status names only grow. conform: false does not follow the TAPs at all. How the default follows changes

• Branch on `e.data.status`, not on messages: the status names are the lowercase names the TAPs use (unsupported, hub-changed and container-mismatch are TapeAPI's own). Names only grow, and data.status is experimental in 2.0 (it follows a Draft); it is considered for Stable after TAP-11's review period ends with no unresolved objection. not-opened and unpaid are for the provider to fix (do not retry), store-changed means update the SDK (conform: false is the stop-gap), unavailable is a node problem (retry, or add an operator of your own).
• The command lines follow. tapeapi-verify, tapeapi-mcp and tapeapi-doctor use the new default, say which resolution they used, and take --no-conform for the 1.x one. In the default, tapeapi-doctor now fails a name that is not activated (a default client cannot resolve it); with --no-conform it is still a warning.
• The agent toolkit too. createAgentKit (@tapeapi/sdk/agent, experimental) resolves the agent and the providers as TAP-11 §2 says when you give it no resolve.
• `dev: true` means `conform: false`, without a warning: development mode never checks the chain identity.
• What it costs. Measured on BNB Smart Chain with the default nodes, a cold resolution of one service sends about 45 JSON-RPC calls instead of about 24 (about 2 times); a repeated one on the same client about 36 instead of about 9 (about 4 times). If a public node rate-limits you, add an operator of your own to rpcUrls.
• How we checked. A differential run over 637 cases: conform: false made the same requests in the same order with the same results as 1.8.1's default in all 637 (the only differences allowed: the deprecation warning, and the version-2 inbox room that chain.channelKeys reports). Our own services 11.1013.tape and 12.1013.tape resolve on mainnet with the TAP-10 resolution; both are activated, paid until 2036-08-09.
• If you provide a service: run tapeapi-doctor from a 2.0 install. If its first seven checks pass (name to delegation), a 2.0 client resolves you; the checks after them are for AI services, so a service that is not one fails at ai-field, as in 1.x. If the name's payment runs out, 2.0 clients see unpaid, and the receipt checker can no longer check receipts your service signed while it was paid.

Other breaking changes

• Private channels and groups use TAPI-26 v2 and TAPI-27 v2 by default: labels that begin with tape-channel/ and tape-group/ instead of TAP-26/ and TAP-27/, as the TAPs editors asked before merging the drafts #12 and #20. labels: 'v1' selects version 1 (deprecated in 2.x, not removed in 2.x). The two versions do not interoperate, and nothing fails open: a mismatched pair times out or gets a named mismat