You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been thinking about Boltz Liquid swaps a bit. I'm sure this has been discussed before - I think Chris has mentioned it in the Friday meetings in passing - but I've had an idea and I want to see if it's feasible.
There's an overview of Boltz Liquid swaps at https://blog.boltz.exchange/p/dispatching-chain-swaps. I'd recommend reading that, but my take on this is that by doing BTC Lightning->on-chain L-BTC swaps and then on-chain L-BTC->on-chain BTC swaps, it's possible to gain outbound liquidity at about a 0.2% fee (two lots of 0.1% fees) instead of the 0.5% charged for Boltz's BTC-only lightning->chain swaps.
There's also a potential saving in the on-chain fees which are charged on top of the 0.5% Boltz fee with our current implementation, since the on-chain L-BTC from the Lightning swaps can be allowed to accumulate to some extent over time and swapped back to on-chain BTC in a single operation later with a single mainnet fee. This might help make small clboss nodes more viable, since the on-chain fee is a disproportionate part of the cost for small amounts, although I guess a small node is less likely to be able to afford to keep its limited capital tied up in L-BTC.
Assuming this idea works at all, obviously an ideal implementation would be fully native support inside clboss. But that's potentially quite a lot of work for an uncertain reward, and I wonder if it might be possible to experiment with this in a relatively low-effort way first. Then if that pays off, we can gradually polish up the implementation to be production quality.
https://blog.boltz.exchange/p/guide-how-to-use-boltz-clients-autoswap describes a Boltz tool which will automatically attempt to maintain a Lightning node's channels in some desired liquidity state (there are inbound-heavy, outbound-heavy and balanced configurations available) using Liquid swaps.
Suppose we set up clboss using the "don't do any rebalancing" options from #212 and have this Boltz tool running. clboss would still be able to set the fees for channels for us depending on their current balance. It would just see the actions of the Boltz tool as user-originated payments (when swapping out to Liquid) and new funds being deposited on-chain by the user (when swapping back from Liquid) - this would mess up the accounting, but wouldn't it mostly otherwise "just work"?
If that did work, a next step might be to make clboss aware of the L-BTC on-chain balance. A first implementation of this could perhaps just have a script which scrapes the Boltz tool logs and updates a value in clboss's database with the current balance, or uses a simple dev-only RPC call to tell clboss "hey, here's the current L-BTC balance". We could perhaps even tweak the Boltz code to call that RPC automatically when it does something. This would open up the possibility of fixing the accounting, and at that point we might have a Heath Robinson implementation of Liquid swaps which mostly works.
Am I missing anything fundamental here or is there at least a chance this could work?
The text was updated successfully, but these errors were encountered:
I've been thinking about Boltz Liquid swaps a bit. I'm sure this has been discussed before - I think Chris has mentioned it in the Friday meetings in passing - but I've had an idea and I want to see if it's feasible.
There's an overview of Boltz Liquid swaps at https://blog.boltz.exchange/p/dispatching-chain-swaps. I'd recommend reading that, but my take on this is that by doing BTC Lightning->on-chain L-BTC swaps and then on-chain L-BTC->on-chain BTC swaps, it's possible to gain outbound liquidity at about a 0.2% fee (two lots of 0.1% fees) instead of the 0.5% charged for Boltz's BTC-only lightning->chain swaps.
There's also a potential saving in the on-chain fees which are charged on top of the 0.5% Boltz fee with our current implementation, since the on-chain L-BTC from the Lightning swaps can be allowed to accumulate to some extent over time and swapped back to on-chain BTC in a single operation later with a single mainnet fee. This might help make small clboss nodes more viable, since the on-chain fee is a disproportionate part of the cost for small amounts, although I guess a small node is less likely to be able to afford to keep its limited capital tied up in L-BTC.
Assuming this idea works at all, obviously an ideal implementation would be fully native support inside clboss. But that's potentially quite a lot of work for an uncertain reward, and I wonder if it might be possible to experiment with this in a relatively low-effort way first. Then if that pays off, we can gradually polish up the implementation to be production quality.
https://blog.boltz.exchange/p/guide-how-to-use-boltz-clients-autoswap describes a Boltz tool which will automatically attempt to maintain a Lightning node's channels in some desired liquidity state (there are inbound-heavy, outbound-heavy and balanced configurations available) using Liquid swaps.
Suppose we set up clboss using the "don't do any rebalancing" options from #212 and have this Boltz tool running. clboss would still be able to set the fees for channels for us depending on their current balance. It would just see the actions of the Boltz tool as user-originated payments (when swapping out to Liquid) and new funds being deposited on-chain by the user (when swapping back from Liquid) - this would mess up the accounting, but wouldn't it mostly otherwise "just work"?
If that did work, a next step might be to make clboss aware of the L-BTC on-chain balance. A first implementation of this could perhaps just have a script which scrapes the Boltz tool logs and updates a value in clboss's database with the current balance, or uses a simple dev-only RPC call to tell clboss "hey, here's the current L-BTC balance". We could perhaps even tweak the Boltz code to call that RPC automatically when it does something. This would open up the possibility of fixing the accounting, and at that point we might have a Heath Robinson implementation of Liquid swaps which mostly works.
Am I missing anything fundamental here or is there at least a chance this could work?
The text was updated successfully, but these errors were encountered: