While the limitations of Bitcoin Script hinder on-chain enforcement of contracts using global consensus rules, the Lightning channel state is managed locally between the relevant peers, allowing for various custom state management protocols to be explored. Solutions such as DLCs aim to achieve privacy and on-chain settlement of contracts for difference that rely on oblivious oracles, and similar contracts can be recreated on Lightning channels, enabling trust-minimized peer-to-peer trades, at least between peers who share a channel.
The tradeoff space that can be explored is even greater if the relationship between those peers is such that compromises can be made regarding on-chain enforceability, e.g. if trustlessness is overkill and being able to prove fraud is sufficient. Such channels can handle concepts such as credit, settlement on other blockchains or databases, and more.
Channels based on credit already exist in a limited capacity, commonly known as hosted channels, and are already being used to provide community banking services such as fiat-denominated Lightning channels (a delicate topic for another day). In theory, even exchange accounts can be represented as a hosted channel! Such constructs give us flexibility to explore financial use cases and user experiences today, particularly where the service provided requires custody and trust anyway.
In addition to the possibilities that custom state management on individual channels can bring, this peer-to-peer finance limits systemic risk to the network. If a credit-based channel provider is insolvent, the credit-based channels with its users may be affected, but other channels in the network would not be (assuming they don’t rely on this provider behind the scenes). Regular Lightning channels, in particular, are completely immune, as they are fully collateralized and permissionless.
Finally, we are also seeing projects experimenting with token issuance schemes that enable transfers over Lightning. In my opinion, the advantages of this approach over others is unclear at best, as most tokens are predicated on the provision of services by a centralized party, and can therefore be better served by a centralized database or hub-and-spoke model. Nonetheless, there seems to be interest in developing tokens on Lightning, which could result in some useful innovations.
As a payments technology, it is important to consider what pain points the Lightning Network is well positioned to solve. Given recent events, one answer is becoming clearer and clearer: Lightning enables payments that resist censorship and deplatforming.
Indeed, the Web5 concept announced by Jack Dorsey’s project TBD, is focused on building a decentralized application platform that aims to free users and developers from the stranglehold of major tech platforms and payment processors by separating the concerns of identity, data storage, authentication and app distribution.
While Web5 itself does not necessitate the use of Lightning or bitcoin, it is obvious that a web where users run servers to selectively provide data to applications has a strong synergy with Lightning (even if most choose not to run their own servers/nodes!). Indeed, although not representative of the general public by any means, Lightning enthusiasts run thousands of nodes, thanks in part to the efforts of projects like Umbrel, RaspiBlitz and many more node managers.
In fact, since Lightning payments are technologically an atomic trade between a pre-committed piece of information (preimage) and bitcoin, it is especially suited for payments for information, be it paid content, data retrieval or key material. There already exist lapps (Lightning-powered apps) that explore some of these use cases.
Great Crypto post. We've reshared it.
🙏🔁👍
Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit