适用范围：Tondi（Taproot-only，Schnorr）面向AdaptorSig-based 的跨链原子互换；
目标读者：链/钱包工程师、审计方、前端集成方。
产物形态：PSKT(Partially Signed Kaspa Transactions) → PSTT（Tondi 版“部分签名交易”容器）、WASM SDK、前后端交互协议。
兼容性：不影响普通 PSKT/PSTT 交易；Adaptor Sig 字段完全可选。

---

0. 摘要与路径（TL;DR）

0.1 摘要

在去中心化金融的发展史上，每一次关键机制的诞生都代表着范式的跃迁。比特币的出现让价值第一次真正摆脱了中心化的控制；Taproot 的落地让签名学与脚本语言走向极简与私密；而 Adaptor Signature 的引入，则意味着跨链原子互换第一次可以在“无脚本化”的条件下获得秒级体验。

Tondi 选择以 Taproot-only + Schnorr 作为唯一执行语义，并在此基础上推动 PSKT → PSTT 的演进，不仅仅是一次容器层的升级，而是一次跨时代的接口标准化：

• 它将 MuSig2 与 Adaptor Sig 引入容器级别，第一次让跨链原子互换的安全路径与退款路径在结构上高度统一；

• 它保证 向后兼容，任何普通交易无需改动即可运行，而高级功能可通过新增字段无缝叠加；

• 它借助 WASM SDK 的前后端分层，把复杂的签名学逻辑前置到浏览器与钱包，而把费控、广播、mempool 交互留在宿主环境，真正实现安全边界的清晰化。

在历史叙事的长河中，PSTT 的意义不仅是“跨链更快”，更在于它开创了一条 以容器为核心、以签名学为共识内核、以 WASM SDK 为开发接口 的新路径。这条路径将使得跨链从繁琐、漫长、充满信任假设的交互，转变为 可审计、可复用、秒级执行 的新一代金融基建。

Avato Labs 在此承担了先锋角色。我们并不满足于在 BTC 或单链生态中优化性能，而是以 Tondi 为实验场，将 DAG 架构、Taproot 极简性、Adaptor Sig 的原子性 融合成一套可推广的跨链协议栈。这既是对区块链签名学数十年积累的致敬，也是对未来多链协作格局的积极塑造。

0.2 路径

• Tondi 将会把从Kaspa继承的 PSKT 演进为 PSTT（Partially Signed Tondi Transaction），在不破坏兼容性的前提下，新增对 MuSig2 + Adaptor Signature 的可选扩展字段与流程支持。

• BTC 侧继续使用 PSBT v2 + BIP 371 (Taproot Fields for PSBT)；跨链原子互换的“桥接层”只交换少量与容器无关的 Adaptor 包（T, R, s* 等）。

• 成功路径走 Taproot key-path（MuSig2 聚合签名）；退款路径走 tapscript（CSV 或 CLTV 等价）。

• 在设计 WASM SDK 时，Avato Labs 选择将签名学和见证组装的计算逻辑暴露给钱包前端，旨在通过分离计算和网络交互的职责，提高系统的安全性和灵活性。前端直接调用这些纯计算接口，可以将复杂的签名算法、MuSig2 聚合、Adaptor Signature 等处理逻辑推向用户设备，**使得敏感操作（如密钥管理、签名生成）无需依赖后端服务器，减少了潜在的安全风险。**同时，**节点/RPC/存储/费控等交互操作留在宿主环境中，可以保证数据的一致性和网络通信的优化。**这种分层设计使得系统能够在提高安全性的同时，保持高效性和可扩展性，从而在保护用户隐私的同时，也确保了跨链交易的高效执行。

---

1. 术语与符号

• Schnorr（BIP340）：签名 (R, s)，e = H_tag(R_x || P_x || m32)，s = k + e·x (mod n)

• MuSig2：2-of-2 聚合公钥 P = μ(PA, PB) 与双阶段 nonce（commit→reveal）

• Adaptor Signature（“scriptless scripts”）：

  • 给定 Adaptor 点 T = t·G，将完整签名 加密为 s* = s + t；

  • 校验：s*·G = R + e·P + T；

  • 补全：s = s* − t；提取：t = s* − s。

• msg32 / sighash32：待签名消息的 32 字节摘要。

• BlueScore/CSV：Tondi 的相对时间锁等价量。

• PSTT：Tondi 的“部分签名交易”容器（本规范）。

• BTC PSBT：Bitcoin 的 BIP-370/371 容器，本文不复述。

---

2. 签名原理（Schnorr / MuSig2 / Adaptor Sig）

本节全面阐述 Tondi 采用的签名原理，包括 Schnorr 签名、MuSig2 聚合签名以及 Adaptor Signature（脚本外条件签名） 的工作机制及其在跨链原子互换中的角色。

2.1 Schnorr 与 Taproot key-path

基本定义
Schnorr 签名算法基于 secp256k1 椭圆曲线，签名由 (R, s) 组成：

• 公钥P：P = x·G（x 为私钥，G 为基点）；

• **签名者的私钥x：**签名过程中的计算依赖于 x 来生成签名。x 是签名者唯一的密钥，与公钥 P = x·G 相关联。

• **挑战值e：**在签名过程中，e 是基于消息和前面生成的中间结果（如 R 和 P）计算出来的一个值。其计算方法是通过哈希函数 H_tag(R_x || P_x || m32)，其中 R_x 是 R 点的 x 坐标，P_x 是 P 点的 x 坐标，m32 是待签名的消息的 32 字节哈希。这个哈希值 e 用于加密签名，使得签名是对消息的“验证”。

• 签名中的随机数k： k ∈ [1,n−1]，对应 R = k·G；。它是在签名生成过程中通过随机选择的一个私有值，作用是生成 R = k·G。为了避免安全问题，k 必须是独立随机的，且在同一密钥对下不能重复。

• 通过随机生成的 nonce k 得到的点R：R = k·G，其中 k 是一个随机数，G 是椭圆曲线的基点（public base point）。R 是在签名过程中用来生成签名的一个中间值。

• 签名s：s = k + e·x (mod n)。

验证公式：

s·G ?= R + e·P

其中 R_x、P_x 是点的 x 坐标（x-only 公钥语义），m32 是消息摘要。

在 Tondi 的应用

• Taproot-only：Tondi 强制采用 Taproot 花费，不允许 P2PKH/P2SH 等旧路径。

• 链上表现：链上仅能看到 (R, s) 这 64 字节签名，完全不可见内部脚本（隐私增强）。

