# Table of Contents - [Taproot Assets | Builder's Guide](#taproot-assets-builder-s-guide) - [Taproot Assets Protocol | Builder's Guide](#taproot-assets-protocol-builder-s-guide) - [Edge Nodes | Builder's Guide](#edge-nodes-builder-s-guide) - [FAQ | Builder's Guide](#faq-builder-s-guide) - [Glossary | Builder's Guide](#glossary-builder-s-guide) - [Taproot Assets on Lightning | Builder's Guide](#taproot-assets-on-lightning-builder-s-guide) - [Taproot Assets Trustless Swap | Builder's Guide](#taproot-assets-trustless-swap-builder-s-guide) --- # Taproot Assets | Builder's Guide [PreviousImplementations and Links](/the-lightning-network/l402/implementations-and-links) [NextTaproot Assets Protocol](/the-lightning-network/taproot-assets/taproot-assets-protocol) Last updated 11 months ago Was this helpful? Taproot Assets (formerly Taro) is a new Taproot-powered protocol for issuing assets on the bitcoin blockchain that can be transferred over the Lightning Network for instant, high volume, low fee transactions. At its core, Taproot Assets taps into the security and stability of the bitcoin network and the speed, scalability, and low fees of Lightning. Taproot Assets relies on Taproot, bitcoin’s most recent upgrade, for a new tree structure that allows developers to embed arbitrary asset metadata within an existing output. It uses Schnorr signatures for improved simplicity and scalability, and, importantly, works with multi-hop transactions over Lightning. Throughout Bitcoin's history, there have been a number of proposals with regard to bringing assets to the Bitcoin blockchain. Taproot Assets advances those ideas by focusing on what Taproot enables in that realm. With a Taproot-centered design, Taproot Assets can deliver assets on Bitcoin and Lightning in a more private and scalable manner. Assets issued on Taproot Assets can be deposited into Lightning Network channels, where nodes can offer atomic conversions from Bitcoin to Taproot Assets. This allows Taproot Assets to be interoperable with the broader Lightning Network, benefiting from its reach and strengthening its network effects. Taproot Assets uses a Sparse-Merkle Tree to enable fast, efficient, private retrieval and updates to the witness/transaction data and a Merkle-Sum Tree to prove valid conservation/non-inflation. Assets can be transferred through on-chain transactions, or over the Lightning Network when deposited into a channel. Participants in Taproot Assets transfer bear the costs of verification and storage by storing Taproot Assets witness data off-chain in local data stores or with information repositories termed "Universes" (akin to a git repository). To check an asset's validity, its lineage since its genesis output is verified. This is achieved by receiving a verification file of transaction data through the Taproot Assets gossip layer. Clients can cross-check with their copy of the blockchain and amend with their own proofs as they pass on the asset. Summary: 1. Allows assets to be issued on the bitcoin blockchain 2. Leverages taproot for privacy and scalability 3. Assets can be deposited into Lightning channels 4. Assets can be transferred over the existing Lightning Network [Read more: Taproot Assets announcement presentation slides April 2022](https://docs.google.com/presentation/d/1YgMG4MOjs5dHhlf77Zh0WOENXqB0JTV8ZarVjS8slyk) [Watch: Taproot Assets: A new protocol for multi-asset Bitcoin and Lightning](https://www.youtube.com/watch?v=-yiTtO_p3Cw) [](#docs-internal-guid-9b2bf3f9-7fff-60c9-5880-bd52d991db46) Features & Limitations ---------------------------------------------------------------------------------------- Taproot Assets allows for a long list of features that make the protocol scalable, robust, and friendly for low-powered mobile devices in situations of limited bandwidth. * Taproot Assets is light client-friendly: has low verification costs and needs only access to untrusted bitcoin transactions. Taproot Assets does not require knowledge of the entire blockchain. * Taproot Assets allows for atomic swaps between assets and BTC * Taproot Assets can handle both unique and non-unique assets as well as collections. * Taproot Assets allows for creative multi-signature and co-signatory arrangements. * Taproot Assets channels can be created alongside BTC channels in the same utxo, allowing Taproot Assets to exist in the Lightning Network without consuming additional resources. For instance, Alice can create two channels with Bob in a single Bitcoin transaction, one containing an asset, the other BTC * Future features may include confidential transactions and zero-knowledge proofs as part of Taproot Asset transfers. To learn more about the implementation of the Taproot Assets Protocol, follow this [link to the `tapd` client](/lightning-network-tools/taproot-assets) . Further reading: * [Taproot Assets Q&A with Ryan Gentry - LNMarkets](https://lnmarkets.substack.com/p/51-ryan-gentry-on-taro-massive-stress) [Taproot Assets Protocol](/the-lightning-network/taproot-assets/taproot-assets-protocol) [Taproot Assets on Lightning](/the-lightning-network/taproot-assets/taproot-assets-on-lightning) [Taproot Assets Protocol](/the-lightning-network/taproot-assets/taproot-assets-protocol) [Taproot Assets on Lightning](/the-lightning-network/taproot-assets/taproot-assets-on-lightning) [FAQ](/the-lightning-network/taproot-assets/faq) --- # Taproot Assets Protocol | Builder's Guide [](#concepts-and-topography) Concepts and topography --------------------------------------------------------- To understand Taproot Assets, we will need to make ourselves familiar with several concepts, some of which are novel, in the context of the bitcoin blockchain. [Read the BIPs: Taproot Assets Protocol](https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap.mediawiki) Learn about the basic concepts here: [Public-key cryptography](https://www.cloudflare.com/learning/ssl/how-does-public-key-encryption-work/) [Cryptographic Hashes](https://resources.infosecinstitute.com/topic/introduction-to-hash-functions/) [Merkle trees](https://nakamoto.com/merkle-trees/) [Bitcoin UTXO](https://unchained.com/blog/what-is-a-utxo-bitcoin/) ### [](#docs-internal-guid-4d5379eb-7fff-d82b-c5fe-6c905a4ecb5e) Taproot transactions Taproot is a new transaction type defined in [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) and fully functional on Bitcoin mainnet as of November 2021. The main difference of Taproot transactions to conventional Bitcoin transactions is that scripts controlling coins are contained within a tree structure called the 'tapScript branch' which is privately committed into the transaction. These scripts don’t need to be revealed if the KeySpend path is used to move the coins. While a conventional transaction requires the entire script to be revealed, a Taproot transaction can be spent with a key to abstain from revealing the scripts and if the keyspend path is infeasible, only the executed portion of the script is revealed on the blockchain. All other script paths can remain private, or be selectively revealed off-chain. This makes it possible to create more complicated scripts without the added cost of submitting extra data to the blockchain in the keySpend path, and efficient verification of a pruned script data. In the context of Taproot Assets, it allows us to provably attach arbitrary data to a transaction without revealing this data on-chain. ### [](#committing-to-a-hash-taptweak) Committing to a hash: Taptweak We refer to a transaction that includes such arbitrary data as a commitment. Once the transaction has been included in a block, we have committed to this data and can no longer change or amend it. To commit to data, we tweak the public key of our Taproot spending key using a trick known as “Taptweak.” It allows us to selectively reveal the data without revealing the private key, or to spend the output without revealing the commitment. This technique is used in Taproot transactions to commit to the Taproot script tree, and can be used to commit to any arbitrary data. `Q= P+H(P|c)G` Q = the final Taproot public key P = the internal public key H(P|c) = A hash of the internal public key and the commitment To sign a transaction with our private key, the private key needs to be tweaked with the same hash of the public key and commitment, H(P|c). [Read: Taproot Is Coming: What It Is, and How It Will Benefit Bitcoin](https://bitcoinmagazine.com/technical/taproot-coming-what-it-and-how-it-will-benefit-bitcoin) [Watch: Bitcoin Optech Schnorr Taproot Seminar](https://bitcoinops.org/en/schorr-taproot-workshop/) ### [](#docs-internal-guid-5a068ff4-7fff-ecac-596d-f7631d0a2edd) Sparse Merkle trees A Sparse (meaning ‘thinly scattered’) Merkle tree is a data structure in which it can be proven that specific data doesn't exist within a merkle tree. An SMT is an authenticated key-value store, meaning that the key, or location, of a leaf and the content of the leaf are bound to each other. To achieve this property, the contents of the leaf are hashed and a merkle tree is created in which the leaf's position corresponds to the bitmap of the hash digest. By necessity, this requires a tree of 256 levels and 2^256 leaves. Generation of the tree is efficient--despite the apparently large size--because the overwhelming majority of the branches contain empty leaves and can be represented with nil hashes. For example, we may create a Sparse Merkle tree using a fictitious hashing function of sha002, which results in a number between 0 and 3. We generate a Sparse Merkle tree with 4 leaves: 0, 1, 2 and 3. Only leaf 2 is populated, all other leaves are empty. To find leaf 2 (written 10 in binary), we go right at the first branch (1), then left at the second branch (0). To verify leaf 2, we now only need to reveal the value at this leaf, plus the hash of leaf 3 and the hash of branch 0. In Sparse Merkle trees, every leaf can be described as a guide to itself through a map when expressed in binary form. The map is the Sparse Merkle tree itself, and the guide is represented by instructions on whether to turn left or right at each fork. The 10th leaf in a 2^4 large Sparke Merkle tree for example is expressed in binary as 1001, meaning we find the appropriate leaf by turning right, then left, left and finally right. This property is extremely useful for constructing and reconstructing the Sparse Merkle tree, as it describes precisely which parts of the Sparse Merkle tree we have to reconstruct. More importantly, the data in each leaf can now be described by their location in the tree. Using the Sparse Merkle tree, we can associate data with public keys, and prove that we have deleted this data in an easily verifiable way without having to reveal the entire tree. Because every item has its predetermined location, the tree’s root hash is not dependent on the order in which items are inserted. [See also: Plasma Cash](https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298) ### [](#merkle-sum-trees) Merkle sum trees Merkle sum trees are a type of merkle tree that contains numeric values at each leaf, and each node also carries the sum of the values below it. At the root of the Merkle sum tree is the sum of total values in the tree. Merkle Sum trees allow efficient verification of conservation (non-inflation) by committing to quantities associated with leaves. [See also: Using Merkle sum trees for liability proof](https://blog.bitmex.com/addressing-the-privacy-gap-in-proof-of-liability-protocols/) ### [](#docs-internal-guid-562ab959-7fff-e882-7df8-7c4d7189830f) Combining taproot, taptweak, sparse Merkle trees and Merkle sum trees Taproot Assets makes use of a combination of the concepts above to allow for the issuance of Bitcoin-native assets. Sparse Merkle trees and Merkle sum trees are combined into sparse Merkle sum trees. The root of this tree is added to a taproot tapscript, and together a taproot address is created. Instead of its own blockchain, Taproot Assets issuers store sparse Merkle sum trees off-chain and issue proofs to asset holders out of band. The owners of such assets can independently verify that their account is included in the tree, is filled with the appropriate amount and the corresponding taproot transaction exists and is confirmed on the Bitcoin blockchain. [Read the BIPs: Merkle Sum Sparse Merkle Trees](https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap-ms-smt.mediawiki) [](#issuing-assets) Issuing assets --------------------------------------- ### [](#asset-id) Asset ID To issue Taproot Assets , we must first create its identifier. We create a 32-byte asset ID which is produced by hashing three elements: the outpoint being spent to mint the asset, an asset tag of the minter’s choice (e.g. a hash of a brand name) and meta information associated with the asset--such as links, images or documents. `asset_id = sha256(genesis_outpoint || asset_tag || asset_meta)` ### [](#docs-internal-guid-926da57d-7fff-edec-b9e3-ed00906dcf69) Asset Script The asset script can have inputs and outputs, similar to a Bitcoin transaction. A newly created asset does not contain any Taproot Assets inputs, while an asset transfer does. The output of the asset script defines who the newly created assets are issued to. More precisely, this is done through a sparse Merkle sum tree, in which each account is identified by its 256-bit key, and each leaf corresponding to this key contains information about the amount the account holds. It is possible to issue multiple assets in one transaction, but each asset will have its own asset script and within it, sparse Merkle tree. Assets can be unique or non-unique. [Read the BIPs: Taproot Asset Script](https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap-vm.mediawiki) ### [](#asset-leaves) Asset leaves Each leaf contains a TLV (type, length, value) blob, akin to the TLV used in the Lightning Network. It contains information such as versions, asset id, amount, as well as data pertaining to previous transfers of this asset, such as signatures. ### [](#commit-to-tree-root) Commit to tree root Once we have generated the sparse Merkle sum tree and asset script, we can tweak our internal public key and obtain the contract’s address and finalize the transaction. ### [](#publish-transaction) Publish transaction Once we publish this transaction and have it confirmed on the bitcoin blockchain, we have irreversibly created the asset. To an observer, this transaction will look like any other standard taproot transaction. ### [](#asset-proof) Asset proof The asset issuer can now selectively reveal what assets were created and to whom they were allotted. Most importantly, the issuer can prove to the recipient that an asset has been transferred to them, by revealing a specific asset proof, which contains the asset script as well as the path of the sparse Merkle sum tree with the recipient’s account as the key. The recipient can verify the partial sparse Merkle sum tree to recreate the script, tweak the issuer’s public key and verify that the genesis transaction exists on the blockchain, while the partial Merkle tree gives them assurance over the assets issued to them, as well as the total number of assets issued. [](#undefined) ------------------ [](#docs-internal-guid-ae0229ef-7fff-480d-ba27-14c268d89d16) Transferring assets ------------------------------------------------------------------------------------- Taproot Assets can be transferred on-chain, or they can be used to open Lightning Network channels. In this chapter, we will discuss on-chain transactions only. Exactly how individual account holders interact with each other is not prescribed by Taproot Assets, but can be application specific. Issuers are given flexibility in how they define their assets, or how they intend to restrict these assets. The Asset Root Commitment commits to all assets held inside of the tree as well as their sum. The asset\_id is globally unique as it depends on the identifier of its genesis output. The overall root can comprise multiple asset\_ids whose conservation of funds is provided by verifying the asset\_tree\_root. `asset_tree_root = sha256(asset_id || left_hash || right_hash || sum_value)` ### [](#docs-internal-guid-9dd22c77-7fff-d40d-b240-51c0f6f07a08) Taproot Assets Addresses Taproot Assets addresses are bech32m encoded identifiers of the asset ID, the asset script hash, the internal key of the sparse Merkle sum tree and an amount, prefixed with Taproot Assets or `taptb1` (testnet). `bech32(hrp=TapHrp, asset_id || asset_script_hash || internal_key || amt)` The issuer or asset holder can use the information in your Taproot Assets address to create or modify the sparse Merkle sum tree as explained below. This address format can also be used to request a specific proof over the amounts held by the address. [Read the BIPs: Taproot Assets On Chain Addresses](https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap-addr.mediawiki) ### [](#move-assets-inside-the-tree) Move assets inside the tree To transfer Taproot Assets, the recipient communicates their address to the current holder, who can initiate the transfer. The exact interaction between account holders and issuers is not strictly defined at this time. It could be left up to each application or even asset issuer to specify. The sender of the funds will need to generate a new sparse Merkle sum tree reflecting the new balances. This is done by reducing the balances of certain leafs and increasing the balances of other leafs. The sparse Merkle sum tree guarantees that no new assets are created in such a transaction and that the previous claims to the assets are fully relinquished. Creating assets requires a single on-chain taproot transaction, in which there is no limit on how many assets can be minted or how many accounts can hold these assets. To transfer assets, as explained above, requires reorganizing the Merkle tree and publishing a new on-chain transaction. There is no limit to how many internal Taproot Assets transactions are reflected in this single on-chain transaction. Using this methodology, funds are allocated to account holders, represented as leafs in the sparse Merkle sum tree, but the ability to make such internal transfers is limited to the owner of the internal taproot private key(s). ### [](#docs-internal-guid-81622115-7fff-548d-5594-a7c4b43b97b3) The Universe A Universe is a service that provides information about assets as well as proofs for asset holders. It acts similarly to a bitcoin block explorer, but showcases Taproot Assets transaction data which is stored off-chain with Taproot Assets clients. The main difference is that, as most information related to Taproot Assets is off-chain, it is easier to conceal. A Universe may be run by the asset issuer themselves or may be appointed by an issuer. It is also conceivable that community-run Universes aggregate information submitted by asset holders. Given a known asset ID, the Universe for example may provide information about its Genesis output, as well as current meta information such as documentation, asset scripts or total coins in circulation. A service may also know about multiple assets (Multiverse) or only about a single output (Pocket Universe). A Universe has no privileges within the Taproot Assets Protocol. It produces transaction data validated against the bitcoin blockchain. An adversarial Universe could only refrain from returning data requested by clients. Taproot Assets transaction data isn’t bound to a Universe. The data availability offerings provided by a Universe is motivated by entities who wish to have fast, cheap verification of their Taproot Assets. [Read the BIPs: Taproot Asset Universes](https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap-universe.mediawiki) ### [](#asset-merge-or-split) Asset merge or split Assets may be transferred internally within the assets’ sparse Merkle tree, as described above, or they may be sent to another taproot key holder. This is referred to as an asset split. In an asset split, the sender will again first need to update the sparse Merkle sum tree of their own taproot output, adjusting the balance(s) and recalculating the Merkle root. In the case of a merge, the root sum will also change. Additionally, there will be a second sparse Merkle sum tree committed to a new taproot output. This second Merkle tree is calculated by the recipient of the assets, who acts similarly to an issuer in the example above, with the difference that these assets aren’t created from nothing, but rather are split from a previous output, for example the asset’s genesis output. ### [](#docs-internal-guid-c07ae888-7fff-b8c7-0394-06c7498c1d43) Asset proof To be able to verify that the asset split has taken place, the operator of the new Universe needs proof that * assets were created at transaction zero (t0) * assets existed on a leaf in the original Merkle tree at t0 * the balance of this leaf was set to zero at t1 * the assets existed on a leaf of the new Merkle tree at t1 Once assets are split, the owner of the asset is able to perform internal transactions in the same way as the issuer. Each proof before the split will always need to include the Issuance proof for provenance verification. Asset proofs grow linearly with each new on-chain transaction. Every asset transaction needs to be audited back to its Genesis output. An asset proof is only valid as long as the output it references is unspent on the blockchain. ### [](#invalidating-assets) Invalidating assets An asset is considered invalid as soon as its output has been spent without committing to a new sparse merkle sum tree. This is not obvious for a third party observer, and in some instances it may be preferable to spend outputs to a new empty merkle tree to prove that assets were destroyed, invalidated, or “burned”. [Read the BIPs: Taproot Assets Flat File Proof Format](https://github.com/Roasbeef/bips/blob/bip-tap/bip-tap-proof-file.mediawiki) [PreviousTaproot Assets](/the-lightning-network/taproot-assets) [NextTaproot Assets on Lightning](/the-lightning-network/taproot-assets/taproot-assets-on-lightning) Last updated 6 months ago Was this helpful? Constructing a Sparse Merkle tree Identifying leaves in a Sparse Merkle tree Proving non-inclusion in a Sparse Merkle tree Identifying Accounts Overview over the various tree structures used in Taproot Assets ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252FSBmoRaTSau9moyFJR2N3%252FMerkle%2520tree%2520introduction%2520B1.png%3Falt%3Dmedia%26token%3D5ac341f6-c00b-42af-9db0-de207657d9f6&width=768&dpr=4&quality=100&sign=5be8f6d0&sv=2) ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252FqW7JSrhRJL2DXhRp0sWS%252FMerkle%2520tree%2520introduction%2520B3.png%3Falt%3Dmedia%26token%3D9739db6a-c586-4173-ac15-6b7cb2183a2a&width=768&dpr=4&quality=100&sign=2b3c189e&sv=2) ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252FjUka2iiyNI45TBWvetOd%252FMerkle%2520tree%2520introduction%2520B5.png%3Falt%3Dmedia%26token%3D597d5769-b561-4373-af4d-7dd37832afb6&width=768&dpr=4&quality=100&sign=192ef0e3&sv=2) ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252Fq9o0Q5kttwU9N9bjkT4n%252FMerkle%2520tree%2520introduction%2520B6.png%3Falt%3Dmedia%26token%3D168fa66f-3714-4908-808b-29f5fad96583&width=768&dpr=4&quality=100&sign=46fd02fb&sv=2) ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252FpHqrP9lcqUcAxP0TFziT%252FMerkle%2520tree%2520introduction%2520C5.png%3Falt%3Dmedia%26token%3Ddd74ac78-d31d-4497-9d0f-fb012a13ddaa&width=768&dpr=4&quality=100&sign=11372df1&sv=2) ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252FI51sSxkkpA2Gi7fZY4hb%252FTAP%2520Trees.png%3Falt%3Dmedia%26token%3De7012a06-94e0-476d-89fa-a694a061f593&width=768&dpr=4&quality=100&sign=5aeec036&sv=2) --- # Edge Nodes | Builder's Guide Taproot Assets can be deposited into Lightning Network channels. Such Taproot Asset channels are not announced to the network, but are available as “private” channels to both channel partners. Typically, these unannounced channels are between a client (the wallet of an end-user, running on a mobile device or personal computer) and a service provider (a routing node operating on a server). The service provider is always available and well connected to the larger network through public channels, while the client only comes only sporadically to make or receive a payment. In the context of Taproot Assets, an Edge node is a service provider with multiple public Bitcoin channels to the Lightning Network, and unannounced Taproot Assets channels with their clients. They may have multiple channels per client, for example to facilitate the transfer of multiple asset types. What makes an Edge node different to an ordinary routing node or Lightning Service Provider is the ability to swap the Taproot Asset into BTC or vice versa, and route the value of the payment over the greater Lightning Network. This enables a Taproot Assets-aware Lightning wallet to hold a Taproot Asset, but pay to any Bolt 11/12 Lightning invoice, LNURL or Lightning address. It also allows this wallet to receive Taproot Assets for any payment made by any existing Lightning wallet. Through Edge Nodes, Taproot Assets-enabled wallets are able to plug into the existing network effects of the Lightning Network, and are able to interact with services and users that are not aware of Taproot Assets. As Edge nodes swap Taproot Assets to BTC through traditional [HTLCs](/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc) , they do not hold client assets or require custodial arrangements of any other kind. [Read more: Set up an Edge node](/lightning-network-tools/taproot-assets/rfq) [](#docs-internal-guid-9848fd86-7fff-5305-d8ad-ff2ea6ce4686) What does an Edge node do ------------------------------------------------------------------------------------------- * **Open channels** Similar to a Lightning Service Provider, an Edge node might be expected to open Taproot Asset channels to clients on demand. It might charge a fee for this service, or operate under the expectation of generating revenue through future routing activity * **Quote swap rates** Before the client performs a swap from Taproot Assets to Bitcoin, it will expect to get a quote from the Edge node. As Lightning invoices are denominated in Bitcoin, this quote is necessary for the client to know how much of their Taproot Assets they are expected to pay: “This invoice is over 10,000 satoshis, how many Taproot-USD will this cost me?” Conversely, when generating a Lightning invoice, a quote is necessary for the client to generate the invoice: “I would like to receive 10 Taproot-USD, what amount of satoshis should I make this invoice out to?” As Bitcoin’s exchange rate is volatile, spreads offered by Edge providers may differ based on how long they are valid for. When paying an invoice quotes only need to be valid for a few seconds, while invoices require quotes for the period of their validity. Existing mechanisms like LNURL-pay may help create static, reusable and dollar-denominated payment requests that do not require extensively valid swap quotes. A user may have channels to multiple Edge nodes and choose the most attractive quote. * **Route payments** An Edge node is expected to route payments to and from their clients and the larger network. They earn fees for routing payments, as any other routing node would. Payments are routed atomically through HTLCs. * **Hedge** As an Edge node performs swaps between Taproot Assets and Bitcoin, they might choose to hedge their trades on an exchange, but they may also be used by others as a hedging mechanism, for example by allowing for circular routes that let a client swap from and to a Taproot Asset. [](#docs-internal-guid-af7e0901-7fff-8577-4dae-2106e2d2e783) How to find an Edge node ------------------------------------------------------------------------------------------ The mechanisms of how Edge nodes become discoverable are not fully determined and ultimately up to the market. Edge nodes may be popularly known, affiliated with wallets, exchanges or brokers. Eventually, Edge nodes may offer their liquidity services through a marketplace like [Pool](/lightning-network-tools/pool) . [](#how-to-run-an-edge-node) How to run an Edge node --------------------------------------------------------- To run an Edge node, we recommend getting started with [a regular LND routing node](/lightning-network-tools/lnd/run-lnd) . By running [litd](https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/get-lit) in integrated mode, the node benefits from having access to Loop, Pool and Taproot Assets from the very beginning. In addition to Bitcoin, the Edge node will need to get access to the Taproot Assets they want to offer to their clients, as well as implement their custom logic for providing quotes and hedging their trades. [PreviousTaproot Assets on Lightning](/the-lightning-network/taproot-assets/taproot-assets-on-lightning) [NextTaproot Assets Trustless Swap](/the-lightning-network/taproot-assets/trustless-swap) Last updated 8 months ago Was this helpful? --- # FAQ | Builder's Guide [](#docs-internal-guid-ae4b02ad-7fff-4740-c7fd-34f471681055) Taproot Assets -------------------------------------------------------------------------------- ### [](#docs-internal-guid-ae4b02ad-7fff-4740-c7fd-34f471681055-1) What is Taproot Assets? Taproot Assets is a novel Taproot-based protocol that defines how assets can be issued/used on the bitcoin blockchain. Assets issued with the Taproot Assets protocol are held in bitcoin utxos and are transferred as part of regular bitcoin transactions. ### [](#what-can-i-do-with-taproot-assets) What can I do with Taproot Assets? Taproot Assets lets you issue all kinds of assets on bitcoin, both collectible and fungible (often called _normal_). There are no technical limits to what these assets can represent, including stablecoins, shares, tickets, ownership rights or art. Assets can be programmed using Taproot Asset scripts, allowing for a broad range of functionality similar to bitcoin transactions. From an initial protocol design and prioritization perspective, Lightning Labs is focused on stablecoins’ use cases first. ### [](#how-does-taproot-assets-work) How does Taproot Assets work? Taproot Assets uses Merkle trees known as a ‘Merkle Sum, Sparse Merkle Tree (MS-SMT)’ and Taptweak to commit to information defining an asset’s creation and ownership. ### [](#what-does-taproot-assets-have-to-do-with-taproot) What does Taproot Assets have to do with Taproot? Taproot Assets requires Taproot to function efficiently, as Taptweak makes it possible to commit to arbitrary data without additional overhead on the blockchain. Taproot allows Taproot Assets to be scalable, economical, and privacy enhancing. ### [](#where-can-i-buy-taproot-assets-tokens) Where can I buy Taproot Assets tokens? Taproot Assets is a protocol. The Taproot Assets Protocol is released under the BSD-2-Clause license, also known as the “simplified BSD license,” making it free to use and build upon. The best way to invest in Taproot Assets is to build on top of it. [](#taproot-assets-on-chain) Taproot Assets on-chain --------------------------------------------------------- ### [](#docs-internal-guid-ecae09ba-7fff-98fc-8581-c0543aaa5874) Does Taproot Assets scale? Taproot Assets minimizes its on-chain footprint by storing all necessary metadata off-chain. It further optimizes how UTXOs are used by allowing multiple assets to be controlled by the same output, and aggregate multiple transactions into a single UTXO. Taproot Assets on the Lightning Network vastly improves on the scalability of other on-chain or sharded off-chain protocols while allowing for the highest degree of self-sovereignty. ### [](#how-do-i-find-out-what-assets-have-been-issued) How do I find out what assets have been issued? Once the protocol is released, information about asset issuance may be obtained either directly from an issuer, through a Taproot Assets universe or from Lightning Labs’s products. ### [](#what-is-a-universe) What is a universe? A Taproot Assets universe is a repository of assets and their proofs. A universe may serve information about a single or multiple asset types (e.g. a specific stablecoin or all stablecoins). It may hold information about which assets have been issued, their quantity, and rules as well as hold proofs about recent transfers. The criteria for releasing this information is up to a universe or universe operator. ### [](#what-is-a-pocket-universe) What is a pocket universe? A pocket universe is a way to collectively store Taproot Assets and use the protocol without giving up ownership of assets. This pocket universe is a single party (or federation) maintaining a Taproot Assets commitment that includes assets that they can't unilaterally move themselves. A pocket universe controls the Taproot key to a UTXO, but not the keys to the (possibly multiple) Taproot Assets held in that UTXO. Asset holders can use the pocket universe to batch their transactions in an efficient manner. ### [](#docs-internal-guid-995924ec-7fff-bf47-4b88-25b6658d8c66) Do I need the full blockchain to issue or transact assets with Taproot Assets? Taproot Assets does not require you to keep or scan the entire blockchain. Similar to running a Lightning Network node, your Taproot Assets client only requires proofs about the existence of specific transactions relating to its assets, which can be obtained in ‘Neutrino’ mode, also known as BIP157. ### [](#do-i-need-bitcoin-to-issue-assets-with-taproot-assets) Do I need bitcoin to issue assets with Taproot Assets? To issue and transact Taproot Assets, bitcoin transactions need to be made, which generally require transaction fees paid in BTC. Each output also needs to carry with it a small number of satoshis to be valid. ### [](#how-do-i-issue-assets-with-taproot-assets) How do I issue assets with Taproot Assets? Using the initial implementation, anyone is be able to issue assets with Taproot Assets using `tapd` on Bitcoin. Once the asset has been issued and its genesis transaction is confirmed on the blockchain, your asset is live and can be transferred. In the future it will be possible to also deploy this asset into a Lightning Network channel. ### [](#do-all-assets-have-a-limited-supply) Do all assets have a limited supply? When minting a Taproot Asset asset, you define its rules. It is possible to limit the total supply of your asset or to leave it uncapped to create additional assets later. These supply controls are enforced through cryptographic means in the Taproot Assets client. ### [](#how-do-i-hold-assets-in-my-wallet) How do I hold assets in my wallet? Your Taproot Assets wallet will need to store Taproot keys as well as Taproot Assets keys, plus the knowledge of which assets were held in which UTXOs. How such data is stored and backed up will be up to the wallet developer. If a user loses their asset proof information, it’s possible for a Universe to serve the proof back to the user. ### [](#docs-internal-guid-157496c4-7fff-e705-7be6-06f7c05e7cd4) How do I send assets on-chain? To send Taproot Assets to somebody else, they will need to first provide you their Taproot Assets address. This address contains information about the asset and public keys necessary for holding the asset, as well as the requested amount. The address format is designed to help prevent Taproot Assets from being lost or unrecoverable. ### [](#what-fees-do-i-have-to-pay) What fees do I have to pay? Typically, a Taproot Assets transaction will carry on-chain fees, which are paid to bitcoin miners similar to a regular bitcoin transaction. When transacting Taproot Assets off-chain, you may pay routing fees to Lightning Network nodes instead. When using a pocket universe, grouped transactions can share on-chain fees. [](#taproot-assets-on-the-lightning-network) Taproot Assets on the Lightning Network ----------------------------------------------------------------------------------------- ### [](#how-do-i-send-taproot-assets-over-the-lightning-network) How do I send Taproot Assets over the Lightning Network? Taproot Assets can be deployed into a Lightning Network channel in a similar manner as bitcoin. When a route denominated in the relevant asset exists, the asset can be routed through it, otherwise it can be trustlessly swapped for BTC and its value is routed to the destination, where it may be swapped back or into a different asset. Ultimately, the majority of this process will be obfuscated to the end user and handled by nodes and wallets. ### [](#docs-internal-guid-db923dbf-7fff-0947-dc8c-ded0b5d02196) What is edge liquidity? Edge liquidity describes the concept that some Lightning Network nodes, with which you have Taproot Assets channels, may be willing to swap their value to BTC and back, allowing you to use your Taproot Assets to pay for any Lightning Network invoice, or receive any asset by issuing a standard Lightning invoice. ### [](#how-does-taproot-assets-know-how-much-an-asset-is-worth) How does Taproot Assets know how much an asset is worth? The Taproot Assets Protocol does not prescribe how edge nodes and Taproot Asset holders agree on a price -- though a few options can be supported. As long as both agree on a rate, any Taproot Assets can be swapped for BTC and its value transmitted through the broader Lightning Network. ### [](#how-does-taproot-assets-deal-with-the-optionality-challenges) How does Taproot Assets deal with the “optionality” challenges? Edge nodes’ liquidity has some optionality properties, but this optionality will be priced by the market. Nodes, which offer this optionality, can decline to facilitate the quoted swap and users can avoid nodes which don’t perform adequately. Ergo, Taproot Assets doesn’t have a “free option problem” which can exist in cross-chain atomic swaps. ### [](#do-you-need-an-equivalent-amount-of-bitcoin-to-move-taproot-assets-between-channels) Do you need an equivalent amount of bitcoin to move Taproot Assets between channels? The owner of an asset does not need to own an equivalent amount of bitcoin to be able to send or receive amounts denominated in their asset. However, a route must exist between the sender and receiver with sufficient liquidity -- either in bitcoin or the asset. ### [](#custody-and-redeemability-in-the-taproot-assets-protocol) Custody and redeemability in the Taproot Assets protocol User holds the keys to the taproot UTXO 🔑Yes 🚫No User holds asset keys 🔑Yes Full self-custody User is **using** a pocket universe 🚫No User is **operating** a pocket universe Entirely custodial relationship [PreviousTaproot Assets Trustless Swap](/the-lightning-network/taproot-assets/trustless-swap) [NextGlossary](/the-lightning-network/taproot-assets/glossary) Last updated 7 months ago Was this helpful? --- # Glossary | Builder's Guide [](#docs-internal-guid-85ae5d8e-7fff-f351-537f-243d2bc233ca) Anchor ------------------------------------------------------------------------ The anchor transaction is the Bitcoin transaction that mints or transfers a Taproot Asset. [](#asset-group) Asset group --------------------------------- An asset group describes a series of assets, as identified by their asset ID, for which new assets can be added by the issuer. [Read more: Minting asset groups](/lightning-network-tools/taproot-assets/first-steps#docs-internal-guid-326a3acb-7fff-c694-2400-496ff7278e63) [](#asset-id) Asset ID --------------------------- The asset ID is used to identify an asset. It is the hash of the [genesis outpoint](/the-lightning-network/taproot-assets/glossary#genesis-point) , the [asset tag](/the-lightning-network/taproot-assets/glossary#asset-tag) and the [asset meta](/the-lightning-network/taproot-assets/glossary#meta-data) data. It is a globally unique identifier. If an asset is [grouped](/the-lightning-network/taproot-assets/glossary#group-key) , each minted series contains its own asset ID. [](#asset-tag) Asset tag ----------------------------- The asset tag is equivalent to the name of an asset. Other information is collected as part of the [meta data](/the-lightning-network/taproot-assets/glossary#meta-data) . [](#batch) Batch --------------------- A batch is a set of Taproot Asset mints or transfers that are contained in a single Bitcoin-level UTXO. [](#burn) Burn ------------------- Burning an asset means irrevocably removing it from the circulating supply. [Read more: Burn assets](/lightning-network-tools/taproot-assets/first-steps#burning-assets) [](#collectibles) Collectibles ----------------------------------- A collectible, unique or non-fungible asset, unlike a normal asset, cannot be divided or aggregated, as there are no other units of its kind. It can however be put into a collection with other similar collectibles. [Read more: Collectibles](/lightning-network-tools/taproot-assets/collectibles) [](#collections) Collections --------------------------------- A collection is a [group](/the-lightning-network/taproot-assets/glossary#group-key) of collectibles. While every item in the collection is unique, they can still be identified as part of the same collection using the group key. [](#commitment) Commitment ------------------------------- A commitment is typically the hash of data that is to be permanently recorded to have existed at a certain point in time, and in a certain utxo. [](#fungible-tokens) Fungible tokens ----------------------------------------- See also [normal assets](/the-lightning-network/taproot-assets/glossary#normal-asset) . [](#genesis-point) Genesis point ------------------------------------- The genesis point is the first input of the transaction that mints a Taproot Asset. [](#group-key) Group key ----------------------------- The group key identifies normal and collectible assets that do not have a fixed supply. When new assets of this group are minted, a signature using this key must be present. [](#internal-key) Internal key ----------------------------------- The internal key is the key that is able to spend the Taproot Bitcoin UTXO. [](#issuer) Issuer ----------------------- The issuer of an asset is whoever creates and publishes the mint transaction. The issuer of a grouped asset is identified using the group key. [](#leaf) Leaf ------------------- A leaf is the lowest level in a [Merkle tree](/the-lightning-network/taproot-assets/glossary#merkle-tree) . They typically contain the data that the Merkle tree commits to. [](#lightning-polar) Lightning Polar ----------------------------------------- Lightning Polar is software that helps you simulate a regtest Lightning environment in which you can easily add multiple nodes. It can also be used to test Taproot Assets mints and transactions. [Read more: Lightning Polar and Taproot Assets](/lightning-network-tools/taproot-assets/polar) [](#merkle-root) Merkle root --------------------------------- The Merkle root is the hash at the very top of the Merkle tree. If a single value in the Merkle tree changes, the root also changes. [](#merkle-sum-tree) Merkle sum tree ----------------------------------------- A merkle sum tree is a Merkle tree that for each leaf contains a numerical value, which is sumed up in each node. The sum at the [Merkle root](/the-lightning-network/taproot-assets/glossary#merkle-root) is equal to the sum of values at the leafs. [](#merkle-tree) Merkle tree --------------------------------- In a merkle tree a pair of items is hashed, the pair then hashed with other pairs until only a single hash is left, the [Merkle root](/the-lightning-network/taproot-assets/glossary#merkle-root) . This helps to cheaply commit to large amounts of arbitrary data and check whether anything has changed. [](#meta-data) Meta data ----------------------------- The asset meta data can be used to commit to any arbitrary data. Most commonly it describes the asset and its terms or represents the asset itself. [](#mint) Mint ------------------- The action of issuing an asset. Also see -> issuer. [](#non-fungible-token) Non-fungible token ----------------------------------------------- Also see -> collectibles. [](#normal-asset) Normal asset ----------------------------------- A normal or fungible asset is one that is divisible into a predefined set of units. Each unit is expected to be valued the same as any other unit of the same asset. Normal assets can be fixed in total supply, or be part of an -> asset group. [](#proof-file) Proof file ------------------------------- The proof file contains information about the asset, when and how it was minted as well as previous transfers. it is needed to verify ownership over an asset. [](#psbt) PSBT ------------------- A partially signed Bitcoin transaction is a file format that lets two wallets communicate only specific details about a new transaction, for example only its inputs, or only its outputs. These PSBTs can be used to sign transactions with external signing devices, or allow multiple parties to contribute inputs to one transaction. [](#sparse-merkle-tree) Sparse merkle tree ----------------------------------------------- A sparse merkle tree is a merkle tree over all numbers of a given space. A sparse merkle tree over 2^256 for example theoretically contains 2^256 leafs. It can be computed because by default all leafs are empty. Sparse merkle trees help with exclusion proofs, e.g. proving something is not present in a merkle tree. [Read more: Sparse merkle trees in Taproot Assets](/the-lightning-network/taproot-assets/taproot-assets-protocol#docs-internal-guid-5a068ff4-7fff-ecac-596d-f7631d0a2edd) [](#supply) Supply ----------------------- The supply of an asset is the total amount of units of that asset in circulation. For -> grouped assets, this supply can be increased later. For all assets, it can be reduced by -> burning a portion of the supply. [](#tapd) Tapd ------------------- Taproot Assets Protocol Daemon is the reference implementation for Taproot Assets. [Read more: Install tapd](/lightning-network-tools/taproot-assets/get-tapd) [](#taproot) Taproot ------------------------- Taproot is a Bitcoin transaction type. Bitcoin sent to taproot scripts can be unlocked either using the -> internal key or a predefined set of conditions, the -> tapscript. [](#taproot-asset-address) Taproot Asset address ----------------------------------------------------- A Taproot Assets address is created by the recipient of an asset to be able to receive an asset. Such addresses are specific to an asset and an amount and should not be reused. [Read more: Generate Taproot Asset addresses](/lightning-network-tools/taproot-assets/first-steps#docs-internal-guid-2d861222-7fff-ef76-60b9-65367a4fd1b7) [](#taproot-assets) Taproot Assets --------------------------------------- Taproot Assets leverages Taproot transactions to commit to newly created assets and their transfers in an efficient and scalable manner. [Read more: Taproot Assets protocol](/the-lightning-network/taproot-assets/taproot-assets-protocol) [](#taproot-assets-channel) Taproot Assets Channel ------------------------------------------------------- Taproot Assets can be deposited into Lightning channels. These channels are referred to as Taproot Asset Channels. [Read more: Taproot Assets on Lightning](/the-lightning-network/taproot-assets/taproot-assets-on-lightning) [](#tapscript) Tapscript ----------------------------- Tapscript is a feature of -> Taproot transactions that allows to create various conditional spending conditions. Taproot Assets and their merkle trees are stored in the Tapscript. [](#tapscript-sibling) Tapscript sibling --------------------------------------------- The Tapscript sibling is the hash in the leaf next to the data in question. The sibling is needed to compute the -> Merkle root. [](#unique-asset) Unique asset ----------------------------------- See also -> Collectibles. [](#universe) Universe --------------------------- A universe is a server that serves information about assets and their transfers. Universes can also be used to transfer proof files between users. [](#vpsbt) vPSBT --------------------- Virtual partially signed Bitcoin transactions achieve what -> PSBTs achieve, but on the Taproot Assets layer. Using vPSBTs, it becomes easier to batch Taproot Asset transactions, use external signing devices or assemble transactions between the Taproot asset and Bitcoin layer. [](#vutxo) vUTXO --------------------- A vUTXO is a Taproot Assets utxo. As the Taproot Assets themselves are not perfectly synonymous with the Bitcoin UTXO that they are anchored in, vUTXOs are used to reference them. [PreviousFAQ](/the-lightning-network/taproot-assets/faq) [NextLND](/lightning-network-tools/lnd) Last updated 1 year ago Was this helpful? --- # Taproot Assets on Lightning | Builder's Guide [PreviousTaproot Assets Protocol](/the-lightning-network/taproot-assets/taproot-assets-protocol) [NextEdge Nodes](/the-lightning-network/taproot-assets/edge-nodes) Last updated 1 month ago Was this helpful? The Taproot Assets Protocol describes how assets can be issued on the bitcoin blockchain. These assets can be deposited into [Lightning Network payment channels](https://docs.lightning.engineering/the-lightning-network/payment-channels/lifecycle-of-a-payment-channel) and transacted instantly. This principle allows Lightning Network users to hold a balance in their wallet different from BTC: for instance, a stablecoin. They can receive payments denominated in that stablecoin, and use their stablecoin balance to pay for goods and services over the Lightning Network. Bitcoin remains as the backbone of the Lightning Network, and payments through Taproot Assets can be routed over the existing Bitcoin Lightning Network, without the need to upgrade or opt in. With Bitcoin providing the liquidity for these payments denominated in other assets, Taproot Assets routing can deliver more routing fees paid in satoshis for routing node operators. [](#docs-internal-guid-8073d85d-7fff-f958-e660-b596e6d08d6d) Taproot Assets-enabled channels ------------------------------------------------------------------------------------------------- Taproot Asset channels can be created similar to the way that Bitcoin channels are currently created in the Lightning Network. [HTLCs](/the-lightning-network/multihop-payments/hash-time-lock-contract-htlc) can be constructed for transfers in these Taproot Assets-aware payment channels similarly to how bitcoin is transferred. Assets are transacted by creating nested HTLC which, if needed, can be claimed by the recipient by revealing a [preimage](/community-resources/glossary#preimage) , or by the sender after a timeout period. These transactions are Taproot Asset’s equivalent of Lightning Network transactions. ### [](#multi-hop-taproot-assets-transfers) Multi-hop Taproot Assets transfers Historically, payment networks struggle with a bootstrapping problem -- any time a new asset is created, an entirely new payment network needs to be created to serve that specific asset's payment demand. Taproot Assets enables a payment-routing paradigm in which the LN is able to handle channels with any asset, but with the ability to find routes across different assets. Taproot Assets in LN channels can be transferred over the general Lightning Network, For example, in a situation in which all participants along a route have liquidity with each other, they can opt to charge fees in BTC or the transferred Taproot Assets. Even if no Taproot Assets route exists, a BTC route can take its place as long as the first node is willing to forward the Taproot Assets value in satoshis. This can also allow the LN to facilitate exchange between bitcoin and Taproot Assets over the Lightning Network. This also allows the recipient of a payment to opt into receiving Taproot Assets instead of BTC. In the examples below, Bob and Yana act as edge nodes and swap payments between L-USD and BTC. As a general routing node, Yana can also forward pure BTC HTLCs. This makes it possible to receive Taproot Asset but present the corresponding invoice to any other Lightning wallet - even those that do not opt into the Taproot Assets Protocol - which could pay the invoice using BTC. This maintains the Lightning invoice as the standard scheme for invoices. An invoice ultimately settled in Taproot Assets can be paid by BTC or any other asset, and anyone with a Taproot Assets balance can pay any Lightning invoice. ### [](#docs-internal-guid-08fce969-7fff-c159-5dda-e3434119debb) Exchange rates The Taproot Assets Protocol itself gives integrators choice with regard to how to handle exchange rates. Each peer in a channel performing swaps is responsible for determining their own exchange rate. They might use reference rates from liquid exchanges, or determine their own. It is important to note that when receiving a payment the recipient generates the invoice themselves, thus ensuring that the recipient receives the proper amount denominated in their desired asset. Any Lightning Network node aware of Taproot Assets channels can potentially act as an edge node. They compete with each other over fees they collect from forwards and swaps. These fees include the routing fee, a swap fee or alternatively a spread When creating an invoice, the recipient (e.g. Zane in the example below) and their peer (e.g. Yana) agree on a rate before the generation of the invoice. They use this agreed price to generate a general Lightning Network invoice, including the hop hints and the channel policies and pass it on to the payer. As the payer passes the payment through their constructed route to Zane, it passes Yana, who forwards L-EUR. Before releasing the preimage, Zane’s wallet can check whether it received the exact expected amount of L-EUR. When paying a satoshi-denominated invoice through L-USD, Alice has to agree with Bob over the latest rates and fees. She can confirm the payment, passing the required amount of L-USD plus fees, and the recipient will only release the preimage if they receive the amount of satoshis they expected. Edge nodes may have other tools at their disposal if they fear abuse of their forwards, such as closing a channel, reducing the validity of invoices or increasing spreads. The Taproot Assets Protocol does not regulate or set rates, but only provides for the mechanisms of a functional market with low technical barriers to entry and the tools that allow for automated, atomic and instant forwards. An example of a Taproot Assets payment made to the wider Lightning Network An example of a Taproot Assets payment in which the receiver opts to receive the same asset type. Sender and recipient do not need to transact in the same asset type. ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252FUfTHCgpn3guanoLmhaU7%252FGroup%25203881%281%29.png%3Falt%3Dmedia%26token%3Dea5e0814-feb6-4303-9b8a-f837f2f863c9&width=768&dpr=4&quality=100&sign=18f9dd4c&sv=2) ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252Fq1sqfqqkrmchWKqLdhR0%252FGroup%25203882%282%29.png%3Falt%3Dmedia%26token%3Dc1e55692-3bbd-4e53-8026-102236517b6e&width=768&dpr=4&quality=100&sign=83fa53c9&sv=2) ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252F5YUmQvbKYMvannBLtsLt%252FGroup%25203881%282%29.png%3Falt%3Dmedia%26token%3Df878921c-72e6-43c3-af39-44004b8cebce&width=768&dpr=4&quality=100&sign=ebe9bf00&sv=2) --- # Taproot Assets Trustless Swap | Builder's Guide [PreviousEdge Nodes](/the-lightning-network/taproot-assets/edge-nodes) [NextFAQ](/the-lightning-network/taproot-assets/faq) Last updated 9 months ago Was this helpful? Atomic swaps are swaps that either complete in full, or reverse back to their initial stage. This removes the need for two swap parties to trust each other, also known as the “first mover problem.” Using Partially Signed Bitcoin Transactions (PSBTs), this swap can be performed in a single onchain transaction using minimal interaction between the swap partners without an external coordinator. The seller of the Taproot Asset creates a PSBT that proves their ownership over the asset while also allowing anybody who fulfills the PSBT to claim ownership over it (OP\_TRUE). The PSBT defines the Taproot Asset as an input, and the desired BTC amount as an output (22 million sats in the above example). To make the PSBT valid, somebody will need to add an input with at least 22 million sats. To effectively “buy” the Taproot Asset, they will also include an anchor output for the Taproot Asset and if needed, a change output for their BTC. As the anchor input cannot be double-spent on the Bitcoin blockchain, only the winner of this auction can claim the Taproot Asset as theirs, while all competing transactions become invalid once a bid is confirmed on the blockchain. Diagram of trustless Taproot Assets swap ![](https://docs.lightning.engineering/~gitbook/image?url=https%3A%2F%2F2545062540-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-MIzyiDsFtJBYVyhr1nT%252Fuploads%252FlJZ2UkHfhtmXvlVsgs4r%252Fpsbt_auction_complete.drawio.png%3Falt%3Dmedia%26token%3D1e8a0911-be82-49e0-a3fb-065407e19c13&width=768&dpr=4&quality=100&sign=b7b56859&sv=2) ---