Taproot Assets: Issuing Tokens on Bitcoin and Routing Them Over Lightning
Taproot Assets lets anyone issue tokens on Bitcoin and transfer them instantly through the Lightning Network. Here's how.
Bitcoin was designed to move one asset: bitcoin. For over a decade, projects have tried to change that by layering token protocols on top of the base chain. Most either bloated the blockchain, broke the UTXO model, or had no path to instant transfers. Taproot Assets takes a different approach: it embeds token metadata inside Taproot outputs, stores proof data off-chain, and routes asset payments through the existing Lightning Network without requiring intermediate nodes to know anything about the assets being moved.
The result is a protocol where anyone can mint stablecoins, utility tokens, or collectibles on Bitcoin and transfer them in seconds for near-zero fees. With Tether launching USDT on Lightning via Taproot Assets in early 2025 and the protocol reaching v0.8 by mid-2026, this is no longer theoretical. It is live infrastructure carrying real value.
From Taro to Taproot Assets
Lightning Labs announced the protocol in April 2022 under the name "Taro," alongside a $70 million Series B funding round. Following a trademark dispute with Tari Labs, the project was rebranded to "Taproot Assets" in May 2023. The first mainnet alpha (v0.3) shipped in October 2023, supporting on-chain minting and transfers. Lightning Network integration followed in July 2024 with v0.4, making Taproot Assets the first multi-asset Lightning protocol on mainnet.
Subsequent releases have added significant functionality. Version 0.6 (June 2025) introduced improved RFQ (Request for Quote) negotiations for edge nodes and support for up to 20 inbound asset channels per receiver. Version 0.7 (December 2025) added static reusable addresses (AddressV2), auditable supply commitments, and multi-path payment support for larger transfers. As of June 2026, v0.8 is the current release, with USDT live on Lightning.
How Minting Works
Issuing a Taproot Asset starts with a single Bitcoin transaction. The issuer defines the asset parameters: name, supply cap, whether additional minting is allowed, and whether the token is fungible or non-fungible. The protocol then generates witness data, assigns the newly minted asset to a key controlled by the issuer, and publishes a standard P2TR (Pay-to-Taproot) output to the blockchain.
The on-chain transaction looks indistinguishable from any other Taproot spend. Asset data is committed by tweaking the Taproot internal public key with a hash of the commitment:
Q = P + H(P | c) * G
Where:
Q = final Taproot output key (visible on-chain)
P = internal public key
c = commitment data (root of the asset Merkle tree)
G = generator point on secp256k1The UTXO consumed by this minting transaction becomes the genesis point. The asset ID is derived deterministically from the genesis data:
asset_id = sha256(genesis_outpoint || asset_tag || asset_meta || output_index || asset_type)Multiple assets can be batched into a single minting transaction, saving fees and conserving block space. Once the transaction confirms, the asset is live and transferable.
The Merkle-Sum Sparse Merkle Tree
Asset state is encoded in a data structure called a Merkle-Sum Sparse Merkle Tree (MS-SMT). This combines two properties that matter for token systems:
- Sparse Merkle Tree: a 256-level key-value store where leaf positions correspond to hash digests. This supports efficient proofs of both inclusion (this asset exists) and non-inclusion (this asset does not exist in the tree).
- Merkle Sum Tree: each leaf carries a numeric value (the token amount), and every internal node holds the cumulative sum of its children. The root encodes the total supply, letting anyone verify that no tokens were created or destroyed during a transfer.
Multiple distinct assets can occupy a single Bitcoin UTXO, each in its own MS-SMT leaf. The on-chain footprint remains a single hash commitment regardless of how many assets are packed inside.
Off-Chain Proof Storage: Universes
To avoid bloating the blockchain, Taproot Assets stores transfer proofs and witness data off-chain. Participants in asset transfers bear the cost of verification and storage rather than pushing data to every Bitcoin node.
A Universe is a server that indexes off-chain asset data and serves proofs to holders. It functions like a block explorer for Taproot Assets. Universes have no special protocol privileges: all data they serve can be independently validated against Bitcoin's blockchain. Issuers or third parties can run Universe servers, and multiple servers can federate in "Multiverse" mode for redundancy.
Each proof chain traces an asset from its genesis output through every subsequent transfer, demonstrating at each step that the MS-SMT was updated correctly and supply was conserved. This is a form of client-side validation: rather than every node verifying every asset, only the parties involved in a transaction need to verify the proof chain relevant to them.
Proof growth tradeoff: Each transfer appends to the proof chain. Over many transactions, proof files grow linearly, requiring more bandwidth and storage to validate the full history from genesis. The protocol does not currently support proof pruning or compression, though this is an active area of development.
Transferring Assets On-Chain
On-chain Taproot Asset transfers work similarly to regular Bitcoin transactions. The sender constructs a virtual PSBT (defined in the bip-tap-vpsbt specification) that reassigns asset leaves in the MS-SMT. The updated tree root is committed to a new Taproot output, and a standard Bitcoin transaction is broadcast. The receiver gets a proof file showing the asset was validly transferred from the sender's tree to theirs.
From the perspective of Bitcoin's consensus layer, nothing unusual happened: it is just another Taproot spend. The asset logic lives entirely in the commitment and proof layers above.
Burning Assets
Taproot Assets includes a native burn mechanism introduced in v0.3. Burning irrevocably destroys a specified amount of tokens, reducing the total supply. The protocol returns a cryptographic burn proof confirming that the assets can no longer be spent.
This matters for stablecoin issuers doing redemptions: by provably destroying tokens and uploading the burn proofs to a public Universe, issuers can demonstrate that the circulating supply matches the reserves backing it. The burn proof data feeds into the supply commitment system introduced in v0.7, which lets anyone audit total outstanding supply via RPC.
Routing Assets Over Lightning
The most significant capability of Taproot Assets is native Lightning Network integration. Rather than building a separate routing network for each asset, the protocol uses Bitcoin as a universal routing currency. Only the first and last hops in a payment need to understand Taproot Assets. Every intermediate routing node processes the payment as ordinary HTLC-based Bitcoin.
The Edge Node Model
The payment flow works through edge nodes: Lightning routing nodes that bridge Taproot Assets users with the broader network. Here is how a payment from Alice (holding USDT) to Bob (wanting USDT) works:
- Bob generates a Lightning invoice denominated in the Taproot Asset (USDT). His edge node uses the RFQ protocol to get a time-limited price quote for converting between USDT and BTC.
- Alice's wallet sends the payment. Her edge node converts the Taproot Asset (USDT) into a BTC-denominated HTLC based on its own RFQ quote.
- The payment routes through the Lightning Network as a standard Bitcoin payment. No intermediate node knows or cares that the payment originated from or will settle into a Taproot Asset.
- Bob's edge node receives the BTC and converts it back into the Taproot Asset (USDT), crediting Bob's asset channel.
The entire flow is atomic: either all legs complete, or none do. The RFQ quote is cryptographically signed by the edge node and embedded in the invoice, indistinguishable from a normal BOLT 11 invoice.
Why this design matters: By reusing Bitcoin as the routing currency, Taproot Assets avoids the liquidity fragmentation that would occur if each asset needed its own routing channels. The entire existing Lightning Network's liquidity and routing infrastructure is available on day one.
Taproot Assets Channels
Taproot Assets channels are Lightning payment channels that can hold both BTC and one or more Taproot Assets simultaneously in the same UTXO. This means opening an asset channel does not consume additional on-chain resources beyond what a regular Lightning channel requires. The channel funding transaction is a standard Taproot output with asset commitments embedded inside.
As of v0.6, receivers can use up to 20 inbound Taproot Assets channels, increasing routing options and supporting larger transactions. Version 0.7 added multi-path payment support, allowing a single payment to split across multiple channels for improved reliability.
The RFQ Protocol
The Request for Quote protocol is how asset-to-BTC conversion rates are negotiated. When a receiver creates an invoice for a Taproot Asset payment, their edge node requests a price quote from connected peers. The edge node can source this quote from its own order book (if it operates an exchange) or from external exchange APIs.
Quotes are time-limited to protect both parties from price volatility. Edge nodes compete with each other on fees, creating a decentralized foreign exchange market embedded within the Lightning Network. Any Lightning node running the litd bundle (which packages lnd and tapd together) can operate as an edge node.
Comparison to Other Bitcoin Token Standards
Taproot Assets is not the only way to issue tokens on Bitcoin. Four major approaches exist today, each with fundamentally different design philosophies. Understanding the tradeoffs is important for builders choosing a token layer.
| Feature | Taproot Assets | RGB | Runes | BRC-20 |
|---|---|---|---|---|
| Data storage | Off-chain (MS-SMT committed on-chain) | Off-chain (client-side validated) | On-chain (OP_RETURN) | On-chain (witness field) |
| On-chain footprint | Minimal (single hash per tx) | Minimal (single commitment) | Moderate (80-byte OP_RETURN) | Heavy (full JSON in witness) |
| Lightning support | Native (live since v0.4) | Planned (in development) | Theoretically possible | None |
| UTXO model | Yes | Yes | Yes | No (account-based) |
| Smart contracts | Limited (TAP VM) | Full (Turing-complete AluVM) | None | None |
| Issuance model | Issuer-controlled | Issuer-controlled | Open (anyone can etch) | Open (anyone can deploy) |
| Privacy | Transfers indistinguishable from regular Taproot txs | High (zk-STARK support in v0.12) | Visible on-chain | Visible on-chain |
| Maturity | Production (v0.8, USDT live) | Mainnet alpha (v0.12) | Production (live since April 2024) | Production (live since March 2023) |
Taproot Assets vs. RGB
RGB is the closest architectural cousin to Taproot Assets. Both use client-side validation to keep data off-chain. Both commit only a hash to Bitcoin's blockchain. Both aim for Lightning integration.
The differences are in scope and backing. RGB is a full smart contract platform with its own Turing-complete virtual machine (AluVM), schema system, and contract state management. It aims to be the programmable layer for Bitcoin. Taproot Assets is narrower in scope: it focuses on token issuance and transfer, with a simpler virtual machine (TAP VM) oriented around asset locking and unlocking.
RGB's development has been largely community-driven, reaching v0.12 on mainnet with zk-STARK support. Tether announced plans to launch USDT on RGB as well, signaling that both protocols may coexist. Taproot Assets has the advantage of production Lightning integration today and institutional backing from Lightning Labs.
Taproot Assets vs. Runes
Runes, created by Casey Rodarmor (also the creator of Ordinals), launched at Bitcoin's fourth halving in April 2024. Runes store token data in OP_RETURN outputs and use a UTXO model, making them cleaner than BRC-20 but still fully on-chain.
Runes saw explosive initial adoption: within hours of launch, Runes transactions consumed over 90% of Bitcoin network fees. By early 2026, that figure had dropped below 2% of daily transactions. The protocol added "agents" in March 2025 for interactive transaction construction, with plans for on-chain AMMs.
The core distinction: Runes are designed for permissionless, community-driven token launches entirely on-chain. Taproot Assets is designed for issuer-controlled tokens (stablecoins, regulated assets) that need to move at Lightning speed.
Taproot Assets vs. BRC-20
BRC-20 tokens use JSON inscriptions in Bitcoin's witness field, inheriting the Ordinals framework. They are the simplest approach: anyone can deploy a token by inscribing a JSON object. The cost is high on-chain footprint, no Lightning compatibility, and an account-based model that conflicts with Bitcoin's UTXO design.
BRC-20 requires two transactions for deployment and minting and three for transfers. Runes improved on this by requiring only one transaction for all operations. Taproot Assets goes further by moving most data off-chain entirely.
Stablecoins on Lightning
The most immediate real-world application of Taproot Assets is stablecoins. When Tether announced USDT on Bitcoin and Lightning in January 2025, it marked a shift: stablecoins, which had primarily lived on Ethereum, Tron, and Solana, were coming to Bitcoin's network.
The implications for payments are significant. Lightning already provides instant settlement and sub-cent fees. Adding stablecoins means merchants and users can transact in dollar-denominated value without exposure to bitcoin price volatility, while still benefiting from Lightning's speed and global reach.
| Stablecoin use case | Traditional rails | Taproot Assets on Lightning |
|---|---|---|
| Cross-border remittance | 1 to 3 business days, 5 to 7% fees | Seconds, sub-cent routing fees |
| Merchant payment | T+1 to T+3 settlement, 2 to 3% interchange | Instant finality, edge node spread only |
| Micropayment | Not economically viable below $1 | Viable at sub-cent amounts |
| Dollar savings (emerging markets) | Requires bank account, limited access | Self-custodial, accessible with a phone |
Several assets are already live in the Taproot Assets ecosystem: USDT and USDC as bridged USD stablecoins, DePix (a Brazilian real stablecoin), and GBP-denominated tokens. The ecosystem is building toward a world where Lightning functions as a decentralized FX network, with edge nodes competing to offer the best conversion rates between any two assets.
Current Adoption
Taproot Assets adoption centers around a growing ecosystem of wallets, SDKs, and edge node operators. Lightning Labs provides the reference implementation through the taproot-assets daemon (tapd), written in Go, and the litd bundle that packages lnd and tapd into a single binary.
Wallets and Applications
Speed Wallet was among the first to integrate USDT on Lightning, enabling users to send and receive stablecoins through Lightning Addresses. Tiramisu Wallet provides a web interface for interacting with Taproot Assets without running a full node. Other ecosystem participants include Joltz (rewards and DeFi bridging), LnFi Network (SDK tooling), and UXUY (multi-asset wallet). The ecosystem also spans asset explorers, Nostr integrations, and developer tools.
Edge Node Operations
Any Lightning node running litd can become an edge node. Edge nodes earn fees by facilitating asset-to-BTC conversions at the network boundary. As more edge nodes come online, competition drives down spreads, improving the economics for end users. This creates a natural incentive structure: edge nodes earn revenue, users get better rates, and the network becomes more liquid over time.
Protocol Specifications
Lightning Labs has submitted seven draft BIPs covering the core protocol. These remain in draft status as of mid-2026:
- bip-tap: core validation and state transition rules
- bip-tap-mssmt: Merkle-Sum Sparse Merkle Tree data structure
- bip-tap-addr: Bech32m address format for asset sends and receives
- bip-tap-vm: off-chain virtual machine for asset locking and unlocking
- bip-tap-vpsbt: virtual PSBT types for asset transactions
- bip-tap-proof-file: flat file format for proving asset provenance
- bip-tap-universe: Universe server construct for off-chain data indexing
The specifications build on BIP 341 (Taproot) and use Schnorr signatures for transfer authorization. All asset transfers use TLV (type-length-value) encoding, consistent with Lightning's own message format.
Limitations and Risks
Off-Chain Data Availability
Taproot Assets depends on Universe servers to store and serve proof data. If an issuer's Universe goes offline and no mirrors exist, holders may lose the ability to verify or transfer their assets. Multiverse federation mitigates this, but the protocol does not yet match the data availability guarantees of fully on-chain approaches.
Centralized Issuance
Unlike Runes or BRC-20, where anyone can mint tokens, Taproot Assets issuance is controlled by the asset creator. This is appropriate for regulated stablecoins but means the protocol is less suited for permissionless, community-driven launches.
Channel Liquidity Requirements
Routing Taproot Assets over Lightning still requires the same channel liquidity management that makes Lightning operationally complex. Edge nodes need sufficient BTC liquidity to facilitate conversions, and the economics depend on competitive RFQ markets developing. Receiving large asset payments requires multiple inbound channels (up to 20 as of v0.6).
Proof Chain Growth
Every transfer adds to an asset's proof chain. For high-velocity assets like stablecoins, this can become a storage and bandwidth burden. The community is exploring proof compression, but no production solution exists yet.
Taproot Assets and Spark
Taproot Assets and Spark represent complementary approaches to bringing tokens to Bitcoin. Both support stablecoins. Both enable instant transfers. But they make different architectural choices.
Taproot Assets inherits Lightning's channel-based model: users need payment channels, edge nodes must manage BTC liquidity, and the RFQ market introduces conversion spreads. Spark's statechain architecture eliminates channels entirely. Stablecoins like USDB exist natively on Spark without requiring liquidity management or edge node conversions. Users hold and transfer tokens directly, with FROST threshold signatures securing custody.
For developers building stablecoin payment products, both paths are viable. Taproot Assets plugs into the existing Lightning Network's massive routing infrastructure. Spark offers simpler UX with no channel overhead. The Spark SDK provides a straightforward integration path for wallets and applications, including native support for Lightning interoperability. For a deeper comparison of Bitcoin scaling approaches, see the Bitcoin Layer 2 comparison.
What Comes Next
Taproot Assets has crossed the threshold from experimental protocol to production infrastructure. USDT is live on Lightning. Edge nodes are competing on conversion rates. The v0.7 release added auditable supply and reusable addresses, the features stablecoin issuers need to operate at scale.
The open questions are about ecosystem growth: will enough edge nodes come online to create deep, competitive FX markets? Will proof chain growth become a bottleneck before compression solutions arrive? Will RGB's parallel development fragment the Bitcoin token ecosystem, or will both protocols find distinct niches?
What is clear is that Bitcoin is no longer a single-asset network. Between Taproot Assets, RGB, Runes, and statechain-based approaches like Spark, the infrastructure for multi-asset Bitcoin is being built in real time. The question is not whether tokens will flow over Bitcoin rails, but which combination of protocols will carry the most volume.
This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.