• 消息域分离：Tondi 的 msg32 计算严格遵循 BIP-341 Taproot SigHash：

  • msg32 = TapSighash(tx, inputIndex, sighashType)

  • 使用 SHA-256（保持 BTC 生态兼容）。

  • 即便未来 Tondi 其他非签名域可能迁移至 BLAKE3，签名路径仍保持 SHA-256，以避免跨库差异。

安全约束

• 所有签名必须使用唯一的随机 nonce，这是为了防止重放攻击或签名泄漏的风险。在加密算法中，nonce（一次性随机数）起着至关重要的作用，它保证每个签名的唯一性，避免了由于相同的 nonce 被多次使用而导致的安全漏洞。例如，Schnorr 签名中的 nonce 若重复使用，可能使攻击者通过特定的数学推导方法恢复出私钥，因此确保每个签名使用独立的 nonce 是至关重要的。

• 为了保障 nonce 的生成安全，nonce 必须通过一个安全的随机数生成器 (RNG) 来产生。在 WASM SDK 中，安全的随机数生成由宿主环境提供，结合内部的熵混合机制，确保 nonce 的生成过程不可预测且具备足够的熵（随机性）。通过这种方式，可以确保生成的每个 nonce 都具有高度的不可预测性，从而有效地防止了潜在的攻击者通过猜测或推测来重用 nonce，保障了签名过程的安全性。

• 此外，SDK 必须提供零化机制，确保使用过的私钥和 nonce 在计算完成后立即被清除出内存。该机制防止了敏感信息在内存中滞留，减少了被攻击者从内存中提取的风险。通过这种内存清理措施，Avato Labs 确保了即使在恶意程序或硬件攻击的情况下，密钥和 nonce 不会被恢复或滥用，进一步增强了系统的安全性。

---

2.2 MuSig2（2-of-2 聚合签名）

目标
MuSig2 允许多个参与方在不暴露单独签名的情况下，生成一份 聚合 Schnorr 签名 (R, s)，在链上与普通单签 indistinguishable（不可区分）。
这在跨链原子互换中至关重要：我们希望 A 与 B 的交互在链上仅体现为一枚 64B 签名，不泄露“多方协作”的痕迹。

关键步骤

1. 公钥聚合

   • 双方公钥：P_A, P_B

   • 聚合公钥：P = μ(P_A, P_B)

   • **注意：**聚合函数 μ 包含 权重因子，避免恶意方构造 P_B = −P_A 导致公钥抵消（key cancellation）。在MuSig2的聚合签名中，两个参与方会共同生成一个聚合公钥 P = μ(P_A, P_B)，其中 P_A 和 P_B 是两个独立的公钥。通过使用聚合函数 μ，将两个公钥合并为一个，从而避免了需要每个参与方单独签署的麻烦。

     然而，聚合公钥的生成过程涉及一个潜在的安全风险——公钥抵消（key cancellation）。这是指，如果一个恶意参与方 B 能够选择一个公钥 P_B，使得 P_B 等于 -P_A，即 P_A 和 P_B 在数学上相互抵消，那么最终的聚合公钥 P 就会变成零。这样就可能使得合约或交易的签名变得无效，从而使恶意方能够规避协议要求的签名或达成其目的。在MuSig2签名方案中，聚合函数 μ（mu）是由签名协议的设计者和实现者定义和控制的。这个函数并不是由单个参与方或控制者直接操作，而是由协议的规则和算法所规定的。

2. nonce 承诺与揭示

   • 每方生成随机 nonce：k_A, k_B

   • 承诺阶段：双方先交换 commit_A = H(k_A·G)，防止对手“后见 nonce”攻击；

   • 揭示阶段：互换 R_A = k_A·G, R_B = k_B·G；

   • 聚合得到：R = R_A + R_B。

   • 问题1：为什么先交换 commit_A？

     • 确保不可篡改性：commit_A = H(k_A·G) 提供了一个对 k_A 的“保证”，即攻击者无法在之后改变 k_A 的值来制造伪造签名。如果commit_A交换在 R_A 和 R_B 交换之前，那么即使 R_A（由 k_A 生成）被交换出来，恶意方仍然无法利用“后见”来反推对方的 k_B 并伪造签名。

     • 承诺生成随机数的不可见性：通过在 k_A 和 k_B 之前交换 commit_A，双方确保 k_A 被固定且无法更改，确保了 k_A 的随机性和独立性。这个承诺函数使用了哈希算法，防止了可能的“二次选取”攻击。

   • 问题2：对方的 commit_B 为什么不用先交换？

     • 理论上，commit_B 和 commit_A 的交换次序可以交换，但这样做的意义在于保护双方的随机数独立性。通常情况下，先交换commit_A 是因为：

       • 在交换 commit_A 后，A 的随机数 k_A 就已固定，B 无法利用 k_A 的值来进行攻击。

       • 然后，B 才会对 k_B 进行承诺并交换 commit_B。一旦 B 完成 commit_B，A 就能保证B不会调整 k_B，确保双方的随机数都已“锁定”。

通过这个顺序，两方的随机数可以独立且安全地生成，并且承诺过程避免了在签名生成之前对nonce的操控，从而增加了协议的安全性。

3. 挑战计算

   • e = H_tag(R_x || P_x || m32)

4. 部分签名

   • A 计算 s_A = k_A + e·x_A (mod n)

   • B 计算 s_B = k_B + e·x_B (mod n)

5. 聚合

   • s = s_A + s_B (mod n)

   • 完整签名为 (R, s)。

SDK 内部保障

• 禁止 nonce 复用：SDK 会标记 session 内所有使用过的 (k_A, k_B)；

• 提供 nonceCommit() 与 nonceReveal() API，强制完整走 commit → reveal 流程；

• 聚合函数 μ 实现 anti-kc（权重修正），防御抵消攻击。

---

2.3 Adaptor Signature（scriptless scripts）

Adaptor Signature 的设计目标是：在链上依旧表现为一枚普通 Schnorr 签名，但在链下内含一个“条件秘密”t。
这使得 跨链原子互换无需脚本化对称条件，而通过签名本身完成原子性。

定义

• 给定 adaptor 点：T = t·G（t 为秘密标量）。

• 完整签名 (R, s) 被加密为：

s* = s + t  (mod n)

• 广播时，链上只需看到完整签名 (R, s)；

• 对手在获得 (R, s*) 与 (R, s) 的同时，可立即提取：

