Comment on page
Introduction
In the Hub and Spoke model, the platform ("Hub") acts as a centralized hub with which all the entities ("Spokes") in the platform interact and have channels with. The hub provides outbound liquidity to all spokes, coordinates payments and handles state updates. The platform does not expose public keys and channel ids, and handles lightning channels and state updates internally. This reduces the possibility of attacks by entities since they don't have a copy of their state (only the platform does). This however, this increases trust and responsibility on the platform since the platform should maintain these states in a stable manner, ensuring that no entity defrauds the other. The platform could also hire a watchtower's services in order to provide guarantees on users' channels not closing due to internal platform errors.
When users sign up on the platform, the platform could open an outbound channel with them and provide a fixed amount of liquidity. Users can add funds to channels by using Submarine Swaps or splicing funds into the channel if they choose to invest in a project.
Submarine swaps is a technique by which users can send altcoins to a specific altcoin address and atomically, a transaction funding a channel on lightning is broadcast to Bitcoin-L1. Splicing funds into a channel is done by closing a channel, adding an extra input and opening a channel, all in the same Bitcoin-L1 transaction. A channel can be funded by a number of means, and any can be used as long as the investor manages to successfully create / add funds to a channel with the platform.
An alternate proposition is to not have a channel unless an investor decides on investing in a project. The disadvantage with this approach is that investors have to wait for the transaction to be reliably confirmed before the platform can confirm their investment.
An investor creating a channel or pushing funds to the platform would have to push extra funds above the amount they wish to invest to cover for on chain fees of creating a channel, and to cover the channel closing transaction in the future. Therefore, the project's desired funding goal should include a small buffer.
For other entities, the platform opens a channel if and once the project they are associated with is funded. This prevents the need to deal with channels that aren't being used. The platform should close channels by default if a new state update has not occurred in the past 3/6 months to efficiently manage liquidity and to minimise attack vectors surrounding liquidity. If a project's expected time to reach the funding threshold is greater than this period, the channel should be kept open until this time elapses.
Once a channel is in place, the investor pushes the amount they wish to invest towards the platform. When the total amount invested reaches the project threshold, the platform opens a new outbound channel with the receiver, developer and other entities, the project is marked complete, and the investor is given the transaction ids of the channels that the platform newly opened. The platform pushes back a small amount of funds back to the investor to update the last known state. The investor could also choose to transfer some small amount funds back to the platform through additional investment or through donations in order to bury the bigger investment within the list of states. This increases the effort required by a malicious platform admin to defraud them.
After completion of investment, the investor could choose to close the channel but closing and opening a new channel each time an investment is completed or initiated has no difference (and in some cases, is more expensive) compared to a standard Bitcoin-L1 transaction. The platform could potentially detect user behaviour and recommend on-chain funding if the fee is low, if a given investor does not plan on investing in more than one project, or if the amount of investment is sufficiently high to warrant the high transaction fee on Bitcoin-L1.
With the newly established outbound channel, the platform and receiver collaborate to send funds to different entities (the platform should cooperate by default). If the receiver wishes to pay the developer, it tells the platform that it wants to push funds to the developer and the platform will push funds through its channel with the developer. Alternatively, the platform can push funds towards the recipient and the recipient can choose to route funds through the platform or other means to the developer. The receiver could also receive LN payments from the platform and pay the developer off chain, and provide confirmation by adding the receipt to stage data.
Guarantors need to open a channel with the platform (or top up the balance on their end towards the platform) and in the event the receiver fails to pay, the guarantor should push funds towards the platform and the platform will treat this as a normal payment from the receiver while keeping note and sending notifications to all parties on the platform that the receiver has defaulted on a payment.
An alternate route for investments in projects is that a receiver provides an invoice which the investor funds through a non-openx account. The platform and the receiver should still be able to pay the investor back since the platform can scan the public key of the investor from the blockchain. This also enables donation projects where investors look to donate funds to different projects through the Bitcoin Lightning Network.
Investors holding altcoins can use atomic swap services (which could either be facilitated by the platform or by a third party service) or submarine swaps to invest in projects. This expands the reach of the platform beyond Bitcoin.
The platform should take note of griefing attacks (ie) when users sign up as receivers or developers but don't use the account, effectively forcing the platform to lock funds for a pre-defined period of time. This can be avoided by only opening channels with entities that are already associated with a project, and by efficiently closing unused channels.
The trust model in this scenario is that entities trust the platform to push funds to the developer, contractor, create multisig escrows, etc. The availability of proofs in the form of state update hashes and tx ids removes the need for state variables.
Last modified 3yr ago