biii

BIII

在 Base 上安全支付判定，证据随附：29 个工具、55 个模块、 142 个测试文件、54 个自行公布边界的探测器。非托管、仅描述符， 每项判定都可在链上重新验证。

读作 “B3”。写作 BIII——一个带三道横杠的 B。 Base 上面向现实世界的 USDC 收银台：独立商户只用一部手机，就能当面接受 USDC。非托管（使用商户自己的钱包），无需终端、PSP 或 KYB 中间商。

B = Base · 3 = 三部曲的第三阶段，也是 Base 的三大支柱。

---

缺口（基于调研，而非假设——2026-07-21）

在 Base 上接受 USDC，对线上企业来说已不是难题，对现实世界中的独立商户来说却仍未解决：

现有方案	为什么不符合需求
Base Pay（Coinbase）	仅支持在线结账——基于浏览器的 pay() SDK；不支持当面支付，没有二维码，也无法脱离网站使用
Lyzi	通过支付服务提供商提供 PSP + 实体终端（Ingenico/Verifone），面向企业客户
Flexa + Base Pay	支持当面支付，但商户必须加入 Flexa 网络
BitPay / Binance Pay / Eco	托管型处理商——需要 KYB、收取费用，且由它们持有资金
Shopify POS + USDC	必须使用 Shopify
原始地址 + 二维码（DIY）	没有用户体验、确认或收据，且需要技术知识

没有任何服务能满足咖啡馆、集市摊位、管道工、自由职业者的需求：他们只想用一部手机在 Base 上收取 USDC，把资金留在自己的钱包里，并交付一张真正的收据——两分钟内完成，无需注册账户。

（上方日期为调研核实日期；公开声明前请重新核查。我们致力于与 Base/Coinbase/Flexa/Lyzi 兼容，不声称与其存在合作关系。）

三部曲——第三阶段：Agent 经济向现实世界中的人类付款

MainStreet   →  WHO is safe to pay            (the reputation oracle)
LAWBOR       →  agent ↔ agent, outcomes PROVEN paid in USDC on Base
BIII         →  agents & humans  →  REAL-WORLD merchants     ← this

BIII 是链上 Agent 经济与街角店主之间的桥梁。它将同样的“可安全支付”及“经真实 USDC 转账证实已付款”的严谨标准，应用于收银台。

工作原理

1. 商户输入金额。→ 生成一笔收款请求（仅数据；使用商户自己的地址）。
2. BIII 显示一个通用二维码——一种 EIP-681 支付 URI，所有主流钱包都能扫描（Base App、Coinbase Wallet、MetaMask、Rainbow 等）。
3. 客户（或 AI Agent）使用自己的钱包在 Base 上支付 USDC。
4. BIII 监控链上情况，并逐字段验证转账——代币 / 链 / 收款方错误、支付不足或未确认 ⇒ 永远视为未付款。多付的部分算作小费。
5. 双方都会收到一张锚定至 txHash 的收据（任何人都可以在 Basescan 上对其提出质疑）。

**BIII 不持有密钥，也不转移资金。**它只生成支付意图并读取链上数据；客户的钱包负责签名，而只有区块链——不是我们——有权判定“已付款”。

运行

npm test                               # all offline; 1269 assertions across 96 files + a 22-case eval harness (2026-08-05)
node test/suite-total.js               # re-derives that count — two report formats coexist, so grep undercounts it
BIII_MERCHANT=0x<your address> npm run serve   # the non-custodial HTTP surface, :4700

