docs(decimal-precision): add decimal precision analysis doc

[glevco]

Rendered

[trondbjoroy]

The technical tradeoff looks to be essentially free so we can base our decision on business and ecosystem needs. From that perspective, I agree with 18 decimals. 3 main reasons for that:

• EVM compatibility. Nearly all EVM tokens default to 18 decimals as it's the default in OpenZeppelin contracts. Bridging any of them to Hathor without a 1:1 decimal match would require truncation or rounding, introducing precision loss and potential trust issues as users expect exact amounts.

• Integration cost reduction. Developers bridging EVM assets or building cross-chain applications would need to handle decimal conversion logic if we used 8 decimals.

• Avoiding a second migration. Going to 8 decimals and later finding it insufficient for EVM would mean a second protocol change.

[obiyankenobi]

I also agree with 18 decimals, given the analysis.

One other question: I imagine network impact is also minimal, right? That could impact TPS. I mean, it will just be a couple of extra bytes per tx.

[glevco]

@obiyankenobi

One other question: I imagine network impact is also minimal, right? That could impact TPS. I mean, it will just be a couple of extra bytes per tx.

Yes, it would be at most 5 extra bytes per output, for extremely large values (comparing 13 bytes to 8 bytes of the current encoding of large values). This is small in comparison to other recent additions to transaction size, such as headers (nano, fees), and shielded outputs in the future.