This system relies on users coming online at least once during the lifetime of a "factory," which is suggested to last about a month. During this period, users must decide whether to exit or transition to a new factory, ensuring their safety through trustless means. The concept introduces a grace period known as the "dying period" at the end of each factory's life cycle. During this time, users are required to make critical decisions regarding their participation in the system, including unilateral exits, assisted exits involving offchain-to-onchain swaps, or moving to a new factory possibly under a different LSP.

The design specifically targets mobile app use-cases, leveraging the ability of iOS and Android apps to receive notifications that can awaken the app briefly for essential cryptographic operations, including potentially making payments while the device is inactive. This feature aims to reduce the need for asynchronous payment receipt, enhancing user convenience and security.

A significant technical challenge mentioned involves the necessity for publishing O(N) transactions during a unilateral exit, where N represents the number of clients in a factory. The complexity and cost of these transactions depend on the arity of the tree structure organizing these exits, with different arities affecting the overall efficiency of the process. The hope is that this approach could effectively increase the channel-opening capacity by tenfold, equivalent to expanding block size to 10Mb, thereby potentially supporting millions of clients without compromising the foundational principle of trustlessness.

No current implementations of this concept exist, as it is a recent idea. The development would require new client-side software, possibly reusing some existing code for managing specific types of channels but also introducing new algorithms for managing the proposed tree structure. On the LSP side, integration into existing node software would be necessary, with suggestions that certain node software like CLN could support this through plugins allowing for the routing of payments within this system. Implementing such a scheme would involve both client and LSP sides to develop novel solutions for handling the unique challenges presented by this proposed system.