# taproot-assets: issuing Bitcoin assets through Taproot outputs and a universe

> tapd implements the Taproot Assets Protocol, letting you mint and transfer assets whose state is committed in Bitcoin Taproot UTXOs while the witness data travels off-chain. It depends on lnd for key custody, is still marked alpha, and the README warns in capitals that uninstalling without a backup destroys funds.

**lightninglabs/taproot-assets** — A layer 1 daemon, for the Taproot Assets Protocol specification, written in Go (golang)

- Repository: https://github.com/lightninglabs/taproot-assets
- Stars: 528 · Forks: 154
- Language: Go
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/lightninglabs-taproot-assets

## Assets that live inside a Bitcoin UTXO with the data kept off-chain

tapd is the Taproot Assets Daemon, and it implements the Taproot Assets Protocol for issuing assets on the Bitcoin blockchain. The design idea is what makes it interesting. Taproot assets use Taproot transactions to commit to newly created assets and their transfers in an efficient and scalable manner, and multiple assets can be created and transferred in a single Bitcoin UTXO, while the witness data is transacted and stored off-chain. So the Bitcoin chain carries the commitment, not the payload. The set of features the README lists is short: mint and burn assets, synchronize to universes, send and receive assets, export and import Taproot Asset proofs, and create and manage CLI profiles. The last one is a tell about the audience. Profiles are a per-user concern, which suggests the intended users are people running their own wallets rather than an application backend.

## The genesis point is the asset's identity, and it comes from a spent outpoint

The How It Works section explains the lifecycle, and the key sentence is about identity. When minting a new asset, Taproot Assets generates the relevant witness data, assigns the asset to a key held by you, and publishes the corresponding Bitcoin UTXO, which is the minting transaction. The outpoint that this minting transaction consumes becomes the `genesis_point` of the newly minted asset, acting as its unique identifier. So an asset is named by the place in the chain where it was born, which is a neat way to make creation non-forgeable: you cannot claim an identifier that was not consumed by a real transaction. For a transfer, assets are spent to a new recipient, who provides the sender with the necessary information encoded in their Taproot Asset address, and the witnesses in the prior transaction are recommitted into one or multiple Taproot outputs while the necessary witness data is passed to the recipient. As with Bitcoin transactions, the remaining balance is spent back to the sender as a change output.

## tapd does not hold the Bitcoin key, lnd does

The architecture section describes a two-process design. Taproot Assets are implemented as the daemon `tapd` and the command line interface `tapcli`, and additionally `tapd` exposes a gRPC interface to allow for direct integration into applications. The custody model is the part to understand before you install anything. Custody of Taproot Assets is segmented across `lnd` and `tapd` to maximize security. `lnd` holds the private key, which has had a Taproot tweak applied to it, controlling the Bitcoin UTXO holding the asset. The Taproot tweak is held by `tapd`. Because both the internal key and the tweak are necessary to spend the output, recovery requires both, and the README says this prevents `lnd` from accidentally burning Taproot assets. The dependency on lnd is therefore not optional plumbing. Taproot Assets require lnd version `v0.20.0-beta` or later, synced and running on the same Bitcoin network, for example regtest, simnet or testnet3, with RPC connections accepted and a valid macaroon present.

## Getting lnd and tapd running is two builds and one flag set

The lnd prerequisite comes with its own build instructions:

```shell
$ git clone https://github.com/lightningnetwork/lnd.git
$ cd lnd
$ make install tags="signrpc walletrpc chainrpc invoicesrpc"
```

The `tags` argument selects which lnd RPC subsystems get compiled, and for Taproot Assets you need the wallet and signing capability, which is what `walletrpc` and `signrpc` provide. Then Taproot Assets itself:

```shell
$ git clone https://github.com/lightninglabs/taproot-assets.git
$ cd taproot-assets
$ make install
```

Go version 1.24 or higher is required according to the README, and the go.mod in the repository declares go 1.26.0. Initialization is a single daemon invocation with flags pointing at lnd and naming the network:

```shell
$ tapd --network=testnet --debuglevel=debug \
    --lnd.host=localhost:10009 \
    --lnd.macaroonpath=~/.lnd/data/chain/bitcoin/testnet/admin.macaroon \
    --lnd.tlspath=~/.lnd/tls.cert
```

The bitcoin backend and lnd both have to be running and synced before tapd can start. The full list of options is available with `tapd --help`. The API surface is gRPC on port 10029 and REST on port 8089, both encrypted with TLS and authenticated using macaroons, and the repository includes a `sample-tapd.conf` plus a `tapcfg/` package and a `tapconfig/` directory for configuration.

## The CLI covers minting, universes, addresses and transfers

Everything a user does goes through `tapcli`. Minting an asset and finalizing the mint is two commands:

```shell
$ tapcli assets mint --type normal \
    --name fantasycoin --supply 100 --meta_bytes "fantastic money"
$ tapcli assets mint finalize
$ tapcli assets list
```

The mint is a two-phase operation, which is a consequence of the design. You commit to the asset by publishing the minting transaction, then finalize it, and only then can the asset be transferred. The universe is the discovery and sync mechanism. You synchronize with a universe, for example the one running as part of the issuer's tapd:

```shell
$ tapcli universe sync --universe_host testnet.universe.lightning.finance
```

Multiple universes can be added to your local federation so you always stay up to date, and the universe can also be used to query existing assets and their metadata. A tapd instance can listen for incoming requests with `--rpclisten 0.0.0.0:10029` to run your own universe. Adding universes and listing the roots you have are both one-liners:

