The Stack Overflow podcast is back! Listen to an interview with our new CEO.
9

It is not possible as on 24th March 2018. Etherscan is unable to locate contract code on the address of subcontract. Here is the transaction which deploys two contracts. But for the second contract, etherscan is unable to find contract code. The second contract does exist and this was verified by using "at address" feature of remix. Until there are some ...


5

I deployed the contract on the Kovan test net. Deployment versions same as you. Everything worked properly. I see no reason for it not to work on Ropsten. How did you deploy the contract? Maybe share the address to I can try to verify it.


5

This was already answered in the comments to your own previous question To summarize: The transaction that created the contract is visible on Etherscan (example here) The input data to that transaction, which is mostly the compiled bytecode of the contract itself, also contains the constructor parameter values in the last bytes (32 bytes per parameter) ...


4

You can use assert (over require) to indicate your intention to source code analyzers such as oyente. While require is good to validate input, it can sometimes be false because the user did something innappropriate. assert, on the other hand, is meant to indicate something that should never be false under any circumstances. Knowing this, a source code ...


3

Yes, you can use this tool: https://abi.hashex.org. It can automatically parse constructor parameters from ABI or you can add them manually. After you enter parameter values, ABI-encoded parameters string would be automatically generated, so you just copy and paste it in etherscan.io constructor parameters input.


3

In order to deploy contract on MyEtherWallet, you need the bytecode. The bytecode contains the solidity pragma version in the metadata which is converted into the object parameter in the bytecode you get itself. It will compile using whatever is set as the pragma. As for verification. You will need to know what pragma was set in the solidity code itself. ...


3

I was able to verify my contract with optimization turned on, when compiling from remix: https://ethereum.github.io/browser-solidity/ For some reason, it produces a different bytecode from Parity, even if you select the same compiler version and the same optimization setting.


2

I have deployed a contract from another contract: https://etherscan.io/tx/0x8fd885ce7ad7b6a591d9614d41cbb1d97aa7d2e290f6aa52531ce3d4c799a5ff which deployed: https://etherscan.io/address/0xb1400278014f34c8243b15613a4b463b51fb6f2a#code and I was able to verify contract using the same compiler version and optimization. You have to encode all constructor ...


2

You were trying to verify the "Migrations" contract that you used in your truffle configuration. You incrementer contract was the next contract you created, and can be found here: https://ropsten.etherscan.io/address/0x8705c513da621a16fd1defc9de8ae7cdead01fb8#code I verified it for you, using the Optimizer but setting it to 0 optimizations. You were using ...


2

Per https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20-token-standard.md#transfer: The function SHOULD throw if the _from account balance does not have enough tokens to spend. So I'd say you should indeed use require, but don't include the _amount > 0 clause. From the same documentation: Note Transfers of 0 values MUST be treated as normal ...


2

I don't think your question is unclear (someone flagged it) but it's pretty far off from the way Ethereum works conceptually. Let's start with the big one. Everything in Ethereum is deterministic, meaning it is possible to verify correctness. In fact, it must be possible for every node to verify every computation now, and in the future. Consider this ...


2

The semantics of Solidity change with every update, and the only canonical definition is the compiler itself. Note that there is a distinction between the intended behavior of the compiler and the actual behavior, which sometimes leads to compiler bugs. Maybe then it is more accurate to say that the (informal) definition of the solidity semantics is in the ...


2

There's a link on the right-hand side (in "Profile Summary") labeled "Contract". Click that, and then, assuming there's verified code available, you should see a tab for the contract's code. (You should end up at https://etherscan.io/address/0xa74476443119A942dE498590Fe1f2454d7D4aC0d#code.)


2

It looks like you just deployed this contract recently. I would suggest upgrading your compiler to the latest (0.5.10 at the time of this post) or at least the latest 0.4.x compiler and redeploying. Not only will you be able to verify your contract code on Etherscan, but you won't be subjected to all the compiler bugs that existed in those old versions.


