This new ERC404 hype seems to have a funnyside-effect in its _transfer, which can invoked via transferFrom (only allowsto transfer 1e18) and transfer (allows to transfer any amount):
As you can see, a transfer does two things:
a) Adjust balanceOf from sender andrecipient
b) Burn tokens from sender and mint tokensfor recipient
The crux here is that the tokens_to_burnand tokens_to_mint is calculated as follows:
(balanceBeforeSender / 1e18) -(balanceOf[from] / 1e18)
(balanceOf[to] / 1e18) -
(balanceBeforeReceiver / 1e18)
So let's assume we have an initial balanceof 1e18 and transfer 0.5e18 tokens, this means that our balance is decrease by0.5e18 and the recipient balance is increased by 0.5e18.
So far so good - now let's go to theburn/mint.
Due to the arithmetic operation highlightedabove, this will be as follows:
(1e18 / 1e18) - (0.5 / 1e18) = 1e18, hence1e18 are burned since solidity rounds down, but at the same time nothing isminted, since the arithmetic operation for mint is as follows:
(0.5e18 / 1e18 - (0 / 1e18) = 0, hence 0tokens are minted to the recipient.
So to summarize: We can transfer tokenswhich correctly change the balanceOf mapping but the actual ERC721 part, whichis the burn/mint that keeps track of the owner will not be correctly reflected(result in an actual loss, while still having a partial balance).
RT if you would like to learn more aboutERC404 (lmao)
As we know, this is the transferFromfunction, which is invoked upon swaps by the router. Currently, this functionis triggered using the second condition, since the UniswapV2 router willtransfer more than the "minted" amount in:
However, in such a scenario where only avery tiny amount is being bought which is converted to the corresponding tokenamount below the "minted" value, the pair will actually receive 1e18instead of the desired amount, due to the first condition being fulfilled. Theswap however is just using the provided small amount, not the full 1e18received.
(Assuming the caller has granted the routerspend approvals for ERC721 purposes lmao)
This means that (1e18-amount) is actuallydonated to the pair, since it is automatically sync'd post-swap, resulting inthis being distributed as fee for the liquidity providers.
