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
Comments
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. |
Thanks for the reply. Thinking about this some more, it would be nice if I could do the following.
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? |
Thanks for the feedback, here are my thoughts:
Hope this helps. |
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. |
To summarize, the algorithm to model crypto conversion fees is:
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! |
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. |
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. |
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! |
I have the following 3-step scenario:
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:
What is the right way to enter these transactions in the input spreadsheet?
The text was updated successfully, but these errors were encountered: