lightninglabs / lightninglabs/taproot-assets

[feature]: non-interactive BTC<->asset swaps with asset-level ANYONECANSPEND

Open
#813 0 comments 1 reaction 1 assignee View on GitHub

@GeorgeTsagk is already working on this.

Since Feb 3, 2026.

enhancement
Dominant language
Go
Stars
525
Forks
150
Avg merge
2d 15h
Merged PRs (30d)
31

Description

Related to #577.

Currently we're enabling asset-level sighashes, with one application being BTC-to-asset swaps via PSBT.

A seller can construct a 1-in 1-out PSBT, where the first output anchors any assets not being sold + determines the price to fulfill the swap. The TX is invalid until a buyer attaches an input of sufficient value. The second output, constructed by the buyer, would anchor the assets being sold.

An issue here is how to maintain non-interactivity, while also constructing the asset purchased by the sender correctly. The script key they want to use cannot be known in advance, and there are issues around splitting the input asset to complete the sale.

One option is to have the purchased asset spendable by **anyone** - in practice only one TX built from this PSBT will confirm, so there will only be one owner of the sold asset.

There are many ways to create this ANYONECANSPEND behavior using the asset script key, via [OP_TRUE](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch06_transactions.adoc#output-scripts) or a [constant](https://bitcoin.stackexchange.com/questions/72773/how-to-create-a-p2sh-transaction-with-a-scriptsig-of-op-true). We could extend the script further to make these ANYONECANSPEND keys globally unique, similar to burn keys.

This would allow a seller to perform an asset split in the same TX as the sale. They would publish the asset leaf being sold, with the correct ANYONECANSPEND key, and all the relevant proof data. Specifically the split commitment, proof of non-inclusion in the first output, and the proof of inclusion for the input. That should be enough for any buyer to construct the second output that anchors the sold asset with their own internal key.

One issue with the seller anchoring assets in the output is that they need to generate a proof of non-inclusion for any output a buyer produces, which would require knowing the internal key used by the buyer. Also, since the value of the other anchored assets is unknown, the seller is at risk if the auction is griefed and the TX is constructed s.t. all assets are burned.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.