Enable display of currencies other than USD for unit of account (Real, Rand, Quetzal, Sol)

[agbegin]

The Bitcoin Beach Wallet is being used in Guatemala and Peru to onboard communities to Bitcoin. Other projects have indicated that they would also use the wallet in their communities if they could see the value of sats in their local currency.

What would it take for us to roll out a feature to enable users to pick their unit of account in settings?

Currencies that we could look into incorporating first, based on existing usage or interest:

• Guatemalan Quetzal (GTQ)
• Peruvian Sol (PEN)
• South African Rand (ZAR)
• Brazilian Real (BRL)

See examples from Muun.

What would it take to incorporate a currency selector in galoy-mobile and/or web-wallet? Is this something that could be issued as a bounty?

[sebastianwindeck]

Since the European system has an increasing awareness in the system it might be useful to add EUR

What do you think?

[agbegin]

Definitely. Plan is to add every fiat currency (see comment below linking to the issue)

[agbegin]

Issue from @nicolasburtey: display currency in every fiat currency #1202

Next step is to capture the implementation/thinking done so far and scope out the remaining work.

cc @dolcalmi @vindard

[agbegin]

Sharing the currency conversion & POS work from Fä Bu on twitter.

pagar.bitcoinlake.io

• Simple POS screen for paying to Bitcoin Beach Wallet username over lightning
• Ability to choose which currency to use as unit of account
• Can link directly to each user's receive page: https://pagar.bitcoinlake.io/agbegin

On github: https://github.com/fabu21/bbw-fiat-invoices

[vindard]

Notes on implementing multiple display currencies

The idea for displaying multiple currencies in our system is as follows. There are 2 ways to support multiple currencies:

1. Naive
   Get the current rate for a given default currency and convert all balances, past transactions and receive/send amounts at the current price

2. Persist transaction rates
   Register each transaction against a given currency and rate at the time of transaction and store this currency/rate. Present transactions in the transaction history with their recorded currency and rate at the time of transaction. Get the current rate for a current default currency and convert all balances and receive/send amounts at the current price.

We plan to support the 2nd way, which would mean storing a single unique display currency and rate at the time of transaction. When a user parses their transaction history, they will see the transaction represented as the display currency and amount in that display currency at the time of transaction. This is for e.g. how Muun handles multiple currencies today.

Support from backend

Already implemented

• We have three fields that are currently populated for each transaction under payment transaction type:

  • displayAmount
  • displayFee
  • displayCurrency

  These fields currently are populated with only the USD price since we only support USD on the backend for now and do not have a multicurrency Price Service implemented as yet.

  These fields are only implemented for transactions with payment type so far (displayFee gets auto added as 0 if not present on all transactions).

  The following aggregation should confirm which transaction types otherwise get the correct value for these properties.

  [
    {
      '$match': {
        'satsAmount': {
          '$exists': true
        }
      }
    }, {
      '$group': {
        '_id': '$type'
      }
    }
  ]

TODO

Data structures:

• All transaction types should write to the 3 display currency fields in our db

  • figure out which transaction types are not populating the 3 new display currency fields as yet

  • refactor code to ensure the missing transaction types all write to these fields when new transactions are created

  • migrate old transactions to use these new fields

• Reading from these new fields when returning transaction info to the API

  The Transaction payload for the API still reads from usd and feeUsd fields for its display currency logic. We would need to:

  • refactor the LedgerTransaction logic to read from these new fields instead

  • include any missing selections in the Transaction graphql object to support multiple currencies

• Reading from these new fields for constructing messages for the Notifications Service

  • refactor notifications service publish events to use these new fields instead

Multi-currency Price Service

• Implement a new Price Service, or multi-currency support into our existing Price Service (@dolcalmi should know the status/plans for this work)

Multicurrency handling in API

• Support setting/getting a user-level "default display currency"

• Use a user's "default display currency" to fetch display currency data and record into the 3 display currency fields for each new transaction

Frontend

For each transaction:

• detect a transaction's display currency
• parse a currency prefix (e.g. $, AUD)
• present the values for this currency from the display... fields on a transaction together with that currency's prefix

For balances:

• present balances in the current user's display currency