• lib/till.js — 纯核心：金额计算、收费、EIP-681 URI、验证、收据
• lib/chain.js — 只读 Base 监视器（查找付款转账；绝不凭空编造）
• lib/server.js — 精简 HTTP：/charge、/status、/receipt、/trust（本地安全付款判定，只需一次 fetch() — 已知恶意项筛查 + 此节点的 trust-core 分类器 + 底线来源信息，失败时默认拒绝，CORS 开放：任何 Web 应用都能嵌入付款前检查，无需 MCP；与 MCP 工具共用 lib/vet.js，确保两种接入方式不会产生偏差）、/asset（代币化资产真实性检查，只需一次 fetch — genuine/impersonation/unsafe/unknown，失败时默认拒绝：非注册表代币绝不会被误判为 genuine；任何页面都能嵌入交易前检查，并在链上重新验证）
• lib/trust.js — 信任三角：将声誉（MainStreet）+ 良好记录（LAWBOR）+ 结算（链上）组合为一个失败时默认拒绝的判定（unsafe/unknown/trusted/settled）
• lib/invoice.js — 同一注册表也支持 Web2 风格的发票：编号、明细项（精确微额计算）、到期日、账单收件方 — 使用相同的 EIP-681 付款，采用相同的链上验证规范，具备已结算/逾期生命周期，其收据也会进入与咖啡馆销售记录相同的、可验证的收银记录
• lib/asset.js — 同一注册表也支持代币化资产（股票 / 国债 / RWA）：代币合约属于真实发行方，还是冒名者？genuine / impersonation / unsafe / unknown，失败时默认拒绝 — 可检测 FBI 标记的仿冒代币欺诈，并纳入信任三角（till_vet_asset）。
• 发行方验证注册表（data/issuer-verified.json，已提交，多链） — 权威、无需密钥、适用于商业场景的层级，可获得醒目的**绿色“发行方已验证”**徽章。共 11 条链上的 183 个条目（由 hermes/economy/probe-readme-claims.js 于 2026-08-05 统计，该脚本读取注册表而非此处的描述），全部来自发行方直接来源：Dinari dShares（Base 上的 54 个条目 — 从工厂的 DShareAdded 事件中枚举链上条目，并通过 symbol()/name() 逐个重新验证；scripts/biii-rwa-issuer-direct.js）、Backed / xStocks（Ethereum/Optimism/BSC/XLayer/Mantle/Arbitrum/Ink 上的 100 个条目，来自 Backed 自有的公开 API api.backed.fi，无需密钥；另有 Base 上的 12 个条目，来自 backed-fi/tokenlists；scripts/biii-issuer-backed.js）、Ondo（9 个 OUSG/USDY/rUSDY 条目 — 来自官方文档，逐个进行链上验证），以及 Base 上 8 个单一发行方条目（Circle USDC/EURC、Coinbase cbBTC/cbETH、Franklin Templeton BENJI、Lido、Aerodrome）。 lib/asset-registry 按地址将此注册表与聚合器数据合并，因此已验证地址会显示 provenance: issuer-official（绿色），其余条目则继续显示聚合器的蓝绿色。
• scripts/biii-rwa-registry.js — 构建聚合器回退层（蓝绿色“已收录”层）。Coingecko 免费套餐（无需密钥）→ data/rwa-registry.json，generatedFrom: "coingecko (free)"。Coingecko 是聚合器，因此此处匹配的条目会显示 provenance: aggregator（蓝绿色“已收录”），绝不会显示为发行方验证的绿色 — 交叉检查（scripts/biii-issuer-registry.js）会标记聚合器列出的地址与发行方官方地址不同的任何符号（可能是仿冒代币）。**安全兜底：**每个条目都必须通过验证（0x + 40 位十六进制 · 整数 chainId · 符号），否则将被丢弃 — 即使架构发生变化，结果也只会是空注册表，绝不会出现错误的“真实”地址。
• lib/export.js — 财务团队需要的会计导出功能：till_export 将同一批已验证收据转换为会计师可用的 CSV（QuickBooks / Xero / Excel 可导入），每一行都包含 txHash + Basescan 链接 — 指向链上记录的凭据，而不是一本需要盲目信任的账簿。非托管，可重新验证。
• lib/meter.js — 白标试点的用量→账单机制：till_meter 根据一个月的收据，按注入的套餐生成账单，并按信任状态拆分 — 已结算收据记录在链上（可验证），判定数量由自行报告（仅供参考），并明确标注。纯函数、无状态、非托管。
• lib/erc8004.js — 与主流 Agent 声誉标准互操作（ERC-8004）：将 ReputationRegistry.getSummary 结果转换为独立、仅供参考且可重新验证的 till_trust 观察视角。反馈由客户端提交（可能遭受女巫攻击刷分），因此绝不会纳入付款判定 — 它只提供参考，除非筛选为可信客户端，否则会保留女巫攻击提示，并始终指引用户在 Base 上重新验证 getSummary。
• 去中心化可供检查，而非仅靠宣称 — 已知恶意项底线带有内容指纹（floorFingerprint / till_floor）：具有相同指纹的两个节点会依据同一条客观底线作出判断，而该底线可从具名的公开 MIT 列表重新推导，因此一致性基于公开数据 + 确定性哈希，而非中心化运营方。分类器经过复制（纯 trust-core），底线基于公开数据收敛，相对声誉则刻意保持本地化 — 若存在差异，始终会以失败时默认拒绝的方式处理（数据较少的节点会更加谨慎，绝不会更加宽松）。
• lib/identity.js — Agent 身份胶合层：npub 和/或 did:key ↔ Base，无需信任第三方。将 buzz/Nostr 身份（secp256k1 npub）或 gitlawb 身份（Ed25519 did:key），也可以将两者解析为可付款、可进行信任评估的 Base 地址，方法是使用双向证明（每个身份密钥都要签名，Base 密钥也要签名，且所有签名针对同一条规范消息；任何人都能重新验证）。失败时默认拒绝：未经验证 / 身份密钥缺少签名 / 没有身份密钥 / 已过期 ⇒ 这只是声明，不具约束力。解析不等于信任 — 仍需针对该地址运行信任三角。
• lib/skyfire.js — 与 Skyfire 互操作（Experian 的 Agent 身份层）：(1) KYA JWT 观察视角 — 谁为 Agent 提供支持（仅供参考，aud 可防重放，会显示薄弱的安全态势：没有 exp 或未绑定受众的令牌会被标记；严格调用方可通过 requireExpiry 拒绝此类令牌）；(2) authorizeCharge — 可编程付款：只有当收费符合 Agent 所有者签署批准的范围时，才能将其转为可执行的 EIP-681 意图 — 包括代币、收款方允许列表、单笔收费上限，以及累计上限（防资金耗尽：十笔小额收费也不能绕过较低的上限；格式错误或缺失的限制将被拒绝，绝不会视为“无限制”）。两者都在失败时默认拒绝；BIII 不会自行验证 JWT 签名（委托处理，无依赖项）。
• bin/biii-mcp.js — Agent 桥接层：任何 Agent 都能加载的 MCP 服务（29 个工具，根据导出的 TOOLS 列表统计 — 而非对源码使用正则表达式，否则会因 till_b20_authentic 名称中带有数字而漏掉它： till_authorize、till_b20_authentic、till_check_invoice、till_check_payment、till_create_charge、 till_create_invoice、till_export、till_floor、till_funder_history、till_key_exposure、till_kya、 till_launch_funder、till_meter、till_open_approvals、till_receipt、till_recovery_offer、 till_resolve、till_roll、till_rug_powers、till_seed_exposure、till_trace_theft、till_trust、 till_verify_delivery、till_vet_agent、till_vet_approach、till_vet_asset、till_vet_meme、 till_vet_merchant、till_watch_wallet）— Agent 可以审查商家或代币化资产，一次调用即可获取完整的信任三角，开具或支付发票，保存收据，导出账簿，计量用量，证明其底线，将 buzz npub 或 gitlawb did:key 解析为 Base 地址，读取 KYA 身份，仅在签名授权范围内支出，并生成可验证的账簿（till_roll）
• pitch/trust-triangle.html — 可用于销售的白标单页介绍（自包含，可适配主题）
• COMPETITION.md — 经研究的市场格局（注明日期）：利用现有支付渠道（x402/Stripe），与标准互操作（ERC-8004/Skyfire KYA），始终保持非托管 — 开放层是非托管信任注册表
• INTEGRATION-buzz.md / INTEGRATION-gitlawb.md — 诚实的合作简介，每份都附有可运行的离线证明（examples/buzz-agent-pays.js、examples/gitlawb-agent-pays.js — 已在 CI 中通过冒烟测试，确保演示不会失效）：密钥对 Agent 解析→Base，受制裁交易对象会被拦截，正常付款完成结算，并生成以 txHash 为锚点的收据
• web/ — 商家手机应用（PWA）：金额 → QR → 已付款 ✓ → 收据

