If the backup participant B is offline, LSPs might resort to onchain methods, which can introduce additional fees that are typically passed on to the user, A. The process of adding on-chain funds requires modifying the root transaction to include more funds, a complex operation that necessitates updating the entire tree structure to reflect the changes in the leaf outputs. This operation implicates every node within the tree, potentially requiring them to become active to accommodate the update. Alternatively, LSPs may choose not to fulfill the liquidity request until it becomes feasible for other participants within the network to come online and facilitate transfers within the factory or by transitioning to a new factory setup with a fresh on-chain root transaction.

Following a unilateral exit, the impact extends beyond the direct participants, affecting clients connected to the same and adjacent leaf transactions. Specifically, if A decides to exit, not only B but also sibling clients C and D at the next higher level are exited from the system. These clients then revert to standard lightning channels, confirmed on-chain, enabling them to join a new factory through a splice of the existing channel. Meanwhile, entities such as E, F, G, and H remain in a reduced-capacity factory, losing a hierarchical level but otherwise continuing operations with a diminished set of state transitions available.

The synchronization of liquidity requests within the factory presents significant challenges, especially when multiple, concurrent requests occur, and not all participants are online. For instance, if A requests liquidity but B is offline, reaching out to C and D for their leaf's liquidity necessitates B's eventual online presence to finalize the transaction with all required signatures. This situation becomes further complicated with simultaneous liquidity requests, risking a scenario where conflicting allocations cannot be easily reconciled. To manage such complexities, LSPs might enforce a strict sequence for processing requests, ensuring orderly handling but potentially causing delays as participants sequentially come online to approve transactions.