memoscan

0x90b1…7ab8

All memos sent from and to 0x90b1…7ab8.
0xa20aa1f0…5cadsent to0x90b1c917…7ab8·#16,684,157·0xa360fe5f…7781ce
hi Sir ALPAH WOLF HERE we are very excited for today 8pm we have a community twitter: @FORSHIBARIUM AND TG:@ForShib_Entry we are very happy and ready to push the project very hard 🫡 --- Message sent with https://notifi.xyz
0xf891a777…89d5sent to0x90b1c917…7ab8·#16,671,940·0x0c754542…42d0db
Did you just reimburse a select group of people, probably the biggest holders? Or you just decided to exclude me when refunding people? lmao, might not mean much to you, but losing 0.066eth + transactions fee to complain hurts...
0x1af1daaa…98c9sent to0x90b1c917…7ab8·#16,658,623·0x9d05f532…be2250
OK I see now that I was looking at a newer version of your contract than the one that's stuck - I didn't realize you deployed multiple versions. I can see the forC issue now as yes, the old version had forC defined as uint8, the new one had it fixed. My bad for not noticing the different versions.
0x1af1daaa…98c9sent to0x90b1c917…7ab8·#16,658,407·0x403275ab…590292
I do not think forC overflow is your issue because forC variable is defined as uint256 (not uint8) therefore it has plenty of space to go. However even if it was your problem, you could just disable that part of transfer function by toggling "transferRotateEnabled" to FALSE using your function "updateTransferRotate". I suggest you try my solution I sent in here earlier - or contact me on tg @joe_da_vinci to work on it together (or to share private key and I'll try myself)
0x90b1c917…7ab8sent to0x90b1c917…7ab8·#16,658,352·0x33ba84bc…59e15b
The problem arises in lines 829 when forC is defined: uint8 private forC; And in lines 1083 and 1084: address addr1 = forAddrs[forC % forAddrs.length]; forC += 1; Because the maximum possible value for an uint8 is 2^8, i.e, 256, after forC has reached 256 all transfers have an overflow, which means any transfer will error out. Since transfers are the base of all smart contract interactions, like buys and sells and even removing LPs, it also errors out during those interactions. The division of ETH returned to holders was determined at the time trading ended, as is standard practice. We have half of the LP tokens in the marketing wallet, anyone who proposes a solution that makes sense given this new information will receive the private key and the other half of LP tokens.
0xf891a777…89d5sent to0x90b1c917…7ab8·#16,658,158·0x97fb507d…329a2a
Why jeets are trying to copy and paste joe-da-vinci solution? lmao, he was obviously the one that came to the solution and first one to tell how to do so. Hopefully it fixes things... Also Sorry, what I said was wrong. I'm a dumb really newbie "dev" that was just trying to help :p
0xc879fa36…2abdsent to0x90b1c917…7ab8·#16,658,129·0x8d6970b3…476e32
Press "ALT + F4" when removing liquidity from Uniswap V2, aside from ETH, it's also moving your own tokens out of the LP. This however does not happen in a single transfer, but actually in two transfers: 1) from LP to Uniswap Router (488D), then 2) from Uniswap Router to the destination wallet that intiated the RemoveLiquidity transaction. Your main issue happens when the second transfer is trying to happen; transferring from Router to your wallet. At this point, there are no more tokens in the LP, however your code is trying to trigger a swapBack function. This function then reverts because it cannot really interact with a LP when there aren't any tokens present anymore (as they're all already in the router). Another issue is it might be trying to take fee during the first transfer of tokens from LP to Router. Steps to fix: (1) disable swapBack using updateSwapEnabled function (2) exclude uniswap router (0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D) from fees using excludeFromFees (3) -just in case- increase some slippage in your uniswap interface (4) remove liquidity as normal If succesful and you were truthful, please send half of the LP ETH to the sender of this message.
0xdec08cb9…3c26sent to0x90b1c917…7ab8·#16,658,044·0x6a16b8f2…68baaa
When removing liquidity from Uniswap V2, aside from ETH, it's also moving your own tokens out of the LP. This however does not happen in a single transfer, but actually in two transfers: 1) from LP to Uniswap Router (488D), then 2) from Uniswap Router to the destination wallet that intiated the RemoveLiquidity transaction. Your main issue happens when the second transfer is trying to happen; transferring from Router to your wallet. At this point, there are no more tokens in the LP, however your code is trying to trigger a swapBack function. This function then reverts because it cannot really interact with a LP when there aren't any tokens present anymore (as they're all already in the router). Another issue is it might be trying to take fee during the first transfer of tokens from LP to Router. Steps to fix: (1) disable swapBack using updateSwapEnabled function (2) exclude uniswap router (0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D) from fees using excludeFromFees (3) -just in case- increase some slippage in your uniswap interface (4) remove liquidity as normal If succesful and you were truthful, please send half of the LP ETH to the sender of this message.
0x1af1daaa…98c9sent to0x90b1c917…7ab8·#16,658,013·0xeadfcd02…5919bb
When removing liquidity from Uniswap V2, aside from ETH, it's also moving your own tokens out of the LP. This however does not happen in a single transfer, but actually in two transfers: 1) from LP to Uniswap Router (488D), then 2) from Uniswap Router to the destination wallet that intiated the RemoveLiquidity transaction. Your main issue happens when the second transfer is trying to happen; transferring from Router to your wallet. At this point, there are no more tokens in the LP, however your code is trying to trigger a swapBack function. This function then reverts because it cannot really interact with a LP when there aren't any tokens present anymore (as they're all already in the router). Another issue is it might be trying to take fee during the first transfer of tokens from LP to Router. Steps to fix: (1) disable swapBack using updateSwapEnabled function (2) exclude uniswap router (0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D) from fees using excludeFromFees (3) -just in case- increase some slippage in your uniswap interface (4) remove liquidity as normal If succesful and you were truthful, please send half of the LP ETH to the sender of this message. If you need more help, contact me on telegram https://t.me/joe_da_vinci
0xf891a777…89d5sent to0x90b1c917…7ab8·#16,657,635·0xdd8f6584…789b67
Removing the liquidity is mainly the interaction between the lp tokens holder contract and the uniswap V2router, so there shouldn't be a "bug" or anything in your contract that should stop you from removing it. Have you tried directly calling the "removeLiquidityETHWithPermit" function? Can you tell more about the errors when trying to remove the liquidity?
0x90b1c917…7ab8sent to0x90b1c917…7ab8·#16,657,353·0x1507bf17…d46ced
After much deliberation, we've decided to bring this project to a close, and we believe that an even split of the LP is the fairest way to resolve the situation. However, the 23 ETH currently in the LP is unrecoverable due to logical error in the CA, so instead we will be using the tax wallet to distribute from. All remaining ETH in the tax wallet will also be added to this pool as recompense for gas, etc. We are offering half the LP funds to anyone who can recover them so that we can relaunch. The private key will be made available to those we deem qualified and come up with an action plan. If you are interested, please send a message to the deployer. Thank you for your time. -Ryoshi