breez/fiatlink

Add support to ask for a quote to ask "how much fiat for X sats"

Closed this issue · 3 comments

Amperstrand commented

When asking for a quote, the user has two options:

  • User wants to purchase X amount of BTC
  • User wants to spend X amount of fiat

This means it is possible to buy X amount of BTC and spend X amount of fiat.

But it is not possible to buy BTC for X amount of fiat.

So for example if I have exactly 100 euro and want to know how many sats I can buy for 100 euro, I need to hit the quote endpoint to brute force the number of sats that will bring me closest to 100 euro.

This is how you would spend 1000 chf today:

# client wants to spend 1000chf
POST /quote   

{ 
  "session_id": "d7ef9a88-1ca1-4ac8-bc9e-da3d9824cdc5",
  "amount_fiat": 100000, # in cents 
  "currency_id":1,
  "payment_option_id":1
}

If we also add something like a direction parameter, it would become this instead:

client wants to spend 1000chf

POST /quote

{
"session_id": "d7ef9a88-1ca1-4ac8-bc9e-da3d9824cdc5",
"amount_fiat": 100000, # in cents
"direction": "from_fiat"
"currency_id":1,
"payment_option_id":1
}

Now I can also buy an exact amount of sats:
{
"session_id": "d7ef9a88-1ca1-4ac8-bc9e-da3d9824cdc5",
"amount_btc": 0.028696,
"direction": "from_fiat"
"currency_id":1,
"payment_option_id":1
}

This quote might ask me to transfer 1000.15 CHF, but will give me the exact right number of sats.

The number of sats should include the withdraw fees.

This is useful for people that have a bitcoin invoice they need to pay. So for example, if I have been issued an invoice of 100 euro that I need to pay and the receipient makes out a bitcoin invoice, they are expecting an exact number of sats. If my wallet uses fiat link and only purchases 99.9% of the expected number of sats, the invoice will not really have been paid in full.

So for this reason it must be possible to ask for both an exact fiat amount and an exact number of sats for both orders that are from_fiat and to_fiat.

Another possible name for the parameter I called direction would be quote_type.

from_fiat could be purchase

to_fiat could be spend

so to buy sats:

  • order_type=purchase amount_btc=0.028696
  • order_type=purchase amount_fiat=1000

so spend sats:

  • order_type=spend amount_btc=0.028696
  • order_type=spend amount_fiat=1000
aljazceru commented

i might be misunderstanding this but what you are talking about sounds like limit orders:

  • i want to buy 0.1btc @ 42690chf
    this means that you specify both fiat price and amount

you can already use the /quote endpoint to specify that you want 100k sats, then the difference is if the broker supports quotes or just estimates.

POST /quote   

{ 
  "session_id": "d7ef9a88-1ca1-4ac8-bc9e-da3d9824cdc5",
  "amount_sats": 100000 # in sats
  "currency_id":1,
  "payment_option_id":1
}

if this is a real quote (which will probably be depending on payment method) you will get 100k sats out of it. If its an estimate then of course that might not happen (lets say your fiat payment takes 2days to arrive, the broker can't honor that as it poses tons of price risk for them).

did i understand this correctly?

Amperstrand commented

I'm probably the one that misunderstood.

I know that you can ask for a quote for both amount_sats and amount_fiat. It was my understanding that 'User wants to spend X amount of fiat' ment that the user wanted to send the broker sats to spend X amount of fiat.

Since this is not the case, maybe I should rename this issue to add support for that instead.

The usecase is that the user has a SEPA payment that they want the broker to do. They want to pay for their €42 mobile phone bill. So they ask their broker: How many sats will you charge me to pay this €42 SEPA transfer.

Maybe this is outside of scope for fiatlink, but it would standardise a protocol for making services like https://bringin.xyz/

aljazceru commented

it seems so yeah, FLS01 is only meant as a non-kyc onramp spec, what you are suggesting is not covered by this

the first priority is to address on/off ramp spec to enable wallets standardized integrations with different providers and thus easier user onboarding

  • 👍1