RGB And Taro, Both Putting Tokens On Bitcoin, Take Two Different Approaches To Development

RGB and Taro, two protocols capable of putting tokens like stablecoins on Bitcoin, have taken different approaches to solving similar problems.

This is an opinion editorial by Kishin Kato, the founder of Trustless Services K.K., a Japanese Lightning Network research and development company.

Demand for stablecoins on Bitcoin is returning as the Lightning Network offers massive scalability advantages. Currently, users in emerging markets who want to transact and save in USD will settle for stablecoins on other chains, according to proponents. Putting my personal feelings about these other blockchains aside, I must acknowledge that bitcoin received in cheap, cross-border remittances cannot easily be sold for dollars while they reside in non-custodial Lightning channels.

RGB and Taro are two new protocols that enable token issuance on Bitcoin, and are therefore expected to bring stablecoin transactions on Lightning. I studied these protocols and the client-side validation paradigm that they employ and published a report on my findings called “Emergence Of Token Layers On Bitcoin” through Diamond Hands, a major Japanese Lightning Network user and developer community and Bitcoin-focused solution provider.

During this research, I noticed subtle differences in how these seemingly-similar protocols were being developed, and became interested in how these differences may affect their trajectories. In this article, I would like to share my impressions of these projects and how they may affect Lightning as we know it.

Priorities And Mindset, Revealed Through Protocol Development

Protocol development is not easy, and often takes years. Deciding what features to prioritize and compromise on is critical, and one of the primary differentiators between RGB and Taro is the decisions they have made in that regard.

RGB, with its ambitions as a smart-contracting layer on top of Bitcoin (i.e., not just for tokens), has a robust on-chain protocol to execute off-chain state transitions. Careful design has resulted in superior privacy, on-chain scalability and versatility, at the cost of conceptual complexity. On the other hand, Taro seems to be more focused on off-chain use, such as on the Lightning Network, specifying methods for multi-hop payments and token exchange. However, among the practical shortcuts Taro has taken in favor of conceptual simplicity is its neglect to standardize at least one basic building block of its on-chain protocol.

Since Taro assets are stored using an on-chain UTXO, Taro transactions can theoretically be constructed in two ways: one where the sender pays bitcoin for the recipient’s output, and the other where the recipient contributes their own input to pay for it themselves. The former case is simpler, but the sender is effectively gifting some bitcoin; the latter can be more precise, but requires sender-recipient interaction to create the transaction. Unless these methods and their selection are standardized, wallet interoperability is a pipe dream.

Perhaps Taro’s reluctance to standardize such a basic component can be explained by its approach to development. Overall, while RGB is being developed quite transparently, Lightning Labs seems to reserve more control over its project in Taro, possibly to take a more iterative, feedback-based approach to bringing its product to market.

Indeed, once a protocol is widely adopted it is difficult to update or replace without breaking interoperability. However, this is not necessarily the case if your implementation is the only one. Lightning Labs may be reserving its ability to rapidly iterate by intentionally postponing widespread adoption of the protocol. I got this impression from the aforementioned gap in standardization, as well as the fact that Lightning Labs plans to ship its Taro wallet with LND, its Lightning node implementation with more than 90% market share.

It is certainly possible that Lightning Labs’ approach will be more successful at bringing tokens to Lightning. But unless it surrenders its dominant role at some point, Taro risks becoming little more than an LND API. It is not unimaginable to me that Taro will remain an LND-specific feature.

Will Lightning Survive Tokens?

As a semi-paranoid Bitcoiner, I must wonder if the proliferation of tokens on Bitcoin will result in negative consequences for the Lightning Network or Bitcoin itself. While concerns of the latter are validated by Circle’s (the issuer of USDC) ability to influence users during any potential contentious hard fork in Ethereum, I would like to point out a specific avenue of concern for Lightning.

As mentioned earlier, Taro’s approach if continued will result in the increased utility of LND through use of its included Taro wallet, in relation to other implementations. This can potentially further lock in LND’s dominant position in the node implementation landscape. To keep Lightning decentralized, it is preferable that users are spread more evenly across multiple implementations, so that even the most popular implementation cannot simply implement protocol changes without consequence to its users.

While I personally am not a fan of the vast majority of crypto tokens, I do believe that the Lightning Network has something to prospectively offer users of such tokens: fast, private and decentralized exchange and payments. Being able to pay someone in their local or preferred currency instantly, without the sender owning any of it, has immense potential to disrupt existing payment and remittance rails. Though it is unclear what protocol will prevail for token issuance on Bitcoin, I hope that proliferation of tokens will not sacrifice the things that bitcoin and Lightning stand for.

This is a guest post by Kishin Kato. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Read the full article here