Protocol Design

Security guarantees and trust assumptions of the Sparkle Protocol

Core Security Properties

Zero Key Custody

Private keys never leave the user's browser wallet. The protocol coordinator only sees public keys and hash commitments. No server-side key storage.

Cryptographic Atomicity

Hash Time-Locked Contracts (HTLCs) enforce all-or-nothing execution. Either both parties receive their assets, or the trade times out and assets are refunded.

Timelock Protection

CLTV timelocks (BIP-65) guarantee sellers can always reclaim their inscriptions if buyers abandon trades. No funds can be permanently locked.

Lightning Native

Protocol designed for Lightning Network settlement from the ground up. Preimage revelation on LN directly enables on-chain claims via Taproot.

Technical Standards

Bitcoin Standards

  • BIP-341Taproot script-path spending
  • BIP-342Tapscript validation
  • BIP-65CLTV timelock verification
  • BIP-174PSBT transaction format

Lightning Standards

  • BOLT-11Payment request encoding
  • SHA-256Preimage hash binding
  • Hold InvoicesConditional payment release

Trust Assumptions

1
Coordinator Availability

The coordinator must be online for trade matching. However, funds cannot be stolen if coordinator is compromised - only trade availability is affected.

2
Bitcoin Network Security

Standard Bitcoin consensus assumptions apply. Timelock security depends on accurate block height progression.

3
Wallet Security

Users must trust their browser wallet extensions. Signing happens client-side; the protocol cannot protect against compromised wallets.

Mainnet Validation

The protocol has been validated on Bitcoin mainnet with successful atomic swaps. See the proof bundle for transaction verification.

View Mainnet Proofs