商业模式 — 供合作伙伴转售的信任 + 桥接层

BIII 不只是一个逐个帮助商家增长的应用。它是一个白标信任 + 桥接层，供已经拥有商家资源的公司接入：

他们带来客户群。BIII 提供可信的 USDC 支付 + 人与 Agent 之间的桥接 + 可验证的收据。面向 PSP、新型银行、商家平台和 Base 生态应用销售。

用于这类洽谈的单页介绍——信任三角、四种判定状态、白标合作模式、收据和客观的市场概况——位于 pitch/trust-triangle.html（独立文件、支持主题适配、不发起外部请求）。

Lyzi 为 PSP 提供白标服务，但面向终端设备和企业，且仅支持人工操作。BIII 同样支持白标——而且它还允许 AI Agent 付款、提供无法伪造的消费者收据，并以非托管方式运行（合作伙伴绝不会接触商家的资金，因此无需申请货币转移托管牌照）。这正是我们的差异化切入点。

立场：真诚欢迎拥有分销渠道的合作伙伴。我们构建时兼容 Base/Coinbase/Flexa/Lyzi，只有签署协议后才会宣称建立了合作关系（反炒作）。

信任路线图 — 保障双方安全

• 现在： 通过逐字段的链上验证保护付款方；可通过 MainStreet 的“付款安全”信誉机制审核商家（till_vet_merchant），仅供参考。
• 下一步（ZK）： 提供保护隐私的证明，让双方各自证明重要信息，而不暴露身份——例如“该商家已通过验证”“该付款方信誉良好 / 资金充足”——以零知识徽章呈现，而非数据倾倒。收据已经证明了付款；ZK 则证明了交易双方。（设计已在跟进，尚未构建完成——功能上线前不会宣称支持 ZK。）

收据与账簿（面向人的一层）

lib/ledger.js 会将付款转换为普通人一眼就能读懂的纸质票据（商家、B3-####、商品、金额、小费、✓ 已付款、验证链接），并为商家生成可验证的每日汇总——每一笔都可在链上重新核验，同一个 txHash 只计一次，账簿无法虚增。目前还没有任何服务为线下 USDC 支付提供这些；这就是让信任清晰可见的方式。

不可妥协的原则

从设计上采用非托管模式 · 仅描述交易（绝不签名、绝不托管） · 链上数据是“已付款”状态的唯一事实来源 · 任何人都能重新验证每张收据 · 只报真实数据，不虚构使用量或合作关系。