Could anyone shed some lights on the following contract?


I am quite confused about what's going on here. Why doesn't the "EVM bytecode" of the contract show up on etherscan.io? Or it is because it has been self destructed or something?

Any suggestion would be appreciated very much.

1 Answer 1


The source code is indeed missing as etherscan cannot link it easily.

If you switch to OPCODE View, you're going to find the following:

PUSH20 0x273930d21e01ee25e4c219b63259d214872220a2
PUSH2 0x235a

Judging by the time the contract was deployed and the code it's using ( CALLCODE ) we can determine that it's actually delegating it's storage and execution to another contract.


Now you have the actual ABI and source code that you can use to create calls against it.

These days instead of CALLCODE, we use DELEGATECALL for such cases.

Hope that helps.

  • Thank you Micky! That makes a lot of sense to me. Just one quick question, so instead of "fixing" the delegated code address, is it possible to make it dynamic? Commented Dec 30, 2018 at 15:36
  • So what I means is that, given this contract, since it dispatches its functionality to another contract, I would like to link with that contract and do some analysis. If the address of "that contract" is hard coded, then I guess it's feasible to link. Otherwise if it is dynamically determined, then I guess I will have no way to do that. Commented Dec 30, 2018 at 15:37
  • 1
    1 - For analysis and usage think about this contract, as a "proxy" that just delegates calls to the master contract. In essence you don't really need to know what the "master's address is" because the child knows and transfers calls internally. In this case it's hard coded due to the way it was created ( most likely a Library ). Commented Dec 30, 2018 at 15:47
  • 1
    2 - There are more advanced implementations, that implement call delegation manually that CAN have a dynamic "master", being that they store that in a variable, in which case you can determine when it changes. You should probably read up on DELEGATECALL and upgradeable smart contracts as well as blog.zeppelinos.org/proxy-patterns Commented Dec 30, 2018 at 15:51
  • 1
    @rick-park if you take a closer look at the etherscan page it does say "Contract ABI (Uses ABI Data From Contract 0x86018025a553d3e88b38dc5409e4b52edeb9ab83)", that suggests it either detected it somehow, or someone manually added the ABI on that contract at one point :). Since the "Write Contract" was added just a few months back, and it does not work here it stands to reason the contract's ABI interface was added quite a while back. Commented Dec 30, 2018 at 16:05

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.