16
The page "Verify Contract" ask for "Constructor Arguments ABI-encoded".
In your case the constructor has no parameters, so you can leave such field empty.
In the general case when your constrctor has parameters you can proceed as follow:
You can use ethereumjs-abi to encode/decode the parameters for transaction calls.
Let's suppose your constructor is ...
12
Currently etherscan does not support verification of multifile contracts. But there is discussion on etherscan's reddit about this issue.
Concatenating files into one worked some time ago, but since version 0.4.7 Solidity includes hash of contract's metadata at the end of compiled contract. As this metadata contains file names and hashes, you may get the ...
10
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 ...
6
I don't think so. If you could, then anyone could come along, copy the source code, and reverify it with completely different comments, which opens up for all types of attacks, including phishing. You could possibly contact Etherscan directly and they might let you replace the code if you can prove that you're the creator of the contract.
6
Guys I really hate my life. It took me over 10 hours to find the solution to this problem.
I compiled the contract with various different methods. Deployment worked with each of the but the contract couldn't be verified nontheless.
After a while I figured out that I didn't set the optimisation checkbox on etherscan to "yes".
I was compiling optimized all ...
5
There are a few different reasons for verifying your key.
To make sure you actually saved the private key and address correctly. e.g. You saved a private key but recorded the address 0x122... instead of 0x123... (note: you should avoid hand writing things anyways).
To make sure you have all the necessary information, including the password. e.g. You ...
5
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 ...
5
Disclaimer : I am not a cryptographer nor a mathematician nor a low level software engineer. Please correct me if any information provided below is incorrect.
Very short answer: Yes
Short answer: Possible, but very difficult today.
Longer answer: The main challenge with Ethereum is that since you have a programmable blockchain, you effectively need to ...
5
Etherscan is the most cut-and-dry, but there are at least a couple of other resources available:
SmartContract.Codes - a p2p search engine for smart contract source code.
ethPM - a decentralized package manager used to distribute EVM smart contracts and projects.
I'm a big fan of ethPM, but it can take a bit of time to understand. Here are a few more links ...
4
In case you want to use a simple online tool to encode parameters you may use https://abi.hashex.org
You can enter abi to automatically parse parameter types or just enter them manually. In Function type selector constructor should be picked.
Here is example of using this service, at the bottom are abi-encoded parameters that you enter in etherscan.io ...
4
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.
4
You need to correctly ABI-encode constructor arguments. You can easily do this with online tool https://abi.hashex.org. Just paste in abi to automatically parse constructor parameter types or add them manually.
4
It depends on how strongly you want to verify the identity:
If you want a person, who you already knew, to prove that they sent the transaction, it's easy: They can just attach a piece of data to the transaction containing their name, email address, date of birth and/or any other data you require. (preferably hashed, for anonimity)
If you want someone to ...
4
You need to correctly ABI-encode your constructor parameters. You can easily do this with online tool https://abi.hashex.org. Just paste in your abi to auto-parse constructor parameters or manually add them and enter values. ABI-encoded constructor parameters would be automatically calculated. Just copy them and paste in etherscan.io constructor parameters ...
4
I built a CLI that may help you, called multisol. You can install it via Homebrew if you're on Mac, or download one of the executables I provide if you're on Windows or Linux:
$ brew tap paulrberg/multisol
$ brew install multisol
Then you can use it like this:
$ multisol path/to/YourContract.sol
This will generate a folder named "multisol-yourcontract&...
3
I was able to successfully verify the contract code you linked in a new deployment.
Are you sure the parameters and source code you used were identical to those you used in the verification tool?
For reference, here is the verification of the new deployment of your contract.
EDIT:
It might be that you are having the same problem as I am having now. It ...
3
In case you want to use a simple online tool to encode parameters you could use https://abi.hashex.org
You insert the abi code to automatically parse parameters types or just enter them manually. In Function type selector constructor should be picked.
Here is an example, at the bottom are abi-encoded parameters that you enter in etherscan.io constructor ...
3
The compiler was timing out, and documentation online suggested that truffle optimizes the compilation -- nevertheless, I selected "no" for the optimized option, and didn't enter in the library addresses, to find it successfully compiling in under 30 seconds!
3
Let's see what happens here.
In solidity v0.5.11, the end of the bytecode includes the following :
0xa2
0x65
627a7a7231 => "bzzr1" in hex
0x58
0x20
<32 bytes swarm hash>
0x64
736f6c63 -> "solc" in hex
0x43
<3 byte version encoding>
0x00
0x32
That's exactly what you have.
In your two bytecodes ...
2
I was able to verify the contract on Etherscan by checking the "Input Data" of the transaction that created the contract. It includes the contract bytecode and the constructor argument bytecode right after. So you can copy the constructor argument bytecode into the "Constructor Arguments ABI-encoded" field to be able to verify the contract. Thanks for that ...
2
Sorted.
Had pasted contracts in wrong order
Removed import references
Pasted constructor argument bytecode from end of deployed TX
2
The contract you're looking at is a stub. If you look at the contract's code and select Switch to Opcodes View, you can see it references another contract at 0x273930d21e01ee25e4c219b63259d214872220a2 with source code and abi published.
2
Q1: I don't see an obvious way to do that without getting into a gas-expensive loopy process that won't scale. A web3 client would be better suited to searching for it in my opinion.
Q2: I would incline to this approach if it's necessary.
It looks like it should be bytes32 instead of string. According to this: http://solidity.readthedocs.io/en/develop/...
2
I've met same problem with contract verification at etherscan.io.
https://etherscan.io/verifyContract2 - helped in my case.
Thank you
2
Summary
Your comparison will never work.
The compiled code at 0x01861C6Dfab20bAe0FA4EE698912630697D78cE4 is way too small to represent the compiled wallet.sol source code.
Why do you think the contract code at the address 0x01861C6Dfab20bAe0FA4EE698912630697D78cE4 is the wallet.sol compiled code?
Details
Compiled Code At Address ...
2
You're generally describing a trust-verification system ("Can I trust that Alice is who she says she is?"). Public/private keys allow you to concretely prove a message came from a particular private key, but the question then becomes do you trust the private key to be truthful (about anything; shipping addresses, names, the weather, etc.). There are several "...
2
I created truffle-plugin-verify to automate Truffle contract verification on Etherscan.
Install the plugin with npm
npm install truffle-plugin-verify
Add the plugin to your truffle.js or truffle-config.js file
module.exports = {
/* ... rest of truffle-config */
plugins: [
'truffle-plugin-verify'
]
}
Generate an API Key on your Etherscan ...
2
This is probably what you're looking for,
https://ethereum.stackexchange.com/a/1173/19016
Each account has a globally accessible nonce which prevents double spends. The nonce is the sequence number, which miners check, because a block that has a transaction with an incorrect nonce is an invalid block (other miners won't build on top of it). (The nonce ...
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible