I know how to extract the constructor arguments out of the transaction object returned from a contract-deployment operation.

It is explain in web3.js official documentation here.

But this is not an issue of course, because if I am the one deploying the contract, then I obviously know the constructor arguments beforehand.

I am interested in retrieving the constructor arguments of an already deployed contract, i.e., the constructor arguments used during the deployment of that contract (by someone else).

I have the following at my disposal:

  • The address of the deployed contract
  • The byte-code of the deployed contract
  • The contract-deployment's transaction hash

Can any of the above help me retrieving the constructor arguments of an already deployed contract?

Thank you!

1 Answer 1


You can get them on Etherscan for any contract, see here for Example. It will take some research about RLP encoding to decode everything into readable text though.

  • Great, thank you. I actually started off my search at the exact link that you've specified. But for the contract address that I am using, I get a different response, which does not include the constructor arguments. Can you please explain why etherscan.io/address/… doesn't show them? Commented Jan 7, 2019 at 12:08
  • Oh, wait... I see this at the (pretty much) top of the page: Note: Displaying Similar Match Verified Source Code At Contract 0x5cb5F46a655C02889172323760d12d0e5D83CDAf(Excluding Constructor Arguments if any). When I click the link there, I do get to see constructor arguments. But as I understand it, those are not necessarily the same values used in the contract that I am interested in. Do I have to get this contract verified in order to view its constructor arguments? In the link that you provided, the contract doesn't seem to have been verified. Commented Jan 7, 2019 at 12:17
  • Part 1: afaik constructor params are always attached to the end of the bytecode and yes, one needs to know about their encoding (by having / verifying the code for example) to know where they start and where they end. In your example the code that was found to be similar seems to not provide enough info to etherscan to parse the constructor values - although it seems to ignore them on purpose: Both codes end with the same values, and...
    – n1cK
    Commented Jan 8, 2019 at 7:48
  • Part 2: ... here etherscan.io/tx/… in inputData you can seem to find the constructor values, right after "98f565b9056" which both contract codes end with. so actually, etherscan could (!) display the deployment parameter values in the displaying of the contract bytecode.
    – n1cK
    Commented Jan 8, 2019 at 7:50
  • Yes, I've already posted another question and got this answer, which led me to the same solution. Thank you! Commented Jan 8, 2019 at 8:18

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.