Skip to main content

Transaction Flow

Transactions related to providing inbound capacity over the capacity market happen one after another on two blockchains, Ethereum and the Lightning Network. As a basic requirement, Lightning Nodes handle payment channels over the LN as usual and set transaction fees in sat at their own discretion. Also, gas fees on Ethereum are dealt with by Lightning Nodes.

However, building on the underlying transactions in sat, participating in the capacity market involves the use of PL2. To clarify, payment channels are maintained over the LN in sat while the capacity market transacts in PL2. This procedure handles fees and rewards incurred in PL2 separately via Ethereum.

To summarize, the transaction flow, interaction, and setup of Lightning Nodes on the capacity market works as follows:

  • As a prerequisite, Lightning Node users register an Ethereum wallet and address (e.g. MetaMask).
  • The newly connected Lightning Node uses the capacity market and chooses its role: Liquidity Maker or Taker or both.
  • Makers use the Plenny DLSP module for computing data off-chain.
  • Makers offer the opening of payment channels with inbound capacity over the LN in sat while quoting the Royalties over the capacity market in PL2.
  • The Royalties for opening a channel via Plenny is freely determined by the LM. This cost is expressed as X PL2 per sat per 24 hours (e.g. ≈6,500 blocks).
  • Liquidity Takers can join the capacity market without using the DLSP module. However, Takers only need to lock PL2 for down payment of Royalties. They choose from various offers and opt for the desired inbound capacity.
  • To obtain inbound capacity, Takers lock the quoted Royalties in PL2 in the capacity market.

The interactions in this process consist of several operations highlighted below:

  1. First operation on-chain for reservation via P2C: Takers populate and sign their transaction data to request inbound capacity in sat via HTTPs. This locking event is an on-chain transaction using Ethereum. It is gas-less as the Taker relays this meta-transaction fee for prepayment to the LM.
  2. Second operation off-chain for opening the payment channel on the LN via P2P: As a result, the DLSP module of the Liquidity Maker automatically opens a payment channel and provides transaction data services while providing inbound capacity via the LN over their Lightning Node in sat.
  3. Third operation on-chain for authorization via P2C: In this operation, the DLSP module automatically triggers the smart contract for Channel Rewards in PL2, which get locked in the capacity market contract. This event is a blockchain transaction that requires gas fees to be paid by the LM. These expenses are partly compensated through an immediate payment (i.e. fixed amount) to the LM.

During these operations, Lightning Oracles validate payment channel capacity on the LN and payment details on Plenny as soon as the activity becomes apparent on both sides. The validation requires a blockchain transaction and gas fees to be paid by Lightning Oracles. These costs are offset by the amount of Oracle Validator Rewards that are immediately paid as part of the validation transaction. In the process, Lightning Oracles monitor the opening and closing of the payment channel and trigger the smart contract to release to the Maker the previously locked rewards, which originate from the down payment of the Taker.

Royalties and rewards are distributed gradually. The Fixed Royalty is paid immediately, then the LOC Channel Rewards are distributed daily and the Baseline Reward distribution is split over time. Reaching the total amount of royalties and rewards due is thus aligned with the duration of the payment channel. This means that Liquidity Takers receive a pro-rata refund of their down payment if the payment channel is closed early. The implemented distribution method is a security mechanism to avoid transaction spamming and to ensure users do not close payment channels right after opening them. In summary, this process works as follows:

  • Royalties and Channel Rewards are calculated in 24-hour increments based on the capacity provided. Settlement payments are done at the end of each increment to ensure the channel remains available.
  • To start with, Plenny distributes an immediate initial payment (i.e. Fixed Royalty) of the PL2 locked by the Taker to partly compensate the Maker for expenses. The remaining Royalties and Channel Rewards are distributed proportionally over time for as long as the payment channel is kept open.
  • Royalties and Channel Rewards are automatically distributed among the participants. However, accrued rewards can be collected manually after 1 d (e.g. ≈6,500 blocks). At this point, the amount of collected Royalties and Channel Rewards is deducted from the running balance.
  • When the total Royalties and Channel Rewards are reached, Makers stop earning rewards.
  • Upon payment channel closure, the Taker gets back the remainder of their unspent down payment.