Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to enter the swap fee without double counting the deduction? #23

Closed
stevendavis opened this issue Apr 3, 2022 · 8 comments
Closed

Comments

@stevendavis
Copy link

I have the following 3-step scenario:

  1. Buy Coin1
  2. Swap Coin1 for Coin2, paying a fee in Coin1 currency
  3. Sell Coin2 for USD.

To enter this scenario in rp2, I split the swap into two separate transactions at the exact same timestamp with each transaction truthfully reporting the fee for the swap. The transactions are OUT(Coin1) and IN(Coin2). When I run rp2 on this scenario, it correctly reports a final position size of zero for both Coin1 and Coin2. However, this approach is double counting the fee -- it reduces the proceeds for the sale of Coin1 and it also increases the cost basis of Coin2. I think this is not allowed.

Here is what I want to accomplish:

  1. Apply the swap fee towards the cost basis of the purchased asset (Coin2).
  2. Do not double-count the fee deduction, meaning the fee should not be used to reduce the proceeds from the sold asset (Coin1).
  3. Accurately reduce the position size of the sold asset (Coin1) by the total transaction cost including the fee.

What is the right way to enter these transactions in the input spreadsheet?

@eprbell
Copy link
Owner

eprbell commented Apr 3, 2022

To model this correctly you need to assign the crypto_fee (not fiat_fee) field either in the OUT transaction or in the IN transaction, but not in both. If you assign it in the OUT transaction it will reduce the proceeds, if you assign it in the IN transaction it will increase the cost basis: the final effect is the same. This is also what DaLI does when modeling swaps.

@stevendavis
Copy link
Author

Thanks for the reply. Thinking about this some more, it would be nice if I could do the following.

  1. Assign the crypto fee in both the IN transaction and the OUT transaction, because this matches the downloaded data from the exchange and is what I expect to see when reviewing transactions for accuracy.
  2. Override the crypto fee in the OUT transaction by setting the fiat fee = 0

When I tried this, rp2 correctly generates a warning (crypto_fee * spot_price != fiat_fee). The warning is helpful and non-fatal as it should be. However the fiat fee does not override the crypto fee. Would it be possible to add a configuration flag to cause the fiat fee to override the crypto fee when computing the tax for the transaction?

@eprbell
Copy link
Owner

eprbell commented Apr 3, 2022

Thanks for the feedback, here are my thoughts:

  1. assigning the fee twice would mean that you paid the fee twice and it would affect taxes accordingly. I'm not sure what the data from the exchange is showing but it's important to avoid ambiguity at the RP2 level (representing a fee that was paid only once by entering it twice would be confusing and break RP2 operational semantics).
  2. usually fees for outgoing transactions are paid in crypto: are you paying out fees in fiat (with no crypto) instead? If the crypto fee is specified and you don't specify a fiat fee, then the fiat fee is computed internally by RP2 as crypto_fee * spot_price. Normally you would just pass the crypto_fee without assigning fiat_fee. However some exchanges (e.g. Coinbase) sometime report both crypto_fee and fiat_fee and the two values don't match, so RP2 allows you to specify both crypto_fee and fiat_fee to model such cases.

Hope this helps.

@stevendavis
Copy link
Author

Thanks for the reply. I've been manually entering and splitting the swap transactions for rp2 using data from various sources. If DaLi knows how to handle swaps, it may be more fruitful to use DaLi.

@eprbell
Copy link
Owner

eprbell commented Apr 4, 2022

To summarize, the algorithm to model crypto conversion fees is:

  • identify in exchange reports how much you paid in crypto fees for the conversion
  • if the crypto fee was paid in the out currency, assign it to the crypto_fee field of the Out Transaction
  • if the crypto fee was paid in the in currency, assign it to the crypto_fee field of the InTransaction

The fiat fee should not be used, unless the fee was paid in fiat: in this case assign the fiat_fee of the InTransaction and leave the crypto_fee to zero.

I added this information to the conversion FAQ: https://github.com/eprbell/rp2/blob/main/docs/user_faq.md#how-to-handle-conversion-of-a-cryptocurrency-to-another

Hope this is clearer, thanks for helping refine the documentation!

@stevendavis
Copy link
Author

My apologies for continuing this conversation. If I understand correctly, the guidance above is a recommendation, not a hard requirement, and the user could assign the fee to the BUY transaction if she wanted to. My preference would be to always use the fee to increase the cost basis of the purchase rather than decreasing the proceeds from the sale.

@eprbell
Copy link
Owner

eprbell commented Apr 5, 2022

No worries! Yes, the point is that the fee must be expressed fully and only once. If the fee is fiat you can express it using the fiat_fee field either in the InTransaction or the OutTransaction.

@eprbell
Copy link
Owner

eprbell commented Apr 5, 2022

This conversation made me realize the FAQ on crypto conversion needed more work. I uploaded a new version, which hopefully is comprehensive enough: https://github.com/eprbell/rp2/blob/main/docs/user_faq.md#how-to-handle-conversion-of-a-cryptocurrency-to-another

Let me know if you think this is clear enough or if I need improve it some more. Thanks for identifying a weak point in the docs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants