hey guys i'm having a lil trouble in my contract. Transfer is applying a tax fee, which is what I want. But it also applies it on Liquidity deposit and withdraw. How do I change that?

The token has no idea why it's being transferred - it can't know whether it's for liquidity or for trade.
Unless you start somehow analyzing the recipient's code to determine whether it's a Uniswap router (or some other dex), but that's not going to be trivial

if I track the sender or recipient address I can see if it's going to the LP address. I'm thinking that the way is by performing some overriding with super. or something, but I still can't figure exactly haha

the uniswap router uses Transferfrom so it never receives any token actually (from what i've seen)

Yes it does get the tokens, with transferFrom.
Well, you can track the sender or receiver addresses, but that approach is valid only for UniswapV2 and no other exchanges - if that's ok for you.

Indeed, it's why I can also add a way to implement other addresses if I need later on, with some addLiquidityAddress or some function like that

Well, for example UniswapV1 uses a different address for each pair (exchange contract), so it wouldn't work there

Oh yeah, gotcha. I think it doesn't bother me if it can't be used on some exchanges, this feature shouldn't be left for the entire token life anyway, so it's just a mesure I want for the beginning (thus not being bothered about only being on uniswap v2)

Well, actually, now that I think about it a bit more... Normal swaps are also done through the router, so they have the router also as sender/recipient

indeed, it's pretty much the same as Liquidity providing from the token perspective

or withdraw

You can maybe whitelist addresses which then don't pay a fee or when sending to it the user does not pay a fee. Since pools, lp etc. mostly are fixed and don't change that often, this shouldn't be a big problem. Maybe use the ERC20 _beforeTransfer() and calculate the fee there or if an address is whitelisted. But keep in mind that LP tokens are transferable too so they could bypass the fee with this 😄

well you can't affect the LP tokens anyway, since they are not created by you

This'll work, but won't it also eliminate the fee for token buy/sell?

It uses the same router address

From what I understood, @MAXCALLS has an own fee principle in the token (additionally to the UNI fees?) which works on each transfer. If now no fees are paid when I add liquidity to UNI in that token currency and also no fees when I remove liquidity, I can transfer tokens from address A to address B by making address A add liquidity to the pool (fee free), then send that LP tokens to B and make B remove liquidity again (fee free). But maybe am thinking too far 😄

Let's say a 2% fee on trades 😉

On trades or on transfers? Like is it limited to UniSwap or is it pre-defined in the transfer() function of the token(!)?

what I want to do exactly is applying a fee on Swaps (I will check if it's a swap most likely by checking if msg.sender using transferFrom is the router, if so it then checks if sender/recipient == liquidity address) if it's the case, then the tax applies

that should leave normal transfer feeless (and it's not the issue here). It gets a bit complicated where I want to differenciate a deposit/withdraw to the liquidity from a normal swap

Does that fee go to you?

I am thinking that maybe allowances could solve the issue, or else I need to build something around _beforetransfer as you pointed out (still thinking about it)

It goes to one address collecting all the fees

Maybe there is something differiencing the way the router uses Allowances when it comes to swaps and liquidity deposit/withdraw, it's what I am trying to figure out right now too

Then it will be difficult. The only thing your contract gets is a transfer() call. There's, as mentioned by @Lauri_P, no way that the contract differentiates between a swap or adding liquidity since both use the transfer call. The only ways I'd see is to a) deploy an uniswap token pair yourself (by taking the source code) and implementing the fees - but then the pair is not registered on uniswap or b) Doing an own swap interface since then you can call your contract by using the uniswap interface, but then you cannot use the Uniswap router and also here it can be bypassed by simply using the official interface too. Don't think that there's a better solution than providing liquidity yourself (except it's risky).

Yeah I have to do it the way it's safu, I doubt messing with too much for that

there is something i'm pretty sure differs from Withdraw at least. It's that I think the tokens actually get drawn into the router, then back to the person withdrawing. I'm almost certain it does a double transfer. So if it does, I can at least check if _transfer() from comes from the Router, which only occurs when a withdraw happens

The reason I point that out is due to withdraws actually applying a double tax 😄

I think I actually know the difference. A swap always modifies the eth/token balance, adding Liquidity never does that. So I can check at the end of my transfer if the liquidity balance is the same as before, and use that as a proof of liquidity providing, right?

well, you can add liquidity with some other ratio if you want - it's just not beneficial. Also, I'm not sure, but I believe adding liquidity is often not with exactly the same ratio due to rounding issues, so the ratio changes anyway

I assume you meant the liquidity ratio, not the balance

Yes ratio indeed

Then that can be fixed by adding a small margin of error, which would also let small trades bypass that, but it shouldn't be an issue (probably trades like 0.01 eth or less)

Awesome tho, I hope this way of doing it helps for the future if you decide on using it 😊

in my experience, things like that simply tend to get very complicated. "oh, there's also this small exception...". Your contract will become horrible

It's more like taking care of the rounding by checking if the Liquidity pool ratio is approx the same instead of being absolutely the same

I don't see any flaws other than possible small trades getting through , and even, they would need to be extremely small for that

thanks alot Lauri