One of my goals for my recent Taproot Assets workshop was to explain how Taproot Assets are added to Lightning channels and used on the Lightning Network. I spent ~45mins on it in Atlanta… but here I’ll take a shot at explaining it via Tweets.

Let’s start with how assets are embedded in UTXO’s. You can think of Taproot Assets as “living in UTXO’s”.

Taproot Assets live in a data structure that is essentially a set of Merkle trees... Merkle Sum Sparse Merkle Trees to be specific. The root of that tree is included in the tapscript tree, which is then included in a regular Taproot transaction via taptweak.

Let’s imagine that Alice is minting AliceBux by creating an onchain transaction that includes that asset data in a set of Merkle Sum Sparse Merkle Trees. This graphic provides a stylized picture of what’s happening.

Reply to this note

Please Login to reply.

Discussion

So then, we can imagine that Alice wants to open an asset channel to Bob. Alice funds the channel with a transaction where she uses as an input the UTXO that currently holds her AliceBux.

After the channel opening the Merkle trees that hold that asset data are now “living” in the new UTXO for the Lightning channel.

Currently this will be an unannounced simple Taproot Lightning channel that does contain sats. Taproot Assets is an entirely opt-in protocol. Both the Bitcoin network and the Lightning network don’t need to know anything about Taproot Assets. As such we still need sats to open/close channels, and for use in the HTLC’s in Lightning transactions.

So now we have a situation where Alice and Bob have a Lightning channel that contains some sats, but also holds Taproot Assets as that asset data was included in the UTXO that opens the channel.

So now let’s try to visualize what’s happening as Alice and Bob transact with each other and update their channel balance. Here we’ll use two pretty pictures!

Let’s imagine that Alice opened the channel adding 1000 AliceBux to the channel. For their first transaction in the channel, Alice sends Bob 100 AliceBux. As with a normal Lightning channel, this channel update requires both parties to sign a new potential settlement transaction that reflects their new balance. Both Alice and Bob sign a transaction, that could be broadcast to chain, that gives Alice 900 AliceBux and gives Bob 100 AliceBux. If this transaction were broadcast onchain it would essentially be a Taproot Assets on-chain split transaction.

The UTXO holding the 1000 AliceBux would be consumed and two new UTXO’s would be created. One that has the Merkle tree data that holds 900 AliceBux and one that holds the Merkle tree data that hold 100 AliceBux.

Now let’s zoom out and look at what this means for the Lightning Network at large. What does a multi-asset Lightning Network look like??

First lets picture an Edge Node. This is a node that connects asset channels to the larger network and facilitates transactions between sats and assets.

[Price oracles and the RFQ process will get saved for another thread.]

Now let’s imagine that Alice has a USD stablecoin in an asset channel and wants to transact with Bob who has another asset channel on the other side of the Network. This could be any kind of asset as long as the Edge Node that Bob is connected to is willing to transact with both sats and that asset. That transaction might look a bit like this…

https://m.primal.net/LmFA.mp4