2

It depends on what you mean by "safe". You can confidently derive the source code of this contract by the source code of the deployer. It will normally happen from a statement in the form of new Contract(arguments) and analysis of the deployer contract will leave no doubt about what it does. It does not mean that the quality of the contract or the intent ...


1

As mentioned here: https://www.reddit.com/r/etherscan/comments/bcbojh/problem_in_contract_verification_through_api/ekwxfnr?utm_source=share&utm_medium=web2x It was under some maintenance.


1

Since I'm extremely lazy, I usually let Etherscan tell me. If you click Verify and Publish, it'll bring you to the "you messed up" page. If you look at the "ByteCode (what we are looking for)" and search for "{bzzr}", which denotes where the swarm hash is. Everything after the "{bzzr}" is the constructor parameters. Just copy that stuff, go back to the ...


1

Contracts cannot access someone else information on their own. They can call other contracts to acces information but only when someone else instructed them to do so. For example a smart contract cannot move ERC20 tokens that belong to someone else, but if the owner has approved them they can move them. Is the responsability of the contract holding the ...


1

It depends what you mean by manual testing. You could paste the contract into Remix for superficial testing. http://remix.ethereum.org. That would help you discover that the deposit() function doesn't accept deposits. It might not help you discover that the contract contains an anti-pattern and a re-entrance vulnerability because a state-change takes place ...


1

Solidity code is compiled into EVM bytecode. All compiled code can, at least in theory, be reverse-engineered. Reverse-engineering any compiled code gives us the basic functionality in a very unreadable format (it's optimized, minimized and whatnot). Some more info can be found here: How can you decompile a smart contract? Having spent a minute googling ...


1

I created truffle-plugin-verify to automate Truffle contract verification on Etherscan. This has made the process much easier. I explain the usage of this plugin in my article Automatically verify Truffle smart contracts on Etherscan.


1

It's done. You were most of the way there with your ABI-encoded constructor arguments. It was necessary to copy the complete source from your verified factory to get it to compile, then pick out the StillBank contract. It would have to be the same compiler version that made the factory, leaving only the optimization to guess at. Hope it helps.


1

How i can do that ? Generate flat sol file from your two source files, for example, with solidity-flattener. Insert content of this flat file to "Enter the Solidity Contract Code below" field Choose the version of compiler you used in Remix Choose optimized flag true/false depending on what was this flag switched or not in Remix Copy contract name from the ...


1

This is coming late, but to whoever it will help: https://adibas03.github.io/online-ethereum-abi-encoder-decoder/#/ Disclaimer: This is a tool I designed almost 2 years ago


1

Miners want to win future blocks. If they don't independently verify that the chain they are following is the right one, they may end up spending future money doing proof of work on an incorrect chain. As soon as they see the winning block hash from some other miner, they confirm it, add the new block to their own chain, and hurriedly start trying to win ...


1

An easy way to find the constructor arguments is: Browse to your contract on Etherscan and click on the tx hash for its creation On the top right, where it reads "Tools & utilities", click on the arrow to see more options and select "Parity Trace" For the action pertaining the contract creation, click on "Show more" below to see the input/output On the ...


1

At the end of this document, https://etherscanio.freshdesk.com/support/solutions/articles/16000053599-contract-verification-constructor-arguments, you will find how to get your constructor argument: Another quick and dirty way of figuring out what your constructor arguments are is to compare both the browser solidity / remix compiled byte code and compare ...


1

For Library verification to work you have to use version 2.0 of Verify Contract Code (currently in Beta) i.e. make sure the verification URL starts with https://etherscan.io/verifyContract2?a=


1

If you want to punish the naughty users who supply bad arguments to your functions, you should use up all their gas :-)


1

try to verified contract with Optimization Disabled with out add ABI code


Only top voted, non community-wiki answers of a minimum length are eligible