The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the TapeAPI: signed BNB Chain reads listing page.
Tape out a circuit, and its container is your API. Every response is signed by it, anyone can verify it against the chain, and containers can talk to each other over end-to-end encrypted channels.
TapeAPI is the service and communication layer of the TapeOut ecosystem on BNB Chain. In that ecosystem, DeWEB is websites, TapeSend is messaging, and TapeAPI is services.
中文说明 · Guides · Specifications · Examples · Docs · Website · Changelog · Roadmap · Contributing · Code of Conduct
Status: pre-alpha (v0.8.0). The free tier needs no contract of ours and runs on TapeOut's deployed contracts. Our own contracts (the paid-call escrow, the service directory, ChannelBus) are not audited by a third party; ChannelBus is deployed (address below). Interfaces may still change. The TAP numbers below are proposed to the TapeKit maintainers and not yet assigned.
A free public service runs at https://api.tapeapi.fun under the TapeOut name 11.1013.tape. Ask it for the BNB price:
curl shows you the signed envelope (result, container, ts, block, sig) but does not check it. The SDK does.
The packages are not on npm yet, so set up the repository once (Node.js 20 or later):
Or install just the SDK into your own project from the GitHub release (not the npm registry):
Save this as try.mjs inside the tapeapi directory (@tapeapi/sdk resolves through the repository's workspace;
a script saved anywhere else fails with ERR_MODULE_NOT_FOUND) and run node try.mjs:
No install at all: the playground runs the same SDK in the browser. Every method of the public service is listed in Public API.
The same eight methods are MCP tools at https://api.tapeapi.fun/mcp (Streamable
HTTP, no key). In Claude, add it under Settings > Connectors > Add custom connector; in Cursor, add it to
mcp.json:
Every result is signed by the service's on-chain delegated key and carries a receipt with a verification link that
anyone can check against the chain. The remote server signs its answers; the local command tapeapi-mcp, in the SDK's
release package, checks every answer itself before the model sees it. Setup for each client, receipts and limits:
MCP guide.
An API today is a URL plus an account plus trust. You sign up with the vendor, you trust whatever its server says, and the vendor can change the answer, the price or the rules at any time.
TapeAPI makes the identity of a service an on-chain object and every answer a signed statement:
.well-known/tapeapi.json, the manifest: endpoints, methods, prices and the service's signing key.Requirements: Node.js 20 or later. The packages are not on npm yet; use the repository.
Run the minimal example service locally (it reads BNB Chain through public nodes):
Call it from code. The SDK resolves the manifest, calls the method and verifies the signature before it returns:
On mainnet, resolve by TapeOut name, container address or circuit, with at least two RPC nodes that must agree:
Or with curl, and verify by hand later (how):
Wrap any function, or any existing REST API, as a signed method:
Going live takes a circuit with an opened container, a delegation signed by its holder, and the manifest written to the container's site. The holder console does all three from a phone wallet. See Run a service.
| Verifiable answers | Signed envelopes bound to the exact request; signer checked against the on-chain holder; freshness window; an independent Python implementation checks the test vectors. |
| Quorum reads | Chain reads need agreement from every answering node, never a majority. callQuorum accepts a result only when independent providers return the same bytes. |
| Pay per call | Cumulative EIP-712 vouchers, session keys, an escrow with a withdrawal cooldown, no mandatory protocol fee and no operator fee switch; a default 1% maintenance contribution from the provider's share that each provider can set to 0 (or up to 50%). Not deployed yet. |
| Private channels | TAP-26: mutual authentication, forward secrecy, per-direction keys, replay and reorder protection; relay or on-chain transport. |
| Private groups | TAP-27: up to 32 containers, owner-managed epochs, encrypted roster, per-sender signatures. |
| On-chain transport that does not lose messages | The ChannelBus reader holds rather than skips: it works with public nodes' history limits, result caps and failures, and warns about anything it cannot read. Tested with thousands of randomised adversarial runs. |
| AI agents | exposeTapeAPI turns any service into WebMCP tools for in-browser agents; every answer is signature-checked, paid methods need an explicit budget. |
| Runs anywhere | Node, Cloudflare Workers (Fetch API), browsers and DeWEB sites; three small audited dependencies (@noble/curves, @noble/hashes, @noble/ciphers). |
| Path | What it is |
|---|---|
sdk/ | @tapeapi/sdk: resolve, call, pay, verify, channels, groups, WebMCP bridge. |
server/ | @tapeapi/server: the provider runtime (Node listen and Fetch handleRequest), metering, rate limits. |
contracts/ | Solidity with Foundry tests: TapeAPIEscrow, ServiceDirectory, ChannelBus. |
spec/ | The TAPs, bilingual (English authoritative), with test vectors and an independent Python verifier. |
examples/ | Runnable services: minimal reader, Web2 adapter, DeFi reads, attested cross-chain reads, a relay, a Cloudflare Worker, a WebMCP demo. |
conformance/ | A black-box suite any provider or relay implementation can run against a URL. |
site/ | The website and the holder console (site/console/), plain static files. |
docs/ | Guides and design notes; start at docs/README.md. |
| TAP | Title | In one line |
|---|---|---|
| TAP-1 | TAP process | Types, statuses, numbering and required sections. |
| TAP-20 | Service identity and manifest | A service is a circuit; .well-known/tapeapi.json; the holder's EIP-712 delegation; the resolution algorithm. |
| TAP-21 | Signed response envelope | POST {live}/{method}; the TAPI-1/resp/v2 digest; canonical JSON; error codes. |
| TAP-22 | Metered payment | Cumulative vouchers, per-provider escrow channels, no mandatory protocol fee (default 1% contribution, provider can set 0). |
| TAP-23 | Attested Read | Signed, block-pinned reads of other chains, agreed by independent providers. |
| TAP-24 | Intent RFQ | Signed quotes for bridge-free cross-chain swaps (frozen until staking exists). |
| TAP-25 | Circuit-Verified Methods | Methods bound to a circuit whose on-chain eval() settles disputes. |
| TAP-26 | Tape Channel | End-to-end encrypted channels between containers; relays and ChannelBus. |
| TAP-27 | Tape Group | Private groups of up to 32 containers. |
| Contract | Address | Owner |
|---|---|---|
| DeWebHub | 0xe61A9C7213a6Aa616C246a2B569e555B417b25ee | TapeOut (deployed) |
| SiteRegistry | 0xd006ffdd5Ae313B17729621A00999cD3C71CE5e6 | TapeOut (deployed) |
| Processor factory | 0x68224F668083c29e9800Be2a646d42d18cedF7e2 | TapeOut (deployed) |
| BEM token | 0x5ce033b2bfca3af30b3e8c8457deaf776a8b695a | TapeOut (deployed) |
| ChannelBus | 0x486110c35d9b90a9d6D85c8063A065f9e7b6b707 | TapeAPI (no owner, no state, no upgrade path) |
| TapeAPIEscrow, ServiceDirectory | not deployed | TapeAPI |
npm test), 169 Foundry tests (cd contracts && forge test), and 102
checks by an independent Python implementation of the signatures, hashes and encodings
(python3 spec/vectors/verify.py).Report vulnerabilities privately, as described in SECURITY.md. Please do not open public issues for security problems.
Issues and pull requests are welcome; see CONTRIBUTING.md. Specification changes go through the TAP process in TAP-1. All three test suites must pass.
Code is MIT (LICENSE): contracts/, sdk/, server/, examples/, conformance/, scripts/, site/.
The specifications in spec/ are CC0-1.0 (LICENSE-SPEC).
The idea of a service layer for TapeOut, "DeWEB is websites, TapeSend is messaging, TapeAPI is services", came from @Theairresearch. A permanent 10% of any revenue TapeAPI earns goes to them.