← Back to Home

Sparkle Protocol: Lightning-Settled Ordinal Trading

Serverless P2P atomic swaps for Bitcoin Ordinals using Taproot and Lightning Network.

Status: Mainnet Validated (v1.0.0)

  • Taproot atomic swaps: Hashlock + timelock script-path spending
  • Decentralized orderbook: Nostr relays with NIP-15 product events
  • Secure wallet integration: NIP-07 for Nostr, Unisat/Xverse for Bitcoin
  • Live demo: Try the Taproot Swap interface

Technical Specification

Version 1.0.0 | December 2025

Author: David A. Michael

This document describes the production-proven Sparkle Protocol v1.0.0, validated on Bitcoin mainnet.

Abstract

Sparkle Protocol enables trustless peer-to-peer trading of Bitcoin Ordinal inscriptions using Lightning Network payments and Taproot atomic swaps. The protocol uses a fully decentralized architecture: orders are published to Nostr relays as NIP-15 events, negotiations occur via NIP-04 encrypted DMs, and settlement uses Taproot script-path spending with hashlock/timelock conditions. No central coordinator or custody is required. Private keys never leave the user's browser wallet extensions.

Note: The core protocol has been validated on Bitcoin mainnet. While production-proven, the implementation has not received a formal third-party security audit. Users should start with small amounts and test on testnet before trading high-value inscriptions.

1. Introduction

1.1 The Problem

Bitcoin Ordinals have emerged as a way to inscribe arbitrary data—including images, text, and metadata—directly onto individual satoshis. This creates NFT-like digital artifacts with Bitcoin's security model. However, trading these inscriptions currently requires on-chain Bitcoin transactions, which introduce several limitations:

1.2 Proposed Solution

Sparkle Protocol proposes a hybrid approach that leverages the Lightning Network for instant payment settlement while maintaining Bitcoin's on-chain ownership model for the actual inscriptions. The core idea is to separate payment finality from ownership transfer timing.

Note: This proposal does not eliminate the need for on-chain transactions. It aims to make payment settlement instant while on-chain ownership transfer follows standard Bitcoin confirmation times.

2. Technical Architecture

2.1 Core Components (v1.0.0 Decentralized)

The protocol consists of four main components:

  1. Nostr Orderbook: Orders published as NIP-15 product events to decentralized relays (relay.damus.io, nos.lol, etc.)
  2. NIP-04 Negotiation: Encrypted peer-to-peer messaging for trade negotiation without intermediaries
  3. Taproot Atomic Swaps: P2TR addresses with script-path spending (hashlock for buyer claim, timelock for seller refund)
  4. Browser Wallet Integration: NIP-07 for Nostr identity (Alby, nos2x), Unisat/Xverse for PSBT signing
Architecture Evolution: v1.0.0 replaces the centralized coordinator model with a fully decentralized design. Orders, negotiations, and settlements all occur peer-to-peer with no trusted intermediary.

2.2 Metadata Standard

Sparkle-compatible inscriptions include metadata that signals Lightning Network support:

{
  "p": "sparkle",
  "v": 1,
  "lightning": {
    "enabled": true,
    "min_channel_capacity": 100000
  },
  "trade": {
    "provider_pubkey": "seller_nostr_hex_pubkey",
    "fee_rate": 1
  }
}

2.3 Taproot Atomic Swap Mechanism

Trades follow this trustless P2P sequence:

  1. Discovery: Buyer finds offer on Nostr orderbook (NIP-15 product event)
  2. Negotiation: Buyer and seller negotiate via NIP-04 encrypted DMs
  3. Preimage Generation: Seller generates 32-byte preimage and SHA256 payment_hash
  4. Taproot Address: Both parties derive P2TR address with two script paths:
    • Hashlock: OP_SHA256 <hash> OP_EQUALVERIFY <buyer_pk> OP_CHECKSIG
    • Timelock: <locktime> OP_CLTV OP_DROP <seller_pk> OP_CHECKSIG
  5. Funding: Seller sends Ordinal to Taproot swap address
  6. Lightning Payment: Seller creates invoice with payment_hash; buyer pays, learns preimage
  7. Claim: Buyer uses preimage to claim Ordinal via hashlock script path
  8. Refund (fallback): If buyer fails to claim, seller reclaims after timelock expires
Definition: Atomic swap means either both legs complete (buyer gets inscription, seller gets Lightning payment) or neither completes. No trusted third party is required. The Taproot scripts enforce the atomic property cryptographically.

