Conversion to/from different fixed point decimals

[thedavidmeister]

Thanks to features like decimals in ERC20 we have tokens like USDT with 6 decimals commonly paired against tokens like USDC with 18 decimals.

This means that expressing "1 USDT = 1USDC" to humans really looks like "1 USDT = 1e12 USDC" on the contract.

For the sake of contract calculations it can be convenient to first normalise values to 18 decimals then do math on them.

prb-math already has conversions to/from integers (i.e. decimals = 0) but no way to go back and forward between other common cases like token balances

i have some examples here https://github.com/rainprotocol/rain-protocol/blob/develop/contracts/math/LibFixedPointMath.sol

but they use OZ math due to the need to specify rounding in the general case of scaling up/down, because it's relatively easy to e.g. scale "dust" down to literally 0, with potentially unintended consequences

[PaulRBerg]

Thanks for your feature suggestion.

I actually have a solution for what you need - it's called ERC20Normalizer, which is a contract available in my PRBContracts library.

But this logic is too high-level to be included in PRBMath. If anything, PRBMath may not be used with ERC-20 tokens.

[thedavidmeister]

hmmm, it's pretty common to want to do the kinds of things that prb math does with ERC20 token amounts, for the sake of calculating ratios between things, like a sale/trading curve etc.

also that link is a partial solution as it puts a limit on 18 decimals so can only scale in one direction iirc

and it relies on calling decimals on the token directly, which is against the ERC20 spec https://eips.ethereum.org/EIPS/eip-20#decimals

OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

so what i'm suggesting is NOT using the decimals interface from tokens, but merely being able to scale some value from some fixed point representation to another.

prb math already does this with integers, which are basically "0 decimals", so this can be generalised relatively easily imo.

[thedavidmeister]

OpenZeppelin/openzeppelin-contracts#3549

https://github.com/rainprotocol/rain-protocol/blob/develop/contracts/orderbook/IOrderBookV1.sol#L37

generally i've been pretty careful to avoid calling decimals() directly, and have it provided explicitly where it is needed for onchain calculations

[thedavidmeister]

oh, another example is chainlink oracles, they have "decimals" in their price feeds but don't support derived price feeds, e.g. if you wanted eth/gold price you need eth/usd then gold/usd and divide the two

their decimal values in the price feed sit behind an upgradeable contract, so rescaling dynamically before applying fixed point math to calculate the derived price ratio is required

[thedavidmeister]

FYI i moved and improved rescaling logic here https://github.com/rainprotocol/rain.math.fixedpoint/blob/main/src/FixedPointDecimalScale.sol

includes better testing and ~200-300 less gas per re-scale, and supports a wider range of inputs without error