Five Minutes to Understand Taro: A Multi-Asset Protocol for Bitcoin and the Lightning Network

Author: Sato Xi, The Way of DeFi

Since the activation of the Taproot upgrade in November last year, there seems to have been little news of new technological solutions in Bitcoin. Looking across the entire DeFi space, the TVL of the Lightning Network (which is insignificant among various protocols due to reasons such as lack of incentives) raises the question: could this situation change?

（Image: Changes in the TVL of the Lightning Network, data from https://defillama.com/chain/Bitcoin）

Today, Lightning Labs, the developer of the Lightning Network, announced the completion of a $70 million Series B funding round. Additionally, they announced a protocol called Taro for issuing assets (such as stablecoins) on the Bitcoin blockchain. It is reported that using this protocol, users can also conduct instant, high-volume, low-fee transactions via the Lightning Network.

Conceptually, Taro is somewhat similar to early colored coins. We know that USDT was originally issued as a stablecoin asset through the Omni colored coin protocol, but due to the slow settlement and high fees of the Bitcoin network, the share of USDT on Bitcoin has been decreasing (Note: specific data can be referenced at https://tether.to/en/transparency).

The difference is that Taro relies on Bitcoin's latest upgrade, Taproot, to build a new tree structure that allows developers to embed arbitrary asset metadata in existing outputs. It uses Schnorr signatures to enhance simplicity and scalability, and importantly, it can be used with multi-hop transactions on the Lightning Network. To this end, Lightning Labs has also released a series of Bitcoin Improvement Proposals (BIPs) regarding the Taro protocol to solicit feedback and opinions from the developer community. You can learn more and read the complete Taro specification on GitHub.

Components of the Taro Protocol

To understand the Taro protocol, we first need to be familiar with several concepts in Bitcoin, such as public key cryptography, cryptographic hashes, Merkle trees, Bitcoin UTXOs, and Taproot.

Taro utilizes a combination of Taproot, taptweak, Sparse Merkle Trees (SMT), and Merkle Sum Trees to issue Bitcoin-native assets. Among these, Sparse Merkle Trees (SMT) and Merkle Sum Trees combine to form Sparse Merkle Sum Trees (MS-SMT).

(Note: For explanations of new concepts like taptweak, interested readers can refer to Lightning Labs' documentation.)

The root of this MS-SMT tree is added to a Taproot script, creating a Taproot address.

Taro issuers do not use their own blockchain but store the MS-SMT tree off-chain and issue proofs to asset holders. These asset owners can independently verify whether their accounts are included in the tree, whether the appropriate amounts are filled in, whether the corresponding Taproot transactions exist, and whether they have been confirmed on the Bitcoin blockchain.

To issue Taro assets, we must first create its identifier, which is a 32-byte asset ID generated by hashing three elements: (1) the outpoint used to mint the asset, (2) the asset label chosen by the issuer (such as a hash of the brand name), and (3) metadata related to the asset (such as links, images, or documents).

Once the issuer publishes the transaction and it is confirmed on the Bitcoin blockchain, the asset is created irreversibly. To observers, this transaction looks like any other standard Taproot transaction.

After issuance, Taro assets can move on the Bitcoin main chain or be transferred via the Lightning Network.

Note: A Taro address is a bech32 encoded identifier of the asset ID, asset script hash, internal key of the MS-SMT tree, and amount, with the prefix Taro or Tarot (testnet).

Multi-hop Taro Transfers

For the Taro protocol, multi-hop payments on the Lightning Network are a very important feature.

Historically, payment networks have faced a bootstrap problem (whenever a new asset is created, a brand new payment network needs to be established to meet the payment needs of that specific asset). Taro adopts a payment routing model in which the Lightning Network can serve any asset and overcome this bootstrap problem.

Let’s understand the principle through an example:

Imagine that Alice and Bob have a Lightning Network USD (L-USD) channel with a capacity of $100. After balancing, they both have $50 worth of incoming liquidity. Carol and Dave also have a $100 L-USD channel, and after balancing, they too have $50 worth of incoming liquidity.

Image: Example of multi-hop Taro transfers

If Bob and Carol only have a BTC channel, Alice can still send $10 of L-USD to Bob, who collects a small routing fee in BTC and forwards the $10 in BTC to Carol, who collects a small routing fee in L-USD and forwards $10 of L-USD to the final destination—Dave.

This structure leverages the current network effects and liquidity of the Lightning Network to route transfers of any amount of assets, avoiding the need to launch a brand new network for new assets, and ensuring that all transactions on the network are supported by Bitcoin. It also incentivizes the growth of BTC liquidity in the Lightning Network to serve a broader multi-asset Lightning Network.

Conclusion

For more in-depth technical details about the Taro protocol, you can refer to the BIPs. In short, the main benefits of this Taproot-native design include:

1. Scalability: A single Taproot output can contain an essentially unlimited number of Taro assets;
2. Programmability: Taro assets have an unlock script similar to ordinary Bitcoin UTXOs, allowing developers to program transfer conditions into the asset;
3. Auditability: Taro uses a special tree structure that allows for effective supply audits of issued assets;
4. Usability: Asset-specific addresses make wallets smart enough to prevent users from mistakenly sending the wrong assets.

However, due to the lack of token incentives, the Taro protocol may still face challenges in scaling up. Do you think Lightning Labs will choose to issue a token?