RGB and Taro, two protocols that can place stablecoin-like tokens on Bitcoin, have taken different approaches to solving the same problem.
This is an editorial opinion by Kishin Kato, founder of Trustless Services KK, a Japanese Lightning Network research and development company.
The demand for stablecoins in Bitcoin is back because the Lightning Network offers great scalability advantages. Now, users in emerging markets who want to transact and store in USD will establish stablecoins on other chains, according to supporters. Putting aside my personal feelings about these other blockchains, I have to admit that the bitcoins I receive for cheap, cross-border remittances cannot be traded easily for dollars while residing in the non-custodial Lightning channel.
RGB and Taro are two new protocols that enable the issuance of tokens in Bitcoin, and therefore are expected to bring stablecoin transactions to Lightning. I studied the protocol and the client-side validation paradigm used and published a report on my findings called “Emergence Of Token Layers On Bitcoin” through Diamond Hands, the 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 developed, and became interested in how these differences could affect their trajectory. In this article, I want to share my impressions of the project and how it will affect Lightning as we know it.
Priorities and Mindsets, Revealed Through Protocol Development
Protocol development is not easy, and often takes years. Determining which features to prioritize and compromise is critical, and one of the main differentiators between RGB and Taro is the decision that has been made about it.
RGB, ambitiously a smart contract layer on top of Bitcoin (ie, 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 flexibility, at the cost of conceptual complexity. On the other hand, Taro seems to focus more on off-chain use, such as on the Lightning Network, defining methods for multi-hop payments and token exchanges. However, among the practical shortcuts that Taro takes for conceptual simplicity is the neglect of standardization of at least one basic building block of the on-chain protocol.
Since Taro assets are stored using UTXO on-chain, Taro transactions can theoretically be built in two ways: one where the sender pays the recipient in bitcoin for output, and the other where the recipient contributes their own input to pay for themselves. The former case is simpler, but the sender effectively gives some bitcoins; the latter can be more precise, but requires sender-receiver interaction to create a transaction. Apart from these methods and default options, wallet interoperability is a pipe dream.
Maybe Taro’s reluctance to standardize the basic components can be explained by the development approach. Overall, while RGB is being developed transparently, Lightning Labs seems to have more control over the project at Taro, perhaps taking a more feedback-based approach to bringing the product to market.
Indeed, once a protocol is widely adopted, it is difficult to update or change it without destroying interoperability. However, this is not always the case if your implementation is the only one. Lightning Labs may be preserving its speedy capabilities by deliberately delaying adoption of the protocol. I get this impression from the standardization gap, as well as the fact that Lightning Labs plans to ship the Taro wallet with LND, a Lightning node implementation with over 90% market share.
It is likely that Lightning Labs’ approach will be more successful in bringing tokens to Lightning. But if it does not give up its dominant role at some point, Taro risks becoming little more than API LND. It is not unimaginable to me that Taro will keep LND-specific features.
What is Lightning Survive Token?
As a semi-paranoid Bitcoiner, I have to wonder if the proliferation of tokens in Bitcoin will have negative consequences for the Lightning Network or Bitcoin itself. When the concerns of the latter have been validated by Circle (the issuer of USDC) the ability to influence users during any potential contentious hard fork in Ethereum, I would like to bring out a specific avenue of concern for Lightning.
As mentioned earlier, the Taro approach if continued will increase the utility of LND by using the included Taro wallet, in relation to other implementations. This could potentially further lock in LND’s dominant position in the node implementation landscape. To maintain Lightning’s decentralization, it’s best to have users evenly distributed across multiple implementations, so that the most popular implementations can’t just implement protocol changes without consequence to users.
While I don’t like the majority of crypto tokens, I believe that the Lightning Network has something to offer users for these tokens: fast, private and decentralized exchanges and payments. Being able to pay people in their local or preferred currency quickly, without the sender owning it, has huge potential to disrupt existing payment and remittance rails. Although it is not clear what protocol will be used for the issuance of tokens in Bitcoin, we hope that the spread of tokens will not sacrifice the things that bitcoin and Lightning have in mind.
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.