search

Uniswap / interface

🦄 Open source interfaces for the Uniswap protocol
https://app.uniswap.org
GNU General Public License v3.0
4.95k stars 5.02k forks source link

Support of fee-on-transfer tokens #835

Closed realrouse closed 4 years ago

realrouse commented 4 years ago

Is your feature request related to a problem? Please describe. The Uniswap v2 front-end doesn't support deflationary tokens. (tokens that burn a % of each transaction, like the one I'm contributing to, "BSOV" (https://bsov.io). BSOV Token Request: https://github.com/Uniswap/uniswap-frontend/issues/836 Deflation is very important for the deflationist community, and many of us wish that BSOV keeps on burning, while trading on-chain.

Describe the solution you'd like Possibly like @NoahZinsmeister described to me in the Discord: A feature in the Uniswap v2 front-end that lets the user "set their slippage to whatever % deflation they expect from their token".

Describe alternatives you've considered When there is a token request of a deflationary token on Github, then there could be a custom parameter that could be prefixed for easier implementation of deflationary tokens in the Uniswap v2 front-end, so the user would not need to set their slippage for every trade, to match the % deflation.

Additional context While I don't know how to develop these things, then there are several things I can help you with, like paying you some BSOV or doing tasks revolving Media & Communication (like design and videos).

ciconsulting commented 4 years ago

I believe this issue also affects tokens that have a transfer and/or storage fee. In v1 there didn't seem to be an issue but with v2 it requires fee exemption of the router and pool address which is a less than ideal solution (particularly having to exempt the pool from storage fees) but it does some to work.

Transfer and storage fees are not very common features but there are a few examples. This will probably become more common as tokens backed by real assets gain in popularity.

NoahZinsmeister commented 4 years ago

For posterity, a summary of the status of fee-on-transfer (FoT) tokens on Uniswap V2 follows. Note that this also applies to tokens which deflate on transfer, but does not necessarily apply to tokens which deflate in other ways.

Swapping {W,}ETH -> FoT swaps will succeed.

FoT -> {W,}ETH swaps will fail because of incompatibility with the current router, but may be supported in a future router release. Nothing theoretically prevents these swaps from occurring.

Adding Liquidity Adding liquidity will succeed.

Removing Liquidity Removing liquidity will succeed, as long as ETH is not one of the outputs. This limitation may be removed in a future router release. Unfortunately, the easy fix of receiving WETH directly (instead of ETH) is not supported in the current interface. This limitation may be removed in a future interface release.

NoahZinsmeister commented 4 years ago

For those wishing to manually remove their FoT<>WETH liquidity before a fix is released on our end, steps to do so follow:

Manually Removing Liquidity for FoT<>WETH Pairs

Step 1: Approve the Uniswap router to transfer your pool tokens

Step 2: Burn your pool tokens

Step 3 (Optional): Convert your WETH to ETH

CryptoChaser13 commented 4 years ago

So we can never ever remove liquidity with burning tokens? What would be an ideal solution or alternative for this? I might face loss for this one.

realrouse commented 4 years ago

So we can never ever remove liquidity with burning tokens? What would be an ideal solution or alternative for this? I might face loss for this one.

If you read what @NoahZinsmeister wrote in the post above, you can Remove Liquidity by following his guide above.

CryptoChaser13 commented 4 years ago

So we can never ever remove liquidity with burning tokens? What would be an ideal solution or alternative for this? I might face loss for this one.

If you read what @NoahZinsmeister wrote in the post above, you can Remove Liquidity by following his guide above.

Even if its a deflationary token?

ciconsulting commented 4 years ago

Can confirm it works even if it’s a deflationary token or a token that has a transfer fee.

CryptoChaser13 commented 4 years ago

Can confirm it works even if it’s a deflationary token or a token that has a transfer fee.

Lastly, its deflationary, but paired with ETH, would still work?

NoahZinsmeister commented 4 years ago

yes @MirasolFerrer, please stop cluttering the conversation.

NoahZinsmeister commented 4 years ago

removing Fot <> WETH liquidity into ETH should now work on the frontend

FoT -> ETH/token swaps should now work on the frontend

two notes on swaps:

realrouse commented 4 years ago

removing Fot <> WETH liquidity into ETH should now work on the frontend

FoT -> ETH/token swaps should now work on the frontend

two notes on swaps:

  • all swaps involving FoT tokens must specify an exact input, not an exact output
  • all swaps involving FoT tokens must have slippage set to at least the fee percentage

Thank you for the swift development, @NoahZinsmeister ! I was wondering:

  1. If there could be made a custom URL to set the slippage to the ease of our users?
  2. If it is possible to develop a workaround so that you are able to specify exact output?
  3. Is it possible that the slippage could be set automatically when you for example list a FoT token like BSOV (https://bsov.io) ?
  4. Should I create another issue about this, or is this comment sufficient?

If there is anything you'd need help with, Noah, let me know! 😁

NoahZinsmeister commented 4 years ago

If there could be made a custom URL to set the slippage to the ease of our users? tracking in #876

If it is possible to develop a workaround so that you are able to specify exact output? we are not going to be supporting this on the default frontend, you are welcome to come up with a custom solution.

Is it possible that the slippage could be set automatically when you for example list a FoT token like BSOV (https://bsov.io) ? it's unlikely

evinke commented 4 years ago

I just posted this on reddit: https://www.reddit.com/r/UniSwap/comments/hs6uqf/problem_with_removing_tokens_and_eth_from_ampl/

Can this be related to this issue? When will this be fixed in the frontend? I might have migrated from V1 to V2, but I am not sure...

Fukunaga42 commented 4 years ago

Hey guys we have the same problem on our DTH/ETH pair https://uniswap.info/pair/0xC0Cb62f0b5C9574Cc88907dC0712F27b4a6a60c1. Users in front-end are not able to remove their liquidity, The workaround describes heres works, but how can we do to make it works directly from your front-end?

NoahZinsmeister commented 4 years ago

removing liquidity for FoT tokens works on the frontend, you just have to specify a slippage higher than the fee

a7om commented 4 years ago

Just put an issue in that is similar to this with metamask that relates to getting UMA/ETH pool tokens out that are stuck. Can't approve or withdraw any pool tokens, signing the transaction always fails. Nonce on the approval message is set to 0x00 and the transaction is never sent to the ledger.

Seems like this is a problem with Ledger/Metamask interacting with Uniswap V2. Directly communicating with a Ledger would stop a huge portion of these problems it seems like. After doing a lot of research on how to fix this, I have seen countless people with the same issue recently.

shivasai780 commented 3 years ago

Can anyone explain me what is the difference between swaptokens and swaptokenssupporting feeto

italoHonoratoSA commented 2 years ago

Can anyone explain me what is the difference between swaptokens and swaptokenssupporting feeto

Here the details: https://docs.uniswap.org/protocol/V2/reference/smart-contracts/router-02

cache-gold commented 2 years ago

I believe we have discovered a work around for transfer fee tokens that works with our CACHE Gold (CGT) token. Our token has both a fee on transfer and a storage fee. The solution is to exempt:

The Uniswap v3 Factory contract - 0x1F98431c8aD98523631AE4a59f267346ea31F984

The Uniswap v3 Positions contract - 0xC36442b4a4522E871399CD717aBDD847Ab11FE88

Our own Uniswap v3 Pool contract(s) - 0x98eb3887B6c2CD50341aF13E26BA5111Ec585c57

In our experience if you are developing any type of token that has fees of any kind in addition to standard Ethereum gas fees, it is advisable to make sure you build in a function to exempt specific addresses from fees, especially if you want your token to be compatible with existing and future DeFi infrastructure.

Right now we are testing our new v3 pool and everything seems to be working as expected.

The solution described above also worked for v2.

Hope this helps.

italoHonoratoSA commented 2 years ago

These are the available functions to call for our team

https://etherscan.io/address/0xabd8f6cd6b1f9ee6ca88528a4fccff84093a23e8#writeContract

Screen Shot 2022-04-21 at 7 20 36 AM

I'm afraid we're completely stuck here on why we can't migrate to V3 or even withdraw the tokens / W (ETH) .. we can't afford to take a loss here and are willing to award ETH to anybody who can figure this out.

I have already solved similar cases with many BNB stuck. I went through that too once.

My question: why did you renounce the contract?

sswink commented 2 years ago

How does the uniswap/pancakeswap front end know to use the SupportingFeeOnTransferTokens functions when interacting with my contract?