Hi Johan, I haven't really been able to find a precise technical explanation of the "utxo teleport" scheme, but after thinking about your example use cases a bit, I don't think the scheme is actually sound. Consider that the scheme attempts to target transmitting "ownership" to a UTXO. However, by the time that transaction hits the chain, the UTXO may no longer exist. At that point, what happens to the asset? Is it burned? Can you retry it again? Does it go back to the sender? As a concrete example, imagine I have a channel open, and give you an address to "teleport" some additional assets to it. You take that addr, then make a transaction to commit to the transfer. However, the block before you commit to the transfer, my channel closes for w/e reason. As a result, when the transaction committing to the UTXO (blinded or not), hits the chain, the UTXO no longer exists. Alternatively, imagine the things happen in the expected order, but then a re-org occurs, and my channel close is mined in a block before the transfer. Ultimately, as a normal Bitcoin transaction isn't used as a serialization point, the scheme seems to lack a necessary total ordering to ensure safety. If we look at Taro's state transition model in contrast, everything is fully bound to a single synchronization point: a normal Bitcoin transaction with inputs consumed and outputs created. All transfers, just like Bitcoin transactions, end up consuming assets from the set of inputs, and re-creating them with a different distribution with the set of outputs. As a result, Taro transfers inherit the same re-org safety traits as regular Bitcoin transactions. It also isn't possible to send to something that won't ultimately exist, as sends create new outputs just like Bitcoin transactions. Taro's state transition model also means anything you can do today with Bitcoin/LN also apply. As an example, it would be possible for you to withdrawn from your exchange into a Loop In address (on chain to off chain swap), and have everything work as expected, with you topping off your channel. Stuff like splicing, and other interactive transaction construction schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work. Ignoring the ordering issue I mentioned above, I don't think this is a great model for anchoring assets in channels either. With Taro, when you make the channel, you know how many assets are committed since they're all committed to in the funding output when the channel is created. However, let's say we do teleporting instead: at which point would we recognize the new asset "deposits"? What if we close before a pending deposits confirms, how can one regain those funds? Once again you lose the serialization of events/actions the blockchain provides. I think you'd also run into similar issues when you start to think about how these would even be advertised on a hypothetical gossip network. I think one other drawback of the teleport model iiuc is that: it either requires an OP_RETURN, or additional out of band synchronization to complete the transfer. Since it needs to commit to w/e hash description of the teleport, it either needs to use an OP_RETURN (so the receiver can see the on chain action), or the sender needs to contact the receiver to initiate the resolution of the transfer (details committed to in a change addr or w/e). With Taro, sending to an address creates an on-chain taproot output just like sending to a P2TR address. The creation of the output directly creates the new asset anchor/output as well, which allows the receiver to look for that address on chain just like a normal on chain transaction. To 3rd party observers, it just looks like a normal P2TR transfer. In order to finalize the receipt of the asset, the receiver needs to obtain the relevant provenance proofs, which can be obtained from a multi-verse gRPC/HTTP service keyed by the input outpoint and output index. In short, the send process is fully async, with the sender and receiver using the blockchain itself as a synchronization point like a normal Bitcoin wallet. -- Laolu