We're excited to announce the release of Taproot Assets v0.8, along with the first public release of the Taproot Assets SDK, a client library that makes it dramatically easier to build applications on top of Taproot Assets.

Taproot Assets is the first multi-asset Lightning protocol on mainnet, where assets like stablecoins can be minted on bitcoin and sent over the Lightning Network instantly and for low fees. With Taproot Assets, Lightning becomes a scalable, multi-asset network anchored in bitcoin's security and decentralization.

Building an application on Taproot Assets means talking to tapd, the Taproot Assets daemon, which is the background process that holds your assets, builds transactions, and manages proofs. The daemon exposes the full protocol surface, including asset IDs, group keys, mint batches, and tranches, which gives advanced developers precise control. The Taproot Assets SDK builds on that surface with a higher-level interface that maps those primitives to the operations most applications reach for, and v0.8 ships the daemon changes that the SDK relies on. Together, they shorten the path from idea to working application.

Some of the release highlights include:

• The Taproot Assets SDK, a client library that exposes assets, collections, issuances, balances, proofs, and universe discovery through a single asset handle, so you no longer have to track raw protocol identifiers by hand.
• Wallet backup and restore, with three formats that trade off backup size against how much data is reconstructed on import, giving operators a practical way to protect the Taproot Assets layer of a wallet.
• Burn and transfer by group key, which lets you burn or move a grouped asset without first picking apart which individual issuances hold the units.
• Edge node operation improvements, giving the routing nodes that sit at the edge of the network, connecting users to it and forwarding their asset payments, more control over how they price and route. This includes a new service contract that lets operators move pricing, hedging, and quote-acceptance logic out of tapd and into their own external engine.
• Auditability and reliability improvements across forwarding history, proof verification performance, and the request-for-quote flow that prices asset payments on Lightning.

As always, we're grateful for the ongoing support of our external contributors across development, review, and testing. For the complete list of changes in this release, check out the full release notes.

Meet the Taproot Assets SDK 📦

The Taproot Assets SDK, distributed as a Go package, is a client-side library for applications that talk to tapd. It maps the protocol's primitives to operations that match how developers think about assets, so common flows take fewer steps and less bookkeeping. The result is that issuing, sending, and tracking assets on bitcoin starts to feel like working with an ordinary application library, which lowers the barrier to building real products on Taproot Assets. The SDK requires tapd v0.8.0 or newer, since it depends on the per-row asset type data and group-key-aware records that this release adds to keep grouped fungibles and collectible items cleanly distinguished.

The clearest example of improved ease of use is how the SDK handles asset identity. At the protocol level, an asset might be addressed by an asset ID, which identifies one specific issuance, or by a group key, which ties together every issuance of the same asset so the units remain interchangeable. Tracking which identifier to use, and when, has been a common request from the developer community for a simpler approach. The SDK replaces both with a single value called an AssetRef, a self-verifying string that you store, pass around, and expose over your own APIs. The SDK figures out the right underlying identifier at the point where it talks to the daemon, so your application code carries one handle from start to finish.

That one handle works everywhere. You use the same AssetRef to request a receive address, send to one or many recipients, check balances, export and import proofs, burn units, prove ownership, and query the universe, which is the network of servers that store and share the proofs backing each asset. A developer writing a payments flow, an issuer dashboard, or an asset explorer can hold onto one reference rather than threading protocol details through every call.

The SDK also clarifies the relationship between concepts that are closely related at the protocol level. A fungible asset, meaning a token where every unit is interchangeable, is distinct from an issuance, which is a single supply-increasing event for that token. A standalone collectible is distinct from a collection, which is a named grouping of collectible items and is not itself an asset. The SDK keeps these as separate types with plain names, so CreateFungible returns an asset while IssueFungible returns an issuance, and the list methods return exactly the kind of object you asked for. You get the convenience of high-level operations while the underlying distinctions stay visible.

Getting connected takes a transport package and a few lines of configuration. The SDK ships two transports, which are the layers that carry requests to the daemon: a native gRPC client and a REST client. gRPC is a high-performance protocol well suited to long-lived server applications, while REST is the familiar request-and-response style used by most web services. Both return the same SDK types and the same errors, so you can pick whichever fits your stack and switch later without rewriting your application logic. Connections authenticate with TLS, which encrypts the link to the daemon, and macaroons, which are bearer credentials that scope what a given caller is allowed to do.

The current Go library is the source of truth for the SDK's design, and that design is deliberately portable. The business concepts are meant to carry over to future SDKs in other languages, so a TypeScript, Rust, Python, Kotlin, or Swift library can expose the same AssetRef, wallet, issuer, and universe surfaces even where the package layout differs.

Backups That Fit Your Operation 💾

The latest v0.8 release introduces wallet backup and restore for the Taproot Assets layer, with three modes that let operators choose how to balance backup size against the work done at restore time.

The three modes trade backup size against how much work happens at restore time:

• Raw mode exports complete proof files, which produces the largest backup and the most self-contained one.
• Compact mode strips out the fields that can be recomputed from the blockchain, then reconstructs them on import, which yields a significantly smaller file.
• Optimistic mode goes furthest by omitting proofs entirely and fetching them from a universe federation server, which is a shared, replicated store of asset proofs, during restore, producing the smallest backup of the three.

