Governance Proposal View Decoding should indicate scientific notation of values

[nambrot]

Expected Behavior

The values should should display scientific notation when above 1 Million

Current Behavior

The values are displayed in full

[tromer]

On related note (which may merit a dedicated issue):

Some parameters have magical correction factors between the natural representation and the one used by contracts (and thus showing in proposals). This makes it error-prone to verify proposals.

For example, consider the way fixed-point fractions are represented by FixidityLib:

$ celocli governance:view --proposalID 1
...
  1: 
    contract: EpochRewards
    function: setCarbonOffsettingFund
...
    params: 
      partner: 0x0ba9f5B3CdD349aB65a8DacDA9A38Bc525C2e6D6
      value: 1000000000000000000000
...

To understand what reward fraction this really sets, one would have to open up the code of FixidityLib and figure out how it represents fixed-point fractions as integers.

Similarly with the reserve fraction of CGP 0007 and CGP 0008. The CGP mentions the correction factor (Data: 1000000000000000000000 (1/1000 * 10^24 = 1e21)), so you can sort of know what to expect... But imagine if we had a proposal that claims to set some number to 17 and indeed puts 17 in the actual parameter, yet (unbeknownst to the reviewer) the contract uses FixidityLib for that parameter so 17 actually means 17e-24.

Same problem with the 10^-18 factor for CELO amounts as in CGP 0006. Now you may say, people are already used to dividing by 10^18 whenever they see a huge number representing CELO amounts. But that's not good enough, and in fact is dangerous: if the number does look natural, people may forget that it should be divided by 10^18 anyway. And also, conversely: if for whatever reason some contract accepts CELO amounts as integers instead of fractions, and a proposal sends it 10^19 in a parameter, reviewers will think that means 10 CELO.

I'm not sure how to resolve all of these, and they also affect the usability of celocli in many other use cases.

[nambrot]

That is absolutely a great point! I'm not sure how easy it will be to automatically parse that a value is indeed a fixidity value, but whoever works on this should consider looking into it!

[yorhodes]

related ethers-io/ethers.js#228