t = s* − s (mod n)

验证公式

s*·G ?= R + e·P + T

成立时，说明 (R, s*) 确实是一个被 “加密” 的 Schnorr 签名。

在原子互换中的作用

• 成功路径

  • A 与 B 通过 MuSig2 协作，生成 adaptor 签名 (R, s*)；

  • 一旦 A 在 Tondi 链上公布完整签名 (R, s)，B 就能立刻提取 t，从而解锁 BTC 侧的交易；

  • 这实现了 跨链条件同步。

• 退款路径

  • 如果一方不合作，双方可等待锁定超时：

    • Tondi 使用 CSV/BlueScore 退款叶脚本；

    • BTC 使用 CLTV 退款叶脚本；

  • 确保资金安全返回。

安全约束

• t 必须由一方产生并承诺，同时可选提供 PoK(T)（证明知道 t 的零知识证明），防止恶意生成陷阱点；

• 域分离：不同链、不同 session 的 adaptor 包含 domain_tag，避免 replay；

• SDK 暴露接口：

  • makeTapKeyAdaptor：生成 (R, s*)；

  • verifyTapKeyAdaptor：校验等式；

  • completeSignature：补全签名 s = s* − t；

  • extractAdaptorSecret：提取秘密 t = s* − s。

---

2.4 小结

• Schnorr：基础签名算法，64B，不可区分。

• MuSig2：将多方聚合为单签名，链上无从觉察或区分，保障隐私。

• Adaptor Signature：通过签名差值携带条件秘密，赋予签名**“脚本外的原子性”**。

在 Tondi/BTC 跨链原子互换的落地中：

• 成功路径：MuSig2 + Adaptor Sig → key-path 签名；

• 失败路径：tapscript → CSV/BlueScore or CLTV。

这三者结合，构成了 PSTT 容器最核心的签名学逻辑，也是本方案将跨链从被BTC的HTLC时间锁拖慢到分钟级的一侧，提升到秒级的技术基石。

---

3. 基于Adaptor Sig 的原子互换流程

角色：A（要 TNDI、出 BTC），B（要 BTC、出 TNDI）。
关键不变量：同一个 T = t·G 同时出现在两链的 adaptor 验证中。

3.1 准备（两链锁仓）

• BTC：P2TR(internal=P_btc)，tapleaf：<T1> CLTV, DROP, <PA_btc> CHECKSIG（退款给 A）。

• TONDI：P2TR(internal=P_ton)，tapleaf：<ΔBlue> CSV, DROP, <PB_ton> CHECKSIG（退款给 B）。

3.2 会话（MuSig2 两套 + Adaptor 包）

1. 交换公钥，聚合 P_btc、P_ton；

2. A 生成 t 与 T=t·G（可附 PoK(T)，防陷阱点）；

3. 两链分别进行 nonce 承诺→揭示，得到 R_btc, R_ton；

4. Adaptor 包交换：

   • A→B：(T, R_btc, s*_btc = s_btc + t, msg32_commit_btc)

   • B→A：(T, R_ton, s*_ton = s_ton + t, msg32_commit_ton)

msg32_commit_* = 对 PSTT/PSBT 做规范化序列化后的哈希，用于绑定，防“换单”。

3.3 执行与兜底

• A 先花 TONDI（key-path）：s_ton = s*_ton − t → 广播；

• B 提取 t 并花 BTC：t = s*_ton − s_ton，s_btc = s*_btc − t → 广播；

• 超时：Tondi 未花 → B 走 CSV 退款；BTC 未花 → A 走 CLTV 退款。

• 超时窗口：保证 T1（BTC） > ΔBlue（TONDI） + 网络/传播裕度。

---

4. PSTT：Tondi 部分签名交易容器（PSKT → PSTT 扩展）

PSTT 继承 PSKT 的“键值表”容器思想（与 PSBT 类似）：Global / Inputs[i] / Outputs[j] 三个命名空间。
兼容性原则：新增 key 不影响现有 PSKT 解析器；未知 key 直接忽略。

4.1 编码与版本

• 版本：PSTT_GLOBAL_VERSION = 2（与 PSBTv2 对齐的“字段分解式”结构）；

• 编码：建议保持 key(varint + type) → value(varbytes) 的 KV 映射，文件头 pstt\xff；

• 网络/域：PSTT_GLOBAL_NETWORK_ID（mainnet/testnet），PSTT_GLOBAL_PROTO_VER。

• 规范化序列化：定义 canonical_serialize(pstt)（见 4.5），用于 msg32_commit_ton。

4.2 Global 区（必要/可选）

PSTT_GLOBAL_SWAP_CONTEXT（建议字段）

{
  "session_id": "uuid",
  "role": "A|B",
  "domain_tag": "TONDI_SWAP_V1/TONDI",
  "adaptor_point_T": "33-byte secp point (compressed)",
  "T_pok": "optional proof-of-knowledge"
}

4.3 Inputs[i] 区

PSTT_IN_TAP_KEY_ADAPTOR 格式（新增，核心）

struct TapKeyAdaptor {
  uint8  version;     // 1
  bytes32 R_xonly;    // 32B
  bytes32 s_star;     // 32B scalar (big-endian)
  bytes33 T_point;    // 33B compressed secp point
  uint8  flags;       // bit0: musig2, bit1: scriptless_only, reserved
}

校验等式：s*·G ?= R + e·P + T（P=MuSig2 聚合公钥，e=TapSighash(msg32)）。
完整签名写回 PSTT_IN_TAP_KEY_SIG；Adaptor 字段可留存或删除，不影响上链。

4.4 Outputs[j] 区

4.5 规范化序列化 canonical_serialize(pstt)

• 目的：生成唯一字节序列以供 msg32_commit_ton = H(canonical_bytes)；

