Your understanding is correct, but there are additional benefits. Since each user can create LN invoices and pay LN invoices, one member of the pool can create an invoice which another member of the pool then pays. The result is what you'd expect: money moves from one user of the pool to another. But the way I'm implementing it, the person P (from your description) acts as the routing node for these payments, and that person (who I call "the admin") does not charge a fee for "internal" in-pool payments. I also have him allow free payments to people in *other* pools as long as he manages those pools too. So once you get into the channel factory, you get free transactions to anyone else who used the same admin, and you *also* get to send and receive lightning payments.

And thanks to my hedgehog protocol, you can also send money to someone when they are offline, and you can then *go* offline because hedgehog works in such a way that the recipient of a hedgehog transaction (which is just text, you can get it from e.g. an email or a nostr dm) can redeem it even if the creator of that transaction went offline.

The way that works is this: the recipient has the preimage to a pending htlc created by the sender, and that pending htlc would, if broadcast, pay the admin, but only if the admin learns the preimage. Since the sender gave the preimage to the recipient (it's contained in the hedgehog transaction text), the recipient just contacts the admin and asks him to pay an invoice for the same amount as the pending htlc, locked to the same preimage. Which means the admin knows that if he pays the recipient's invoice, he will get reimbursed from the sender's htlc, even if the sender is offline.

Voila! Asynchronous payments that are free for anyone in any pool managed by the same admin (I call a collection of such pools a "metapool"), and you can use lightning if you want to pay someone *outside* your metapool.