Becoming Unbanked part 4 – How to price work and collect payments in nano

In "Becoming Unbanked Part 3: Receiving Payments in Nano", I explained that having decentralised money is essential on the journey to depend less on fiat and the banking system. I also outlined how I have been increasing and encouraging payments in Nano.

In this article, I will explore two major difficulties faced by anyone who wants to receive payments in a new currency:

• Defining the unit of accounting for pricing things;
• Pricing future payments with exchange rate definition.

Defining a currency as a unit of accounting for the base price

The other day, I saw a restaurant in Brazil had started pricing its menu in 'sats' (the smallest unit of bitcoin). The photo of the menu went viral and yes… It's an interesting case of adoption, but it's not very practical and can lead to problems for the business. Let me explain.

Using a currency as a unit of accounting (UoA) is the last adoption phase in monetary theory; and many currencies may never actually reach this point. Its use is entirely about convenience and social convention — just like the use of a language or dialect.

Many currencies can be used as means of exchange (MoE) simultaneously, in a free-market society.

I myself receive payments (MoE) in many currencies — even those that I am not interested in keeping as a store of value for future use and will exchange almost immediately for stronger reserves, or those that I have greater personal or investment thesis interest. It's natural.

At the same time, I can decide to use more than one of these currencies as a store of value (SoV), allocating parts of my assets in the hardest ones, or in my favourites. The use as a store of value, then, filters part of the currencies used as means of exchange.

And at the end of the funnel, there is the one (or those) that I will use to price my services and measure the performance and purchasing power of my money. The 'language' I will use — being an even smaller and more select number.

MoE is much more about user choice – who sends and who receives – and an agreement between both parties to achieve a mutual solution. e.g. I accept to receive in A, B or C; and my client wants to pay me in C, D or E. We will probably close the deal in C.

SoV is about a personal economic choice based on a personal thesis. e.g. I prefer to store value in XYZ.

UoA is about something much bigger and involves the entire local ecosystem or market in which you are inserted.

When pricing products in a currency that is not commonly used for this purpose in the ecosystem/market where it is being applied, the user suffers competitive disadvantages and difficulty in cash flow management due to exchange rate volatility — which exists even between solid fiat currencies, such as the dollar and the euro.

In summary: it does not depend only on you or your client, but on the entire environment. Like languages or dialects.

Exchange rate fluctuation will be your enemy when challenging the standard unit of accounting of your region (or the ecosystem) and could bring you losses in (1) cash flow; or (2) number of sales/customers. Depending on which 'side' the exchange rate is on.

I price my work in USD to stay competitive and facilitate negotiation, as I serve clients from all over the world. But I manage my balance sheet in both USD and BRL, as the second is the currency in which my expenses are priced in Brazil.

Download the spreadsheet template I use to manage my cash flow.

Importers and exporters dealing with multiple currencies face similar challenges to those who want to use decentralised money in a free market.

Exchange rates for multi-currency payments

When dealing with multiple currencies and exchange rates, it is necessary to establish an exchange system to know how to charge payments in a currency other than that which is pricing the product or service. Makes sense, right?

For immediate payments in an open market like cryptocurrencies, the exchange rate definition can be as simple as looking at the current rate on a trusted platform (coinmarketcap, coingecko, etc.); or the rate of the platform that will be used for the exchange — if you use a local exchange with less liquidity, or one that charges a premium for the transaction.

The native open-source wallet for nano, Nault.cc, for example, allows you to request payments in XNO based on a fiat currency of your choice (such as USD, EUR, or BRL) — generating a QR Code with the value in nano for your private address.

So, if you are concluding a sale of a product or service whose payment will be made at the same time as the collection, just calculate the equivalence, receive the payment, and enter both values in your control spreadsheet in both the base currency (BRL) and the received currency (XNO).

Receiving future payments in different currencies

In my case, the biggest challenge is in pricing and defining the exchange rate for future payments. This may also be the case for:

• Employees receiving salaries or bonuses;
• Freelancers in general;
• B2B suppliers working with payment terms;
• The payment of fines;
• The settlement of agreements or bets;
• Etc.

Future payments occur when the recipient issues an invoice for payment within more than 24 hours of issuance. Or when receiving, for example, a payment every month within the first five business days of the month.

Considering exchange rate volatility (even in the Forex market between FIAT→FIAT), both parties could be harmed by the definition of the corresponding value in the payment currency on the day of invoice issuance; and the receiving party could be harmed by leaving the exchange rate arbitrary.

In the traditional market, companies dependent on exchange rates already use a base quote from a pre-defined moment. And it is under this premise that I developed my own billing system that has been working very well for future payments.

In the infographic below, I illustrate the two situations. Where there is (1) the pricing of the exchange rate at the time of invoice emission; and (2) the pricing of the exchange rate at the time of payment or collection.

With my clients, I established that the rate used will always be the closing price (23:59h UTC) of the day before the payment day – payday minus one. This way, we have a reliable source (coingecko or coinmarketcap), with the decisive record of the exchange rate that will be used — no confusion, no doubts.

Some may argue that we could simply use the exchange rate at the exact moment of sending the payment, but I have already gone through the frustrating experience of a payer delaying sending to try to arbitrate the best rate at the best possible second, waiting for a hike in price to 'close' the amount in nano with me, having bought before at a lower price. Yes, that happens.

So, the definition of a non-arbitrary and decisive rate based on the closing of the previous day, works to avoid this undignified situation or mistrust between the parties. There is a service delivery deadline and a payment conclusion deadline. Deal.

And there is a single rule to measure how this demand will be concluded in financial terms. Deal again.

Of course, the payer can (and should, if willing) improve their results and get a 'discount' on payments using good exchange rate management. Knowing that they will have to pay in 30 days, they can spend the previous 29 days buying small amounts of the final payment to get an average price. Or make, for example, 3 swaps every 10 days. It's up to each one.

It is also possible, in the case of a price drop on the payment day, to repurchase the amount that would be paid at the previous rate, managing its own cash flow. Again, it's up to each one.

Of course, I don't have all the answers, but this system seems to work.

I would love to know what you think about it, too. And if you have a simpler and fairer solution to solve the exchange rate challenge in multi-currency operations.

For my next article I am looking for suggestions from you! If there is a part of my journey towards financial sovereignty that you are particularly interested in, or would like to know more about, get in touch via my socials. 

Find Vini on Twitter, Reddit and Substack.