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

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) ...


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.


4

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.


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

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.


3

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 ...


3

Those are predeployment suggestions to reduce ambiguity at this step. The issue is there no way to be certain how the bytecode was generated because the pragma allows flexibility. If possible, examine the tools you used to compile, e.g. solc, Remix or truffle-config.js to work out the compiler version that must have been used. If you cannot do that, then ...


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

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 ...


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

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

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 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 ...


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

The blockchain is an internally consistent data structure. It is deterministic so that all nodes can verify the transitions. It cannot see the apples. That is an external reality. Generally, this is sometimes called the onboarding problem - how to get information from the real-world into the blockchain. It is a common design challenge. in the simplest ...


2

The transaction will be included in the blockchain the moment it is included in a block (at least from the miner's perspective), so it doesn't need to "wait" for other nodes to verify it first. If the miner is dishonest and the transaction result is not calculated correctly the block will be ignored by others. Miners can choose which transactions ...


2

Short answer is: you have to create the API key at etherscan.io either for the mainnet and the rest of public testnets (Ropsten, Rinkeby, Goerli..). (Bonus) In addition, I had some issues when trying to verify a contract with interfaces located in subdirectories. Perhaps it is not your case, but if you are using Truffle to manage the contracts deployment, ...


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

The answer by Daniel Hume is wrong. Some constructors require more than 32 bytes for storage. Here is a constructor that requires 8*32 bytes: https://etherscan.io/address/0x317dc3f08f7947f363dfc7cb008048a5a5ea1840#code So the question is still open.


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

We can see the application of a number of interesting formal verification tools and frameworks on Ethereum lately. In the event of rising attack vectors against the smart contract security model of Ethereum, formal verification has become a strong imperative. Initial efforts were based on Coq proof assistant. Nowadays we can see the adoption of K-framework ...


1

Verifying source code not worked for me when I tried to flatten source code to single file and upload it to etherscan.io. I think thats because pragma experimental ABIEncoderV2; in multi-file project is applied to only to some files but when you flatten files to single it applied to the whole source code. Solved this issue by deploying binary got by ...


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

mining : The ethereum main net uses, untill now, the Proof of work as a mechanism of getting the blocks(transactions inside) agreed upon and added to the blockchain. The proof of work requires the nodes in the network to do some work in order to prove their "will to be part of the network". working and succeeding in completing the task is rewarded by ...


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.


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