Documentation

📌 Summary

This proposal introduces a burn-based redemption mechanism to enable scalable, privacy-preserving, and trust-aligned off-chain settlement of Rune assets (especially stablecoins) on the Lightning Network. It solves the dust UTXO explosion problem, enables instant and individual redemption without channel closures, and maintains public accountability through on-chain burn commitments.

We propose enhancing the Rune protocol to support:

• Off-chain burns over Lightning
• On-chain minting by issuer or user with cryptographic proof
• Optional reissuable flag for assets

Why This Is Needed

The Problem

In its current form, Runes:

• Are fully on-chain, which is a strength for permanence, but a limitation for scalability.
• Have no reissuance capability, meaning that once minted, tokens cannot be dynamically issued or re-minted.
• Do not yet support Lightning Network routing, which is needed for real-world microtransactions and fast settlement.

If you try to move Rune assets onto Lightning today (via channel-based locking), the following problems emerge:

1. Dust Explosion on Channel Exit

If a channel contains 1000 RUNE-USD distributed across 500 users (e.g., each holding 2 tokens), and they all wish to settle on-chain…

You would need 500 individual UTXOs to represent those 2-token balances.

That's 500+ dust outputs at 546 sats or more, leading to chain bloat and fee inefficiency.

2. Channel Fragmentation

If one party wants to exit while others stay, you need to close and reopen Lightning channels.

This creates friction and cost for everyone.

3. No Issuer-Level Flexibility

There is no mechanism for an issuer to accept tokens off-chain and reissue new ones when needed.

🆚 How Taproot Assets Address This (and Their Limitations)

Taproot Assets address off-chain movement and redemption by relying on:

• Off-chain proof chains (commitments embedded in Bitcoin Taproot outputs)
• Live indexer infrastructure to validate ownership and double-spend resistance
• Asset-aware channel construction in Lightning

Limitations of Taproot Assets:

Our Proposed Solution

We propose a burn-and-mint mechanism to enable:

• Off-chain redemption over Lightning
• On-chain supply tracking
• Zero-dust settlement
• User-exit without global coordination

🔄 Flow Summary

1. Receive RUNE-USD over Lightning
   User receives fungible stablecoin over LN
2. User Sends to Burn Address (Off-Chain)
   A special Lightning address controlled by the issuer
   Burn transaction is recorded in the LN channel state
3. Issuer Marks RUNE-USD as Burned
   Internal accounting updates
   Payout may be triggered in USD, BTC, USDT, etc.
4. Issuer (or User) Posts Aggregate On-Chain Burn
   For public transparency, OP_RETURN burn with edict pointer
5. Optionally Mint New Tokens
   Either the issuer or the user (via burn proof) can mint equivalent Runes on-chain if necessary

What Must Change in Rune Protocol

Advantages of This Approach

Real-World Applications

• Lightning-native stablecoins (RUNE-USD, RUNE-EUR)
• Cross-chain swaps (burn Rune, receive ETH)
• Fiat payouts (burn via Lightning, receive USD in bank)
• Lightning L2 DeFi (burn to trigger DAO redemption, protocol interactions)

Conclusion

This proposal unlocks a powerful, low-friction, and scalable path for Runes to become not just an on-chain token standard, but a Lightning-native financial primitive.

It allows Runes to:

• Retain their Bitcoin-aligned simplicity
• Avoid the complexity and fragility of Taproot Assets
• Compete with USDT/USDC in both functionality and efficiency

This is the missing bridge between Bitcoin-native assets and the scalability of Lightning — and it can be built.

Abstract

This paper explores a novel implementation path for enabling Rune-based fungible tokens to operate over the Bitcoin Lightning Network. Unlike Taproot Assets, which rely on an off-chain proof model and indexer infrastructure, the proposed Rune-Lightning design prioritizes full on-chain verifiability, trust-minimized off-chain settlement, and optional asset redemption using burn-based settlement channels. We present a high-level architecture, explore critical challenges (e.g., dust mitigation, off-chain state tracking, double-spend prevention), and propose a clean integration path leveraging LND (Go) and Rune client tools (Rust). This work contributes toward building a Bitcoin-native, resilient, and trust-aware token layer that extends beyond speculative use.

1. Introduction

