Question on 0.00001 SAT Precision Data

[haricharan]

Is there a way to increase the precision of the asset amounts especially for higher value cryptos (like BTC)?

For example, I have the following in IN table

BTC | 0.000214345960800000 BTC | 0.001076080000000000 BTC | 0.000000135094000000

The total value of BTC should be 0.003331371054800000, but the BTC Tax tab in the generated full report shows an outstanding balance of 0.00333137105. The BTC In-Out tab also doesn't show all the decimal places.

[eprbell]

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.

[haricharan]

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.

[mdavid217]

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.

[eprbell]

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

[mdavid217]

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.