On import, tapd automatically detects and skips stale assets whose anchor outputs have already been spent, so a restore does not resurrect units that have since moved on.

Two operational details are worth keeping in mind. Backup files contain asset key derivation paths, similar to exporting a wallet descriptor, so they should be stored securely. And because the backup covers only the Taproot Assets layer, a full restore still requires access to the corresponding LND wallet, the underlying Lightning node implementation that holds the keys and signs transactions.

Working With Grouped Assets the Way You Think About Them 🔑

A grouped asset is a single logical token whose supply may have been minted across several issuances over time. In earlier versions, acting on that token at the unit level meant identifying the specific issuances that held the units you wanted to touch. This release lets you operate on the group directly.

You can now burn an asset by specifying its group key instead of a specific asset ID. When you burn by group key, the daemon selects and burns units across all of the issuances in the group on your behalf, producing multiple burn outputs when needed, and the tapcli assets burn command accepts a new --group_key flag for exactly this. Transfer and burn records also gained group key and asset type fields, which is the same daemon-level change that lets the SDK keep grouped fungibles and collectible items cleanly separated. The result is that both a command-line operator and an application built on the SDK can treat a grouped asset as one thing.

Edge Node Operation Improvements 📈

Several v0.8 improvements target edge node operators who price and route asset payments using the RFQ system, which is the mechanism two nodes use to agree on an exchange rate before forwarding an asset payment.

The headline addition lets an operator delegate quote orchestration to an external engine. Pricing, hedging, and acceptance policy can now live in a single external service of the operator's own design rather than being built into tapd, wired up through the new experimental.rfq.portfoliopilotaddress configuration option. A reference implementation ships under docs/examples, complete with constraint enforcement, configurable fill caps, and live pricing from a public market-data source.

RFQ orders also gained finer controls. Buy and sell orders can now carry explicit limit-price bounds and minimum fill sizes, and quotes that violate those constraints are rejected. Orders can specify an execution policy, choosing between Immediate-Or-Cancel, which permits a partial fill above the minimum, and Fill-Or-Kill, which requires the full requested amount or rejects the quote outright. Accept messages can signal the maximum amount the responder is willing to fill, and that negotiated quantity caps the forwarding policy so a payment never exceeds what both sides agreed to. These fields are optional and backward-compatible, so existing integrations keep working and the new validation only kicks in when you opt into it.

Auditability and Reliability Under the Hood 🔍

The rest of the release hardens tapd for production use.

Routing nodes can now track and query historical asset forwarding events. When a node successfully routes an asset payment, the forward event is logged, which gives edge nodes an audit trail of their swap activity, queryable through the new tapcli rfq forwardinghistory command with filters for time range, peer, asset ID, and group key. For complete results, we recommend starting LND with the --store-final-htlc-resolutions flag, which captures the payment-resolution data this history draws on and is disabled by default.

Further, proof verification got much faster. The block header checks that run while receiving proofs, which confirm that the bitcoin blocks backing an asset's history are real, are now deduplicated and run in parallel rather than one after another. Benchmarks show roughly a sevenfold speedup for proof files that contain many unique headers, which is a meaningful improvement for nodes that import large histories.

tapd also now garbage-collects orphaned outputs, sweeping leftover tombstone and burn outputs while it builds on-chain transactions, which keeps a node's on-chain footprint tidy over time. Sweeping is on by default and can be disabled with the wallet.disable-sweep-orphan-utxos flag.

On the security side, RFQ clients such as the price oracle and the external quote engine now verify TLS certificates by default using the operating system's trusted certificate list, and previously always-available RPC endpoints are now governed by explicit read, write, and courier permissions, tightening access control to match what operators expect.

The release also includes pagination across the asset and universe listing RPCs, a long list of bug fixes covering channel close handling, minting batch consistency, and database edge cases, and a new tapcli bakemacaroon command for minting custom credentials with scoped permissions. The full release notes have the complete breakdown.

Get Started 🚀

The combination of v0.8 and the Taproot Assets SDK is meant to make the first hour of building on Taproot Assets feel a lot more productive. This release returns the full asset data a client needs to work with assets directly, and the SDK turns that data into operations you can read at a glance.

To start with the SDK, install it with go get github.com/lightninglabs/tap-sdk, point it at a tapd v0.8 node, and walk through the getting started guide, which covers connecting, issuing assets, sending and receiving, proofs, and universe queries. The integration test suite doubles as runnable, end-to-end examples for each of those flows against a local regtest stack, which is a private test network where blocks are generated on demand so you can experiment without spending real funds.

To start using Taproot Assets, download the v0.8 release, read the release notes, and check out the API docs. For a deeper technical explanation of Taproot Assets, dig into our developer documentation, or watch our Tapping into Taproot Assets series on YouTube.

It's been amazing to see the bitcoin developer community build new experiences with Taproot Assets, from web and mobile wallets to asset explorers, and developer tools, with more arriving every day. Want to get involved? Join our Slack community, follow us on Twitter/X, attend the Taproot Assets Community Calls, contribute a PR, or subscribe to our newsletter. The future of multi-asset bitcoin is upon us!