• 在 PSTT 规范中，规范化序列化是确保容器数据在跨不同平台和系统中一致性的重要步骤。该过程定义了如何将 PSTT 容器的各个字段转换为一个字节序列，以便计算哈希（如用于 msg32_commit_ton），保证数据的唯一性和不可篡改性：

  1. 忽略签名类字段：所有与签名相关的字段（如 _SIG、_PARTIAL、_ADAPTOR 等）在序列化时将被忽略。这是因为这些字段在规范化过程中并不直接影响交易内容的结构，它们通常会根据签名完成后动态生成。因此，在序列化时不需要考虑它们，以确保生成的哈希不受到签名变化的影响。这样做使得容器的基础数据结构保持一致性，并避免因签名的不同而产生不同的序列化结果。

  2. Global/Input/Output字段按key编号升序串联：为保证序列化后的字节序列唯一且一致，所有的字段（包括全局设置、输入和输出字段）会根据其键值（key）进行升序排序。这样做确保了即使字段的添加顺序不同，最终的序列化结果也始终保持一致。这一排序方式避免了由于字段顺序不同而导致的哈希冲突，确保了跨链和多方协作中的数据一致性。

  3. 所有可选字段缺省视为“未设置”：在序列化过程中，如果某个字段是可选的且未被设置，它会被视为“未设置”。这种处理方式确保了可选字段不会影响规范化结果，避免了未设置字段的影响。例如，如果 PSTT_GLOBAL_SWAP_CONTEXT 或 PSTT_IN_TAP_KEY_ADAPTOR 没有被配置，它们将在序列化时被跳过或标记为未设置，从而不会改变最终的字节序列。

  4. 使用 LEB128/varint 标注字段长度：LEB128（Little Endian Base 128）和 varint 是常用的编码方式，用于存储变长的字段数据。这些编码格式能够有效节省空间，尤其是在字段长度可变时，能够保证数据的紧凑性并避免浪费。在 PSTT 的规范化序列化过程中，这些编码方式被用来标识字段的长度信息，以便在反序列化时能够正确地恢复每个字段的边界和内容。

  5. 外层加域分离前缀："PSTT_CANON\x00"：为了防止跨域重放攻击并确保数据唯一性，规范化后的字节序列需要加上一个域分离前缀。在序列化数据的开头添加 "PSTT_CANON\x00" 前缀，标明这是 PSTT 规范化数据的唯一标识。这一前缀不仅有助于防止数据被用于其他域的重放攻击，还确保了在不同的应用场景中能够准确区分不同类型的数据结构。

综上所述，规范化序列化确保了 PSTT 容器的可重复性、跨平台兼容性和安全性，同时也为后续的数据验证（如哈希校验）提供了可靠的基础。通过严格的排序、忽略无关字段、精确的长度标注和域分离前缀的使用，PSTT 的数据结构能够在跨链、跨系统的环境中稳定运行，避免了潜在的安全隐患。

---

5. WASM SDK（给 Tondi Wallet 前端）

目标：纯计算（签名、验证、msg32、见证组装、PSTT 编解码），不做网络/RPC/存储。

5.1 导出接口（TS 伪签名）

// 初始化
init(params?: { rng?: "host"|"wasm"; network: "mainnet"|"testnet" }): Promise<void>;

// Key & 聚合
deriveXOnly(skHex: string): Promise<string>;
musig2Aggregate(pubA: string, pubB: string): Promise<string>;                  // xonly P

// MuSig2 会话（两链各一套）
nonceCommit(sessionId: string, side: "tondi"|"btc"): Promise<{commit: string}>;
nonceReveal(sessionId: string, side: "tondi"|"btc"): Promise<{R: string}>;

// msg32
computeMsg32FromPSTT(psttBytes: Uint8Array, inputIndex: number): Promise<string>;

// Adaptor：生成／验证／补全／提取
makeTapKeyAdaptor(sessionId: string, msg32: string, T: string)
  : Promise<{ R: string, sStar: string }>;
verifyTapKeyAdaptor(Px: string, msg32: string, R: string, sStar: string, T: string)
  : Promise<boolean>;
completeSignature(sStar: string, tScalar: string): Promise<string>;            // s = s* - t
extractAdaptorSecret(sStar: string, sFull: string): Promise<string>;           // t = s* - s

// 见证组装（key-path / script-path）
assembleKeyPathWitness(sig64: string, sighashFlag?: number): Promise<Uint8Array>;
assembleScriptPathWitness(refundLeafScript: Uint8Array, controlBlock: Uint8Array, sig64: string)
  : Promise<Uint8Array>;

// PSTT 编解码
psttEncode(obj: PsttJson): Promise<Uint8Array>;
psttDecode(bytes: Uint8Array): Promise<PsttJson>;
canonicalHash(bytes: Uint8Array): Promise<string>; // msg32_commit_ton

5.2 安全与实现要点

在 Avato Labs 的 WASM SDK 设计中，安全性和可靠性是核心考虑因素。以下是对各个安全机制和设计策略的详细解释：

1. RNG（随机数生成器）：默认使用宿主环境中的 crypto.getRandomValues（浏览器环境）或 node:crypto（Node.js 环境），这两个API提供高质量的安全随机数生成。这些接口依赖于操作系统提供的随机源，能够确保生成的随机数具备足够的熵（随机性）。在 WASM SDK 中，随机数生成后经过二次混合处理，以进一步提高随机性的质量，避免潜在的熵源不足或可预测性问题，从而确保生成的 nonce、私钥等加密材料足够安全，无法被预测或操控。

2. Zeroize（零化机制）：在密码学协议中，私钥、随机数（nonce）、签名中的中间结果（如 t、s*）等敏感信息需要在使用后立即从内存中清除。这是为了防止攻击者通过内存泄漏或侧信道攻击提取出这些信息。在 WASM SDK 中，zeroize 机制会在计算完成后立即清除这些敏感数据，确保它们不在内存中持续滞留，从而降低了数据被窃取的风险。

3. 域分离：为了防止跨域重放攻击，所有的操作都会有一个明确的域标识。在此设计中，"TONDI_SWAP_V1/TONDI" 和 "TONDI_SWAP_V1/BTC" 等不同的域标签确保了数据在不同的交易和链之间不能被滥用或重放。域分离前缀确保了即使有相同的交易数据，也只能在指定的域内有效，防止恶意参与者将数据重放到其他链或协议中。

4. Nonce复用保护：为了确保每个 nonce 的唯一性和不可预测性，SDK 会为每个会话持续追踪 nonce 的使用状态，并在每次使用后标记为“已用”。这种机制防止了 nonce 被重用，进一步增强了签名的安全性。如果尝试重用已标记的 nonce，系统将返回错误并拒绝该操作。

5. PoK(T)（证明知识）：在一些安全敏感的应用场景中，为防止攻击者恶意构造特定的 Adaptor Signature 点 T，SDK 提供了 Proof of Knowledge (PoK) 的选项。通过 PoK(T)，一方可以证明自己知道秘密值 t，而不暴露该值本身。这增加了协议的安全性，确保即使攻击者尝试构造伪造的 T，也无法通过简单的数学推导来绕过协议的安全要求。

