0

I've already deployed many smart contracts to Ropsten testnet and successfully verified them in Etherscan, but today I encountered one contract which doesn't get verified through all my attempts. This is a simplified version of a bigger contract the code of which I was trying to verify.

  • Smart contract with the similar code and optimization enabled was successfully verified.
  • Smart contract with the below code and same compiler setting does not get verified on Etherscan for some reason.
  • Etherscan's Verify Contract Code (version 2.0) doesn't help either.
  • I've tried to deploy the contract both with Truffle and Remix IDE, with optimization enabled (runs = 200) using compiler version v0.4.23+commit.124ca40d.
  • I've provided expanded description on the issue in this GitHub gist.

I appreciate any help or hints regarding this issue. Big thank you.

Code which doesn't get verified in Etherscan:

pragma solidity 0.4.23;

contract TEST {

    string public someVal;
    string public someVal2;

    bytes32 public signature1 = keccak256(
        "address TEST TEST TEST TEST",
        "address TEST TEST TEST TEST TEST TEST",
        "address TEST TEST TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST",
        "bytes TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST"
    );
    bytes32 public signature2 = keccak256(
        "address TEST TEST TEST TEST",
        "address TEST TEST TEST TEST TEST TEST",
        "address TEST TEST TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST",
        "bytes TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST"
    );
    bytes32 public signature3 = keccak256(
        "address TEST TEST TEST TEST",
        "address TEST TEST TEST TEST TEST TEST",
        "address TEST TEST TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST",
        "bytes TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST TEST TEST TEST TEST",
        "uint256 TEST TEST TEST TEST"
    );

    constructor (string val, string val2) public {
        someVal = val;
        someVal2 = val2;
    }

}
1

I was able to verify the contract at 0x746612a6d4dcadbff55619bedeba403c0c252361 (from the gist you linked to) using the source code from the gist and the following ABI-encoded constructor parameters:

0000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000044475636b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044455434b00000000000000000000000000000000000000000000000000000000

I used v2 of the verification tool with the compiler you mentioned and 200 runs of the optimizer.

I think the tool guessed at the constructor parameters incorrectly. I'm not sure how it tries to determine the constructor parameters, but it suggested these parameters. The beginning of that is part of the actual bytecode for the contract.

75696e743235362054455354205445535420544553542054455354205445535461646472657373205445535420544553542054455354205445535400000000006279746573205445535420544553542054455354205445535400000000000000205445535420544553542054455354205445535420544553542054455354205461646472657373205445535420544553542054455354205445535420544553540000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000044475636b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044455434b00000000000000000000000000000000000000000000000000000000

The correct ABI-encoded parameters I used can be understood as follows:

  • 0x...40 (32 bytes) - specifies that data for the first string begins at offset 64.
  • 0x...80 (32 bytes) - specifies that data for the second string begins at offset 128.
  • 0x...04 (32 bytes) - specifies the length of the first string ("Duck")
  • 0x4475636b... (32 bytes) - UTF-8 representation of "Duck"
  • 0x...04 (32 bytes) - specifies the length of the second string ("DUCK")
  • 0x4455434b... (32 bytes) - UTF-8 representation of "DUCK"
  • Amazing, thank you very much! I've tried a couple of combinations of constructor parameters during my tests, but I didn't realize I need the first 64 bytes of data while trying. I think this can be a good note for Etherscan developers to fix the suggestion mechanism in constructor parameters. – ZitRo May 4 '18 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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