RGB and Taro, two protocols capable of putting tokens as stablecoins on Bitcoin, have taken different approaches to solving similar problems.
This is an opinion editorial from Kishin Kato, the founder of Trustless Services KK, a Japanese Lightning Network research and development company.
Demand for Bitcoin stablecoins is making a comeback as the Lightning Network offers huge 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. My personal feelings about these other blockchains aside, I must admit that bitcoins received in cheap cross-border remittances cannot be easily sold for dollars while residing in non-custodial Lightning channels.
RGB and Taro are two new protocols that allow the issuance of tokens on Bitcoin and are therefore expected to bring stablecoin transactions on Lightning. I studied these protocols and the client-side validation paradigm they employ and published a report on my findings called “Appearance of token layers in Bitcoin” through diamond handsa major Japanese community of Lightning Network users and developers and Bitcoin-focused solution provider.
During this research, I noticed subtle differences in how these seemingly similar protocols were developing 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 might affect Lightning as we know it.
Priorities and mindset, revealed through protocol development
Protocol development is not easy and often takes years. Deciding which features to prioritize and compromise on is critical, and one of the main differentiators between RGB and Taro is the decisions they’ve made around it.
RGB, with its ambitions as a smart contracting layer on top of Bitcoin (ie not just for tokens), has a robust on-chain protocol for executing 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 usage, such as on the Lightning Network, specifying methods for multi-hop payments and token swapping. However, among the practical shortcuts Taro has taken in favor of conceptual simplicity is his neglect to standardize at least one basic component of his 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 ticket to pay. The first case is simpler, but the sender is effectively giving away some bitcoin; the latter may be more accurate, but requires interaction between the sender and the recipient 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 being developed fairly transparently, Lightning Labs appears to be reserving more control over its Taro project, possibly to take a more iterative and feedback-based approach to bringing its product to market.
In fact, 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 be reserving its ability to iterate quickly by intentionally postponing widespread adoption of the protocol. I get this impression because of the aforementioned gap in standardization, as well as the fact that Lightning Labs plan to send your Taro wallet with LNDyour Lightning node implementation with more than 90% market share.
Certainly the Lightning Labs approach may have more success in bringing tokens to Lightning. But unless he steps down from his dominant role at some point, Taro risks becoming little more than an NLD API. It’s not unimaginable to me that Taro will continue to be a specific feature of LND.
Will Lightning survive the chips?
As a semi-paranoid Bitcoiner, I have to wonder if the proliferation of Bitcoin tokens will have negative consequences for the Lightning Network or Bitcoin itself. While the latter’s concerns are validated by Circle (the USDC issuer) ability to influence users during any potential contentious hard fork on EthereumI’d like to point out a specific avenue of concern for Lightning.
As mentioned above, Taro’s approach, if continued, will result in higher LND utility by using its included Taro wallet, relative to other implementations. This may further block LND’s dominant position in the node deployment landscape. To keep Lightning decentralized, it’s preferable that users be more evenly distributed across multiple implementations, so that even the most popular implementation can’t simply roll out protocol changes without consequences to its users.
While I’m personally not a fan of the vast majority of crypto tokens, I believe the Lightning Network has something to 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 anything, has immense potential to disrupt existing payment and remittance rails. Although it is not clear which protocol will prevail for the issuance of tokens in Bitcoin, I hope that the proliferation of tokens will not sacrifice the things that Bitcoin and Lightning represent.
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.
