STORY
Business Contract App
AUTHOR
TarunTarun
Joined 2022.09.22
PROJECT
LNContractLNContract
DATE
VOTES
sats
COMMENTS

Business Contract App

Many LN applications are retail oriented, connecting customer and retail seller. These types of transactions don't necessarily require a lasting relationship, at least to effect the transaction. This of course is reasonable, given LN's nature as a payment system designed for faster settlement.

As Bitcoin and LN adoption increases, I am wondering about the viability of Business to Business LN Applications. Unlike retail transactions, Business to Business transactions often require a lasting relationship between the parties. A manufacturer of subsystems supplier to a larger manufacturer buyer, for example, might have contracts to build those subsystems over several months or years and require milestone type payments along the way. In this scenario, the buyer might need to confirm to the supplier that money is actually there that can eventually be paid.

An application that manages this type of relationship through the LN network is intriguing (at least to me!). At a high level it would be this: Essentially the app would handle the basic terms of a contract and manage that contract through a LN channel via RPC.

Because the parties need an existing relationship, a channel would be better than a payment route. The channel itself could embody an aspect of the contract, as we'll see in a minute.

I am mindful that relying on a direct channel will require at least one utxo and so this won't scale, but this aspect could potentially be revised to use a federation or Taro as things develop. (I am not too knowledgeable about federations or Taro so don't beat me up about that. :)).

Consider a manufacturer of electronic subsystems (seller) having a supply contract to a systems integrator (buyer). The supply contract requires:

  1. The seller to manufacture and deliver 12 subsystems.

  2. Delivery of first two units is 9 months from the date of contract and 2 units/month thereafter.

  3. Total Contract is for 150,000,000 sats.

  4. Milestone payments:

    1. materials on order: 25,000,000 sats

    2. stage 1 assembly: 15,000,000 sats

    3. stage 2 assembly: 30,000,000 sats

    4. subsystem testing: 60,000,000 sats

    5. delivery and acceptance: 20,000,000 sats

But would the seller even start work on this without anything? Maybe if he knew money was ear-marked for the contract. The channel itself could serve this purpose, acting as a quasi Letter of Credit. Buyer could give the seller some comfort by funding a channel for 30,000,000 sats at contract signing and then fund further channels (or splice in more funding) at regular intervals.

The app manages the contract. It would create funding and payment terms. It would create invoices and receive payments. It would effect all of this through an RPC connection to its LN Node and ultimately to the counterparty's node via the channel. Ideally, the counterparty would also be using the app, which the contract could require.

An additional feature could be for the app to run a limited server for the purpose of communicating contractual matters with the counterparty. Payments could be automated based on internal approvals or the occurrence of events as determined by a neutral third party/oracle. The app itself could embody the contract--that is contain the contract and signatures and pull from that its major terms to create the required objects.

This application could be customized to any type of manufacturing contract, one that anticipates payments over time or more generally any type of contract that needs to be managed.

This type of application could help expose Bitcoin and LN to a wider audience, one that might already have the need--that is Bitcoiners who run businesses or want to be paid in Bitcoin.

For the purpose of Legends, a basic prototype could be built.

  1. App creates funding and payment objects, both types having an amount attribute.

  2. The app would the establish an rpc connection.

  3. Direct its related LN node to open a channel with the counterparty's node.

  4. Use payment/funding objects to create an invoice.

  5. Send invoice to its node to forward to the counterparty.

  6. Receive invoice--process it and then direct LN node to pay.

I have the beginnings of this at https://github.com/TKChattoraj/LNContractApp . This uses python and pyQt for the gui. The setup uses polar to replicate the LN Nodes and the Bitcoin Node.