1 wei of token remains after requesting removal of 100% from pool

[philipSKYBIT]

Pool web page: https://app.uniswap.org/#/pool/120610?chain=polygon Pool contract address: https://polygonscan.com/address/0xc677ce9130de65b24657c32847262df6aaab9e15#tokentxns

First I created the pool, wanting to deposit 200k tokens. Exactly 199,999.999999999991586348 tokens we transferred. I requested removal of all liquidity by clicking Remove Liquidity button on pool web page, then the 100% button. I ended up getting only 199,999.999999999991586347 back. The pool web page then shows it's Closed, and all liquidity is 0, which is technically not correct as a tiny quantity remains.

This is definitely a bug that needs to be fixed because when 100% is requested, it means ALL tokens that are in there, so there shouldn't be any issues related to rounding numbers (as there could be if under 100% was requested).

I know it's just a tiny amount but the issue can have follow-on consequences, such as for accounting. In my particular case I need all of my tokens burned on Polygon for a bridge-related matter that I'm working on together with Polygon Support staff, but some of it is still in the pool, so I can't burn it until it's back in my address.

You can see the Uniswap pool contract has 0.000000000000000001 tokens and holds 100% of the supply: https://polygonscan.com/token/0xc1abd37d1394cfbe1c3edcc373ecf89108318c59#balances

Please transfer the remaining 1 wei of token to my address ASAP so that I can proceed with what I need to do.

Then please update the code to fix the bug.

Thank you.

[marktoda]

Hey @philipSKYBIT - thanks for reporting this! This is a known precision loss from modifyPosition, you can see some more details in this issue: https://github.com/Uniswap/v3-core/issues/424.

Please transfer the remaining 1 wei of token to my address ASAP so that I can proceed with what I need to do.

We won't be able to do this, as the pool contract is permissionless and doesn't have a dust withdrawal function. I'd suggest that folks running into this simply handle the slight precision loss in their integrations.

The issue I linked above also has a few potential solutions listed, though since v3 is already deployed on mainnet and is immutable we likely won't be able to make those changes. For the time being, adding a note of this to the documentation might be helpful - feel free to submit a PR doing this if you're inclined.