The Lightning Network Unveils the Taro Alpha Daemon for Better Transactions Output

The Lightning Network has announced the alpha release of Taro daemon, a new implementation to the Taproot-powered protocol, Taro, to enhance transaction throughput.

Bitcoin at the Helm of Global Transactions 

With the possibility of the world’s currencies rerouting through the network’s bitcoin liquidity, this news signals a significant transition to a multi-asset Lightning Network.

Taro uses Lightning’s speed, scalability, and cheap costs in combination with the bitcoin network’s security and reliability. In addition to the new protocol, we’re also announcing our Series B fundraising to expand Lightning Network infrastructure and increase the number of users.

Additionally, The Taro daemon will get more improved features in the future months, like universe functionality. Universes will make it easier for users and asset issuers to interact with Taro asset data, supply issuance, and offer evidence of asset provenance. 

We’ll endeavor to integrate the Taro protocol into lnd and bring Taro assets to the Lightning Network once the on-chain functionality is finished. Lightning channels that may send and receive Taro assets must first be implemented as simple, undisclosed Taproot channels in lnd. We’re really eager to introduce the developer community to the new Lightning capabilities.

This initial version of the daemon is released in order to continue soliciting community feedback and building this open source protocol in public. Given the daemon’s alpha, testnet-only nature, we encourage developers to investigate how Taro might fit into their products, with the understanding that it will be revised and improved as we move closer to a mainnet release.

Taro Minting, Sending, and Receiving

Taro assets are embedded within existing bitcoin outputs or UTXOs. The developer creates a new Taro asset by committing to special metadata in a Taproot output in an on-chain transaction.

When a new asset is minted, the Taro daemon generates the necessary witness data, assigns the asset to the minter’s private key, and broadcasts the newly created bitcoin UTXO to the bitcoin network.

This new outpoint serves as the asset’s genesis point and serves as its unique identifier. Taro minting has several key design features, including verifiability, the ability to issue fungible assets such as currencies, and scalability.

Verifiability is a key design feature of the Taro minting process because it is critical that users receiving Taro assets can easily verify that the received assets were minted by the expected issuer.

This verifiability feature is achieved by minting a globally unique asset ID. This asset ID includes the asset genesis field, as shown in the gif above, which describes the provenance, or origination point, of a Taro asset by specifying the genesis point (i.e. the specific on-chain outpoint in which the asset was first issued).

This part of the minting process ensures that the coins received can be traced back to the expected issuance event.

Taro stablecoin assets must be treated similarly. This asset’s fungibility is encoded with the asset type parameter, which is set to NORMAL (as in the gif). Furthermore, minters can link different sets of the same asset under the same family key to achieve the interchangeability properties required for the same assets minted in different tranches.

Taro’s on-chain efficiency and scalability are critical, so the design allows for multiple Taro actions to be completed in a single on-chain transaction. The demo above creates a single tranche of Taro issuance, but multiple mints can now be performed in the same bitcoin transaction.

Multiple Taro actions (mining, sending, etc.) will be possible in the future in a single bitcoin transaction. The parameter chain anchor is used to combine multiple Taro transactions into a single bitcoin transaction. The anchor txid parameter describes the transaction in which the new assets were issued, and it will be visible from both the user’s local node and any public block explorer.

The Taro address BIP details the data it encodes as well as how implementations can create a Taro address. The characteristics specifying which asset is anticipated to be received are encoded within the address, which makes it impossible for a sender to unintentionally deliver the incorrect asset to a recipient. This is one important feature. With Taro, there are no more horror stories about users unintentionally sending assets to exchanges that do not support those assets.

Lightning Strikes Taro

Taro makes it possible for the Lightning network and bitcoin to both be multi-asset networks. Users can launch Taro channels, which connect at the edges and communicate with the current Lightning Network.

Taro will take advantage of the network effects created by the infrastructure that has been developed over the last few years as well as the nearly 5,000 BTC that are currently allocated to the network as a global routing currency, rather than starting from scratch and bootstrapping a new ecosystem of nodes and liquidity.

Given an already broad and deep payment channel graph, The Lightning Network and Taro are well positioned to meet this market requirement.

Taro’s “edge node” model should result in more volume with no upgrades required as Taro transactions route through BTC. For users on the network’s outskirts, this should imply access to all of the Lightning Network’s technological benefits, such as instant settlement, low fees, and global reach, as well as their preferred Unit of Account.

Simple, unannounced Taproot channels will go through an initial spec review as well as cross-implementation compatibility tests before being merged into lnd in order to bring Taro to the Lightning Network.

The primary feature of lnd 0.16 is this ongoing work. They’ll enter the next phase of development for enabling Taro assets on the Lightning network once it’s completed and launched.