Can we somehow allow users to have the balances in Fiat?

[bumi]

I am not sure yet if this makes sense on this level. But I am thinking if it is possible to allow users to have their balances in Fiat. This means whenever a user does a lightning payment we do the conversion to fiat and deduct that amount from the fiat balance. I am not sure if this makes sense, but maybe something to consider for later and when we think about the data model.

[kiwiidb]

https://stephanlivera.com/episode/346/

https://github.com/GaloyMoney/dealer

[MoritzKa]

Having a fiat balance would facilitate accounting, because buying and selling is taxable event. https://jimmymow.medium.com/announcing-strike-by-zap-4f578c7c8984 What other problem would that solve?

[bumi]

I did not read that article. But I think we need to dig much deeper here, much deeper on a technical level but also on a creative legal level. It's a complicated topic so it's not enough to say yes/no to this that easily.

For example: is it buying/selling when you have a fiat balance (what means balance?) and a service transfers some value is transferred through the lightning network? (what is strike doing?)

and in the end in this software we actually do not care about taxes or regulation in certain countries. Those questions must be answered when running this software.

[kiwiidb]

A benefit it would bring is that it would take down mental barriers that are stopping people from spending bitcoin. You don't spend sats, you stack sats. This meme is way too strong and won't be going away anytime soon. Unreasonable taxable event regulation in the US just reinforce this meme.

And indeed, what we build here should not depend on regulations in country X or Y.

[MoritzKa]

comment deleted.

[the-kollider]