Bitcoin's UTXO model and decentralized consensus guarantee unmatched settlement assurances. However, Bitcoin's lack of a native tokenization standard has led to the rise of alternatives like Ethereum-based ERC‑20s, often compromising on decentralization, permanence, and verification. Recent innovations like Taproot Assets and Runes aim to anchor fungible tokens directly into Bitcoin's base layer. While Taproot Assets enable off-chain scalability and Lightning integration through cryptographic proofs, they rely on an external indexer ecosystem and lack full recoverability. In contrast, Runes are entirely on-chain, stateless, and require no auxiliary proofs—but do not yet support Lightning. This research proposes a Rune-over-Lightning framework: a decentralized, Lightning-compatible mechanism for transacting Rune tokens with minimal trust and without proof dependencies.

2. Background

2.1 Runes Protocol

Runes are Bitcoin-native fungible tokens inscribed directly into transaction outputs using Bitcoin Script (OP_RETURN) with "Runestones" that encode issuance, transfers, and burns. They are:

• On-chain only (stateless, immutable)
• Fully recoverable (no indexer needed)
• Trustless by design

Runes include a burn mechanism: transferring to an OP_RETURN output with an edict pointer can signal destruction.

2.2 Taproot Assets

Taproot Assets (TA) are off-chain token proofs anchored in Taproot outputs. They enable Lightning compatibility via LND-based channels but:

• Rely on proof syncing with off-chain storage
• Can be lost if proofs are not preserved
• Require asset-aware channel funding and complex coordination

3. Core Design Philosophy

Our proposal builds on three principles:

4. Architecture Overview

4.1 Key Components

• Rune UTXO Locking: Lock Rune-carrying UTXOs as part of Lightning channel funding.
• Off-chain Rune Balances: Tracked by participant nodes within channels.
• Burn-on-Close Model: Settlement triggers a burn to OP_RETURN, providing chain-native receipt for redemption.
• Issuer Optionality: Asset issuer may offer fiat/asset redemption to a burn address via off-chain oracles, without requiring global on-chain settlement.

5. Technical Flow

5.1 Channel Opening

A user funds a Lightning channel with a Bitcoin UTXO that contains Runes. A portion of the UTXO value represents the token balance. Rune metadata (e.g., ticker, amount) is mapped and tracked off-chain between participants.

5.2 Off-Chain Transfers

Tokens move via balance updates in Lightning invoices. Each participant tracks state, e.g.:

NodeA: +100 DOG
NodeB: -100 DOG

5.3 Channel Close + On-Chain Burn

If users want to settle on-chain:

1. They send the Rune off-chain to a predefined Lightning burn address.
2. This triggers a settlement output to an OP_RETURN with edict, signaling burn.
3. Users claim redemption with the burn tx proof.

6. Dust Mitigation Strategy

A major issue with on-chain settlement of tokens is dust explosion—where large numbers of small-value token outputs require Bitcoin UTXOs above the dust threshold (~546 sats).

Our Solution:

• Fractional ownership off-chain: Minimize chain footprint.
• Burn-and-redeem model: Burn 1000 DOG in a single transaction and allow fractional redemption by issuer without on-chain fragmentation.
• Only settle to chain if necessary: The default state remains off-chain, reducing UTXO bloat.

7. Trust, Issuance & Redemption

Trust is always implicit when using fiat-backed assets like USDT or USDC. Even with fully on-chain tokens, the user must trust the issuer for redemption. Our system preserves:

• On-chain accountability via public burn transactions
• Off-chain redemption flexibility (e.g., fiat transfer, BTC payment, asset swap)

This enables:

• Non-chain redemption pathways (e.g., send Runes over Lightning → burn → receive USD in bank)
• Low-friction user flows with verifiable proof

8. Implementation Stack

9. Challenges & Future Work

• State Sync: Ensuring consensus over off-chain Rune balances.
• Atomic Burns: Preventing double-claim via burn replay.
• Lightning Message Extension: Defining a BOLT or TLV to carry Rune transfer data.
• Index-Free Claiming: Exploring stateless burn proofs for redemption.
• Tooling: Developer SDKs, CLI tools, and testnet faucet integration.

10. Conclusion

Runes offer a uniquely Bitcoin-aligned approach to token issuance: permanent, minimal, and on-chain. By extending Runes to Lightning via a simple UTXO locking model and burn-on-close strategy, we unlock scalable payments, optional redemption, and proof-free asset survivability—without compromising Bitcoin's ethos. This approach is not only possible, but necessary if Bitcoin is to serve as the final layer of financial truth—tokens included.

References

• Taproot Assets Protocol Spec (Lightning Labs)
• Rune Protocol Design (Casey Rodarmor)
• BOLTs (Bitcoin Lightning Network specifications)
• Ordinal Theory Handbook
• Bitcoin Core and LND documentation