```shell
$ tapcli universe federation add \
    --universe_host testnet.universe.lightning.finance
$ tapcli universe roots
```

Once you have the proofs and asset IDs, you generate a Taproot Asset address for a specific asset and amount:

```shell
$ tapcli addrs new --asset_id bab08407[...]129bf6d0 --amt 21
```

And the sender fulfills the request by initiating the transfer:

```shell
$ tapcli assets send --addr taptb1q[...]tywpre3a
```

The asset IDs and addresses in these examples are truncated in the README, so the shape of the commands is clearer than the values.

## It is still alpha, and the README is emphatic about backups

The mainnet section contains the warnings that matter most. `tapd` has supported mainnet since version `v0.3.0`, and the README says that to avoid loss of funds it is imperative that you read the Operational Safety Guidelines in `docs/safety.md` before using tapd on mainnet. It then states plainly that the daemon is still in `alpha` state, which means there can still be bugs and not all desired data safety and backup mechanisms have been implemented yet. The Umbrel note is the most alarming passage in the file. Do not uninstall or re-install the Lightning Terminal app without first making a manual backup of all local tapd data, if you are using Taproot Assets as part of that app with Umbrel or any comparable node-in-a-box solution, because uninstalling Umbrel apps deletes application data. That application data encumbers Taproot Assets and Bitcoin funds, receiving and sending tapd assets updates the daemon's funds-custody material, and merely having the lnd seed phrase is not enough to restore assets minted or received. Without a backup before deletion, funds are destroyed. The repository has a `backup/` package, but the warning stands as written.

## Where taproot-assets is the wrong tool

Three limits are concrete. The first is that it is an alpha system holding real funds, with the README's own warning that data safety and backup mechanisms are not fully implemented. A team that cannot tolerate an unfinished backup story should not be the first to run this on mainnet with meaningful value. The second is the operational dependency chain. You need lnd built with the right RPC tags, a synced Bitcoin backend, macaroons, TLS material and a federation of universes, and every one of those is something that can break independently. The complexity is not in the protocol but in the number of services that have to be healthy together. The third is scope. This issues assets on Bitcoin using a specific protocol draft, and if your requirement is simply to represent a token on a chain with a mature ecosystem and no experimental specification, the amount of infrastructure to learn here is large.

## The alternative is an issued token on a purpose-built chain

The realistic alternative is a token standard on a chain designed for tokens, where issuance and transfer are the chain's own primitives rather than a layer built on Bitcoin transactions. The difference in approach is where the commitment lives. Taproot Assets keep the asset state committed in Bitcoin Taproot outputs while the witness data is stored off-chain and transferred peer to peer, so a holder needs both the on-chain commitment and the off-chain proof to spend, and the proof has to be carried between parties. A token standard on a purpose-built chain instead stores the balances in the chain's state, which means the transfer is one transaction against a ledger that keeps the state, and the off-chain proof distribution problem does not exist. What you give up is the property that makes Taproot Assets interesting to some people, namely that the assets are anchored to Bitcoin UTXOs and inherit Bitcoin's finality story, and what you gain is a system that is not alpha, with a wallet ecosystem and block explorers that already work. The honest framing is that taproot-assets is the more interesting engineering and the riskier operational choice.

## Conclusion

taproot-assets fits a Bitcoin user who wants assets anchored to Taproot UTXOs and is prepared to operate lnd, a universe federation and the backup discipline the README insists on. It is the wrong tool for a team that cannot run an alpha daemon holding funds, and the wrong tool when a mature token standard on a purpose-built chain would serve better. Before you put value in it, read docs/safety.md as the README instructs, confirm your lnd is at least v0.20.0-beta with the wallet and signing RPC tags compiled in, and set up the manual backup of tapd data before any node-in-a-box app touches it.

## FAQ

### What does tapd do and what is a Taproot Asset?

tapd is the Taproot Assets Daemon, implementing the Taproot Assets Protocol for issuing assets on Bitcoin. Assets are committed into Taproot outputs so several assets can live in one Bitcoin UTXO, while the witness data is transacted and stored off-chain.

### What are the prerequisites for running tapd?

You need lnd version v0.20.0-beta or later, synced and running on the same Bitcoin network, with RPC connections accepted and a valid macaroon present. Taproot Assets itself needs Go 1.24 or higher to build from source.

### How do I mint an asset with tapcli?

Run `tapcli assets mint` with the type, name, supply and metadata, then `tapcli assets mint finalize`. The mint is two phases because the minting transaction, and the outpoint it consumes, becomes the asset's genesis_point.

### Is taproot-assets safe to use on mainnet?

The README says tapd has supported mainnet since v0.3.0 but is still in alpha state, with bugs possible and not all data safety and backup mechanisms implemented. It says to read the Operational Safety Guidelines in docs/safety.md first, and warns that uninstalling the app without a manual backup destroys funds.

## Sources

- [Issues](https://github.com/lightninglabs/taproot-assets/issues)
- [License: MIT](https://github.com/lightninglabs/taproot-assets/blob/main/LICENSE)
- [lightninglabs/taproot-assets on GitHub](https://github.com/lightninglabs/taproot-assets)
- [README](https://github.com/lightninglabs/taproot-assets/blob/main/README.md)
- [Releases](https://github.com/lightninglabs/taproot-assets/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lightninglabs-taproot-assets