Truffle: Truffle deployed contracts can't be verified through Etherscan

[akravin]

• I've asked for help in the Truffle Gitter before filing this issue.
• Also I published a question on stackoverflow site https://stackoverflow.com/questions/44704420/truffle-deployed-contracts-cant-be-verified-through-etherscan

---

Issue

Truffle deployed contracts can't be verified through Etherscan (https://etherscan.io/verifyContract)

Steps to Reproduce

1) Init a new Truffle project:

$ mkdir test-contract
$ cd test-contract
$ truffle init

2) Create a simple Ownable contract (Ownable.sol) in "test-contract/contracts" folder:

pragma solidity ^0.4.11;

contract Ownable {
    address public owner;

    function Ownable() {
        owner = msg.sender;
    }

    modifier onlyOwner {
        if (msg.sender != owner) throw;
        _;
    }

    function transferOwnership(address newOwner) onlyOwner {
        if (newOwner != address(0)) {
            owner = newOwner;
        }
    }
}

3) Compile the Truffle project:

$ cd test_contract
$ truffle compile

4) See the bytecode generated by Truffle compiler in test-contract/build/Ownable.json file in "unlinked-bytecode" attribute.

5) (Optional). Deploy Ownable contract to Ethereum (TEST-NET)

$ cd test-contract
$ truffle migrate

-- Deploy only ownable and standard token
Running migration: 1_initial_migration.js
  Deploying Migrations...
  Migrations: 0x822432d53f6a8e5f2d4dad208fe1eecd33cf053d
Saving successful migration to network...
Saving artifacts...
Running migration: 2_deploy_contracts.js
  Deploying Ownable...
  Ownable: 0x6c8e1b321ce94b12069222b543558d4159527ecd
Saving successful migration to network...

Expected Behavior

The bytecode generated by Truffle must be the same as bytecode generated by Remix (online compiler) or solcjs (local compiler), i.e.:

6060604052341561000c57fe5b5b60008054600160a060020a03191633600160a060020a03161790555b5b610119806100396000396000f300606060405263ffffffff7c01000000000000000000000000000000000000000000000000000000006000350416638da5cb5b81146043578063f2fde38b14606c575bfe5b3415604a57fe5b60506087565b60408051600160a060020a039092168252519081900360200190f35b3415607357fe5b6085600160a060020a03600435166096565b005b600054600160a060020a031681565b60005433600160a060020a0390811691161460b15760006000fd5b600160a060020a0381161560e8576000805473ffffffffffffffffffffffffffffffffffffffff1916600160a060020a0383161790555b5b5b505600a165627a7a723058201eb1de901e30ec9818544272a4c70946cd9cb7cd848237ba3dca118e44d771a60029

Actual Results

The actual bytecode generated by Truffle compiler is different from the bytecodes generated by Remix (online compiler) or solcjs (local compiler):

0x6060604052341561000c57fe5b5b60008054600160a060020a03191633600160a060020a03161790555b5b60f3806100386000396000f300606060405263ffffffff60e060020a6000350416638da5cb5b8114602a578063f2fde38b146053575bfe5b3415603157fe5b6037606e565b60408051600160a060020a039092168252519081900360200190f35b3415605a57fe5b606c600160a060020a0360043516607d565b005b600054600160a060020a031681565b60005433600160a060020a0390811691161460985760006000fd5b600160a060020a0381161560c25760008054600160a060020a031916600160a060020a0383161790555b5b5b505600a165627a7a72305820607fc60d96cffbd50e58fbc028c1e4b6f3dfdf356bd439390481a479ef8d25500029

See https://ropsten.etherscan.io/address/0x6c8e1b321ce94b12069222b543558d4159527ecd

RESULT: The SolJS bytecode is identical to the Remix bytecode but different from the truffle bytecode.

Environment

• Operating System:

OS: Ubuntu 15.10
uname -a
Linux sasha 4.2.0-42-generic #49-Ubuntu SMP Tue Jun 28 21:26:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

• Truffle version:

Truffle v3.2.4

• Solidity compiler

0.4.11+commit.68ef5810.Emscripten.clang

• Ethereum client:

geth 1.6.1-stable-021c3c28

• node version:

nodejs v6.3.1

• npm version:

npm 4.6.1

[akravin]

There's a compiler optimization in solc/truffle-compile that in this moment etherscan does not support when compiling contracts.

