I am writing to understand a smart contract which seems quite "meaningless" to me.

The contract is at (https://etherscan.io/address/0xd4fa166d5ffe8f78230fc05e6850881dc08b2da2#code) but indeed over 1k addresses have exactly the same piece of code deployed.

So from the de-compilation results (https://ethervm.io/decompile?address=0xd4fa166d5ffe8f78230fc05e6850881dc08b2da2&network=), I don't see too much has been done here. It seems that this contract somehow sends out something, and then that's it. No information is kept track of in the storage anyhow.

Could anyone shed some lights on this (such kind of) contracts and let me know what's going on here? Thanks a lot.

  • Do you have any actual code that you can post here? Commented Dec 26, 2018 at 9:55
  • @goodvibration I don't. That is an online smart contract and all I can do is to use some decompiler to decompile, and then try to comprehend... Commented Dec 26, 2018 at 10:00

3 Answers 3


I'm not very fluent with reading the decompiled code but I can theorize a bit.

I was looking at some of the similar contracts and only found one which has other transactions: https://etherscan.io/address/0xd8681c956d3a4c50fa491c4ede2bd9e0b8d29db0 . Yes, it forwards funds sent to the contract to an EOA address.

As the contract looks like a really simple one, my best guess is that this is an exercise of some sort. Maybe an online example of "how to write a simple smart contract" or something similar. The oldest transactions are over 1000 days old - I guess back then there were no testnets and Ether was super cheap so you could just practice on the mainnet.

  • Thank you Lauri. The funny thing is that according to some bug detector, this contract is considered to have "re-entrancy" bugs, although this is quite in-obvious to me how is that even possible. Commented Dec 27, 2018 at 13:02

This contract is a simple forwarder. The recipient address is stored in the first contract's slot (storage[0]). The Ether sent to the input contract is immediately transferred to the target address.

On a successful transfer, a Deposit(target,amount) event is also recorded.

As seen by JEB Decompiler (interestingly, it does reconstruct the Deposit event):

contract DecompiledContract {
    function start() {
        *0x40 = 0x60;
        var0 = msg.data.length;
        recipient = storage[0x0];
        var5 = call(0x0, address(recipient), $msg.value, 0x60, 0x0, 0x60, 0x0);

        if(var5 != 0x0) {
            ptr = storage[0x0];
            uint256* var4 = ptr;
            ptr = *0x40;
            *ptr = (uint256)(address(((int)var4)));
            *(ptr + 1) = $msg.value;  // E1FFFCC4923D04B559F4D29A8BFC6CDA04EB5B0D3C460751C2402C5C5CC9109C:Deposit(address,uint256)
            emit Deposit(*0x40, ((uint256)(((int)ptr) - *0x40)) + 0x40);
  • Thank you Alex. Yes, that makes a lot of sense to me. I also decompiled with the JEB decompiler and it looks good. Indeed I am posting this question because some bug detectors (like the Oyenete) marked this contract as suffering from the "re-entrancy" issue, although this is quite in-obvious to me how is that even possible. I don't think there is any reentrancy issue. May I ask your opinion on that? Thank you. Commented Dec 30, 2018 at 9:49

Smart contract is a account controlled by code.

We can identify four main parts in Contract account

  1. Field - Description

  2. balance - Amount of ether this owns

  3. storage - Data storage for this contract

  4. code Raw machine code for this contract

Your Answer

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

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