Add option to specify fiat_fee in out_header vs just crypto_fee

[jamesbaber1]

Some exchanges let you pay fees with their token so the token you see and the token you pay fees with can be different. So in these cases I find my self normalizing all fees to fiat anyways.

Could this be added a option? Thanks!

[eprbell]

This sounds like a case that can be modeled with a fee-only transaction. If you have an out transaction denominated in crypto C1 and you pay fee denominated in C2, you can do this:

• model the C1 out transaction with 0 crypto_fee;
• add a C2 fee-typed out transaction.
• if you like add something in the notes to point out the two transactions are connected

Let me know if this answers your question.

[jamesbaber1]

Ok gotcha, what I have been doing is just doing another conversion back to the crypto fee from fiat, which works, but I assume you are then converting the crypto_fee back to fiat in the tax engine. right? Its not a make it or brake it thing for me, its just a nice to have and saves an extra step

[eprbell]

Right, so to summarize, here's what you can do in an out-transaction, wrt fees:

• if the fee was paid in the same crypto as the transaction: pass crypto_fee > 0 and no fiat_fee: RP2 populates the fiat_fee internally as spot_price * crypto_fee;
• if the fee was paid in fiat (not in crypto): pass crypto_fee == 0 and fiat_fee >= 0: RP2 uses fiat_fee as passed in;
• if the fee was paid in the same crypto as the transaction, but the exchange reports a fiat_fee value that doesn't match crypto_fee (this happens sometimes on Coinbase): pass crypto_fee >= 0 and fiat_fee >= 0 (it should generate a warning log)
• if the fee was paid in a different crypto than the one the transaction is denominated in: use an additional fee-only transaction (transaction_type="fee"). I don't think this case can be represented with only one out-transaction with a fiat fee, because this would not capture the fact that some of the second crypto has flowed out (which affects accounting for that crypto).

Perhaps this should go in a FAQ, as it's a good question. Let me know if the above makes sense or if you think more clarification is needed.

[jamesbaber1]

Ok so sounds like I can add both crypto_fee and fiat_fee to the out table and config and RP2 will know what to do? Also crypto_fee is required while fiat _fee is not it seems

[eprbell]

Yes, that would be the third case I listed above: in case of value mismatch, RP2 will use the mismatched fiat_fee in its tax calculation, but will issue a warning.

The crypto_fee is required, because I my thinking when I designed RP2 was that the fee would always be paid in crypto for out-transactions. Do you know of a case of an exchange where out-transaction fees are paid in fiat? In the current implementation this can still be captured using case 2 above, but crypto_fee has to be passed in as 0. Perhaps I can just change the implementation of out-transactions to be similar to in-transactions (both crypto_fee and fiat_fee are optional).

[jamesbaber1]

Ok yea that works, I will try that then. Maybe the validation checks if at least one kind of fee is specified. And I dont, I have typically only seen crypto fees.

[eprbell]

I added a FAQ about this: https://github.com/eprbell/rp2/blob/main/docs/user_faq.md#how-to-represent-fiat-vs-crypto-transaction-fees.

After some more thinking on this topic, I came to the conclusion that the existing implementation is OK as it is: giving prominence to crypto_fee (non-optional) over fiat_fee (optional) in out-transactions seems correct to me (because we don't know of any exchange that allows fiat fees in out-transacitons). If we discover an exchange that allows fiat fees in out-transactions, then we should make both crypto and fiat fees optional in out-transactions.

[jamesbaber1]

Ok cool sounds good