Nonzero values returning as 0x00 using both BigNumber and FixedNumber

[Sshimaninja]

I'm using the below method to discover reserves and derive price on univ2 clones using BigNumbers & FixedNumbers implementation in Ethers, but BigNumbers is returning 0x00 even though prices are positive numbers.

I have also tried using FixedNumber.from(value) but receive the same 0x00 value.

Here is my query:

                    aReserve0 = aReserves[0]
                    aReserve1 = aReserves[1]
                    let aReserve0Formatted = Number(ethers.utils.formatUnits(aReserve0, token0dec))
                    let aReserve1Formatted = Number(ethers.utils.formatUnits(aReserve1, token1dec))
                    const aPrice0 = (aReserve0Formatted / aReserve1Formatted)//.toFixed(token1dec) //1 / 2100
                    const aPrice1 = (aReserve1Formatted / aReserve0Formatted)//.toFixed(token0dec) //2100 / 1
                    const aPrice0BN = aReserve0.div(aReserve1)
                    const aPrice1BN = aReserve1.div(aReserve0)
                    const aPrice0FN = FixedNumber.fromValue(aReserve0.div(aReserve1), token0dec)
                    const aPrice1FN = FixedNumber.fromValue(aReserve1.div(aReserve0), token1dec)


                    let aPriceMap = {
                        exchange: exchangeA,
                        asset: token0symbol + "/" + token1symbol,
                        aPrice0: aPrice0,
                        aPrice1: aPrice1,
                        Reserves0: aReserve0Formatted,
                        Reserves1: aReserve1Formatted,
                        Reserves0BN: aReserve0,
                        Reserves1BN: aReserve1,
                        aPrice0BN: aPrice0BN,
                        aPrice1BN: aPrice1BN,
                        aPrice0FN: aPrice0FN,
                        aPrice1FN: aPrice1FN
                    }

Here is my returned data:

{
  exchangeA: {
    exchange: 'QUICK',
    asset: 'WMATIC/USDT',
    aPrice0: 1.0447422301973823,
    aPrice1: 0.9571739048119753,
    Reserves0: 794970.8491943,
    Reserves1: 760925.351935,
    Reserves0BN: BigNumber { _hex: '0xa85774c22e243002313d', _isBigNumber: true },
    Reserves1BN: BigNumber { _hex: '0xb12aaf6fff', _isBigNumber: true },
    aPrice0BN: BigNumber { _hex: '0xf33f7d50b5', _isBigNumber: true },
    aPrice1BN: BigNumber { _hex: '0x00', _isBigNumber: true },
    aPrice0FN: FixedNumber {
      format: [FixedFormat],
      _hex: '0xf33f7d50b5',
      _value: '0.000001044742230197',
      _isFixedNumber: true
    },
    aPrice1FN: FixedNumber {
      format: [FixedFormat],
      _hex: '0x00',
      _value: '0.0',
      _isFixedNumber: true
    }
  },

As you can see I have attempted to implement all available methods, but all have the same failure.

I have also attempted to multiply by 100000, etc but that was also unsuccessful.

However, it should be noted that floats such as 1550.783, for example, have also returned 0x00, which is incredibly confusing.

Suggestions in other threads were to use BigInt, or FixedNumber, but other discussions claim BigInt library has a possible security flaws when used in conjunction with blockchain development, and FixedNumber above doesn't work.

Not really sure what to do from here.

[zemse]

In this line: aReserve0.div(aReserve1), BigNumber is being divided by BigNumber. Integer division takes place. For e.g. if you have aReserve0 as 2000 and aReserve1 as 4000, from usual math you'd get 0.5 however integer division rounds down to the integer just lower i.e. 0.

const PRECISION = 30;

const price = FixedNumber.fromValue(aReserve1.mul(parseUnits('1', PRECISION)).div(aReserve0), PRECISION)
// or
const priceD30 = aReserve1.mul(parseUnits('1', PRECISION)).div(aReserve0); // with this you need to remember to later divide by 1e30

[Sshimaninja]

Thank you, @zemse. Is 30 an arbitrary power of ten chosen to pad out the zeros, or has it been used specifically for another reason?

[zemse]

The power 30 can be arbitrary but to prevent loss of precision it should be more than the magnitude the denominator could be.

If you have denominators of DAI or ETH, the denominator would hardly go above $1T or 1T eth. Hence you won't loose bits in division. Hence 30 can be good choice.

If denominator is things like USDC that have decimal 6, then power 18 can be okay.

However, if you are working with SHIB 27 decimals, then you might need more power if you really care about precision but note that in Ethereum smart contracts you only have upto uint256, which is around 10 power 75 so you have to take care that your product is not overflowing. But in Javascript (using ethers js) you really don't have this upper bound. You can use power 100.

[Sshimaninja]

I see. If querying all pools on an exchange, for instance, one should probably either make it dynamic or use the upper boundary. Thanks for clarifying that, as well.

I've also just read your other answer about comparison operators here, which was my next question:
#3003 (comment)

[ricmoo]

Check out the answer by @zemse.

I just wanted to add that the security concerns with BigInt does not affect you. Those concerns are regarding the side-channel attacks possible when running cryptographic signing (for example), since the timing required for various numbers can reveal the value. None of your values are private. :)

