LNContract: The Pitch
What is LNContract?
The LNContract application manages the fundamental components of business contracts (sale of goods/services) within the context of Bitcoin and Lightning protocols, from negotiation to formation to performance to payment. It manages draft contracts, signing, party identities, performance and payment obligations. LNContract provides related reporting, for both individual contracts and in the aggregate. In this sense it is not unique to the market. Comparable applications exist in the fiat world. LNContract, however, extends contract management into the Bitcoin/Lightning world. It connects to a party’s LN Node, which then connects to its counterparty’s node. It opens channels with its counterparty and makes payment according to contractual requirements. With respect to the performance obligations, LNContract provides internal signoff mechanism via MuSig implementation. LN Contract uses direct LN channels between counterparties, recognizing that unlike retail transactions, business contracts contemplate a relationship. Direct channels might not scale and so this functionality may need to upgrade, perhaps to a Taro/Fedimint implementation.
That is the vision. In a larger sense, LNContract is the merger of Bitcoin and Contract Law.
Why Build it? What Problems Does it Solve?
Business Contracts are hard to manage—they take technical, legal and financial expertise. Already there is a fiat market for contract management tools. As companies accumulate Bitcoin on their balance sheets the opportunity to use that Bitcoin in business contracts will increase. As adoption increases the opportunity to receive Bitcoin for the production/development of products and services will also increase.
Current applications do not integrate with Bitcoin and so using Bitcoin would require a separate disjointed process/system, thereby increasing the time and risk. It would also require a higher level of Bitcoin/LN expertise than what would normally be needed to manage the contract itself. By integrating Bitcoin/LN into the business contract context, LNContract removes the need for separate disjointed processes, reducing time and risk of error. By abstracting the Bitcoin/LN layers and putting them into the context of the contract, additional Bitcoin/LN expertise is not needed by those managing the contract itself.
By solving these contractual management problems, LNContract allows businesses to take advantage of all Bitcoin and LN, e.g. non-censorship of payments, maintenance of value, more efficient final settlement.
Current Status of the Build.
The LNContract is a basically a Django application making RPC calls to a LN/Bitcoin nodes and using a little React at the front-end. It uses Polar to model the nodes.
Its current status is a skeletal implementation (a precursor to a minimal viable product). It models a contract in terms of the Party, Counterparty, Performance Obligations and Monetary Obligations. The Party user can view all contracts it manages or a specific contract. Under the specific contract page, the Party can track Performance Obligations, phases in a contract such as material procurement, assembly and testing. The skeletal implementation currently allows a party to connect to its LN Node, direct its node to connect to the counterparty’s node, and establish a channel.
Currently, the app uses LND nodes via gRPC, but will incorporate Core-Lightning. Potential connection to Core-Lightning could be through a plugin but I need to better understand Core-Lightning plugins.
Next, I will implement the payment functionality, enabling the Party to pay a Monetary Obligation via Lighting. This will complete the skeletal implementation.
Frankly, my goal for Bolt was to have the complete skeletal implementation in place by the end of the tournament. I encountered a delay when establishing an LN channel between the two Parties. The gRPC implementation of OpenChannel returns a streaming OpenStatusUpdate. To accommodate the streaming response, I needed to learn WebSocket implementation within the context of Django and React. I now have that understanding and the beginnings of the code to do this, but it is not fully in place. Similarly, the payment functionality is not yet in place either. Completing these two items will complete the skeletal implementation.
Roadmap
Once the skeletal implementation is complete, I will create a minimal viable product. This will consist of serving LNContract, likely on Heroku, and having it use actual Bitcoin/LN nodes on testnet.
From that, subsequent development will consist of:
-
Incorporating the actual contract into the application.
-
Take a contract text, make different versions during negotiations, communicate versions with counterparties, keeping track of changes.
-
Cryptographically sign the contract.
-
Take the agreed terms and automatically extract them into the backend database.
-
These are not directly related to Bitcoin/LN protocols, but will be needed, nevertheless.
-
-
Incorporate MuSig/Taproot: Individual Schnorr pubkeys can represent internal sign-offs of a party. For example, individual keys could be held by manufacturing, engineering, finance, legal, management personnel. The aggregate pubkey/signature could then represent final internal signoff. A seller could agree to provide the buyer the status of the internal signatures as a mechanism for the buyer to accurately understand the state of the manufacturing/development. Buyers spend a lot of time and money understanding the real status of their orders. Depending on the relationship of the parties and their relative leverage, sellers and buyers could agree to this level of insight. It would reduce the buyers risk and the seller could be compensated extra for giving this insight.
-
Consider channel splicing as the mechanism to update contract funding. Here it is important to understand the role of an LN Channel within the terms of a contract. The channel would have contractual meaning, i.e. it would establish a status of the contract or provide a party with rights. For example, establishing a channel could contractually mean that the buyer is representing to the seller that it has the funds available for a particular phase of the contract.
-
Consider use Bolt 12: A Bolt 12 Offer could be made to have contractual significance. An Offer from the seller as a Request for Invoice could be part of tender of delivery. While one as a Send Me Invoice could be final settlement or payment of deposit surplus. Similarly, an Offer from the buyer could act as contractual acceptance. A Offer as Send Me Invoice could be final settlement on the buyer side.
-
Use of Fedimint/Taro as the payment network? LN Contract uses direct channels between the parties rather than relying on the LN payment network. This is appropriate because the parties contemplate a relationship. Direct channels might become become uneconomical and so alternatives should be considered, including perhaps Fedimint and Taro.