Currently, both parties need to be online at the same time to send/receive money, but this can be avoided by using something like the Lightning Rod Protocol by Breez. However, funds have to be locked up longer than usual. The proposed solution is that the payer A pre-signs a transaction handing over money to their local channel partner S and sends the transaction to payee B in an end-to-end encrypted communication channel. B can then sell the signature for the transaction to S using pay-for-signature made possible by payment points and scalars. This enables truly asynchronous Lightning network payments and is yet another reason to move to payment points and scalars. While B hasn't yet claimed its money, the funds in the channel between A and S are essentially locked up. However, A and S could simply overwrite the payment (new update + settlement transaction), then A could send multiple payments with the remaining balance and before going offline, A would do the procedure again. To improve privacy, they plan to use several Rod nodes: a list of nodes chosen by the payer and another list by the payee. The Rod nodes are supposed to be almost always online, so standard https can be used to communicate with them and between them. Additionally, Trampoline implementations might actually just implement the polling behavior automatically without a please_poll flag; this might be viable especially if the Trampoline is given a substantial fee and time budget anyway.In conclusion, the proposed solution would allow asynchronous payments and outsource routing to S. However, there are potential issues such as privacy concerns, locked up capital, communication channel security, and proof of payment. Therefore, they must ensure proper safeguards and protocols to make it effective and secure.