Avato Labs Design and Integration Specification for PSTT (Partially Signed Tondi Transaction) with Adaptor Signature for Atomic Cross-Chain Swap

Scope: Tondi (Taproot-only, Schnorr) for Adaptor Sig-based Cross-Chain Atomic Swaps
Target Audience: Blockchain/Wallet Engineers, Auditors, Frontend Integrators
Deliverables: PSKT (Partially Signed Kaspa Transactions) → PSTT (Tondi "Partially Signed Transaction" Container), WASM SDK, Frontend-Backend Interaction Protocol
Compatibility: No impact on standard PSKT/PSTT transactions; Adaptor Sig field is optional.

---

0. Summary and Path (TL;DR)

Summary

The history of decentralized finance (DeFi) is marked by paradigm shifts brought on by the birth of key mechanisms. Bitcoin freed value from centralized control, Taproot ushered in simplicity and privacy in signature algorithms and scripting, and the introduction of Adaptor Signatures (Adaptor Sig) allows cross-chain atomic swaps to achieve near-instant execution without the need for complex scripts.

Tondi embraces Taproot-only + Schnorr as its execution semantics and evolves PSKT to PSTT (Partially Signed Tondi Transaction), marking more than just a container-level upgrade—it represents a generational leap in interface standardization:

• MuSig2 and Adaptor Sig are integrated at the container level, aligning the safety and refund paths for cross-chain atomic swaps in a unified structure.

• Backward Compatibility: Existing transactions remain unaffected, and advanced features are seamlessly added via optional fields.

• WASM SDK integrates signature logic on the frontend, leaving fee control, broadcasting, and mempool interactions in the host environment, resulting in clear security boundaries.

PSTT’s significance lies not just in making cross-chain swaps faster but in establishing a core framework with a container-centric design, signature-based consensus, and WASM SDK development interface. This transforms cross-chain interactions from cumbersome, trust-laden processes into auditable, reusable, and near-instant financial infrastructure.

Avato Labs pioneers this shift—not just optimizing performance within the BTC or single-chain ecosystem but blending DAG architecture, Taproot’s minimalism, and Adaptor Sig’s atomicity into a scalable cross-chain protocol stack. This is both a tribute to the decades of blockchain signature theory and a proactive shaping of the multi-chain collaborative future.

The advent of PSTT marks a pivotal moment in post-2025 crypto finance history.

Path

Tondi will evolve the PSKT from Kaspa into PSTT (Partially Signed Tondi Transaction), adding optional support for MuSig2 + Adaptor Signature fields while ensuring backward compatibility.

• BTC will continue using PSBT v2 + BIP-371.

• The cross-chain atomic swap "bridge layer" exchanges only minimal non-container-specific Adaptor packages (e.g., T, R, s*).

• Successful path uses Taproot key-path (MuSig2 aggregated signature), and the refund path uses tapscript (CSV/BlueScore or CLTV equivalent).

WASM SDK provides purely computational interfaces for signature and witness assembly, while node/RPC/storage/fee control remains in the host environment.

---

1. Terminology and Notation

• Schnorr (BIP340): Signature (R, s), where e = H_tag(R_x || P_x || m32) and s = k + e·x (mod n)

• MuSig2: 2-of-2 aggregated public key P = μ(P_A, P_B) with two-phase nonce (commit → reveal)

• Adaptor Signature (scriptless scripts): Given Adaptor point T = t·G, the full signature is encrypted as s* = s + t.

  • Validation: s*·G = R + e·P + T

  • Completion: s = s* − t; Extraction: t = s* − s

• msg32 / sighash32: 32-byte message hash to be signed.

• BlueScore/CSV: Tondi’s relative time-lock equivalents.

• PSTT: Tondi’s "Partially Signed Transaction" container.

• BTC PSBT: Bitcoin’s BIP-370/371 container.

---

2. Signature Principles (Schnorr / MuSig2 / Adaptor Sig)

This section provides a comprehensive explanation of the signature principles Tondi uses, including Schnorr, MuSig2, and Adaptor Signature (scriptless scripts), detailing their roles in cross-chain atomic swaps.

2.1 Schnorr and Taproot Key-path

• Basic Definition: Schnorr signature algorithm on secp256k1, signed as (R, s).

• Signer's Private Key: The signature depends on the private key x associated with public key P = x·G.

• Challenge Value: e is derived from the message and intermediate results, calculated via H_tag(R_x || P_x || m32).

• Signature’s Random Value k: Generated randomly, R = k·G. The nonce k must be securely random and unique.

• Signature Formula: s = k + e·x (mod n).

• Verification Formula:
  s·G ?= R + e·P

• Tondi Implementation: Tondi mandates Taproot spend types, prohibiting P2PKH/P2SH paths. The chain only shows (R, s), enhancing privacy.

2.2 MuSig2 (2-of-2 Aggregated Signature)

• Goal: Allow multiple participants to generate a single aggregated Schnorr signature without revealing individual signatures, crucial for privacy in atomic swaps.

