Comments (5)
I agree with the fact it won't affect the taxes. It might be concerning for someone who has thousands of transactions and when each one gets rounded, the total might be off. Even then I don't think it should be a lot.
I am not one with that many transactions. I can look into the code to see if I can do something about it.
Gemini was the one with this precision, other exchanges seem to be fine.
from rp2.
Interesting: that's a precision of 1/100000 Satoshi, which is too small to affect your tax results. RP2 defines precision here: https://github.com/eprbell/rp2/blob/main/src/rp2/rp2_decimal.py#L19. It's currently a constant, but I suppose it could be passed in as a CLI option. Curious: can I ask what exchange is providing numbers with such high precision? I probably won't be able to work on this very soon, but if you'd like to submit a PR I'll be happy to review the code and offer guidance, if needed.
from rp2.
Just adding my $0.02, I've seen this with Gate.IO also. My final TFUEL balance in the tax report is "0.00000025254" for my GateIO exchange entry for a crypto that trades for approx $0.20 apiece. I spent some time looking into it, and one thing I did note is that the file you get when you export transactions on GateIO has less precision than the values shown in their user interface! The fractional problem is exacerbated when they split a buy order into multiple executions which can result in some pretty minute numbers on the crypto fee that I think contributed to this end result.
I tried adjusting the crypto fees on one of my input transactions to offset the remaining balance since the change is inconsequential in the real world, but the adjustment needed was too small, and I couldn't get it to 0. It was either the number I have currently, or negative the same amount.
It's possible RP2 could rounded out / truncate this number, or just leave it as-is to avoid unintended consequences and allowing the data to speak for itself. As for my purposes, I ignore this figure on the report, and in the open positions plugin I've been working on, I have a declared figure of 0.000001 as a cutoff for ignoring wallets with inconsequential balances.
from rp2.
RP2 uses 13 digit precision, however Python Decimal supports up to 20, I think. I don't think this is a high priority issue, because the final effect on fiat tax amount is basically none. However if somebody wants to sumbit a PR to fix this, it should be fairly easy. Something along these lines:
- add a parameter to the ArgumentParser (-x / --precision) in rp2_main.py
- the code handling the new parameter passes the precision to a
rp2_decimal_setup(precision: int) -> None
function which overrides CRYPTO_DECIMALS and CRYPTO_DECIMAL_MASK
from rp2.
I took another look at this on my input, and instead of working it from the output, did a formula of sum(transfer out from exchange) - sum(crypto in at exchange) + sum(crypto fees for in transactions at exchange) which resulted in the value, and copy/pasted the resulting value into the crypto_fee field of a transaction that didnt have a crypto fee. The value was 0.000000252539985590161, which then gave me the expected 0 crypto final balance for that asset at that exchange.
from rp2.
Related Issues (20)
- Short term vs. long term gains HOT 5
- Parameter 'crypto_fee' has zero value HOT 3
- Open Positions affected by "from date" HOT 1
- Spending from Exchange with zero balance HOT 14
- option to specify columns in config.ini by letter HOT 1
- Non-zero balances when zero is expected HOT 2
- Few minor suggestions HOT 1
- Uncertain, but considering making a python wallet reader HOT 1
- Per wallet/exchange Specific Identification (FIFO, LIFO, etc...) Resolution HOT 27
- Exception when executing HOT 3
- Question about "Open Positions by Asset" report HOT 2
- Crypto fee in OUT table HOT 24
- FIFO and exchange/wallet cost-basis calculation HOT 5
- RP2 process runs after "DONE" HOT 5
- Investment Expenses can no longer be used for Deductions HOT 10
- Call for GUI coders: create an intuitive GUI to drive RP2 and DaLI HOT 3
- I can def help HOT 2
- Using Pionex data to Rp2 using dali isn't working. __crypto_sent = unknown HOT 4
- Error total in-transaction crypto value < total taxable crypto value HOT 1
- [Request] Expose settings for what constitutes a taxable event HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rp2.