The scenario is not so much "I want to move from hub A to hub B". Not saying that isn't interesting, but, to give you the flavor of motivation behind "we need to move money across hubs":
When I talk about different hubs I'm mostly trying to address this scalability problem: if there was just one mega-hub, everyone would have to join it and it would have to have huge liquidity and if it ever went down everyone would be trying to broadcast their withdrawal transactions at once. Bad. So, Alice wants to be with hub1 and Bob wants to be with hub2. As the paper notes you can't do that on one ledger and have them minting the same btc-flavor as one could cheat the other. So, you could have them on different ledgers minting their own btc-flavor. Then the question is if only 1000 people are on hub1 and 1000 on hub2 the ability to pay people is way too limited (10k or even 100k could work, instead, but same principle). So you want to *pay* from one hub to the other, and you could do that easily *using atomic swaps cross-ledger*: hub2 has a balance with hub1. Anyone like Alice on hub1 who wants to pay Bob on hub2, pays him with a two-transaction chain: they pay hub2-on-hub1 but only after hashlocks are set up to ensure that Bob gets paid on hub2 at the same time. (A two-hop route, if you prefer).
waxwing
npub1va…knuu7
2026-10-16 14:42:37 UTC
in reply to nevent1q…0tfk
Author Public Key
npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7Published at
2026-10-16 14:42:37 UTCEvent JSON
{
"id": "09afe349fd1d65f7ca1becde31797526c408c85d09eca2a43f9e63dfa32dbd96",
"pubkey": "675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728",
"created_at": 1792161757,
"kind": 1,
"tags": [
[
"alt",
"A short note: The scenario is not so much \"I want to move from h..."
],
[
"e",
"200f28916e6ce7e64b810d5876fbb78250c21922c2afc417cf956d73006d4b7c",
"wss://relay.hodlboard.org/",
"root",
"675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728"
],
[
"e",
"6291df0b6483ef614bb1db7318f1ea5ad0e397a65e54f276dddbfab5da7495cc",
"wss://relay.hodlboard.org/inbox",
"",
"7459d333af66066f066cf87796e690db3a96ff4534f9edf4eab74df2f207289b"
],
[
"e",
"9bb96b773f50fc51165969ade40ce25bd26de3d2f7f7cf985c0fdfa4418b7582",
"wss://relay.primal.net/",
"reply",
"7459d333af66066f066cf87796e690db3a96ff4534f9edf4eab74df2f207289b"
],
[
"p",
"e217899785048ee15da66ab1c4633b8679d141e96c526017d5e7b1991ce584b9",
"wss://nostr-pub.wellorder.net/"
],
[
"p",
"675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728",
"wss://relay.hodlboard.org/"
],
[
"p",
"7459d333af66066f066cf87796e690db3a96ff4534f9edf4eab74df2f207289b",
"wss://nos.lol/"
],
[
"client",
"Amethyst"
]
],
"content": "The scenario is not so much \"I want to move from hub A to hub B\". Not saying that isn't interesting, but, to give you the flavor of motivation behind \"we need to move money across hubs\":\n\nWhen I talk about different hubs I'm mostly trying to address this scalability problem: if there was just one mega-hub, everyone would have to join it and it would have to have huge liquidity and if it ever went down everyone would be trying to broadcast their withdrawal transactions at once. Bad. So, Alice wants to be with hub1 and Bob wants to be with hub2. As the paper notes you can't do that on one ledger and have them minting the same btc-flavor as one could cheat the other. So, you could have them on different ledgers minting their own btc-flavor. Then the question is if only 1000 people are on hub1 and 1000 on hub2 the ability to pay people is way too limited (10k or even 100k could work, instead, but same principle). So you want to *pay* from one hub to the other, and you could do that easily *using atomic swaps cross-ledger*: hub2 has a balance with hub1. Anyone like Alice on hub1 who wants to pay Bob on hub2, pays him with a two-transaction chain: they pay hub2-on-hub1 but only after hashlocks are set up to ensure that Bob gets paid on hub2 at the same time. (A two-hop route, if you prefer).",
"sig": "e1ccc7c3af305f7380889c7dd55575d9ced4609270b49c82f168efde42ae66634e8a824adc900e3af8a8718c161dfee3324064cf4de692eb2d5e7846a40fea06"
}