6. 错误码：为了提高错误处理的透明性和准确性，SDK 采用了标准化的错误码体系，包括：

   • ERR_BAD_NONCE：表示生成或使用的 nonce 不合法或重复。

   • ERR_MALLEABILITY：指示数据存在篡改的可能性，即交易数据的结构可能被不当修改。

   • ERR_DOMAIN：表明存在跨域重放攻击，数据在不合适的域下被使用。

   • ERR_PSTT_FIELD：表明 PSTT 容器中的字段格式错误或缺失。

这些机制可以共同确保 SDK 的高安全性，减少了潜在的攻击面，同时提升了系统的容错性和可调试性。通过这些安全设计，Avato Labs 的系统能够提供稳定且可靠的加密操作，确保用户数据的隐私和安全性。

---

6. 前后端/节点交互分层

• WASM（前端）：签名学 + 见证拼装 + PSTT 编解码；

• 宿主（后端/钱包 App）：

  • 与 tondid 节点交互：广播、查询、BlueScore/高度、mempool；

  • 与 bitcoind 交互：PSBT v2、ZMQ、RBF/CPFP；

  • 风控:

    • 0-conf 评分：0确认交易评分是用来评估一个交易在尚未得到网络确认前的可靠性和风险性。对于加密交易，尤其是跨链交易，0确认交易可能存在一定的回滚或双花攻击的风险。因此，风控系统会对这些交易进行评分，基于历史交易数据、发送方信誉等因素，判断该交易的风险，并给出相应的风控措施。例如，若某个交易的发送者具有较高的历史信誉，或者其交易行为符合预期，则可以降低其风险评分，允许更快地处理该交易。

    • 费率分位：费率分位用于评估交易的优先级。交易费的高低直接影响交易的确认速度，尤其在网络拥堵时。通过分析费率的分布，风控系统能够根据交易的费用分位来决定其优先级。高费率交易通常会被优先处理，而低费率交易可能需要等待更长时间才能获得确认。系统会依据当前市场的费用分布，自动调整交易的费用建议，帮助用户在交易过程中做出更合适的决策。

    • 祖先深度：在交易中，祖先深度指的是一个交易在区块链中所依赖的先前交易的确认深度。风控系统会评估交易的祖先深度，以确保它不会依赖于尚未得到足够确认的交易。例如，在比特币网络中，较浅的祖先深度意味着交易依赖于较少的区块确认，可能面临更大的双花风险。系统会根据祖先深度调整风险评分，确保只有那些具有较强确认链的交易被认为是安全的。

    • 外部多源一致性：外部多源一致性是风控的一项重要策略，它通过集成多个外部数据源来验证交易的真实性和合规性。例如，通过接入外部的区块链分析工具、链上数据服务或者信用评级平台，系统可以评估交易方的历史行为、资产来源等信息，从而提升交易的透明度和可信度。该策略有助于防止洗钱、欺诈等风险。

  • 会话存储：

    在跨链交易和复杂协议执行过程中，会话存储发挥着至关重要的作用，它确保了交易的完整性、可追溯性和实时性。Avato Labs 的会话存储设计专注于以下几个关键要素：

    • session_id：每个会话都有唯一的标识符 session_id，用于区分不同的交易或协议执行。会话标识符是系统内部的一项重要安全机制，它可以确保同一用户或同一交易的操作在多个步骤之间的一致性。通过会话 ID，系统能够跨多个交易步骤跟踪进度，确保每个操作都被正确执行，并避免出现混乱或错误。

    • T/R/s（签名和状态）*：这些是与交易签名和状态相关的核心数据。在会话存储中，*T 是代表 Adaptor Signature 中的秘密标量 t*，*R 是参与方签名计算中的随机数 R*，而 **s* 是加密签名中的加密部分。在交易过程中，这些信息是至关重要的，它们必须保存在会话中，以便在执行过程中进行有效的验证和回滚。

    • msg32_commit_*：在跨链原子交换过程中，msg32_commit_* 存储的是与交易相关的规范化消息哈希。该哈希用于防止交易的重复提交或篡改。一旦交易的结构被规范化，msg32_commit_* 就成为了唯一且不可篡改的标识符。在会话中存储这些信息，可以帮助系统确保交易的完整性和一致性，并防止攻击者通过修改交易内容来破坏交易的原子性。

    • 超时参数：超时参数是在会话存储中定义的一项关键元素，用于确保交易或操作在特定时间内完成。对于跨链原子交换等场景，超时是防止一方违约或交易卡住的机制。如果一方在规定时间内未完成其操作，系统可以根据超时参数自动发起退款或重新执行交易。这一机制能够保证交易双方都能在规定时间内履行合约，确保交易的顺利进行。

---

7. 与普通 PSTT 交易的兼容性

• Avato Labs 在 PSTT 设计中确保了与传统比特币交易的兼容性，使得新版本的交易容器能够平滑地集成到现有的比特币生态中。具体来说，PSTT（Partially Signed Tondi Transaction）通过引入如 PSTT_IN_TAP_KEY_ADAPTOR 等新键来扩展功能，但这些新字段是可选的，并且只在涉及跨链原子交换或更复杂操作时才会使用。这意味着，普通的比特币交易如果不需要这些高级功能字段，完全可以省略，依然符合传统比特币交易的格式和要求。

• 在最终的链上广播和确认过程中，PSTT 交易的结构与普通的 Taproot 交易一致。无论是否使用新的可选字段（如 PSTT_IN_TAP_KEY_ADAPTOR），成功路径的交易将只包含 64 字节的标准签名（Schnorr 签名）。这确保了即使是最基础的 Taproot 交易也能与新的协议兼容，且没有因扩展字段的加入而导致交易大小或结构发生重大变化，维护了系统的高效性和简洁性。

---

8. 安全性与审计要点

在本方案的设计中，多个安全机制和协议规范被用来确保交易的安全性、可靠性和效率。以下是这些机制的详细解析：

8.1. Adaptor 指标

• 等式验证：在使用 Adaptor Signature 时，确保签名满足验证公式：s*·G = R + e·P + T。这是验证签名是否有效的关键，确保 Adaptor Signature 的安全性，并确保生成的签名不会被篡改。任何未能通过该验证的签名都应被视为无效。

• 域分离：为了防止跨链攻击和重放攻击，域分离确保每次交易都绑定到特定的网络和上下文中。通过引入 network_id、session_id 和 domain_tag，系统确保每个签名和数据只能在特定的域内有效。例如，TONDI 和 BTC 侧的交易是分开处理的，彼此不会发生干扰。

