创世区块：2026年3月19日

为 AI 原生代理而构建。

BTX 为开发者提供了两种特别适合 AI 原生软件的原语：用于准入控制的链绑定新鲜工作挑战，以及面向代理、服务和运营者的钱包支持的后量子身份，帮助他们减少对旧式签名的依赖。

集成指南 挑战 RPC
请求路径
  1. 已签名的代理请求
  2. 挑战信封已发出
  3. 本地完成新鲜工作求解
  4. 证明兑换并放行
身份 后量子钱包材料
准入 新鲜工作证明
验证 验证成本远低于求解成本
接口面 RPC + 网关流程
用例 挑战流程 模式 身份 启动包 FAQ
为什么重要

AI 原生产品需要比 CAPTCHA 更好的准入控制。

纯面向人类的挑战流程并不适合自动化系统、API 客户端和运营工具。BTX 服务挑战让你请求新鲜计算：大规模自动化成本高、验证成本低，并且绑定当前链状态。

AI 代理 CAPTCHA

为自动化调用者构建的网关模式。

目标不是用谜题打断人类，而是让每个昂贵路由都给出一个实时工作价格，使代理和 API 客户端能够以程序方式满足它，然后在执行前廉价验证。

仅用 API 密钥

有身份，但没有按路由定价的工作要求。

最擅长：
  • 对已知付费用户和稳定的服务器到服务器客户端来说足够简单。
薄弱点：
  • 面对被复制的凭证、被转售的访问，或昂贵路由上的匿名滥用时较为薄弱。
它真正提供的是：
  • 有身份，但没有按路由定价的工作要求。
挑战流程

一个实用的开发者循环，而不是模糊的未来故事。

已发布的 OpenClaw 网关文档就是一个例子：客户端在握手时声明角色和作用域、签署服务器提供的挑战 nonce，并接收按角色和作用域限制的设备令牌。BTX 适合作为该栈之上的路由级工作要求，用于昂贵或易受滥用的动作。 

# Pseudocode: gateway route protected by BTX work
POST /v1/generate
Authorization: Signature keyId="btx-wallet:agent-42",...
X-Device-Token: devtok_...
X-BTX-Challenge-Id: chal_...
X-BTX-Proof-Nonce: ...
X-BTX-Proof-Digest: ...

# Server sequence
1. validate role + scope + device token
2. verify request signature
3. redeem BTX proof for this route
4. only then run the expensive action
受保护路由契约 OpenClaw 网关协议 MCP 授权
挑战流程
  1. 1
    发起挑战

    使用 getmatmulservicechallenge 将新鲜工作绑定到用途、资源、主体和目标求解时间。

    打开相关文档
  2. 2
    让客户端本地求解

    请求方计算一个绑定当前链状态的 MatMul 证明，因此预计算窗口保持有限。

    打开相关文档
  3. 3
    兑换并验证

    只有当 redeemmatmulserviceproof 确认该证明有效、新鲜且尚未被消费时，才接受请求。

    打开相关文档
  4. 4
    叠加身份层

    当代理或服务需要持久的密码学身份时，在其上叠加 BTX 钱包身份和签名请求标准。

    打开相关文档
服务器检查什么
  • 用途、资源和主体与您要保护的路由一致
  • 求解时间处于服务器向客户端报价的窗口内
  • 证明只兑换一次，之后不能被重放
  • 可以在其上叠加签名身份，用于持久代理或运营者凭证
部署模式

BTX 在真实 AI 与网关栈中的位置。

网关式系统已经区分设备身份、路由策略和授权。BTX 在此基础上增加一层新鲜工作要求，用于那些昂贵、易受垃圾流量影响或值得保护的路由。

参考架构

从最接近你产品的路由形态开始。

这些不是抽象画像，而是可以直接搬进网关、公开 API 或代理工作流里的 BTX 挑战形态，然后再按你的威胁模型继续收紧。

AI 推理画像 单节点部署

公开 AI 推理 API

推荐绑定
  • purpose: ai_inference_gate
  • resource: model:gpt-x|route:/v1/generate|tier:free
  • subject: tenant:abc123 或 api_key:key-42
挑战策略
  • target_solve_time_s: 免费或匿名流量建议 2-4 秒
  • expires_in_s: 60-180 秒，尽快让旧信封失效
  • redeem path: 如果请求会排队或扇出到共享工作节点，使用 redeemmatmulserviceproofs
打开文档: AI 推理画像 打开文档: 发起挑战 RPC 打开文档: 批量兑换 RPC
生产就绪度

告诉构建团队哪些现在可以安全上线，哪些需要路由纪律，以及 BTX 的边界在哪里。

把 BTX 服务挑战当作真正的准入控制子系统来部署：先从单节点开始，在真正的决策点兑换，并明确这种证明能证明什么、不能证明什么。

现阶段可用：单节点受保护路由

文档里的生产路径是同一台 BTX 节点负责 issue 与 redeem，并共享同一个挑战注册表。对很多推理、注册和网关路由来说，这已经够用，不必先引入额外协调层。

扩展注意：多节点需要黏性或共享状态

一旦 issue 与 redeem 可能落到不同的 BTX 节点，挑战注册表就会变成运维依赖。要先加好 sticky routing 或共享 challenge 文件，才能把这条路由视为横向安全。

准入规则：生产用 redeem，诊断用 verify

verify 只回答证明是否匹配挑战。redeem 才是带回放保护的准入事件，会一次性消耗证明，并给网关一个权威的接受或拒绝结果。

受保护路由契约 兑换证明 RPC 多节点部署 失败语义
身份层

从一开始就以后量子为基础的钱包身份。

BTX 钱包是描述符式的，并从一开始就围绕 ML-DSA 和 SLH-DSA 设计。这降低了把核心身份材料当作未来迁移项目来处理的可能性。

创建钱包
身份层

从一开始就以后量子为基础的钱包身份。

  • 默认以后量子钱包设计为起点 BTX 钱包是描述符式的，并从一开始就围绕 ML-DSA 和 SLH-DSA 设计。这降低了把核心身份材料当作未来迁移项目来处理的可能性。
    查看来源
  • 挑战流程锚定实时难度 服务挑战和挖矿 RPC 暴露实时工作画像、目标求解窗口，以及用于滥用定价的新鲜链绑定挑战上下文。
    查看来源
  • 为代理协调服务而建 协议文档已经把 BTX 定位在桥接、服务和代理协调层之上的一个窄结算基础，而不是单一共享运行时。
    查看来源
设计方向

如何向 AI 团队解释 BTX。

  • 签名请求用来识别调用方。
  • BTX 工作挑战为滥用和速率压力定价。
  • 后量子钱包材料为调用方带来更强的长期身份假设。
  • 把它们组合起来，就能为代理工具、API 和网关工作流构建更耐久的准入栈。
开发启动包

先把路由跑通，再把它变硬。

这些组合按 API 团队常见的推进顺序排列文档：先原型化挑战路由，再绑定身份、接入控制平面、监控实时状态。

签发并兑换实时挑战

先做最小可用闭环：发出挑战、完成求解，并在要保护的路由上兑换它。

核心流程指南 getmatmulservicechallenge RPC
开发者 FAQ

团队在原型化 BTX 挑战流程时会问哪些问题？

这些回答尽量贴近当前 RPC 和钱包文档：BTX 补充现有认证，为昂贵路由增加新鲜工作定价，并为 AI 原生系统提供后量子身份路径。

BTX 会替代 API 密钥、OAuth 或网关策略吗？

不会。BTX 最适合补充你已有的认证栈。把身份、作用域和策略保留在原来的位置，只在真正受滥用、成本或资源争用影响的路由上要求 BTX 工作。

打开相关文档
挑战应该放在 AI 或代理工作流的什么位置？

通常是在完成正常请求识别之后、执行昂贵动作之前。服务器发出实时挑战信封，调用方完成求解，服务在消耗 GPU 时间、模型额度或其他稀缺资源前兑换证明。

打开相关文档
为什么要把钱包支持的后量子身份带进这个流程？

BTX 允许同一套系统同时讨论新鲜工作和更强的签名材料。对于已经在规划后量子迁移的团队来说，这让他们更容易把身份和准入一起评估，而不是分成两个未来项目。

打开相关文档
它能适配 OpenClaw 或 MCP 风格的网关栈吗？

从架构上看可以：保留现有的角色、作用域和设备信任模型，再把 BTX 作为路由级工作要求叠加上去。这是本页描述的适配方式，并不是说 BTX 今天已经原生集成 OpenClaw。

打开相关文档
下一步

如果你的产品存在滥用问题、免费层，或者拥有代理层，BTX 就应该进入设计评审。

从服务挑战指南开始，阅读钱包模型，并原型化一个同时要求身份和工作证明的代理安全路由。

构建该流程 查看 BTX