3

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!

goodvibration
  • 26,003
  • 5
  • 46
  • 86

1 Answers1

3

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.

n1cK
  • 3,378
  • 2
  • 12
  • 18
  • 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 https://etherscan.io/address/0x5248e5fd5d3b43126e5352807f75d6a7d6d7eafb#code doesn't show them? – goodvibration Jan 07 '19 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. – goodvibration Jan 07 '19 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 Jan 08 '19 at 07:48
  • Part 2: ... here https://etherscan.io/tx/0x57d48f4c1c5bb81f388271f82c972249438c2676e2eeea4c2e572f3ff8b35f7f 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 Jan 08 '19 at 07:50
  • Yes, I've already posted another question and got this answer, which led me to the same solution. Thank you! – goodvibration Jan 08 '19 at 08:18