• T 一致性：为了防止恶意行为者构造无效的 Adaptor Signature 点 T，必须保证 T 的一致性，特别是确保在跨链交换中双方使用相同的 T。如果任何一方提供了不一致的 T，则该交易无效。

• PoK(T)（可选）：为了增强安全性，系统支持 Proof of Knowledge（PoK）机制，确保交易参与者能够证明他们知道秘密标量 t，而不直接暴露该值。这减少了恶意方构造恶意 T 的风险，防止潜在的陷阱攻击。

8.2 MuSig2 签名

• commit → reveal：在 MuSig2 协议中，参与者通过“承诺-揭示”机制生成签名。这意味着参与者首先“承诺”他们的随机数（nonce），然后在之后的步骤中揭示它们。这样做的目的是防止攻击者提前知道另一方的随机数，从而能够推导出签名信息。通过这一流程，可以确保每个签名的安全性和独立性。

• anti-kc（权重因子）：MuSig2 聚合签名过程中，anti-kc（anti-key-cancellation）机制通过引入权重因子来防止恶意方构造抵消公钥的情况。例如，如果某一方试图通过选择 P_B = -P_A 来抵消另一个公钥，这个权重因子将确保两方公钥的聚合结果是有效的，不会因为恶意操作而导致聚合公钥为零。

• 禁止 nonce 复用：为了避免同一个 nonce 被多个签名使用，MuSig2 禁止在同一签名会话中复用 nonce。在每个会话中，系统会确保生成的新 nonce 是独立且唯一的，防止通过重用 nonce 来破解签名或恢复私钥。

8.3 超时学

• T1（BTC） > ΔBlue（TONDI） + 传播裕度 + RBF/CPFP 时间：超时机制确保跨链原子交换过程在规定的时间内完成。如果某一方未在指定时间内完成交易，超时机制将触发退款或失败路径。具体来说，BTC 侧的交易（T1）必须确保在 Tondi 侧（ΔBlue）超时参数和网络传播裕度之后执行。此外，BTC 侧的 RBF（Replace-by-Fee）或 CPFP（Child-Pays-For-Parent）机制可以进一步调整交易费用，确保交易在网络拥堵时仍能被及时确认。

8.4 绑定防换单

• msg32_commit_ = H(canonical(container))*：为了防止交易在交易过程中被篡改，系统使用 规范化容器 的哈希值作为 msg32_commit_*。这一哈希值确保了交易内容的不可篡改性，在交易交换之前，所有参与方都对交易的结构达成一致。如果任何一方试图修改交易内容，哈希值将不匹配，从而导致交易失败。

• Adaptor 包必须携带双方 commit 并交叉确认：每个 Adaptor Signature 包必须携带双方的承诺（commit_A 和 commit_B），并且双方必须交叉确认这些承诺。通过这种方式，交易双方能够确保交易在签名之前没有被篡改，且签名过程的顺序是安全的，防止任何一方在签署之前得知对方的随机数或签名。

8.5 重放/跨域

• 将 network_id、session_id、domain_tag 混入 transcript：为了防止跨域重放攻击，系统会将 network_id、session_id 和 domain_tag 混入 transcript 中。这些信息确保了即使某些交易数据被窃取，恶意方也无法将其重放到不同的网络或不同的交易会话中。通过这种机制，可以确保数据只在其指定的网络或域中有效，提升了系统的安全性。

8.6 费率钉死

• BTC 侧支持 RBF/CPFP：为了应对比特币网络中可能出现的交易拥堵，BTC 侧的交易支持 RBF 和 CPFP 机制。RBF 允许交易者通过增加费用来替换未确认的交易，从而提高确认优先级；CPFP 允许子交易支付父交易的费用，确保父交易被确认。

• Tondi 侧支持打包优先：在 Tondi 侧，交易被优先打包，以确保交易在网络中能够尽快被确认。当交易接近超时时，系统将自动提高交易费用，确保交易能够顺利执行并及时确认。

8.7 崩溃恢复

• 会话状态落盘：为了确保交易在任何情况下都能恢复，系统会在交易过程中的关键步骤进行状态保存。会话的状态（如 T/R/s* 等数据）会定期保存在持久存储中，以防止意外崩溃或系统重启导致数据丢失。

• 重启可恢复到“已交换 s”阶段*：如果系统发生崩溃或重启，系统能够恢复到上次保存的状态，确保交易流程不会被打断。例如，如果交易在签名过程中发生中断，系统可以恢复到“已交换 s*”的阶段，从而继续执行交易而不需要从头开始。

---

9. 参考流程（端到端）

在跨链原子交换中，交易的顺利完成依赖于多步骤的协作和精密的协议设计。本方案通过一系列精细化步骤和机制来确保交易的顺利执行，即使在某一方违约的情况下，依然能够保障交易的安全和公平。以下是这些步骤的详细扩展：

9.1 锁仓：双方各自将锁仓交易上链（P2TR + 退款叶），PSTT/PSBT 各自维护

在开始跨链原子交换前，双方首先需要将锁仓交易上传到各自的链上。这些交易使用 P2TR（Pay-to-Taproot）结构，保证交易路径的隐私性和灵活性。P2TR 使得交易可以隐匿在 Taproot 的结构下，从而避免公开暴露交易的内容。

每一方都需要通过创建一个退款叶，指定一个 CSV（CheckSequenceVerify）脚本来确保如果交易未按预期完成，资金会被退还到原始交易方。通过这些退款叶机制，即便交易失败，也能保证资金安全返回。

在这个阶段，PSTT 或 PSBT（Partially Signed Bitcoin Transactions）容器用于管理和维护交易的状态信息。这些容器在每个交易参与者的节点中独立维护，并存储有关交易的所有必要信息（如公钥、签名、锁仓脚本等），以便后续步骤中各方能够顺利地完成交易。

9.2 会话：交换公钥、聚合 P、nonce commit→reveal；A 产生 T 并下发

在交易准备阶段，双方需要交换公钥，以便为后续的签名计算提供必要的公钥信息。P 是聚合公钥，由双方的公钥通过 MuSig2 协议聚合而成，这一过程会根据双方的输入进行加权处理，确保公钥的合规性和安全性。通过 commit-reveal（承诺-揭示）机制，每方需要在会话中先承诺自己的 nonce（随机数），再揭示自己的随机数。此过程确保了双方的随机数 k_A 和 k_B 不会被对方提前得知，从而避免了签名的泄露。

在此之后，参与方 A 生成 T（秘密标量）并将其下发给参与方 B。T 是 Adaptor Signature 中的加密标量，确保了跨链交换的原子性。在交换公钥和 T 后，双方均准备好进行签名计算。

9.3 Adaptor 包：A → B (R_btc, s_btc, T, commit_btc)，B → A (R_ton, s_ton, T, commit_ton)**

在会话中，A 和 B 将各自的签名信息通过 Adaptor 包 交换。每个包包括以下内容：

• R_btc 和 R_ton：分别是 A 和 B 根据自己的 nonce 计算得到的点，这些点会用于生成 R，并用于签名。

• s*_btc 和 s*_ton：是 A 和 B 生成的部分签名，s* 包含了加密的签名信息，它的解密将使用秘密标量 t 来补全。

• T：是加密的 Adaptor Signature 点，用于确保跨链交换的原子性，T 必须保持一致，确保双方的签名匹配。

• commit_btc 和 commit_ton：是 A 和 B 在承诺阶段交换的 nonce commit 信息，这些承诺确保了双方在交易中的随机数不会被篡改或泄露。

通过这个交换，双方确认了交易的核心信息，并确保了后续签名过程的顺利进行。

9.4 执行：A 用 t 完成 TONDI key-path 签名并广播；B 见 s_ton 提取 t，完成 BTC 签名并广播

一旦所有必要的交易信息和承诺完成，A 会使用 t（从 s*_ton 中提取的秘密标量）来完成 TONDI 侧的 key-path 签名。A 在完成签名后，将交易广播到 Tondi 网络。

B 则通过查看 s_ton，从中提取出 t，并使用 t 来完成 BTC 侧的签名。B 完成签名后，B 会将签名广播到比特币网络，确保 BTC 侧的交易能够得到确认。

这一过程通过 Adaptor Signature 确保了交易的原子性：只有双方都完成签名后，交易才能被广播到相应的链上，从而完成跨链原子交换。

9.5 兜底：任一侧失约，进入退款叶流程

如果在交易过程中任何一方未按时完成签名或违约，系统将自动进入 退款叶 流程，触发之前设置的退款机制。无论是 BTC 侧还是 TONDI 侧，未完成交易的一方的资金将通过 P2TR 路径自动退回到原交易方。

这种兜底机制保证了即使某一方未履行其承诺，交易的一方也能通过退款机制安全地取回资金，避免了由于对方违约而导致的损失。

---

10. 示例（字段与对象）

10.1 PSTT_IN_TAP_KEY_ADAPTOR

{
  "version": 1,
  "R_xonly": "9f1d...32bytes...",
  "s_star":  "0b7a...32bytes...",
  "T_point": "027acb...33bytes...",
  "flags":   0x01
}

10.2 PSTT_GLOBAL_SWAP_CONTEXT

{
  "session_id": "b1a7d6d2-0e1a-4f45-a8fe-2d8d1d4f9c88",
  "role": "A",
  "domain_tag": "TONDI_SWAP_V1/TONDI",
  "adaptor_point_T": "03a1b2c3...33bytes...",
  "T_pok": "optional"
}

---

11. 测试计划

• 单元测试：makeAdaptorSig/verify/complete/extract、canonical_serialize、compute_msg32、见证拼装。

• 属性测试：随机会话、nonce 异常、字段缺失/顺序扰动、域错配。

• E2E：regtest（bitcoind）+ tondi-testnet：

  1. 正常互换；

  2. A 不广播 → B 退款；

  3. 费率极端 → RBF/CPFP；

  4. reorg；

  5. 崩溃恢复。

• 审计：第三方审计关注 nonce 管理、域分离、t 提取路径、容器兼容与解析健壮性。

---

12. 版本与演进

• PSTT v2（本规范）：Taproot + MuSig2 + Adaptor 可选字段；

• 向后兼容：不含新增键的 PSTT 与既有 PSKT 完全兼容；

• 未来：如引入 ZK/证明，可新增 PSTT_IN_PROOF_* 命名空间，保持解耦。

---

结语

本规范将 Tondi 的“部分签名交易”容器从 PSKT 演进为 PSTT，在保证向后兼容的前提下，一体化支持 MuSig2 与 Adaptor Signature，并给出WASM SDK 接口与跨链原子互换落地流程。
Avato Labs 按此实现，在 2025 Q4 将跨链体验升级到 秒级的 Adaptor Sig 模式，同时维持浏览器/钱包/节点的清晰分层与安全边界。

方案审计报告：Tondi PSTT 扩展方案，用于基于 Adaptor Signature 的跨链原子互换

审计报告：Tondi PSTT 扩展方案，用于基于 Adaptor Signature 的跨链原子互换

审计员说明： 本审计评估了将 PSKT（部分签名的 Kaspa 交易）演进为 PSTT（部分签名的 Tondi 交易）的拟议方案，以支持 Taproot-only、基于 Schnorr 的跨链原子互换，使用 Adaptor Signature 与比特币（BTC）进行原子互换。Tondi 作为 Kaspa 的分叉，具有 Taproot-only 语义，继承了基于 DAG 的共识（使用 BlueScore 作为相对时间锁，等同于 CSV），这为原子性和最终性引入了与 BTC 等线性区块链不同的独特考虑。

审计重点关注正确性、安全性、兼容性、可用性和实现可行性。它基于提供的文档，并与已建立的加密标准交叉引用（如 BIP-340 用于 Schnorr、MuSig2 草案和无脚本脚本文献）。潜在问题通过推理得到证实，建议按严重程度优先级排序（高、中、低）。未提供代码用于执行测试，因此本审计是概念性和结构性的；完整的代码审计需要审查 WASM SDK 和 PSTT 实现。

1. 执行摘要

该方案创新且结构良好，通过从依赖脚本的 HTLC（哈希时间锁合约）转向无脚本 Adaptor Signature，推动跨链原子互换的发展，可能实现亚秒级执行，同时保持原子性。主要优势包括与 PSKT 的向后兼容、清晰的关注点分离（WASM 用于计算，宿主用于网络）和强大的安全原语（如域分离、nonce 保护）。

然而，在 DAG 特定最终性（BlueScore 与 BTC 的 CLTV）、多会话环境中的 nonce 管理和规范序列化中的潜在可塑性等领域存在风险。该方案假设 secp256k1 等加密库的完美实现，但现实偏差可能引入漏洞。总体评级：坚实基础，存在中级风险差距；修复后并经第三方代码审计可投入生产。