https://github.com/trufflesuite/truffle-compile/blob/331809c73389f27f9dda40229061bb75b18f27ca/index.js#L70

[interfect]

This is a blocker for me. Nobody is going to trust my deployed contracts if they can't verify them. How can I turn this optimization off?

[interfect]

@mtbitcoin, can you expose the "runs" parameter when verifying contracts on Etherscan?

[mtbitcoin]

does browser solidity have a similiar option for the "runs" parameter?

[akravin]

@interfect, As workaround you can revert runs parameter to its default value 200 in truffle-compile/index.js file. Etherscan has been informed about this issue but I don't know how fast they'll add supporting the "runs" parameter

[elenadimitrova]

@akravin any reason you closed this without a solution being implemented? Rather than just relying on a workaround? This will be a blocker for us too in very near future.

[akravin]

@mtbitcoin, Remix online compiler doesn't have this parameter, but most developers use truffle to deploy their contracts. So the problem is urgent

[mtbitcoin]

@akravin If remix doesn't support this then how do you propose we (Etherscan) fix this problem? Can truffle be configured to be compile without the "run" parameter ?

[akravin]

@mtbitcoin I propose to add "runs" parameter on your verify page in order to eliminate problems with contract verification that were compiled another way rather than Remix or Mist. I think all compiler's options must be supported to verify contract's source code by Etherscan, because developers may change them anytime. In order to support "runs" parameter you may use solcjs and standard input json.
For example, standard input json may be wrote as below:

{
  "language": "Solidity",
  "sources": {
    "MyContract": {
      "content": "pragma solidity ^0.4.11; contract Ownable {address public owner; function Ownable() { owner = msg.sender; } modifier onlyOwner { if (msg.sender != owner) throw; _;} function transferOwnership(address newOwner) onlyOwner { if (newOwner != address(0)) { owner = newOwner; }}}"
    }
  },
  "settings": {
    "optimizer": {
      "enabled": true,
      "runs": 0
    },
    "outputSelection": {
      "*": {
        "MyContract": [
          "evm.bytecode.object"
        ]
      }
    }
  }
}

In this file replace "runs" parameter on user input. After that run solcjs as following:

$ solcjs --standard-json < input.json