As long as you don’t mind it being custodial this mechanism can be easily created. We’ve actually made a proof of concept Umbrel app (https://github.com/getumbrel/umbrel/pull/1293) which is not released yet but will enable exactly this behaviour.

In essence Lndhub could be extended so that users can have accounts denominated in fiat currencies. The actual value of these accounts is represented by a short position of the relevant fiat currency in an inversely priced perpetual swap. To achieve this, Lndhub has to connect to the Kollider API and buy/sell contracts according to the fiat demand of its users. Being short 1 contract of an inversely priced BTC/USD swap is equivalent to holding 1 USD. Closing this short will return the quantity of Sats that is equal to 1 USD at that point in time. Because everything is done over lightning there is no need for batching orders and the conversion can be done instantly.

On a high level the interaction between Lndhub and the Kollider api could look something like this:

1. User submits a conversion request to Lndhub for 10 USD.
2. Lndhub sends a 10 contract sell order to Kollider.
3. Kollider response with an invoice of the amount of Sats required to execute this trade.
4. Lndhub checks the users LN balance and verifies the user has enough funds.
5. Lndhub pays the invoice.
6. The payment hits Kolliders wallet and trade is executed.
7. Lndhubs short position is increased by 10 contracts and the user now holds a value equivalent to 10 USD.
8. User now submits an invoice of X amount of sats equivalent to 5 USD.
9. Lndhub submits a buy order of 5 contracts on Kollider.
10. Lndhub short position is reduced (unwound) by 5 contracts.
11. Kollider sends a settlement request to Lndhub for the X amount of sats.
12. Lndhub sends users invoice of X amount to Kollider.
13. Kollider settles the invoice with the freed Sats.

Pros:

• It’s much cheaper and faster than using a spot exchange for the conversion, i.e. Bitcoin <> USDT. Currently a full loop, that is, user A sends user B 1 USD and back would cost a total of 0.30% + lightning network fees on Kollider. Spot exchanges would charge between 1% to 4 % of the converted value.
• It has a natural interest earning mechanism. Sats locked in a short position (synthetic USD) accumulate interest on average due to the contango of futures markets. So users would actually get compensated for holding dollars.
• It's capital efficient and scales well. Adding new pairs is very simple and can be scaled as demand scales.

Cons:

• It is custodial. The fiat amount owned by Lndhub is a short position on Kollider, so there is counterparty risk. This also means that only users in certain jurisdictions can use this plugin.
• If the market for perpetual swaps is illiquid, users might not be able to convert their USD or Sats or vice versa.
• The funding rate could be negative which means people that hold USD positions have to pay. It's equivalent to negative interest. In effect, their dollar value decreases.

[bumi]

thanks for this explanation! that sounds actually pretty promising and quite doable. If we can hook this in as a plugin to make it easy for users to optionally enable this could be pretty cool.

[kiwiidb]

Hey there, thanks so much for reaching out!

Having a USD-denominated balance in LNDhub powered by Kollider sounds like it could absolutely work. However, I don't think the system you're describing above is what I had in mind.

The model I had in mind was the one that is described by Nicolas Burtey in this podcast: https://stephanlivera.com/episode/346/. I have the impression that what you are describing is focused around the UX of a single user of LNDhub. What I had in mind is that in the case of many users of a "USD-denominated" - LNDhub, all users would have a USD-denominated balance. It is the server admin's responsability to see that their assets match their liabilities, and for this they could use a trading bot that talks to Kollider, but the flow when a user makes or receives a payment does not involve a derivative trade at all. The only thing that would need to be done is capturing the BTCUSD rate at the time of the transaction. When a user's balance is calculated later, the amount of sats they have is derived by rescaling the amount of sats per transaction by the ratio of the current BTCUSD price and the recorded BTCUSD price, and summing over all transactions. This would cause them to have a balance that is stable in terms of USD. Instead of making a trade per transaction like you describe, trades are only executed periodically (eg. daily) by the server, behind the scenes.

I was looking at this repository for doing that, although I don't understand much of it yet. This would be much cheaper than the model you describe, because if you aggregate daily over 1000's of buys and sells, they might cancel each other out, which means that the volume of the trade that you have to do is much smaller and the transaction cost (LN + trade) would be much smaller. A 0.3% trading transaction cost, coupled with let's say a 0.1% LN transaction cost would be way too expensive IMO.

So I think what you are describing here absolutely makes sense as an Umbrel app, but not as an LNDhub plugin. What I was looking for is more something like a version of GaloyMoney's dealer that works with Kollider, maybe a fork of it that adds Kollider as a back-end, or a simpler re-write of it in Go :).

[the-kollider]

Thanks for your reply! What you're saying makes a lot of sense and I agree that a slightly different implementation is needed if you have a multi account service like Lndhub.

Like you said, if you have a multi account setup you want to pool your assets and liabilities which allows a much more efficient execution of trades. Internal tx's to Lndhub, for example, don't require any action for example as your balance sheet stays net delta neutral. Nevertheless, as soon as you start locking in prices when users make external transaction (to a different lightning wallet) without re-balancing your fiat exposure the server admin takes on delta (risk). That is, if at the end of the day inflow and outflow does not perfectly balance out they either have lost funds or gained funds. At this point its up to the server admin to implement models that control their risk tolerance where they weigh off execution fees vs volatility. I agree that this is probably more optimal. However, this would also be much harder to manage. The server admin would pretty much become a brokerage and their ability to predict the market becomes part of their core business.

So what I describe is probably the naive way of doing things. Galoy's Dealer implementation is exactly what is needed. However, it uses non-lightning enabled derivative exchanges which creates a capital inefficiency for the server admin. Since the channel balance can not be directly used to execute the trades on the exchange, they have to maintain a balance on the exchange which they have to re-balance every now and again. The infrequent re-balance makes much more sense here as they have to take on-chain fees into account as well as the management of a lightning and a on-chain wallet.

Yes we're looking into writing our own Rust SDK that is a mix of LndHub and Galoy's Dealer. Maybe once this is out, it becomes much more clearer how a Lndhub.go plugin could look like!

[kiwiidb]

I thought Galoy's dealer used OKEx as a derivative exchange by default, which is lightning-enabled.

[the-kollider]

Yeah you're right! I stand corrected. I still need to run it, curious how it works.

[the-kollider]

Hi @kiwiidb check out this. Its our own implementation of an lndhub like service. We've also added a microservice that resembles Galoy's dealer. Would be cool to get some feedback. Its only a POC atm but it does what it says on the tin. As you pointed out, the service doesn't have to always hedge, only if it hits its risk limits. We've also added a simple RFQ system which makes it easier for the user to understand what exact exchange rate they're getting.