• 优势： 通过 Taproot key-path 实现隐私，无脚本原子性，WASM 模块化适用于钱包。

• 弱点： 过度依赖宿主 RNG 的安全性，未完全处理 Kaspa/Tondi DAG 重组，SDK 中错误传播有限。

• 建议： 12 项（3 高、5 中、4 低严重性）。

2. 范围和方法论

• 范围内： 签名原则（Schnorr、MuSig2、Adaptor Sig）、原子互换工作流程、PSTT 容器设计、WASM SDK 接口、安全/审计点、兼容性和端到端流程。

• 范围外： 底层 Tondi 链共识（假设与 Kaspa 分叉一样安全）、BTC PSBT 细节（引用但未重新定义）、经济激励（如互换费用）或性能基准。

• 方法论：

  • 与 BIP（340、341、371、MuSig2 规范）进行概念审查。

  • 针对常见陷阱的安全分析（如 nonce 重用、密钥抵消）。

  • 与 PSKT/PSBT 的兼容性检查。

  • 针对目标受众（工程师、审计员、集成方）的可用性评估。

  • 与 Adaptor Signature 和跨链互换的公共资源交叉验证（未发现重大差异）。

3. 积极方面

• 加密稳健性： 该方案正确应用 Schnorr（BIP-340）与 x-only 公钥、MuSig2 用于 2-of-2 聚合（包括通过权重防密钥抵消），以及 Adaptor Signature 用于无脚本原子性。验证方程（如 s*·G = R + e·P + T）准确陈述，提取（t = s* - s）实现无链上脚本的原子揭示。

• 隐私和效率： Taproot-only 强制隐藏多方协作于 64 字节签名之后。成功路径使用 key-path 花费，减少链上足迹，实现“秒级”互换——比 HTLC（因确认而需分钟级）显著改进。

• 兼容性： 新字段（如 PSTT_IN_TAP_KEY_ADAPTOR）可选，并被遗留解析器忽略，与 PSBT 的“未知键忽略”规则一致。规范序列化排除签名，防止部分状态下的哈希不匹配。

• 模块化设计： WASM SDK 将纯计算（签名、组装）与宿主责任（RPC、费用控制）隔离，减少攻击面。接口（如 nonceCommit/reveal）强制协议步骤，最小化开发者错误。

• 安全重点： 融入最佳实践，如域分离（"TONDI_SWAP_V1"）、PoK(T) 用于陷阱门预防、零化以及 nonce 跟踪。超时不变量（BTC CLTV > Tondi BlueScore + 裕度）考虑网络延迟和 RBF/CPFP。

• 可审计性： 第 8 节提供清晰检查点（如方程验证、commit-reveal）。测试计划覆盖单元/属性/E2E 场景，包括重组和恢复。

4. 识别的问题和建议

问题按部分分类，包含严重性、描述和修复。使用表格以清晰呈现枚举数据。

4.1 签名原则（第 2 节）

4.2 原子互换工作流程（第 3 节）

4.3 PSTT 容器（第 4 节）

• PSTT-01 (中)： 规范序列化（4.5）忽略签名但按键编号排序。若设计后添加新键（如未来 ZK 证明），未排序或重复键可能产生非唯一哈希，导致可塑性。LEB128/varint 高效但若溢出则解析易出错。

  • 修复： 指定确切排序算法（如键字节的字典序）并在 psttEncode/Decode 中添加基于哈希的完整性检查。模糊测试可塑性。

• PSTT-02 (低)： GLOBAL_SWAP_CONTEXT 包括 session_id/role 但无时间戳，若 session_id 跨链冲突则风险重放。

  • 修复： 在上下文中嵌入 unix 时间戳或 BlueScore；在 SDK 中验证新鲜度。

4.4 WASM SDK 和交互（第 5-6 节）

• SDK-01 (高)： SDK 暴露纯计算但假设宿主安全存储（如 session_id/T/R/s*）。若宿主被入侵（如恶意钱包 app），敏感数据如 t 可能在广播前泄露。

  • 修复： 使用用户派生密钥加密会话存储（如通过 deriveXOnly）。添加 SDK 审计日志用于敏感操作。

• SDK-02 (中)： 错误码（如 ERR_BAD_NONCE）定义但未在 TS 接口中传播（如 Promise 解析/拒绝无类型错误）。

  • 修复： 在 TS 中使用类型化错误（如扩展 Error 带有 code）。在文档中添加全面错误处理示例。

• INT-01 (低)： 宿主风控（0-conf 评分、费用分位）复杂但缺乏 Tondi 特定 DAG 指标（如父多样性用于重组抵抗）。

  • 修复： 在评分中集成 Kaspa BlueScore 方差；参考 Kaspa 文档用于 DAG 感知费用。

4.5 安全性和测试（第 8-11 节）

• SEC-01 (中)： 费用钉死（8.6）在 BTC 上支持 RBF/CPFP，但在 Tondi 上仅“打包优先”。在 DAG 中，低费用交易可能无限期停留而无确认激励。

  • 修复： 定义 Tondi 费用升级类似于 RBF；使用 mempool 拥堵模拟测试。

5. 总体建议

• 立即行动： 在部署前处理高严重性问题（SIG-02、SWAP-01、SDK-01）。对 WASM SDK 进行第三方代码审计，重点关注 secp256k1 操作和 nonce 管理。

• 测试增强： 扩展 E2E 测试以包括多重组场景（Kaspa 的 DAG 允许比 BTC 更深的重组）。使用基于属性的测试针对敌对输入下的 Adaptor 提取。

• 文档改进： 添加原子性不变量的正式证明。在 regtest 中提供端到端互换的样本代码。

• 未来考虑： 随着 Tondi 演进，监控 Schnorr/MuSig2 更新（如 BIP 修订）。探索与 Lightning 或其他 L2 的集成用于混合互换。

6. 结论

该方案代表 PSKT 向 PSTT 的前瞻性演进，有效桥接 Tondi 的 Taproot-only DAG 与 BTC，实现安全、高效的原子互换。凭借强大的加密基础和深思熟虑的分层，它可能设定无脚本跨链协议的标准。然而，DAG 特定风险和实现依赖需要谨慎——实施修复、严格测试并寻求外部审计以缓解。Avato Labs 定位为先锋，但成功取决于稳健执行。