Output of this command is output JSON (http://solidity.readthedocs.io/en/develop/using-the-compiler.html) which contains "evm.bytecode.object" tag. You just need to compare it with bytecode in the Ethereum transaction.

PS: Solidity compiler "solc" has separate option "--optimize-runs" for changing this value

[akravin]

@mtbitcoin As I know in truffle "runs" parameter is hardcoded and its default value equals 0 (zero)

[rstormsf]

no solutions on this?

[mtbitcoin]

@akravin Thanks for the info. Looking into this, but it will require a rewrite for our backend code handling the source code verification

Edit: Also "--standard-json < input.json" appears to work only with version 0.4.11 and above.

[mtbitcoin]

From what i understand, solcjs has a "runs" value of 200, so if you can truffle to also "runs" at "200" instead of "0" this will produce the same code (see https://stackoverflow.com/questions/44704420/truffle-deployed-contracts-cant-be-verified-through-etherscan)

[rstormsf]

@mtbitcoin How would you verify a contract that depends on 3rd party libraries like openZeppelin ?
Basically if I have a contract that has lots of nested inherited conracts?

[interfect]

Unfortunately, changing the "runs" value in Truffle won't help to verify
code that's already been deployed and is in use by others. But perhaps it
should be exposed as a per-project parameter in truffle.js, rather than
requiring users to edit the installed Truffle tool itself in order to set
it.

Verifying a contract with dependencies requires pasting all the imported
code into the verification text box, and deleting all the import
statements. It's awkward, but (if the compiler parameters are right) it
works.

On Fri, Jun 30, 2017 at 9:05 AM, Matt.Tan [e-mail] wrote:

From what i understand, solcjs has a "runs" value of 200, so if you can
truffle to also "runs" at "200" instead of "0" this will produce the same
code (see https://stackoverflow.com/questions/44704420/truffle-
deployed-contracts-cant-be-verified-through-etherscan)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/trufflesuite/truffle/issues/456#issuecomment-312307787,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAt5tv89Dh0z_4zqeymZJUnq1ZsbS9zZks5sJRzFgaJpZM4OCnr1
.

[akravin]

@mtbitcoin, I agree with @interfect. Our company have already several contracts deployed with "runs=0" and they can't be verified by Etherscan and I can't replace them too as they are already in production. We hope you provide the implementation of this feature asap because we are loosing potential customers every day. I have already wrote the bug report 22 jun to the support service, but at present time I had no information about plans of implementation. Is there a workaround in our case?

[mtbitcoin]

@akravin I am working on this. Please understand that we are a small team, providing a free service and are doing our best to accommodate the various requests and tickets we receive on a daily basis.

The new verifier will accept the runs parameter but only for contracts compiled with >= 0.4.11 (given all the know solidity compiler bugs, contracts should really only be compiled with the latest versions anyhow). If you can drop me your email or contact i will ping you once this is done you can be the first to test this.

[akravin]

@mtbitcoin, of course, I understand and I am very appreciate to hear that you are working on this issue. Here is my email: [email protected]. I'm looking forward to testing it. Thank you!

[yarrumretep]

Hi @mtbitcoin, could you please ping this thread once you have a fix for this deployed? I'd be happy to help test as well - just let me know.

[tcoulter]

I'm going to reopen this. We can easily expose solc optimization parameters in your Truffle config file.

For reference, this is the reason the optimizer has a runs value of zero in Truffle. https://github.com/ethereum/solidity/issues/2245

TL;DR: Anything larger than 0 produces larger bytecode. The default setting in Truffle is to produce the smallest bytecode possible.

[tcoulter]

I'm also open to changing the default optimizer setting back to 200.

[mtbitcoin]

@yarrumretep yup, will post here instead once its completed.

[mtbitcoin]

@yarrumretep @akravin The new verifier is available at https://etherscan.io/verifyContract2

This will only work with solc 0.4.11 and above. This new verifier provides additional information for debugging. Please let me know if this works

Under the optional settings section, there is place where you can enter a custom runs value. Older versions of truffle defaulted to 0. Browser solidity uses 200

[akravin]

@mtbitcoin, thanks for this feature. At last, I was able to verify my deployed contracts. Thank you again!

[yarrumretep]

@mtbitcoin - i'm currently running on kovan - the kovan.etherscan.io does not appear to have the verifyContract2 available yet. Happy to test there when it is.

[mtbitcoin]

@yarrumretep https://kovan.etherscan.io/verifyContract2

[interfect]

My contract is now verified too: https://etherscan.io/address/0xAB6CF87a50F17d7F5E1FEaf81B6fE9FfBe8EBF84#code

Thanks for adding this feature, @mtbitcoin!

[rstormsf]

Yes! Thank you so much @mtbitcoin

[tcoulter]

Thanks everyone for their input, and @mtbitcoin for adding support in etherscan -- we appreciate it. We're going to add support for custom compiler optimization settings, and will be setting the default back to 200. See #486 for more info. Closing this ticket for housekeeping.

[yarrumretep]

Hi @mtbitcoin - sorry for the delay in testing this - been traveling. Back at the screen now.

I am getting an "Opps - that's an error" page when I try to use the https://kovan.etherscan.io/verifyContract2

This seems to happen for Runs=0 and Runs=200. I'm using the 0.4.11 compiler.

[mtbitcoin]

@yarrumretep can you provide the contractaddress, sourcecode gist, optimization setting and I will see if I can replicate the issue

[yarrumretep]

@mtbitcoin - here are some repro data:

• https://gist.github.com/yarrumretep/cb3bcc0d59e734e68ed2834ba7fc5e31
• Address: 0xc84177ad471cf4f9cddeae58be71121af989916b
• Contract Name: TestToken
• Compiler: 0.4.11-commit.68ef5810
• Optimization: Enabled
• Runs: 0
• Constructor Args:
• no libraries

When I click Verify and Publish I immediately get the "Opps - that's an error" page.

NOTE: when I perform the same steps on the original .../verifyContract page, The compilation happens, with the expected message: "Sorry! The Compiled Contract ByteCode for 'TestToken' does NOT match the Contract Creation Code for [0xc84177ad471cf4f9cddeae58be71121af989916b]."

BTW - happy to take this offline if there's a better forum for this

[mtbitcoin]

@yarrumretep please give it another try

[yarrumretep]

Yeee haw! Now we're cookin' with gas. Thank you, @mtbitcoin

Say, Matt - do you guys have plans for validation of contract source by REST api?

[mtbitcoin]

Yes, but only when we have the time to look into that

[danastos]

So how do I change the Runs value in truffle? I am having the same issue where truffle and solidity browser are giving different bytecodes

[alonmuroch]

@mtbitcoin any updates? I just get different ABI code from truffle and Remix on the same exact solidity code... I've tried both running with/ without optimization and with 200 and 0 runs...

[murich]

Is there a tool to automatically concatenate the contract?

[mtbitcoin]

@murich https://github.com/BlockCatIO/solidity-flattener

[mtbitcoin]

it seems that with solc version 0.4.18 and above the Bytecodes dont get outputted anymore, anyone else running into a similar issues?

[schampilomatis]

I am having the same issue as @mtbitcoin, No outputed bytocode in etherscan verifyContract2.

[schampilomatis]

@mtbitcoin it works now, I managed to verify it with optimization disabled, runs 200 solc 0.4.18

[nickjuntilla]

Hi, I'm still having this issue as well. It seems the only difference is that etherscan is not actually adding the ABI-encoded characters to the end, or maybe I'm not seeing the other difference:

Constructor Arguments Used (ABI-encoded):
000000000000000000000000000000000000000000000000016345785d8a00000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000900000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000095961636874436f696e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055941434854000000000000000000000000000000000000000000000000000000

ByteCode on the Blockchain (what we are looking for):
0x606060405260408051908101604052600481527f48302e31000000000000000000000000000000000000000000000000000000006020820152600690805161004b9291602001906100e7565b50341561005757600080fd5b6040516109eb3803806109eb833981016040528080519190602001805182019190602001805191906020018051600160a060020a0333166000908152600160205260408120879055869055909101905060038380516100ba9291602001906100e7565b506004805460ff191660ff841617905560058180516100dd9291602001906100e7565b5050505050610182565b828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f1061012857805160ff1916838001178555610155565b82800160010185558215610155579182015b8281111561015557825182559160200191906001019061013a565b50610161929150610165565b5090565b61017f91905b80821115610161576000815560010161016b565b90565b61085a806101916000396000f300606060405236156100935763ffffffff60e060020a60003504166306fdde038114610098578063095ea7b31461012257806318160ddd1461015857806323b872dd1461017d578063313ce567146101a557806354fd4d50146101ce57806370a08231146101e157806395d89b4114610200578063a9059cbb14610213578063cae9ca5114610235578063dd62ed3e1461029a575b600080fd5b34156100a357600080fd5b6100ab6102bf565b60405160208082528190810183818151815260200191508051906020019080838360005b838110156100e75780820151838201526020016100cf565b50505050905090810190601f1680156101145780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561012d57600080fd5b610144600160a060020a036004351660243561035d565b604051901515815260200160405180910390f35b341561016357600080fd5b61016b6103c9565b60405190815260200160405180910390f35b341561018857600080fd5b610144600160a060020a03600435811690602435166044356103cf565b34156101b057600080fd5b6101b86104d5565b60405160ff909116815260200160405180910390f35b34156101d957600080fd5b6100ab6104de565b34156101ec57600080fd5b61016b600160a060020a0360043516610549565b341561020b57600080fd5b6100ab610564565b341561021e57600080fd5b610144600160a060020a03600435166024356105cf565b341561024057600080fd5b61014460048035600160a060020a03169060248035919060649060443590810190830135806020601f8201819004810201604051908101604052818152929190602084018383808284375094965061066395505050505050565b34156102a557600080fd5b61016b600160a060020a0360043581169060243516610803565b60038054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156103555780601f1061032a57610100808354040283529160200191610355565b820191906000526020600020905b81548152906001019060200180831161033857829003601f168201915b505050505081565b600160a060020a03338116600081815260026020908152604080832094871680845294909152808220859055909291907f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b9259085905190815260200160405180910390a350600192915050565b60005481565b600160a060020a0380841660008181526002602090815260408083203390951683529381528382205492825260019052918220548390108015906104135750828110155b151561041e57600080fd5b600160a060020a038085166000908152600160205260408082208054870190559187168152208054849003905560001981101561048357600160a060020a03808616600090815260026020908152604080832033909416835292905220805484900390555b83600160a060020a031685600160a060020a03167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef8560405190815260200160405180910390a3506001949350505050565b60045460ff1681565b60068054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156103555780601f1061032a57610100808354040283529160200191610355565b600160a060020a031660009081526001602052604090205490565b60058054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156103555780601f1061032a57610100808354040283529160200191610355565b600160a060020a033316600090815260016020526040812054829010156105f557600080fd5b600160a060020a033381166000818152600160205260408082208054879003905592861680825290839020805486019055917fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef9085905190815260200160405180910390a350600192915050565b600160a060020a03338116600081815260026020908152604080832094881680845294909152808220869055909291907f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b9259086905190815260200160405180910390a383600160a060020a03166040517f72656365697665417070726f76616c28616464726573732c75696e743235362c81527f616464726573732c6279746573290000000000000000000000000000000000006020820152602e01604051809103902060e060020a9004338530866040518563ffffffff1660e060020a0281526004018085600160a060020a0316600160a060020a0316815260200184815260200183600160a060020a0316600160a060020a03168152602001828051906020019080838360005b838110156107a457808201518382015260200161078c565b50505050905090810190601f1680156107d15780820380516001836020036101000a031916815260200191505b5094505050505060006040518083038160008761646e5a03f19250505015156107f957600080fd5b5060019392505050565b600160a060020a039182166000908152600260209081526040808320939094168252919091522054905600a165627a7a72305820cbe829b967aed0a7e0ddf4e7a57298b85e71199109215507ede1a3dc57856f850029000000000000000000000000000000000000000000000000016345785d8a00000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000900000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000095961636874436f696e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055941434854000000000000000000000000000000000000000000000000000000

Your Compiled Bytecode + Constructor Argument if any (what you provided):
0x606060405260408051908101604052600481527f48302e31000000000000000000000000000000000000000000000000000000006020820152600690805161004b9291602001906100e7565b50341561005757600080fd5b6040516109ed3803806109ed833981016040528080519190602001805182019190602001805191906020018051600160a060020a0333166000908152600160205260408120879055869055909101905060038380516100ba9291602001906100e7565b506004805460ff191660ff841617905560058180516100dd9291602001906100e7565b5050505050610182565b828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f1061012857805160ff1916838001178555610155565b82800160010185558215610155579182015b8281111561015557825182559160200191906001019061013a565b50610161929150610165565b5090565b61017f91905b80821115610161576000815560010161016b565b90565b61085c806101916000396000f3006060604052600436106100955763ffffffff60e060020a60003504166306fdde03811461009a578063095ea7b31461012457806318160ddd1461015a57806323b872dd1461017f578063313ce567146101a757806354fd4d50146101d057806370a08231146101e357806395d89b4114610202578063a9059cbb14610215578063cae9ca5114610237578063dd62ed3e1461029c575b600080fd5b34156100a557600080fd5b6100ad6102c1565b60405160208082528190810183818151815260200191508051906020019080838360005b838110156100e95780820151838201526020016100d1565b50505050905090810190601f1680156101165780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561012f57600080fd5b610146600160a060020a036004351660243561035f565b604051901515815260200160405180910390f35b341561016557600080fd5b61016d6103cb565b60405190815260200160405180910390f35b341561018a57600080fd5b610146600160a060020a03600435811690602435166044356103d1565b34156101b257600080fd5b6101ba6104d7565b60405160ff909116815260200160405180910390f35b34156101db57600080fd5b6100ad6104e0565b34156101ee57600080fd5b61016d600160a060020a036004351661054b565b341561020d57600080fd5b6100ad610566565b341561022057600080fd5b610146600160a060020a03600435166024356105d1565b341561024257600080fd5b61014660048035600160a060020a03169060248035919060649060443590810190830135806020601f8201819004810201604051908101604052818152929190602084018383808284375094965061066595505050505050565b34156102a757600080fd5b61016d600160a060020a0360043581169060243516610805565b60038054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156103575780601f1061032c57610100808354040283529160200191610357565b820191906000526020600020905b81548152906001019060200180831161033a57829003601f168201915b505050505081565b600160a060020a03338116600081815260026020908152604080832094871680845294909152808220859055909291907f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b9259085905190815260200160405180910390a350600192915050565b60005481565b600160a060020a0380841660008181526002602090815260408083203390951683529381528382205492825260019052918220548390108015906104155750828110155b151561042057600080fd5b600160a060020a038085166000908152600160205260408082208054870190559187168152208054849003905560001981101561048557600160a060020a03808616600090815260026020908152604080832033909416835292905220805484900390555b83600160a060020a031685600160a060020a03167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef8560405190815260200160405180910390a3506001949350505050565b60045460ff1681565b60068054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156103575780601f1061032c57610100808354040283529160200191610357565b600160a060020a031660009081526001602052604090205490565b60058054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156103575780601f1061032c57610100808354040283529160200191610357565b600160a060020a033316600090815260016020526040812054829010156105f757600080fd5b600160a060020a033381166000818152600160205260408082208054879003905592861680825290839020805486019055917fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef9085905190815260200160405180910390a350600192915050565b600160a060020a03338116600081815260026020908152604080832094881680845294909152808220869055909291907f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b9259086905190815260200160405180910390a383600160a060020a03166040517f72656365697665417070726f76616c28616464726573732c75696e743235362c81527f616464726573732c6279746573290000000000000000000000000000000000006020820152602e01604051809103902060e060020a9004338530866040518563ffffffff1660e060020a0281526004018085600160a060020a0316600160a060020a0316815260200184815260200183600160a060020a0316600160a060020a03168152602001828051906020019080838360005b838110156107a657808201518382015260200161078e565b50505050905090810190601f1680156107d35780820380516001836020036101000a031916815260200191505b5094505050505060006040518083038160008761646e5a03f19250505015156107fb57600080fd5b5060019392505050565b600160a060020a039182166000908152600260209081526040808320939094168252919091522054905600a165627a7a72305820768f61cbce7e55f532b6b3237027565cdd86adcd32793187295afd3f7a02a4770029

And it still fails. Shouldn't etherscan be adding the abi encoding I provided to the end?

[schampilomatis]

@nickjuntilla I had the same but the problem was that the settings were not correct, try with optimization disabled, runs 200. I found this setting in /build/cli.bundled.js . Search for "runs:" and you'll see it. Maybe there is a better way to find it but that's what worked for me.

[nickjuntilla]

@schampilomatis I don't have a cli.bundled.js. I'm using truffle 3.4.11. In the build folder all I have are the contract abi .json files. Is there somewhere else this can be? I've tried optimization disabled, enabled, and runs of 200 and 0 and every combination thereof. I've stopped short of trying every optimization level between 1 and 200. I already have contracts out that people are using and now I want to verify them on etherscan. I still have the source code and I've tried concatenating and using both version of the etherscan verify tool as many compilation versions.

I have some questions for anyone:

Does leaving in the comments or white space change any byte code?

Does changing the solidity code version in the file change the byte code?

If I concatenate files do I still have to add the reference files that were deployed via truffle as libraries?

Thanks anyone!

[schampilomatis]

@nickjuntilla https://github.com/nickjuntilla I meant the truffle
installation folder (usually /usr/lib/node_modules) not your project
folder. Type which truffle to see which one you are using. If you get
/usr/bin/truffle , the cli.bundled.js will be in
/usr/lib/node_modules/truffle/build.

Does leaving in the comments or white space change any byte code?
No it doesn't

Does changing the solidity code version in the file change the byte code?

Not sure, but probably not. It refers to the solidity version used, not the
compiler version.

If I concatenate files do I still have to add the reference files that were
deployed via truffle as libraries?
Yes, also you should add the addresses in the libraries section, but
etherscan will ask for it

On Sat, Dec 2, 2017 at 10:29 PM, Nicholas Juntilla <[email protected]

wrote:

@schampilomatis https://github.com/schampilomatis I don't have a
cli.bundled.js. I'm using truffle 3.4.11. In the build folder all I have
are the contract abi .json files. Is there somewhere else this can be? I've
tried optimization disabled, enabled, and runs of 200 and 0 and every
combination thereof. I've stopped short of trying every optimization level
between 1 and 200. I already have contracts out that people are using and
now I want to verify them on etherscan. I still have the source code and
I've tried concatenating and using both version of the etherscan verify
tool as many compilation versions.

I have some questions for anyone:

Does leaving in the comments or white space change any byte code?

Does changing the solidity code version in the file change the byte code?

If I concatenate files do I still have to add the reference files that
were deployed via truffle as libraries?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/trufflesuite/truffle/issues/456#issuecomment-348721511,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGmbfg-4pGY9AmNEACovaBY21KILgHofks5s8cFCgaJpZM4OCnr1
.

[nickjuntilla]

@schampilomatis Thanks for helping! So I found my cli.bundled.js it was in /usr/local/lib/ntruffle/build/cli.bundled.js and my runs are 200, but it's still not working. I'm not getting an error about the missing libraries. It just says the code doesn't match. I don't have the original addresses of where the classes were deployed anymore. Is there a way to find out? You can see here is the contract I'm trying to verify:

https://etherscan.io/verifyContract2?a=0x52f7018bc6ba4d24abfbaefccae4617bfb0a0b52

And here is the source code:

pragma solidity ^0.4.18;

contract Token {
    /* This is a slight change to the ERC20 base standard.
    function totalSupply() constant returns (uint256 supply);
    is replaced with:
    uint256 public totalSupply;
    This automatically creates a getter function for the totalSupply.
    This is moved to the base contract since public getter functions are not
    currently recognised as an implementation of the matching abstract
    function by the compiler.
    */
    /// total amount of tokens
    uint256 public totalSupply;

    /// @param _owner The address from which the balance will be retrieved
    /// @return The balance
    function balanceOf(address _owner) public constant returns (uint256 balance);

    /// @notice send `_value` token to `_to` from `msg.sender`
    /// @param _to The address of the recipient
    /// @param _value The amount of token to be transferred
    /// @return Whether the transfer was successful or not
    function transfer(address _to, uint256 _value) public returns (bool success);

    /// @notice send `_value` token to `_to` from `_from` on the condition it is approved by `_from`
    /// @param _from The address of the sender
    /// @param _to The address of the recipient
    /// @param _value The amount of token to be transferred
    /// @return Whether the transfer was successful or not
    function transferFrom(address _from, address _to, uint256 _value) public returns (bool success);

    /// @notice `msg.sender` approves `_spender` to spend `_value` tokens
    /// @param _spender The address of the account able to transfer the tokens
    /// @param _value The amount of tokens to be approved for transfer
    /// @return Whether the approval was successful or not
    function approve(address _spender, uint256 _value) public returns (bool success);

    /// @param _owner The address of the account owning tokens
    /// @param _spender The address of the account able to transfer the tokens
    /// @return Amount of remaining tokens allowed to spent
    function allowance(address _owner, address _spender) public constant returns (uint256 remaining);

    event Transfer(address indexed _from, address indexed _to, uint256 _value);
    event Approval(address indexed _owner, address indexed _spender, uint256 _value);
}

contract StandardToken is Token {

    uint256 constant MAX_UINT256 = 2**256 - 1;

    function transfer(address _to, uint256 _value) public returns (bool success) {
        //Default assumes totalSupply can't be over max (2^256 - 1).
        //If your token leaves out totalSupply and can issue more tokens as time goes on, you need to check if it doesn't wrap.
        //Replace the if with this one instead.
        //require(balances[msg.sender] >= _value && balances[_to] + _value > balances[_to]);
        require(balances[msg.sender] >= _value);
        balances[msg.sender] -= _value;
        balances[_to] += _value;
        Transfer(msg.sender, _to, _value);
        return true;
    }

    function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) {
        //same as above. Replace this line with the following if you want to protect against wrapping uints.
        //require(balances[_from] >= _value && allowed[_from][msg.sender] >= _value && balances[_to] + _value > balances[_to]);
        uint256 allowance = allowed[_from][msg.sender];
        require(balances[_from] >= _value && allowance >= _value);
        balances[_to] += _value;
        balances[_from] -= _value;
        if (allowance < MAX_UINT256) {
            allowed[_from][msg.sender] -= _value;
        }
        Transfer(_from, _to, _value);
        return true;
    }

    function balanceOf(address _owner) constant public returns (uint256 balance) {
        return balances[_owner];
    }

    function approve(address _spender, uint256 _value) public returns (bool success) {
        allowed[msg.sender][_spender] = _value;
        Approval(msg.sender, _spender, _value);
        return true;
    }

    function allowance(address _owner, address _spender) public constant returns (uint256 remaining) {
      return allowed[_owner][_spender];
    }

    mapping (address => uint256) balances;
    mapping (address => mapping (address => uint256)) allowed;
}

contract HumanStandardToken is StandardToken {

    /* Public variables of the token */

    /*
    NOTE:
    The following variables are OPTIONAL vanities. One does not have to include them.
    They allow one to customise the token contract & in no way influences the core functionality.
    Some wallets/interfaces might not even bother to look at this information.
    */
    string public name;                   //fancy name: eg Simon Bucks
    uint8 public decimals;                //How many decimals to show. ie. There could 1000 base units with 3 decimals. Meaning 0.980 SBX = 980 base units. It's like comparing 1 wei to 1 ether.
    string public symbol;                 //An identifier: eg SBX
    string public version = 'H0.1';       //human 0.1 standard. Just an arbitrary versioning scheme.

     function HumanStandardToken(
        uint256 _initialAmount,
        string _tokenName,
        uint8 _decimalUnits,
        string _tokenSymbol
        ) public {
        balances[msg.sender] = _initialAmount;               // Give the creator all initial tokens
        totalSupply = _initialAmount;                        // Update total supply
        name = _tokenName;                                   // Set the name for display purposes
        decimals = _decimalUnits;                            // Amount of decimals for display purposes
        symbol = _tokenSymbol;                               // Set the symbol for display purposes
    }

    /* Approves and then calls the receiving contract */
    function approveAndCall(address _spender, uint256 _value, bytes _extraData) public returns (bool success) {
        allowed[msg.sender][_spender] = _value;
        Approval(msg.sender, _spender, _value);

        //call the receiveApproval function on the contract you want to be notified. This crafts the function signature manually so one doesn't have to include a contract in here just for this.
        //receiveApproval(address _from, uint256 _value, address _tokenContract, bytes _extraData)
        //it is assumed when one does this that the call *should* succeed, otherwise one would use vanilla approve instead.
        require(_spender.call(bytes4(bytes32(keccak256("receiveApproval(address,uint256,address,bytes)"))), msg.sender, _value, this, _extraData));
        return true;
    }
}

And here is the ABI encoded params:

000000000000000000000000000000000000000000000000016345785d8a00000000000000000000000000000000000000000000000000000000000000000080000000000000000000000000000000000000000000000000000000000000000900000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000095961636874436f696e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000055941434854000000000000000000000000000000000000000000000000000000

I'm not sure the addresses fro StandardToken and Token so I just have to guess for them and the errors I get are that they are not used never that anything is missing. I'm not sure why I would have to concatenate them and link them as well either that seems strange?

[nickjuntilla]

Note: I finally got it. I just started trying all the compilers and v0.4.17+commit.bdeb9e52 worked. Optimizations Enabled and Runs: 200. I think maybe v0.4.17 is what truffle: 3.4.11 uses.

So even though the scripts were tagged with ^0.4.8 they ended up being compiled with v0.4.17 which I guess is understandable if it was the latest one available, but for this verification process it doesn't help to use the latest one. We need to start using exact versions and keep track of them.

Also note I didn't need to link the libraries included in my concatenation, which makes sense since they are there in the body. I reviewed my contract history and I didn't even see them deployed as separate contracts ever. There are migration contracts where a setComplete function was called. Maybe those are the base tokens?

Incidentally it's the same source code for this one and I can't get it to register with the same settings: https://etherscan.io/verifyContract2?a=0xd6e49800decb64c0e195f791348c1e87a5864fd7

Abi encoding

If anyone can verify 0xd6e49800decb64c0e195f791348c1e87a5864fd7 I'll send you some eth.

[nickjuntilla]

@mtbitcoin Is there any way to make this compatible with v0.4.8? solcjs in truffle is still 0.4.8 so even new code cannot be verified.

[nickjuntilla]

So I got a version of my second contract to verify by changing all the dependent classes 0.4.18 and re-deploying, but unfortunately that means all the contracts I have that have pragma 0.4.8 like everything based on consensys code.

[nickjuntilla]

Thanks, guys @schampilomatis got it the last contract: 0.4.11 optimization enabled and 0 runs.

[medvedev1088]

@nickjuntilla

Does leaving in the comments or white space change any byte code?
No it doesn't

Do you know if changing comments will change the hash of the source code file -> it will change the metadata file http://solidity.readthedocs.io/en/develop/metadata.html -> it will change metadata file hash -> it will change the swarm hash appended to the bytecode by Solidity compiler.

Will the contract still verify after that?

[mtbitcoin]

The changed swarm hash should not affect the contract source code verification on our end (Etherscan) in (most cases)