Precision Loss During ETH-to-DOT Conversion Causes removeLiquidityETH Test Failures

[sekisamu]

Description:
When running removeLiquidityETH tests in v2-periphery, transactions revert due to a DecimalPrecisionLoss error originating from the Substrate runtime. This occurs during value conversions between ETH (18 decimals) and DOT (12 decimals).

Key Details:

• Error Context:
  In this test case, the Substrate runtime rejects conversions with a remainder, e.g., converting 3999999999999998000 wei (ETH) to DOT results in a remainder of 998000 wei, which cannot be represented in DOT’s 12-decimal system.

  • ETH value: 3999999999999998000 (wei)
  • Conversion: ETH (1e18) → DOT (1e12) requires division by 1e6.
  • Result: 3999999999999998000 / 1e6 = 3999999999999.998 → Remainder 998000 (unrepresentable in DOT).

• Why This Matters for Uniswap:
  Small values (e.g., dust amounts, liquidity adjustments) are common in Uniswap operations. Precision loss in these cases can:

  • Break transaction atomicity (e.g., failed swaps/liquidity removals).
  • Cause incorrect balance calculations, harming user trust.
  • Trigger unexpected reverts in dependent smart contracts.

Reproduction Steps:

1. Clone repo and set up:

   git clone https://github.com/sekisamu/v2-periphery-polkadot  
   cd v2-periphery-polkadot  
   pnpm install  

2. Add .env file.
3. Run failing test:

   npx hardhat test ./test/UniswapV2Router01.spec.ts --network local --grep "removeLiquidityETH"  

Error Trace on hardhat side

  UniswapV2Router{01,02}
    UniswapV2Router01
      1) removeLiquidityETH
    UniswapV2Router02
      2) removeLiquidityETH


  0 passing (4m)
  2 failing

  1) UniswapV2Router{01,02}
       UniswapV2Router01
         removeLiquidityETH:
     Error: execution reverted (no data present; likely require(false) occurred (action="estimateGas", data="0x", reason="require(false)", transaction={ "data": "0x02751cec00000000000000000000000085ad9db6e0a565ec4c3a3c891bee7f0906108d600000000000000000000000000000000000000000000000001bc16d674ec7fc1800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000f24ff3a9cf04c71dbc94d0b566f7a27b94566cacffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff", "from": "0xf24FF3a9CF04c71Dbc94D0b566f7A27B94566cac", "to": "0xC1F9731296d8Cf0829d7a8bCf3a39fa2065009B6" }, invocation=null, revert=null, code=CALL_EXCEPTION, version=6.14.3)

Error Trace on substrate node

Err(TrapReason::SupervisorError(Module(ModuleError {  
  index: 80,  
  error: [40, 0, 0, 0],  
  message: Some("DecimalPrecisionLoss")  
})))  

[athei]

Thanks for the extensive explanation. This is indeed a problem that is not easily solved without changing the denomination of the host chain. Will need to think about this.