serenita-org/ethstaker.tax

Decimal precision

Opened this issue · 4 comments

aliask commented

Recently it seems like the decimal precision has dropped from 9 places to 6. Is it possible to revert this behaviour back to the increased precision?

eth2353 commented

I did reduce the precision because the rewards table on the website was getting a bit full and there were some issues caused by the floats, where sometimes you'd see a number like 0.0032141000000001 . I figured 6 decimal places would be more than enough.

Would it be sufficient for your usecase if the exported CSV contained the full precision (and the website still only showed the 6 decimal places)?

aliask commented

I had been using the info in an attempt to accurately track the actual ETH reward, but I guess even 9 decimal places doesn't cut it for that purpose.

Ideally accounting software like this would use the Decimal class so that the values do not suffer from any float rounding problems on the backend, and you can choose however many decimal places to display on the web UI.

eth2353 commented

If you want to be completely accurate you'd need to track it in Wei, since validators can receive as little as 1 Wei as execution layer rewards (consensus layer is limited to units of Gwei).

The numbers are stored in the database with sufficient precision at the moment:

  • daily consensus layer balances are in units of Ether (with 15 digit precision which is enough to cover every Gwei)
  • execution layer rewards are stored "raw" in Wei specifically with 27 digit precision
  • withdrawals are stored "raw" in Gwei specifically with 18 digit precision

So the indexing currently tracks every single Wei correctly.

Presenting the data on the website however is not that precise currently and would require some slightly bigger changes:

  • passing the raw, precise Wei/Gwei values from the API to the frontend
  • processing that data a little differently
    • I'm not experienced in processing this kind of data on the frontend. From my limited knowledge, I think I'd need to use something like BigInts and possibly even a custom JSON parsing library since JavaScript doesn't handle precise large numbers very well

I'm not sure if it is worth making those changes to gain that tiny bit of extra precision. For one validator I think the difference would add up to something you'd probably round off on a tax form anyway.

EvilJordan commented

You should convert the floats to a hexidecimal representation of a BigNumber, then you won't have any storage issues at all.

What you will have is some function to convert to/from on the view/import/export layer.