I am a large holder of a certain token. We recently notice that one wallet where liquidity was being sent regarding 8% of transactions was unwrapping and selling those tokens. We confronted the developer. Right around the same time, we noticed a strange change to the contract. It was not verified, so I decompiled it with ByteCode. Here is the decompiled version. If you would be willing to help us dig further on telegram and potentially catch a scammer in the act, let me know. I'm not sure if this is enough info without the original contract which I can also post if that is helpful. Looking for any information you can provide. Thank you. enter image description here

  • You have to post the contract's address and your post does not include the decompiled bytecode, only a small screenshot.
    – Undead8
    Apr 27, 2021 at 0:34
  • Here is the contract: bscscan.com/address/… Here is the change to the contract: bscscan.com/address/… As you can see, it appears to only be that one line of code involving a fallback and payable as shown in the screenshot. One person we spoke to feels it has something to do with transaction fees and is not malicious.
    – user71436
    Apr 27, 2021 at 1:25
  • The second contract (0x7dd) does not seem to have anything to do with the first one (0x83C). The token contract has fee on transfer (burns) and other feather like that. Are you sure that you are not seeing just tokens being burned what a transfer is made?
    – Undead8
    Apr 27, 2021 at 13:51
  • There is 8% of all transactions burned and sent to a wallet and wrapped into liquidity tokens yes. That has been happening. We were just wondering if the second contract made any changes to the first or what it does generally, if anything. It appears it doesn't even change the first.
    – user71436
    Apr 27, 2021 at 13:56

1 Answer 1


Assuming that the intent of the question is to explain the part of the decompiled code in the image (and not the rest of the contract):

The function you've posted is not malicious. A fallback function is called whenever ETH is sent to the contract (but not in the context of a function call) - you can read more about them here. By making a fallback function such as this one with revert inside, it means that if someone tries sending ETH to the contract, the tx will fail.

This is sometimes used to prevent ETH from getting "stuck" in a contract. If someone sends ETH to a contract that doesn't have a function for sending ETH, there's no way to get the funds out. In order to prevent loss of ETH, this fallback will cause any direct ETH transfer to fail.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.