Taro, a new protocol proposed by Lightning Labs, leverages Taproot and the Lightning Network to bring new assets and scalability to Bitcoin.
Lightning Labs has introduced a new protocol proposal for Bitcoin and the Lightning Network, Taro, which seeks to bring new use cases to the network. The company has published a series of draft Bitcoin Improvement Proposals (BIPs) and it is asking for community feedback on the proposed design.
Taro seeks to enable the issuance of assets and collectibles, which are the protocol’s form of non-fungible assets, on Bitcoin as well as their transfer on Lightning in a private and secure manner without bloating the blockchain. To do so, it plans to leverage the protocol’s latest upgrade, Taproot.
“The design principles of Taro on Lightning draw from that of the internet, where you have complexity at the edges, but you keep the simplicity in between,” Elizabeth Stark, Lightning Labs CEO, told Bitcoin Magazine.
Most existing ways to issue and use assets on Bitcoin today either leverage another blockchain entirely, which adds a new trust model with different security assurances, or rely on adding extra data directly on-chain, which is inefficient for keeping track of asset information long term and is dangerous to user privacy.
Instead, Taro uses Taproot.
Taproot allows complex spending conditions to be set for a Bitcoin UTXO while ensuring that only the condition that ultimately gets used to spend the coin is revealed on-chain to all Bitcoin users. As a result, such a spend is more private, because a passive observer can’t tell if there were other spending conditions for that transaction; and more scalable, because now that complex scheme puts considerably less data on chain. This is meaningful because previous programmatic behaviors in Bitcoin meant transactions had to be revealed in their entirety whenever they were spent, hurting user privacy and making very complex schemes unfeasible due to a linear growth in storage needs.
By using Taproot, Taro can also rely on Bitcoin’s proof-of-work (PoW) consensus mechanism for ensuring the correct ordering of transactions and preventing double spends, while defining special directives as to how to interact with and validate the new asset data.
As a result, Taro also differs from other asset solutions on “highly programmable” blockchains, such as Ethereum’s ERC-20 and ERC-721 tokens, because it is based on Bitcoin’s UTXO model instead of an account model, meaning that it is both more secure due to avoidance of key reuse and more private as there isn’t information about balances revealed. Taro’s approach is also more scalable and is compatible with light clients.
More specifically, Taro brings assets to Bitcoin through the “leaves” of the Taproot script tree, as each leaf in the tree is completely independent and can be selectively revealed — which enables structured commitment. By adding information about those assets (known as metadata) in the Taproot script tree, the proposed protocol can function as a layer built on top of Bitcoin, allowing Taro asset transactions to look like regular Bitcoin transactions, as on-chain only the Taproot output is revealed, while still enabling proofs of the movement of assets across the transaction graph.
“This is pretty elegant because it lets you separate these asset commitments from the actual script itself,” Lightning Labs CTO, Olaoluwa Osuntokun, told Bitcoin Magazine. “Taproot, in this case, allows us to logically separate what is the main Bitcoin scripting layer from the asset layer itself. Even though they’re actually within the same output, because the Bitcoin layer doesn’t care about what isn’t revealed, we can use that to have additional structured data.”
As a result, this construction enables a single Taproot UTXO to effectively commit to (that is, include the hash of) an unbounded number of assets that are only revealed to the specific parties that need that information — without burdening the entire Bitcoin network.
“It makes things a little bit simpler and also makes it a lot easier for developers to understand because the overlay layer basically looks and feels like Bitcoin with some slight tweaks, additional commitments, validation, things like that,” Osuntokun said.
By leveraging Taproot for asset issuance and transfer, Taro effectively enables new functionality at the edges of Bitcoin by leveraging bitcoin liquidity as the asset gets routed through the Lightning Network, all without adding unnecessary data on chain.
“If people are doing more transactions at the edges using these assets, well, that means we actually need more capacity in the Lightning Network itself,” Osuntokun said. “Demand for assets at the edges, as far as structural capacity, then translate into increased productive activity on the network and more routing fees, so a greater network effect as well.”
As a result, Taro can take one step in the direction of increasing the demand for blockspace on chain, helping ensure that Bitcoin can keep sustainable once miners begin being paid only through transaction fees as the block subsidy nears zero in the next century.
Taro leverages a data structure known as a Merkle-Sum Sparse Merkle tree (MS-SMT) to enable assets to commit to Taproot script trees, acting as an overlay protocol. MS-SMT joins together properties of a regular Merkle tree, a Merkle-Sum tree, and a Sparse Merkle tree.
A Merkle tree is constructed by hashing a list of items’ hashes in pairs until we arrive at a single hash, called the root hash. For example, in a list of four items, we would first separately hash each item. Next, we would join the hashes of items one and two together and hash that concatenation, and do the same with the hashes of three and four. Lastly, we would hash the remaining two hashes to determine the root hash.
A Merkle tree is useful because it can store lots of data, it makes it easy to prove that some data exists in the tree, and it also allows us to check that data hasn’t been tampered with. In other words, a regular Merkle tree enables scalability, proof of membership and tamper resistance.
Moreover, we only need to store the root hash of the Merkle tree on chain to verify such properties. That’s because if the data in one leaf is tampered with, for example, its hash would also change, further changing all of the hashes at levels above it which would lastly change the root hash — which can have its change attested through comparison to the stored version.
The Merkle-Sum tree takes this one step further by allowing us to commit to the sum of all leaf values, meaning its root hash can also include information about the sum of the values of each leaf in the tree. In the context of assets, this property enables an asset’s supply to be more easily audited, as well as allowing the divisibility of the asset and preventing undesired issuance of new assets in transactions that are only supposed to transfer them. In our fictitious Merkle tree above, if each leaf held a value of one, the root hash would hold a value of four.
The Sparse Merkle tree adds yet another property. All of its leaves are indexed, allowing access to information on the tree in a key-value pair fashion, and it has empty leaves, which actually hold the “null” value, allowing us to check if some data is not in the tree. This property, known as proof of non-membership, is possible by proving membership of null in a given leaf which can be accessed through its index. For example, if there is a claim that the leaf with index six stores some information about an asset, we can prove that such information is not there by attesting that that leaf actually holds a value “null.”
Taro represents assets with nested MS-SMTs, one for each asset ID or asset type. The protocol enables those trees to be layered on top of each other, branching out of the initial Taproot script tree to represent an effectively unlimited number of assets in a single Taproot UTXO. Taro assets are therefore issued on chain.
At the basis of asset functionality on Taro is an asset script, a set of directives established by a developer to programmatically define how a given asset can be transferred on the protocol. The hash of that script is then included in the MS-SMT so it can be easily enforced later on — thereby making the asset and its attributes commit to the asset script hash.
The initial version of Taro proposes the use of a subset of Bitcoin Script, allowing assets to express arbitrary conditions for the valid transfer of an asset. As asset scripts inherit a level of programmability on par with Bitcoin Script, Taro assets can be transferred over Lightning in multi-hop transactions off-chain through hash time locked contracts (HTLCs) embedded in the asset script. However, future versions could introduce new opcodes and extra functionality that would only exist at the Taro level.
“Doing Taproot-within-Taproot makes the initial version simpler and gives us more time to figure out what use cases pop up and desire more expressivity,” Osuntokun said.
For on-chain transfers, Taro leverages a new address format based on bech32 that also includes the asset script hash. To receive a Taro asset on chain, the receiver would need to create an address with enough data that details how the sender can construct a new asset script group that contains the information needed to spend the asset once it is transferred over to the new owner. In other words, the extra information, in the asset script hash, tells the receiver what the unlocking capability is for the asset that is being transferred, so that it can eventually be transferred again.
Since the receiver has all of that information, they can compute the asset leaf, which then lets them compute the asset root, and finally the entire output itself, letting them watch the Bitcoin blockchain for the result they computed.
Additionally, by having the receiver send that defining information beforehand, the only way the sender can make the transaction valid is if they send exactly what the receiver is expecting. If the wrong asset or the wrong amount is sent, the hashes won’t match and the receiver can easily tell that the sender did something wrong.
The issuance and transfer of assets in Taro vary, depending on whether the asset is a regular one or a collectible.
A collectible, or non-fungible asset, is a one-of-a-kind representation of value, with a unique identifier that establishes a claim on an asset at the Bitcoin chain level or at the real-world level and makes it impossible to counterfeit ownership. A collectible on Taro could be a tokenized rare baseball card, for example. Collectibles are created in a single batch transaction, cannot be split or merged, and need to be transferred off-chain or put into a multiparty channel to be transferred among a known set of participants.
A regular asset, on the other hand, commits to a total value of held assets and can be split and merged. Splits can happen within a tree, configuring an internal split, or across different Taproot outputs, configuring an external split. During transfer, the asset holder proves they hold a valid split with a Merkle-Sum proof and the corresponding created assets commit to a new Merkle-Sum output split that ensures the total amount of assets after transfer equals the total amount there was before the transaction.
As mentioned earlier, Taro can port assets issued on-chain onto the Lightning Network, similar to how bitcoin can be sent through Lightning after being locked up in a two-of-two multisignature output that gets confirmed on the Bitcoin blockchain. A Lightning channel holding Taro assets leverages the same flow, however the two-of-two Schnorr Taproot output would also commit to the set of assets in the channel.
“Using the Taro protocol, Lightning channels anchored with a Taproot output are able to send both bitcoin and Taro assets off-chain, with multi-hop payments being facilitated by new HTLCs on the Taro level, which use the scripting system to implement the expected end-to-end payment security guarantees,” Osuntokun told Bitcoin Magazine.
Osuntokun added that Lightning Labs’ proposed deployment path for Taro on the Lightning Network seeks to first only introduce assets at the edges, meaning it would avoid both having to modify the core of the network and bootstrap a new network with adequate liquidity for each Taro asset. Rather, the company’s plans would have Taro plug into bitcoin liquidity on Lightning and require only the sender and receiver of a given asset to use Taro-aware channels.
“The only constraint is that in order to receive/send using a particular asset, corresponding inbound/outbound liquidity is required,” Osuntokun said.
In addition to the similar Lightning on-ramp setup, multi-hop transfers of Taro assets over Lightning would leverage a similar invoicing system that is commonplace on the second layer today. However, instead of denominating the invoice in BTC, the invoice would be denominated in the Taro asset itself.
“As an example, if Alice wants to send Bob a Taro stablecoin asset, she’ll create a new invoice that quotes, say, $10,” Osuntokun said. “Bob will then use a ‘hop hint,’ which are extra routing details provided in the invoice to complete the route and calculate the amount of network fees (paid in bitcoin) to send over his first hop, which will traverse the internal Bitcoin backbone and eventually drop off enough BTC at the final hop to complete the payment.”
The Taro protocol will specify the extra information that needs to be sent to the Lightning peers at the edges in order to update all channels properly, he added.
Taro seeks to leverage Bitcoin’s latest soft fork upgrade to bring assets with real-word use cases like U.S. dollar stablecoins onto the peer-to-peer (P2P) digital currency stack. It enables the issuance of a nearly unlimited number of assets with a single Taproot UTXO, as well as the transfer of such assets with instant, low-fee multi-hop transactions on Lightning.
By leveraging Bitcoin and Lightning as its rails, Taro could establish an interoperable ecosystem of assets that can unite different use cases while not affecting parties that may not care about such assets. At the same time, the protocol also contributes back to Bitcoin by increasing its network effects in the event that a popularization of the concept drives traffic on the network, thereby increasing the fee payout to miners and ramping up BTC liquidity on the Lightning Network.
Though its initial iteration accommodates a limited number of use cases, in an attempt to make the jump onto the new protocol easier for developers through a familiar Bitcoin scripting suite, the possibilities of extensions and further developments are nearly endless, as builders and entrepreneurs get creative and spin the protocol to suit their needs.
“The hope is to open up people’s eyes to what the future of Bitcoin holds and what Taproot can enable,” Stark told Bitcoin Magazine. “The goal is to have Bitcoin be the underlying global monetary network powered by open protocols.”
Lightning Labs has introduced a new protocol proposal for Bitcoin and the Lightning Network, Taro, which seeks to bring new use cases to the network. The company has published a series of draft Bitcoin Improvement Proposals (BIPs) and it is asking for community feedback on the proposed design.
Taro seeks to enable the issuance of assets and collectibles, which are the protocol’s form of non-fungible assets, on Bitcoin as well as their transfer on Lightning in a private and secure manner without bloating the blockchain. To do so, it plans to leverage the protocol’s latest upgrade, Taproot.
“The design principles of Taro on Lightning draw from that of the internet, where you have complexity at the edges, but you keep the simplicity in between,” Elizabeth Stark, Lightning Labs CEO, told Bitcoin Magazine.
Most existing ways to issue and use assets on Bitcoin today either leverage another blockchain entirely, which adds a new trust model with different security assurances, or rely on adding extra data directly on-chain, which is inefficient for keeping track of asset information long term and is dangerous to user privacy.
Instead, Taro uses Taproot.
Taproot allows complex spending conditions to be set for a Bitcoin UTXO while ensuring that only the condition that ultimately gets used to spend the coin is revealed on-chain to all Bitcoin users. As a result, such a spend is more private, because a passive observer can’t tell if there were other spending conditions for that transaction; and more scalable, because now that complex scheme puts considerably less data on chain. This is meaningful because previous programmatic behaviors in Bitcoin meant transactions had to be revealed in their entirety whenever they were spent, hurting user privacy and making very complex schemes unfeasible due to a linear growth in storage needs.
By using Taproot, Taro can also rely on Bitcoin’s proof-of-work (PoW) consensus mechanism for ensuring the correct ordering of transactions and preventing double spends, while defining special directives as to how to interact with and validate the new asset data.
As a result, Taro also differs from other asset solutions on “highly programmable” blockchains, such as Ethereum’s ERC-20 and ERC-721 tokens, because it is based on Bitcoin’s UTXO model instead of an account model, meaning that it is both more secure due to avoidance of key reuse and more private as there isn’t information about balances revealed. Taro’s approach is also more scalable and is compatible with light clients.
More specifically, Taro brings assets to Bitcoin through the “leaves” of the Taproot script tree, as each leaf in the tree is completely independent and can be selectively revealed — which enables structured commitment. By adding information about those assets (known as metadata) in the Taproot script tree, the proposed protocol can function as a layer built on top of Bitcoin, allowing Taro asset transactions to look like regular Bitcoin transactions, as on-chain only the Taproot output is revealed, while still enabling proofs of the movement of assets across the transaction graph.
“This is pretty elegant because it lets you separate these asset commitments from the actual script itself,” Lightning Labs CTO, Olaoluwa Osuntokun, told Bitcoin Magazine. “Taproot, in this case, allows us to logically separate what is the main Bitcoin scripting layer from the asset layer itself. Even though they’re actually within the same output, because the Bitcoin layer doesn’t care about what isn’t revealed, we can use that to have additional structured data.”
As a result, this construction enables a single Taproot UTXO to effectively commit to (that is, include the hash of) an unbounded number of assets that are only revealed to the specific parties that need that information — without burdening the entire Bitcoin network.
“It makes things a little bit simpler and also makes it a lot easier for developers to understand because the overlay layer basically looks and feels like Bitcoin with some slight tweaks, additional commitments, validation, things like that,” Osuntokun said.
By leveraging Taproot for asset issuance and transfer, Taro effectively enables new functionality at the edges of Bitcoin by leveraging bitcoin liquidity as the asset gets routed through the Lightning Network, all without adding unnecessary data on chain.
“If people are doing more transactions at the edges using these assets, well, that means we actually need more capacity in the Lightning Network itself,” Osuntokun said. “Demand for assets at the edges, as far as structural capacity, then translate into increased productive activity on the network and more routing fees, so a greater network effect as well.”
As a result, Taro can take one step in the direction of increasing the demand for blockspace on chain, helping ensure that Bitcoin can keep sustainable once miners begin being paid only through transaction fees as the block subsidy nears zero in the next century.
Taro leverages a data structure known as a Merkle-Sum Sparse Merkle tree (MS-SMT) to enable assets to commit to Taproot script trees, acting as an overlay protocol. MS-SMT joins together properties of a regular Merkle tree, a Merkle-Sum tree, and a Sparse Merkle tree.
A Merkle tree is constructed by hashing a list of items’ hashes in pairs until we arrive at a single hash, called the root hash. For example, in a list of four items, we would first separately hash each item. Next, we would join the hashes of items one and two together and hash that concatenation, and do the same with the hashes of three and four. Lastly, we would hash the remaining two hashes to determine the root hash.
A Merkle tree is useful because it can store lots of data, it makes it easy to prove that some data exists in the tree, and it also allows us to check that data hasn’t been tampered with. In other words, a regular Merkle tree enables scalability, proof of membership and tamper resistance.
Moreover, we only need to store the root hash of the Merkle tree on chain to verify such properties. That’s because if the data in one leaf is tampered with, for example, its hash would also change, further changing all of the hashes at levels above it which would lastly change the root hash — which can have its change attested through comparison to the stored version.
The Merkle-Sum tree takes this one step further by allowing us to commit to the sum of all leaf values, meaning its root hash can also include information about the sum of the values of each leaf in the tree. In the context of assets, this property enables an asset’s supply to be more easily audited, as well as allowing the divisibility of the asset and preventing undesired issuance of new assets in transactions that are only supposed to transfer them. In our fictitious Merkle tree above, if each leaf held a value of one, the root hash would hold a value of four.
The Sparse Merkle tree adds yet another property. All of its leaves are indexed, allowing access to information on the tree in a key-value pair fashion, and it has empty leaves, which actually hold the “null” value, allowing us to check if some data is not in the tree. This property, known as proof of non-membership, is possible by proving membership of null in a given leaf which can be accessed through its index. For example, if there is a claim that the leaf with index six stores some information about an asset, we can prove that such information is not there by attesting that that leaf actually holds a value “null.”
Taro represents assets with nested MS-SMTs, one for each asset ID or asset type. The protocol enables those trees to be layered on top of each other, branching out of the initial Taproot script tree to represent an effectively unlimited number of assets in a single Taproot UTXO. Taro assets are therefore issued on chain.
At the basis of asset functionality on Taro is an asset script, a set of directives established by a developer to programmatically define how a given asset can be transferred on the protocol. The hash of that script is then included in the MS-SMT so it can be easily enforced later on — thereby making the asset and its attributes commit to the asset script hash.
The initial version of Taro proposes the use of a subset of Bitcoin Script, allowing assets to express arbitrary conditions for the valid transfer of an asset. As asset scripts inherit a level of programmability on par with Bitcoin Script, Taro assets can be transferred over Lightning in multi-hop transactions off-chain through hash time locked contracts (HTLCs) embedded in the asset script. However, future versions could introduce new opcodes and extra functionality that would only exist at the Taro level.
“Doing Taproot-within-Taproot makes the initial version simpler and gives us more time to figure out what use cases pop up and desire more expressivity,” Osuntokun said.
For on-chain transfers, Taro leverages a new address format based on bech32 that also includes the asset script hash. To receive a Taro asset on chain, the receiver would need to create an address with enough data that details how the sender can construct a new asset script group that contains the information needed to spend the asset once it is transferred over to the new owner. In other words, the extra information, in the asset script hash, tells the receiver what the unlocking capability is for the asset that is being transferred, so that it can eventually be transferred again.
Since the receiver has all of that information, they can compute the asset leaf, which then lets them compute the asset root, and finally the entire output itself, letting them watch the Bitcoin blockchain for the result they computed.
Additionally, by having the receiver send that defining information beforehand, the only way the sender can make the transaction valid is if they send exactly what the receiver is expecting. If the wrong asset or the wrong amount is sent, the hashes won’t match and the receiver can easily tell that the sender did something wrong.
The issuance and transfer of assets in Taro vary, depending on whether the asset is a regular one or a collectible.
A collectible, or non-fungible asset, is a one-of-a-kind representation of value, with a unique identifier that establishes a claim on an asset at the Bitcoin chain level or at the real-world level and makes it impossible to counterfeit ownership. A collectible on Taro could be a tokenized rare baseball card, for example. Collectibles are created in a single batch transaction, cannot be split or merged, and need to be transferred off-chain or put into a multiparty channel to be transferred among a known set of participants.
A regular asset, on the other hand, commits to a total value of held assets and can be split and merged. Splits can happen within a tree, configuring an internal split, or across different Taproot outputs, configuring an external split. During transfer, the asset holder proves they hold a valid split with a Merkle-Sum proof and the corresponding created assets commit to a new Merkle-Sum output split that ensures the total amount of assets after transfer equals the total amount there was before the transaction.
As mentioned earlier, Taro can port assets issued on-chain onto the Lightning Network, similar to how bitcoin can be sent through Lightning after being locked up in a two-of-two multisignature output that gets confirmed on the Bitcoin blockchain. A Lightning channel holding Taro assets leverages the same flow, however the two-of-two Schnorr Taproot output would also commit to the set of assets in the channel.
“Using the Taro protocol, Lightning channels anchored with a Taproot output are able to send both bitcoin and Taro assets off-chain, with multi-hop payments being facilitated by new HTLCs on the Taro level, which use the scripting system to implement the expected end-to-end payment security guarantees,” Osuntokun told Bitcoin Magazine.
Osuntokun added that Lightning Labs’ proposed deployment path for Taro on the Lightning Network seeks to first only introduce assets at the edges, meaning it would avoid both having to modify the core of the network and bootstrap a new network with adequate liquidity for each Taro asset. Rather, the company’s plans would have Taro plug into bitcoin liquidity on Lightning and require only the sender and receiver of a given asset to use Taro-aware channels.
“The only constraint is that in order to receive/send using a particular asset, corresponding inbound/outbound liquidity is required,” Osuntokun said.
In addition to the similar Lightning on-ramp setup, multi-hop transfers of Taro assets over Lightning would leverage a similar invoicing system that is commonplace on the second layer today. However, instead of denominating the invoice in BTC, the invoice would be denominated in the Taro asset itself.
“As an example, if Alice wants to send Bob a Taro stablecoin asset, she’ll create a new invoice that quotes, say, $10,” Osuntokun said. “Bob will then use a ‘hop hint,’ which are extra routing details provided in the invoice to complete the route and calculate the amount of network fees (paid in bitcoin) to send over his first hop, which will traverse the internal Bitcoin backbone and eventually drop off enough BTC at the final hop to complete the payment.”
The Taro protocol will specify the extra information that needs to be sent to the Lightning peers at the edges in order to update all channels properly, he added.
Taro seeks to leverage Bitcoin’s latest soft fork upgrade to bring assets with real-word use cases like U.S. dollar stablecoins onto the peer-to-peer (P2P) digital currency stack. It enables the issuance of a nearly unlimited number of assets with a single Taproot UTXO, as well as the transfer of such assets with instant, low-fee multi-hop transactions on Lightning.
By leveraging Bitcoin and Lightning as its rails, Taro could establish an interoperable ecosystem of assets that can unite different use cases while not affecting parties that may not care about such assets. At the same time, the protocol also contributes back to Bitcoin by increasing its network effects in the event that a popularization of the concept drives traffic on the network, thereby increasing the fee payout to miners and ramping up BTC liquidity on the Lightning Network.
Though its initial iteration accommodates a limited number of use cases, in an attempt to make the jump onto the new protocol easier for developers through a familiar Bitcoin scripting suite, the possibilities of extensions and further developments are nearly endless, as builders and entrepreneurs get creative and spin the protocol to suit their needs.
“The hope is to open up people’s eyes to what the future of Bitcoin holds and what Taproot can enable,” Stark told Bitcoin Magazine. “The goal is to have Bitcoin be the underlying global monetary network powered by open protocols.”
Feedzy
Now that Bitcoin short-term price action remains bullish, driven by US President Donald Trump’s vocal…
Crypto analyst Ash Crypto has revealed that Bitcoin has entered the ‘thrill’ phase. The analyst…
Wealth management clients of Wall Street banks like Goldman Sachs, Bank of America, Morgan Stanley…
The Bitcoin volume has experienced a severe crash amidst its initial price momentum, falling by…
Follow Mark on X. Well, well, well—if it isn't Jack Mallers dropping truth bombs like…
The user held BTC from when it was worth $0.06 all the way up to…
