In this article
You price goods and services in crypto by choosing the unit the price is fixed in, then stating the rate and the moment at which that price becomes a quantity of tokens. A business whose costs are in a national currency keeps the price in that currency and converts it when the customer pays, or a few minutes before under a quote that expires; pricing natively in a token is the third design, and it leaves the value of the open invoice moving with the token.
That one decision settles who carries a move in the token between the invoice and the payment, what the invoice has to say, how the sale reads in your books, and which figure sales tax or VAT is computed on. The rest is mechanical: the quote window, the rate source, rounding, short payments, the network fee and the unit of a refund.
The figures below come from one worked example, labelled as illustrative throughout: an invoice of $18,500 for a design project, payable in ether, with a reference rate of $2,947.35 per ether on the day the invoice is issued and $2,829.46 on the day it is paid, 4% lower. Tax rules differ from one country to the next; the one rule quoted here is the United Kingdom's, and the whole article is general information, not tax or accounting advice.
Illustrative worked examples from this article; the volatility figure uses a normal approximation and is not a forecast.
What is the unit-of-account decision?
The unit-of-account decision is the choice of the unit in which the price is a fixed number: your home currency, or a token. A price can only be fixed in one unit at a time, so the other unit floats until the rate between them is pinned to a stated moment.
The two choices are different contracts. Under a dollar price paid in ether, the customer owes $18,500 of value, delivered in tokens. Under an ether price, the customer owes 6.2768 ether, whatever that is worth on the day.
The question that settles the choice is where your costs sit. Salaries, rent, suppliers and taxes are usually owed in a national currency. A price fixed in a token while costs are fixed in a currency leaves the margin exposed for as long as the invoice is open. A business whose own costs are in the token has the opposite exposure and a real reason to price natively.
The decision concerns the pricing moment only. Holding or converting the tokens after they arrive is a separate treasury decision, and it does not change what the customer owed.
What are the three ways to price in crypto?
There are three designs: a currency price converted at the rate in force when the customer pays, a currency price converted under a quote that stays valid for a fixed window, and a native token price. They differ on who carries a price move, on what the invoice must state and on how the sale is recorded.
| Criterion | Currency price, rate at payment | Currency price, quote with a window | Native token price |
|---|---|---|---|
| What is fixed | The currency amount | The currency amount, then the token quantity for the window | The token quantity |
| Who carries a price move before payment | Nobody: the quantity follows the rate | The seller, for the length of the window only | The seller if the token falls, the customer if it rises |
| What the invoice states | Amount, token, rate source, the moment the rate is read | Amount, token quantity, rate used, time the quote expires | Token quantity, token, network |
| How the books read | Revenue equals the invoiced amount | Revenue equals the invoiced amount; a small difference if the rate moved in the window | Revenue is the token quantity valued at the transaction date |
Run the worked example through each design, issued at $2,947.35 per ether and paid at $2,829.46.
Under the first design the token quantity is computed at the moment of payment: $18,500 divided by $2,829.46 is 6.5384 ether, and you receive $18,500 of value. The 4% fall changed the quantity, not the price.
Under the second design the customer opens the payment page, receives a quote of 6.5384 ether valid for 15 minutes, and pays inside the window. If the rate slips 0.3% during those minutes, to $2,820.97, the tokens you receive are worth $18,444.63, which is $55.37 under the invoice.
Under the third design the invoice said 6.2768 ether, the quantity that equalled $18,500 on the day it was issued. On the payment date those tokens are worth $17,759.95, so the same work brought in $740.05 less.
The first design is the cleanest on paper and the hardest to operate by hand, because the customer cannot know the quantity before sending it. That is why the quote window exists.
How long should a crypto price quote stay valid?
A crypto price quote should stay valid for as long as the customer needs to complete the payment and no longer, because the seller carries the price move for the whole window. For a customer paying from a wallet that means minutes; for a company whose payment needs an internal approval it can mean a day, and the price of that day should be known before it is offered.
A quote that fixes the token quantity gives the customer a choice the seller does not have. If the token rises during the window, the customer can let the quote lapse and ask for a new one with fewer tokens. If the token falls, the customer pays the quoted quantity, which is now worth less than the invoice. A customer who pays when convenient produces gains and losses that roughly cancel over many invoices; a customer who times the payment leaves the seller with only the losses, and the cost of a window is measured on that case.
The size of the move depends on the token's volatility and on the square root of the time. A token with an annualised volatility of 60% has a one-standard-deviation move of 60% multiplied by the square root of the window's share of a year. The table gives that move for four windows and three volatility levels. The levels are illustrative, and the calculation treats price changes as normally distributed, which understates sharp days.
| Quote window | 30% annualised volatility | 60% annualised volatility | 90% annualised volatility |
|---|---|---|---|
| 15 minutes | 0.16% | 0.32% | 0.48% |
| 1 hour | 0.32% | 0.64% | 0.96% |
| 24 hours | 1.57% | 3.14% | 4.71% |
| 7 days | 4.15% | 8.31% | 12.46% |
Quadrupling the window doubles the move. A seven-day window on a volatile token is no longer a quote: at 90% volatility the typical move is 12.46% of the invoice, more than many service margins.
Turned into money on the $18,500 invoice, counting only the downward moves and averaging them, the expected shortfall is about 0.4 of the standard-deviation move. The chart shows that amount at 60% volatility.
Illustrative: normal approximation, no drift, no fees. A customer who pays without watching the rate costs the seller nothing on average, with the same spread of outcomes.
A 15-minute window costs about $24 on this invoice in the worst behavioural case. A seven-day window costs about $613, a discount of 3.3% that nobody agreed to give. A customer who needs a week is better served by a rate read at payment time, or by a price in a dollar stablecoin.
Which rate source should the quote use, and what happens when it lapses?
The quote should use one named, independent rate source read at one stated moment, and a lapsed quote should be void, with a new quote issued at the current rate against the same currency amount. Both points belong in writing before the first invoice goes out.
A rate source is a published price that both sides can look up afterwards, such as the reference rate of a large exchange or of an independent index provider. Three details make it usable. Say which currency pair is read. Say which price is read, the mid-market rate or the rate at which you could actually sell, because the gap between the two is a cost somebody bears. And say when, to the minute and with the time zone, since "the rate on the invoice date" covers 24 hours of movement.
When a window lapses without payment, the quantity is no longer owed; the currency amount still is. The difficult case is the payment that arrives after expiry. You can accept it at the quoted quantity as a courtesy, or value it at the rate when it arrived and treat any gap as an underpayment or overpayment under the tolerance rule described below. Either answer works, provided it was chosen before the case arose.
A business that issues a currency invoice with "pay within 30 days" and a token quantity printed on it has, without meaning to, written a 30-day quote. Print the currency amount as the amount due, and the token quantity only as an indication or on the payment page.
How do rounding and token decimals change the amount due?
Rounding changes the amount due by up to one unit of the last decimal place you keep, and that unit can be worth cents or tens of dollars depending on the token's price. The rule to state is the number of decimal places shown and the direction of rounding.
On Ethereum, ether divides into 18 decimal places, and the smallest unit is called a wei. Tokens issued under the ERC-20 standard declare their own number of decimals, which the standard describes as the figure used to turn the stored amount into the amount a person reads; a token can declare six or eight where ether has eighteen.
In the worked example the exact quantity is 6.538350 ether and continues beyond that. At $2,829.46 per ether, one unit of the second decimal place is worth $28.29, one unit of the fourth is worth $0.28, and one unit of the sixth is worth less than a cent. Rounded to two places the quantity becomes 6.54 if you round up, which overcharges by $4.67, or 6.53 if you round down, which undercharges by $23.63. Rounded up to four places it becomes 6.5384, an overcharge of $0.14. Four places is enough for an ether invoice of this size, and two places is not.
Round up, to the place you have chosen, and say so. Rounding to the nearest unit leaves half of your invoices fractionally short, and a short invoice needs a decision from somebody.
What tolerance should you allow for underpayment and overpayment?
A payment tolerance is a stated margin inside which a payment that is slightly short is accepted as full, and slightly over is kept or credited without a refund transaction. It is set as a percentage of the invoice or a fixed amount, whichever is smaller, and written into the payment terms.
The usual causes of a short payment are mechanical: the customer sent from an account at an exchange that deducted its withdrawal fee from the amount, the wallet rounded the figure, or the customer typed the quantity from an expired quote. Without a tolerance, each of these leaves an invoice open for a few dollars.
Take a tolerance of 0.5%, an illustrative figure. On $18,500 that is $92.50. A withdrawal fee of 0.002 ether deducted by the customer's exchange leaves the payment $5.66 short, 0.031% of the invoice, well inside the margin; the invoice is marked paid and the $5.66 is recorded as a payment difference. A payment that is $400 short is outside it; the balance stays due and the customer is asked for a second payment at the rate of the day it is made.
Overpayments need the mirror rule. Small ones are cheaper to credit against the next invoice than to send back, because a return costs a network fee. Larger ones are returned under the refund rule. In both cases the difference is recorded as its own line, never inside revenue.
Who bears the network fee, and how do you say it?
The sender bears the network fee on an ordinary transfer, because the fee is paid on top of the amount by the account that submits the transaction. The Ethereum developer documentation states that gas fees are paid in ether and are paid whether the transaction succeeds or fails, so a customer paying in a stablecoin on Ethereum also needs some ether to cover the fee.
That default is convenient for pricing: the amount you invoice is the amount that should arrive, and no line for the fee is needed. It breaks in two situations. The first is the exchange withdrawal described above, where the customer's provider charges its own fee and takes it out of the amount sent. The second is an arrangement in which the recipient submits the transaction, where the fee is the seller's cost and belongs in the price.
Name the network on the invoice along with the token, because the same token can exist on several networks.
Is a price in a stablecoin the same as a price in dollars?
A price in a dollar stablecoin is close to a price in dollars but is not the same thing: the token is a separate asset that trades around one dollar, and the seller receives one dollar per unit only if it can be redeemed or sold at exactly that rate.
Pricing in a stablecoin removes almost all of the quote-window problem. The quantity equals the currency amount, the window can be as long as the payment term, and rounding stops at two decimals.
What remains is the conversion. Suppose the $18,500 invoice is paid with 18,500 units of a dollar stablecoin, and on the day you convert them the token sells at $0.9985. You receive $18,472.25, a shortfall of $27.75, before any conversion fee. To receive $18,500 at that rate the customer would have had to send 18,527.79 units.
So decide which of two prices you are quoting. "18,500 units of the token" is a native token price: the customer's duty ends at the quantity, and the conversion result is yours. "$18,500, payable in the token at one unit per dollar" says the same thing in practice but makes the fixed rate explicit. "$18,500, payable in the token at the reference rate at payment" puts the small difference on the customer and brings the quote window back. Where the difference is a few dollars, the second wording is the simplest to operate.
On what value is sales tax or VAT computed when the customer pays in crypto?
Sales tax or VAT is computed on the value of the sale in the national currency, and the token is only the means of payment; the question each tax authority answers is at which moment the tokens are valued. This section describes the United Kingdom's published position, in pounds, and the rule in another country must be read from that country's own authority.
HM Revenue and Customs addresses the point in its Cryptoassets Manual, in the page on VAT for businesses. It states that VAT is due in the normal way on goods or services sold in exchange for cryptoasset exchange tokens, and that the value of the supply on which VAT is due is the pound sterling value of the tokens at the point the transaction takes place. The same page says no VAT is due on the supply of the token itself when it is used as payment, and describes its VAT treatments as provisional pending further developments. The standard rate of VAT in the United Kingdom is 20%.
Apply that to a tax-inclusive price. A VAT-registered studio in the United Kingdom quotes £9,600 including VAT for a piece of work. At 20%, the VAT inside a tax-inclusive price is one sixth of it: £1,600 of VAT and £8,000 net. If the price is fixed in pounds and the customer pays in tokens worth £9,600 at the transaction, those figures do not move, whatever the token does afterwards.
Now price the same work natively at four tokens, on a day when a token is worth £2,400, so that the price also equals £9,600. If the token is worth £2,280 when the transaction takes place, 5% lower, the consideration is £9,120. The VAT inside it is £1,520 and the net is £7,600. The tax is £80 lower and the studio's net revenue is £400 lower, on a price that never changed in tokens. Under native pricing the tax base floats with the token until the transaction; under currency pricing it is known when the invoice is written.
Where tax is computed on the currency value, a native token invoice therefore needs the rate and the valuation moment on it anyway, and the record of that rate, with its source and time, is kept with the invoice as the evidence for the tax figure.
In which unit is a refund owed?
A refund is owed in the unit the price was fixed in, unless the terms say otherwise: a currency price is refunded as the currency amount, converted to tokens at the rate on the refund date, and a native token price is refunded as the same token quantity. Stating the refund unit in advance matters because the two answers diverge as soon as the token moves.
The customer in the worked example paid 6.5384 ether for the $18,500 invoice at $2,829.46. The table shows what a full refund means if the token has moved 12% in either direction by the refund date.
| Refund rule | Token up 12%, at $3,169.00 | Token down 12%, at $2,489.92 |
|---|---|---|
| Refund the currency amount | 5.8378 ether, worth $18,500 | 7.4300 ether, worth $18,500 |
| Refund the tokens received | 6.5384 ether, worth $20,720.19 | 6.5384 ether, worth $16,280.09 |
| Difference between the two rules | $2,220.19 more with tokens | $2,219.91 less with tokens |
Under a currency price, refunding the currency amount matches the way the sale and the tax were recorded. A seller who converted the tokens on receipt has the dollars and buys back whatever quantity the day's rate requires. A seller who kept the tokens carries the difference: 0.7006 ether left over if the token rose, 0.8916 ether to find if it fell.
Under a native token price the same quantity goes back, and the customer carries the move. The result is a refund worth $16,280.09 against a payment the customer remembers as $18,500, so the terms must have said it plainly at the start.
Three details complete a refund rule: the address the refund is sent to, confirmed with the customer and not assumed to be the sending address, since payments from an exchange come from an address the customer does not control; who bears the network fee on the return; and the rate source and moment, which should be the ones used for the sale.
How does the price work when one payment is shared among several parties?
When one price is shared among several parties, the unit-of-account decision should be made once, on the total, with each party's share expressed as a percentage of it. Converting each share separately, at different moments, produces as many rates as there are recipients and totals that no longer add up to the price.
Shaka is a payment router built for that case: each party's share is set as a percentage of the deal and can be signed by each recipient before the client pays, the client pays once through a payment link, and every party receives their share at the same moment, in one transaction. It routes the payment and never holds the funds, and a deal has at most 20 recipients. It does not set the price, convert tokens or issue invoices: the pricing choices stay with the parties.
What should the invoice say?
The invoice should state the fixed amount and its unit, the token and network, the rate source and moment, the validity of any quoted quantity, the rounding rule, the tolerance, the fee rule and the refund unit. Sample wording for a currency price with a quote window follows, to be adapted to your own terms and the law that governs your contract.
- Amount due: 18,500.00 US dollars, the price of the services.
- Accepted token and network: ether on the Ethereum network, sent to the receiving address shown on the payment page.
- Conversion: the token quantity is calculated at the mid-market dollar rate for ether published by the named rate source at the time the payment page is opened.
- Validity: the quoted quantity is valid for 15 minutes. After that time a new quantity is calculated at the current rate; the amount due in dollars does not change.
- Rounding: token quantities are rounded up to four decimal places.
- Payment received: the invoice is settled when the quoted quantity arrives at the receiving address. Network fees and any withdrawal fee charged by the payer's provider are borne by the payer.
- Tolerance: a payment within 0.5% of the quoted quantity is accepted as payment in full. A larger shortfall remains due.
- Tax: the price includes tax where applicable, calculated on the amount due and shown in the national currency.
- Refunds: any refund is made as the dollar amount paid, converted to the same token at the same rate source on the refund date, and sent to an address confirmed by the customer in writing.
A native token price needs fewer lines and one more: the quantity, the token and network, the fee rule, the refund in the same quantity, and a statement that the currency value shown is an indication at a stated rate and time, given for tax and accounting. The test of either wording is that two people reading the invoice a month apart, at two different token prices, arrive at the same amount owed.