3. Economic Model

3.1 Cost Structure

The protocol introduces new cost dynamics:

Operation One-Time Cost Per-Trade Cost
Metadata Inscription ~$0.50 $0
Lightning Channel Setup ~$2-5 (on-chain) $0
Lightning Payment $0 ~$0.001
On-chain Transfer $0 ~$1-5

3.2 Cost-Benefit Analysis

Traditional Ordinals Trading:

Sparkle Protocol (Proposed):

Note: The primary benefit is instant payment finality, not cost reduction. On-chain fees still apply for ownership transfer.

4. Security Model

4.1 Trust Assumptions

The protocol is trust-minimized but not fully trustless:

Warning: The "free option" problem exists in all atomic swaps: a seller could list an Ordinal, receive Lightning payment, but have already moved the UTXO. Mitigation: buyers should verify UTXO ownership via a block explorer (e.g., mempool.space) before paying the Lightning invoice.

4.2 Attack Vectors

Potential attacks and mitigations:

  1. Free Option Attack: Seller lists Ordinal, receives Lightning payment, but UTXO was already spent
    • Mitigation: Buyer verifies UTXO via mempool.space before paying invoice
  2. Seller double-spend: Seller signs PSBT but broadcasts competing transaction
    • Mitigation: Buyer should verify claim TX confirmation; if failed, refund path activates after timelock
  3. Channel jamming: Attacker ties up Lightning liquidity
    • Mitigation: Standard Lightning Network channel jamming mitigations
  4. Relay censorship: Nostr relay refuses to publish offers
    • Mitigation: Users can connect to multiple relays; offers propagate across relay network

5. Implementation Considerations

5.1 Current Status

Current Status: As of December 2025, Sparkle Protocol has been validated on Bitcoin mainnet. The following infrastructure is available:

5.2 Lightning Node Requirements

Both buyers and sellers would need:

5.3 Coordinator Decentralization

While the protocol includes a coordinator service, it is designed for permissionless operation:

6. Comparison to Other Approaches

6.1 Traditional On-Chain Trading

Advantages over Sparkle:

Disadvantages:

6.2 Centralized Marketplaces

Advantages over Sparkle:

Disadvantages:

6.3 Sparkle Protocol Position

Sparkle attempts to find a middle ground:

Note: Sparkle Protocol is not "better" than existing approaches—it offers different trade-offs. Whether those trade-offs are worthwhile depends on specific use cases and user preferences.

7. Known Limitations

7.1 What Sparkle Cannot Do

7.2 Remaining Research Questions

8. Potential Development Path

8.1 Phase 1: Specification & Research (Complete)

8.2 Phase 2: Reference Implementation (Complete)

8.3 Phase 3: Testing & Validation (Complete)

8.4 Phase 4: Mainnet Deployment (Complete)

Status: The core protocol has been validated on Bitcoin mainnet. Future development and ecosystem expansion depend on community adoption and contributor interest.

9. Conclusion

Sparkle Protocol proposes a hybrid approach to Bitcoin Ordinals trading that combines Lightning Network payment finality with on-chain ownership guarantees. The protocol is trust-minimized but introduces new complexity and infrastructure requirements.

This whitepaper presents an honest assessment of what the protocol could achieve and its limitations. Instant payment settlement is possible; instant ownership transfer is not. On-chain fees remain; only payment settlement becomes cheaper. A coordinator is required; full trustlessness is sacrificed for speed.

Whether Sparkle Protocol is valuable depends on whether these trade-offs align with real user needs. This whitepaper is shared as a starting point for discussion, not a promise of implementation or a claim of superiority over existing approaches.

Invitation for Feedback: This protocol is open for review, criticism, and improvement. If you are a Lightning developer, Ordinals builder, marketplace operator, or security researcher, your feedback would help refine this specification.

References

  1. Bitcoin Lightning Network BOLT Specifications. https://github.com/lightning/bolts
  2. Bitcoin Ordinals Protocol. Casey Rodarmor, 2023. https://docs.ordinals.com
  3. Hash Time-Locked Contracts. https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts
  4. Lightning Network Daemon (LND) Documentation. https://docs.lightning.engineering
  5. Core Lightning Documentation. https://lightning.readthedocs.io

Copyright © 2025 David A. Michael. Licensed under CC0 1.0 Universal.

Sparkle Protocol v1.0.0 | Mainnet Validated. This is production-proven software, not investment advice.

Related Documents