LNContract: Work in Progress

LNContract is a Python/Django app with a bit of React on the front-end to enable WebSocket functionality. It uses Polar for the Bitcoin/LN nodes. Currently, it has LND node functionality, but I will add Core-Lightning nodes soon. The app models a contract in terms of the Party, Counterparty, Performance Obligations and Monetary Obligations. A user Party can view all contracts it manages or a specific one. For a specific contract, a Party can track Performance Obligations—the phases in a contract such as material procurement, assembly and testing. The app allows a Party to connect to its LN Node, direct its node to connect to the Counterparty’s node, and establish a channel. I am currently working on the payment functionality, which will enable a Party to pay its Monetary Obligation via the appropriate LN channel. For the next phase, I will build out a minimal viable product. At the least, this will entail publicly serving the skeletal implementation using actual Bitcoin/LN Nodes (both LND and Core-Lightning) under testnet. Subsequent development will include: 1. Incorporate the actual contract into the application. i. Track different versions during contract negotiations. Provide a negotiations management functionality. ii. Cryptographically sign the contract. (I developed a script to provide this, but haven’t yet included it in the skeletal implementation. For production, this would need to be more closely looked at.) iii. Automatically extract the agreed to terms to populate the application models for use. (This automation would be very desirable for those who are managing the contracts.) iv. These are not directly related to Bitcoin/LN protocols, but will be needed, nevertheless. 2. Provide sign-off functionality. Internal approvals are often required for process management. For example, purchasing, engineering, manufacturing, finance, legal, management personnel might be required to sign off at various stages of a manufacturing contract. Similarly, various buyer personnel might be required to approve a payment. Knowledge of signature status can give insight into contractual progress. i. Model the individual approvals as Schnorr signatures using a MuSig scheme. The aggregate Schnorr signature act as a representation or notice of product completion. Functionality requires key generation, signature creation, tracking, and transmitting pubkeys and signatures to the Counterparty. 3. Consider use of 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. The actual Request for Invoice could act as contractual acceptance. An Offer as a Send Me Invoice could be final settlement or payment of deposit surplus. Similarly, an Offer from the buyer as a Request for Invoice could act as contractual acceptance. A Officer as Send Me Invoice could be final settlement on the buyer side. 4. Channel Splicing. Consider channel splicing as the mechanism to update contract funding. Here it is important to understand that the LN Channel could be given contractual meaning, i.e. it could act as a contractual representation that funds are sufficient for a particular purpose. Channel splicing could be a means to incrementally fund a contract phase, adding to the funding while maintaining an existing channel and in the process acting as an updated contractual representation. 5. Covenants. Consider use of Covenants as a way to ensure payment of subcontractors. 6. 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 uneconomical as adoption increases, given the requirement for an on-chain transaction. If so, alternatives should be considered, including perhaps Fedimint and Taro.
Built with:

Django/React/Lightning/gRPC

github
About the project

LNContract is a Python/Django app with a bit of React on the front-end to enable WebSocket functionality. It uses Polar for the Bitcoin/LN nodes. Currently, it has LND node functionality, but I will add Core-Lightning nodes soon.

The app models a contract in terms of the Party, Counterparty, Performance Obligations and Monetary Obligations. A user Party can view all contracts it manages or a specific one. For a specific contract, a Party can track Performance Obligations—the phases in a contract such as material procurement, assembly and testing. The app allows a Party to connect to its LN Node, direct its node to connect to the Counterparty’s node, and establish a channel. I am currently working on the payment functionality, which will enable a Party to pay its Monetary Obligation via the appropriate LN channel.

For the next phase, I will build out a minimal viable product. At the least, this will entail publicly serving the skeletal implementation using actual Bitcoin/LN Nodes (both LND and Core-Lightning) under testnet.

Subsequent development will include:

1. Incorporate the actual contract into the application.

i. Track different versions during contract negotiations. Provide a negotiations management functionality.
ii. Cryptographically sign the contract. (I developed a script to provide this, but haven’t yet included it in the skeletal implementation. For production, this would need to be more closely looked at.)
iii. Automatically extract the agreed to terms to populate the application models for use. (This automation would be very desirable for those who are managing the contracts.)
iv. These are not directly related to Bitcoin/LN protocols, but will be needed, nevertheless.

2. Provide sign-off functionality. Internal approvals are often required for process management. For example, purchasing, engineering, manufacturing, finance, legal, management personnel might be required to sign off at various stages of a manufacturing contract. Similarly, various buyer personnel might be required to approve a payment. Knowledge of signature status can give insight into contractual progress.
i. Model the individual approvals as Schnorr signatures using a MuSig scheme. The aggregate Schnorr signature act as a representation or notice of product completion. Functionality requires key generation, signature creation, tracking, and transmitting pubkeys and signatures to the Counterparty.

3. Consider use of 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. The actual Request for Invoice could act as contractual acceptance. An Offer as a Send Me Invoice could be final settlement or payment of deposit surplus. Similarly, an Offer from the buyer as a Request for Invoice could act as contractual acceptance. A Officer as Send Me Invoice could be final settlement on the buyer side.

4. Channel Splicing. Consider channel splicing as the mechanism to update contract funding. Here it is important to understand that the LN Channel could be given contractual meaning, i.e. it could act as a contractual representation that funds are sufficient for a particular purpose. Channel splicing could be a means to incrementally fund a contract phase, adding to the funding while maintaining an existing channel and in the process acting as an updated contractual representation.

5. Covenants. Consider use of Covenants as a way to ensure payment of subcontractors.

6. 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 uneconomical as adoption increases, given the requirement for an on-chain transaction. If so, alternatives should be considered, including perhaps Fedimint and Taro.