技术栈
桌面应用、SDK、CLI、钱包引擎以及 MCP/AI 工具链均为开源（MIT），可在 GitHub 上查阅；浏览器扩展和做市方的询价引擎目前尚未开源。
集成层
应用与协议之间有两个软件包。我们自家的客户端使用它们的方式，与外部集成方完全一致。kaleido-sdk
交换集成：报价、交易对、询价流式推送、交换执行、LSPS1 通道订单，以及对 RGB 闪电节点的直接访问。目前提供 TypeScript 与 Python 版本，Rust 核心正在开发中。
wallet-engine
无界面的多协议钱包内核：协议适配器、跨协议路由器、统一接收，以及精简/进阶两档信息披露。采用 TypeScript，可运行在浏览器、React Native 和 Node 环境中。
kaleido-sdk 暴露两个子客户端 —— 面向市场侧的 client.maker 和面向节点操作的 client.rln —— 并根据后端提供的同一份 OpenAPI 规范生成类型，因此 TypeScript 和 Python 版本永远不会脱节。
协议层
每个比特币分层协议都有自己的 SDK、地址格式和各种特殊之处：这个协议讲通道流动性，那个协议讲上船交易，另一个又用静态接收地址。如果不加治理，这些差异就会变成每个应用每个页面上的协议判断分支。 我们的做法是让每个协议实现同一套适配器契约：连接、列出资产与交易、创建与解析发票、发送、接收，以及可选的报价与交换执行。协议之间的差异以能力清单中的数据形式存在，而不是应用代码里的分支。路由器和界面读取该清单，永不按协议名称做特殊处理。 由此带来的实际好处：- 接入新协议只需改动一个适配器和一条清单记录 —— 绝不触碰其他协议的代码路径。
- 客户端只调用一套 API，从不直接调用协议 SDK，因此桌面端、扩展和移动端的行为保持一致。
- 由路由器选择通道。 给定一个目标 —— 闪电发票、比特币地址、RGB 发票或 Liquid 地址 —— 它会判断哪些协议可以支付，以及哪一个最合适。
- 一个接收二维码可同时承载多个协议，任何钱包都能扫码支付，而 KaleidoSwap 钱包还能读取其中更丰富的参数。
交换引擎
交换采用询价（Request for Quote）模型，由哈希锁定合约完成结算。做市方给出价格；闪电网络负责传输；共享的原像保证交换的原子性。
- 接单方通过 WebSocket 接收做市方推送的报价，每份报价都带一个
rfq_id。 POST /api/v1/swaps/init锁定汇率，并返回swapstring和payment_hash。- 接单方的 RGB 闪电节点将
swapstring加入白名单，授权其通过该节点路由。 POST /api/v1/swaps/execute启动 HTLC。- 闪电网络进行路由：做市方公开原像以领取其中一条腿，这同时释放了另一条腿。
- 若任意一方停滞，时间锁到期后双方各自取回自己的资金。
原子性取决于两个层级都具备原生哈希锁。关于目前哪些路径符合、哪些不符合，见 Where atomicity holds。
流动性层
闪电服务提供商
LSP 让用户无需手动操作通道也能使用闪电网络。在本架构中，它们负责：- 提供流动性 —— 开通带入向容量的通道，并可预先注入某种 RGB 资产
- 路由支付 —— 为普通支付和交换的各条腿寻找路径
- 充当对手方 —— 锁定交换的另一条腿
RGB-LSPS1
KaleidoSwap 实现了 RGB Lightning Service Provider Specification，将标准的 LSPS1 通道订购流程扩展到资产：- 标准化接口 —— 与 LSP 交互使用统一的 API 形态
- 资产分配 —— 订购通道时可指定 RGB 资产
- 交换支持 —— 原子交换协调能力内建于同一套接口
- 费用透明 —— 在你确认前就明确列出成本
做市商
询价引擎在设计上就允许做市方之间竞争。目前由 KaleidoSwap LSP 自行提供初始流动性。从 2027 年起，外部做市商将通过同一套接口接入，并在点差上展开竞争。智能层
AI 入口同样是这套技术栈的客户端。它们调用的工具与人机界面调用的完全相同，也受同样的确认环节约束。KaleidoMind
本地优先的推理与工具调用引擎。推理在设备端运行；任何会动用资金的工具都需要明确确认，模型无法绕过。
KaleidoAgent
用于投资组合与节点管理的自主代理。可基于本地模型或托管模型运行，且从不托管资金。
客户端架构
非托管设计
所有涉及密钥的环节都在你的设备上运行。客户端在本地持有或驱动钱包，自行验证状态，只通过上述网络接口与做市方和 LSP 通信。交换的任何阶段都不存在第三方能动用你的资金。- 你的密钥，你的币 —— 私钥永不离开你的设备
- 加密存储 —— 敏感数据以你的密码静态加密
- 不托管 —— 做市方和 LSP 只是对手方，绝不是托管方
- 客户端验证 —— RGB 状态由你自己验证，而不是信任某个服务器
各客户端支持的协议
组件分层
在客户端内部，不论平台如何，分层方式都是一致的：- UI 层 —— 各平台自己的界面
- 业务逻辑 —— 状态管理与流程编排
- 协议层 ——
wallet-engine适配器与跨协议路由器 - 网络层 —— 节点 RPC、做市方 API、LSP 集成、P2P 连接
安全模型
1
比特币基础层
在比特币区块链上完成最终结算并锚定安全性
2
分层协议
哈希锁定合约与时间锁，让失败的交换退款而不是执行一半
3
资产叠加层
在客户端验证 RGB 状态，阻止无效或双花的转移
4
应用层
本地密钥管理、加密存储，以及任何支出前的明确确认
这里的「无需信任」指什么
- 没有对手方风险 —— 在原子路径上，交换要么双方都完成，要么都不完成
- 没有托管方 —— 全程由你保管自己的密钥和资产
- 密码学保证 —— 由时间锁和原像强制执行
结算特性
不同的层做出不同的取舍，这也是这套技术栈同时使用多个层的原因。不存在一个层能同时做到最快、最便宜且最终性最强。
交易发生在闪电网络上，因为它能以极低成本在数秒内结算；比特币 L1 则是仓位最终沉淀的地方。哈希锁那一列决定了某条腿能否做到原子化，以及由谁提供保证 —— 见 Where atomicity holds。
RGB 资产接口
RGB 定义了若干资产接口，以前用 schema 编号来称呼。钱包支持全部四种；目前交易覆盖 NIA 资产。
各术语的定义见术语表。