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 piece by Kishin Kato, the founder of Trustless Services KK, a Japanese Lightning Network research and development company.
Demand for stablecoins on Bitcoin is returning as the Lightning Network offers massive scalability benefits. Currently, users in emerging markets who want to transact and save in USD will settle for stablecoins on other chains, proponents say. Putting aside my personal feelings about these other blockchains, I have to acknowledge that bitcoins received in cheap cross-border remittances cannot easily be sold for dollars while residing in lightning channels not custodians.
RGB and Taro are two new protocols that enable the issuance of tokens on Bitcoin, and therefore should bring stable transactions on Lightning. I have studied these protocols and the client-side validation paradigm they employ and have published a report on my findings titled “Emergence of token layers on Bitcoin” through diamond handsa large Japanese community of Lightning Network users and developers and a provider of Bitcoin-focused solutions.
During this research, I noticed subtle differences in how these seemingly similar protocols were developed and became interested in how these differences may affect their trajectories. In this article, I’d like to share my thoughts on these projects and how they can affect Lightning as we know it.
Priorities and mindset, revealed through the development of protocols
Protocol development is not easy and often takes years. Deciding which features to prioritize and making trade-offs is key, and one of the key differentiators between RGB and Taro is the decisions they made in this regard.
RGB, with its ambitions as a smart contract layer on top of Bitcoin (i.e. not just for tokens), has a robust on-chain protocol for performing off-chain state transitions. Careful design has resulted in superior privacy, scalability, and on-chain versatility, at the cost of design complexity. On the other hand, Taro seems to focus more on off-chain usage, such as the Lightning Network, specifying multi-hop and token swap payment methods. However, among the handy shortcuts Taro has taken in favor of conceptual simplicity is his neglect to standardize at least one basic element of his on-chain protocol.
Since Taro’s assets are stored using an on-chain UTXO, Taro’s transactions can theoretically be constructed in two ways: one where the sender pays bitcoin for the receiver’s output, and the another where the recipient makes his own contribution to pay for it himself. The first case is simpler, but the sender is actually offering bitcoin; the latter can be more accurate, but requires sender-receiver 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 his approach to development. Overall, while RGB is developed fairly transparently, Lightning Labs appears to be reserving more control over its project in Taro, possibly taking 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 it without breaking interoperability. However, this is not necessarily the case if your implementation is the only one. Lightning Labs may reserve its ability to iterate quickly by intentionally postponing widespread adoption of the protocol. I got this impression from the aforementioned standardization gap, as well as the fact that Lightning Labs plans to ship its Taro wallet with LNDits Lightning Node implementation with more than 90% market share.
It’s certainly possible that Lightning Labs’ approach will be more successful in bringing tokens to Lightning. But unless he relinquishes his dominant role at some point, Taro risks becoming little more than an LND API. It’s not unimaginable to me that Taro will remain an LND-specific feature.
Will Lightning survive the chips?
As a semi-paranoid Bitcoiner, I have to wonder if the proliferation of tokens on Bitcoin will lead to any negative consequences for the Lightning Network or Bitcoin itself. While the latter’s concerns are validated by Circle’s (the USDC issuer) ability to influence users during any potentially contentious hard forks in EthereumI would like to highlight a specific area of concern for Lightning.
As mentioned earlier, Taro’s approach, if continued, will result in increased utility of LND through the use of its included Taro Wallet, compared to other implementations. This can potentially further lock in LND’s dominant position in the node implementation landscape. To maintain Lightning’s decentralization, it’s best if users are spread more evenly across multiple implementations, so that even the most popular implementation can’t simply implement protocol changes without consequence to its users.
While I’m not personally a fan of the vast majority of crypto tokens, I think the Lightning Network has something to offer users of these tokens: fast, private, and decentralized exchanges and payments. Being able to pay someone in their local or preferred currency instantly, without the sender owning it, has immense potential to disrupt existing payment and remittance rails. Although it is not clear which protocol will prevail for the issuance of tokens on Bitcoin, I hope that the proliferation of tokens does not sacrifice the things that Bitcoin and Lightning stand for.
This is a guest post by Kishin Kato. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.