• Key Steps:

  • Public Key Aggregation: Two public keys P_A and P_B are aggregated into P = μ(P_A, P_B).

  • Nonce Commitment and Reveal: Each party generates a nonce and exchanges commitments, revealing the nonces and aggregating the results.

  • Challenge Calculation: e = H_tag(R_x || P_x || m32).

  • Partial Signatures: Each participant computes partial signatures s_A and s_B, and these are aggregated to form the final signature.

• SDK Guarantees: Nonce reuse is prohibited, and the aggregation function includes anti-cancellation (anti-kc) measures.

2.3 Adaptor Signature (Scriptless Scripts)

• Definition: Adaptor Signature encrypts the full signature as s* = s + t, where t is a secret scalar, and the signature remains indistinguishable from a standard Schnorr signature.

• Validation:
  s*·G = R + e·P + T.

• Atomic Swap Role:

  • Success Path: A and B exchange MuSig2 signatures and Adaptor Signature, with t extracted to unlock the BTC side.

  • Refund Path: If one party defaults, they can revert to using CSV/BlueScore (Tondi) or CLTV (BTC) scripts.

• Security: t must be securely generated and committed to avoid trapdoor attacks, and the domain tag ensures replay protection.

---

3. Atomic Swap Flow (Adaptor Sig Version)

Participants: A (wants TNDI, sends BTC), B (wants BTC, sends TNDI).
Invariant: The same T = t·G appears in both chains' Adaptor Signature verifications.

3.1 Preparation (Locking Funds on Both Chains)

• BTC: P2TR(internal=P_btc), tapleaf: <T1> CLTV, DROP, <PA_btc> CHECKSIG (refund to A).

• Tondi: P2TR(internal=P_ton), tapleaf: <ΔBlue> CSV, DROP, <PB_ton> CHECKSIG (refund to B).

3.2 Session (MuSig2 + Adaptor Package Exchange)

• Exchange public keys, aggregate P_btc and P_ton.

• A generates t and T = t·G (optionally with PoK(T)).

• Perform nonce commitment and reveal on both chains: R_btc, R_ton.

• Adaptor Package Exchange:

  • 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)

3.3 Execution and Refund Mechanism

• A: Signs and broadcasts Tondi using the key-path: s_ton = s*_ton − t.

• B: Extracts t from s_ton, signs BTC: s_btc = s*_btc − t, and broadcasts.

• Timeout: If A doesn’t broadcast, B initiates the CSV refund; if B doesn’t broadcast, A initiates the CLTV refund.

---

4. PSTT: Tondi Partially Signed Transaction Container (PSKT → PSTT Expansion)

PSTT builds on the PSKT’s "key-value table" container model. The key attributes are split into Global, Inputs[i], and Outputs[j] namespaces.

4.1 Encoding and Versioning

• Version: PSTT_GLOBAL_VERSION = 2 (aligned with PSBTv2’s structure).

• Serialization: Key-value pairs are serialized in KV format with a file header pstt\xff.

4.2 Global Section (Required/Optional)

4.3 Inputs Section

4.4 Outputs Section

---

5. WASM SDK (Frontend for Tondi Wallet)

The WASM SDK provides pure computational interfaces for signing, verification, message hash computation, witness assembly, and PSTT encoding/decoding.

5.1 Exported Interfaces

5.2 Security and Implementation Highlights

• RNG: Default to crypto.getRandomValues or node:crypto.

• Zeroize: Ensures that private keys and nonces are cleared after use.

• Nonce Replay Protection: Session flags mark used nonces.

• PoK(T): Optional proof-of-knowledge to avoid trapdoor points.

---

6. Frontend-Backend/Node Interaction Layer

• WASM (Frontend): Handles signatures, witness assembly, PSTT encoding/decoding.

• Host (Backend/Wallet): Interacts with Tondi and Bitcoin nodes, fee control, session state storage.

---

7. Compatibility with Standard PSTT Transactions

The extension of PSTT maintains backward compatibility with standard PSKT transactions. New keys (like PSTT_IN_TAP_KEY_ADAPTOR) are optional and do not affect existing parsers.

---

8. Security and Audit Considerations

• Adaptor Signature: Verification equation, domain separation, and consistency of T are critical.

• MuSig2: Ensure commitment-reveal process, nonce security, and anti-cancellation.

• Timeout Management: Proper time window handling for cross-chain swaps.

---

9. Example (Field and Object Format)

PSTT_IN_TAP_KEY_ADAPTOR:

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

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"
}

---

10. Testing Plan

• Unit Tests: Functions like makeAdaptorSig, verify, complete, and serialization.

• End-to-End Tests: Cross-chain swaps on regtest (Bitcoin and Tondi testnets), handling edge cases such as rate extremes, reorgs, and crash recovery.

---

11. Version and Evolution

• PSTT v2: Supports optional fields for MuSig2 and Adaptor Signature.

• Future: Potential additions for ZK proofs and new namespaces while maintaining separation.

---

Conclusion
This specification evolves the PSKT into PSTT, fully supporting MuSig2 and Adaptor Signature while maintaining compatibility with existing systems. The integration of the WASM SDK ensures modularity, while the cross-chain atomic swap flow provides seamless, auditable, and near-instant execution.