Stablenuts lnaddress payments using incorrect units

[kirkawolff]

Procedure: 1) open minibits, change to stablenut.umint.cash USD wallet 2) press send, select lightning 3) enter lnaddress (e.g. user@domain.tld) in invoice window, press confirm 4) enter $1.00 USD for amount, press continue 5) "Amount to pay" indicates $0.16, this is the same as 100 sats, not 100 cents

EXPECT: "Amount to pay" reads $1.00

[minibits-cash]

Thank you, sounds like a bug indeed, will look at it.

[kirkawolff]

I'm looking at commit

https://github.com/minibits-cash/minibits_wallet/commit/f34738e68cac0a0b42fe708e7c89342c03001936

Shouldn't the exchange rate be dictated by the stablesats provider and not a separate oracle? (MINIBITS_SERVER_API_HOST)

[minibits-cash]

Whenever it is the stable sat mint who provides lightning invoice (mint quote to a request for x usd), it is upon them to make a conversion and calculate required sat amount to pay.

Payment to a lightning address is a push payment in (mili)satoshis: payer defines the amount of sats he wants to pay, asks for an invoice from payee lnurl server and then instructs the mint to settle that invoice.

In case it is a stable sat mint, it makes sense to handle it UX wise in its currency, but I think it remains wallet responsibility to make a conversion - mint has not any stake in that.

As I did not have rate oracle before upcoming 0.1.9 version I see why that usecase was just broken.

If you are a member of alpha testing program on google pay, you should have access to new native release in Google play to test it on 0.1.9.

Thank you for actually looking into the code, upcoming release is a monster one and commits are not very clearly structured. Any further feedback is welcome.

[kirkawolff]

I agree that minting new USD stablesats would be straightforward for the mint to dictate the amount of sats in the invoice. But in the special case of sending sats to a lnaddress from a usd token mint, it is in the interest of the payer to maximize the number of sats available from the mint for a given amount of sats.

The only way to assure this is to match the rate of the mint when requesting a lightning invoice from the reciever via lnaddress. A third party oracle will consistently have a different rate than the mint, this means the payor will either overapply or underapply the USD redemption for sats.

A way to resolve this is either ask the mint itself to initiate the lnaddress payment denominated in USD, or for the wallet to ask the mint for a temporary lock-in rate between sats and USD for the duration of the invoice issued by the reciever's lightning node.

I was curious if cashu provided such a mechanism as I'm ignorant of stablenut related NUTs.

[minibits-cash]

I see the merits of your proposal. Currently cashu spec does not define any rates endpoint for the mint. It could be obtained by asking for an invoice for specific USD or other supported unit amount and than calculating the rate from it - a bit hacky approach but could work. Will release it as-is and will think of the best approach over time.

[kirkawolff]

It works perfectly now. Thank you!