[Sshimaninja]

That's good. I did assume that the security concerns listed by other users weren't anything I needed to concern myself with, however, the above solution looks promising so I'll try that before adding a new library.

[Sshimaninja]

I seem to still be getting 0x00 when using FixedNumber.

                const aPrice0BN = FixedNumber.fromValue(aReserve0.mul(utils.parseUnits('1', token0dec)).div(aReserve1), token1dec)
                const aPrice1BN = FixedNumber.fromValue(aReserve1.mul(utils.parseUnits('1', token1dec)).div(aReserve0), token0dec)

                    //Exchange A pricing and reserves (calling getReserves(poolID))
                    aReserve0 = aReserves[0]
                    aReserve1 = aReserves[1]
                    let aReserve0Human = Number(utils.formatUnits(aReserve0, token0dec))
                    let aReserve1Human = Number(utils.formatUnits(aReserve1, token1dec))
                    const aPrice0 = (aReserve0Human / aReserve1Human)
                    const aPrice1 = (aReserve1Human / aReserve0Human)
                    const power = FixedNumber.fromValue(BigNumber.from(10000000000))
                    const aPrice0FN = (FixedNumber.fromValue(aReserve0.mul(utils.parseUnits('1', token0dec)).div(aReserve1), token1dec)).mulUnsafe(power)
                    const aPrice1FN = (FixedNumber.fromValue(aReserve1.mul(utils.parseUnits('1', token1dec)).div(aReserve0), token0dec)).mulUnsafe(power)
                    const aPrice0BN = BigNumber.from(aPrice0FN)
                    const aPrice1BN = BigNumber.from(aPrice1FN)

Results:

PricesA:
{
  exchangeA: {
    exchange: 'QUICK',
    asset: 'USDC/DAI',
    aPrice0: 0.9992630851859796,
    aPrice1: 1.0007374582579354,
    Reserves0: 1343687.196627,
    Reserves1: 1344678.1098462348,
    aPrice0BN: BigNumber { _hex: '0x00', _isBigNumber: true }, <----------------this is where BN touched me.
    aPrice1BN: BigNumber {
      _hex: '0x09c4dba54be92a797d34bbf6b200528db2be600000',
      _isBigNumber: true
    },
    Reserves0BN: BigNumber { _hex: '0x0138d9ff7fd3', _isBigNumber: true },
    Reserves1BN: BigNumber { _hex: '0x011cbf257a6f2fa3bdd12a', _isBigNumber: true },
    aPrice0FN: FixedNumber {
      format: [FixedFormat],
      _hex: '0x00', <----------------and here
      _value: '0.0',
      _isFixedNumber: true
    },
    aPrice1FN: FixedNumber {
      format: [FixedFormat],
      _hex: '0x1abf52d44dc17277fa071f2e96df737d07ca37000000',
      _value: '10007374582579354592781015582680000.0',
      _isFixedNumber: true
    }
  },

[Sshimaninja]

Looking more into this, I've come to realize that the problem occurs only when attempting to divide 2 hexadecimal BigNumbers of different levels of precision.

I noticed that implementing zemse's method didn't change the outcome, as the numbers returning 0x00 == 1575.345, for example, which would round down to a number > 0.

Looking at pairs WMATIC/WETH and WETH/DAI, they produce normal results. As does USDT/USDC, whereas WMATIC/USDC produces 0x00 numbers, therefore I can only assume differences in hexidecimal precision are the culprit.

Looking into ways to add precision to the smaller numbers, or take precision away from larger numbers, however, BigNumbers.toPrecision() and .toFixed() do nothing at all.

Let me know if anyone can think of another solution. In the meantime, I'll be update if I find anything.