Comments (21)
So it looks like it somehow retrieved incorrect constructor arguments. When I ran it on my end it retrieved this as the constructor arguments: 0x000000000000000000000000f2e47c29fc9f31cc50a62dea24956545772921bc
, which are completely different from the ones you got.
When running with the installed version v0.4.0, I did get an error because the flattened source code included multiple SPDX license identifiers. As a fix, I updated to the latest version v0.5.0 (which uses multi-file verification) and I was able to verify the contract.
I was able to run migrations and accurately verify those newly deployed contracts as well. I'm still not sure why it got different constructor args on your end than on my end, but I can't reproduce the issue. Could you try updating to v0.5.0 and running compile + migrate + verify again to see if it's working for you?
from truffle-plugin-verify.
Hey @mcplums! That does sound weird. Could you run the command again with the --debug
flag and post the details? Also, did you deploy your contract through a factory contract?
from truffle-plugin-verify.
I have tried to re-create this error and this time using the --debug flag, this time I'm getting 503 error which I assume is a problem at etherscan's end so I will try again later and report back. If I take too long to do so feel free to close 👍
I can confirm it was not a factory. I'm aware that etherscan cannot handle those just yet.
from truffle-plugin-verify.
Any news on this?
from truffle-plugin-verify.
Getting the same error. When i add --debug
Constructor parameters received: 0x697066735822122009eb274d752106666b7b763e3ba5a150b94b8bf7d130791f17324bb70e54903e64736f6c634300060c0033000000000000000000000000c1dcb653a21e3c0069fe494cbe1644206c641ff6
...other output
"constructorArguements": "697066735822122009eb274d752106666b7b763e3ba5a150b94b8bf7d130791f17324bb70e54903e64736f6c634300060c0033000000000000000000000000c1dcb653a21e3c0069fe494cbe1644206c641ff6"
The payload to etherscan API is missing the '0x' from the beginning
from truffle-plugin-verify.
Hey @dmolina79, thanks for chipping in!
That should be fine, Etherscan doesn't expect the 0x
prefix. So I assume there's something else going on. Do you have a repository I can look at to try to reproduce this?
from truffle-plugin-verify.
Hi @rkalis sure, i've created this repo as an example
https://github.com/dmolina79/yearn-truffle-verify
Trying to verify this contract in rinkeby using this command:
truffle run verify StrategyCreamCRV@0xF477479a6bf71F41b8935EFDd347D1794F18e6C1 --network infuraRinkeby --license GPL-3.0
These are the compiler settings which should be good:
Compiling contracts... Solc version: 0.6.12 Optimizer: Enabled Runs: 200 EVM Version: Istanbul
The plugin has worked great so far with other simpler contracts, but it bricks on this one with the constructor error for some reason. Lmk if you need anything else.
from truffle-plugin-verify.
Hi, I am getting the same issue @dmolina79. When running verify it gets my contructor parameters received as: 0x00000000005d3a536e4d6dbd6114cc1ead35777bab948e3643a26469706673582212203f6b1b16b84a192fc410f2b7252382703c506f806748d5f6b2299317b56927cc64736f6c634300060c00330000000000000000000000009b142c2cdab89941e9dcd0b6c1cf6dea378a8d7c
when they should be:
0x0000000000000000000000009B142C2CDAb89941E9dcd0B6C1cf6dEa378A8D7C
This is a different project to @dmolina79 but we are both built off the same baseStrategy.sol
Is there a way to declare contructor arguments manually?
from truffle-plugin-verify.
That is so odd that it works on my end. Could you guys share your Truffle versions as well?
from truffle-plugin-verify.
Truffle v5.1.50 (core: 5.1.50)
Solidity - 0.6.12 (solc-js)
Node v12.18.2
Web3.js v1.2.9
from truffle-plugin-verify.
So it looks like it somehow retrieved incorrect constructor arguments. When I ran it on my end it retrieved this as the constructor arguments:
0x000000000000000000000000f2e47c29fc9f31cc50a62dea24956545772921bc
, which are completely different from the ones you got.When running with the installed version v0.4.0, I did get an error because the flattened source code included multiple SPDX license identifiers. As a fix, I updated to the latest version v0.5.0 (which uses multi-file verification) and I was able to verify the contract.
I was able to run migrations and accurately verify those newly deployed contracts as well. I'm still not sure why it got different constructor args on your end than on my end, but I can't reproduce the issue. Could you try updating to v0.5.0 and running compile + migrate + verify again to see if it's working for you?
thanks a lot @rkalis updating the plugin to 0.5.0 did the trick, so it was not the abi constructor issue it was the mix licenses, but that worked in any case.
from truffle-plugin-verify.
I cloned @dmolina79 repo and added my contract, but still getting the same constructor error when trying to verify.
Here is the repo: https://github.com/Grandthrax/yearn-truffle-verify
And I am running command:
truffle run verify YearnDaiCompStratV2@0x5b62F24581Ea4bc6d6C5C101DD2Ae7233E422884 --network infuraMainnet
from truffle-plugin-verify.
I am using [email protected].
Error is: Invalid constructor arguments provided. Please verify that they are in ABI-encoded format
Constructor parameters retrieved: 0xcf6dea378a8d7c
so I am now getting different constructor parameters, but still the wrong ones...
from truffle-plugin-verify.
Strange. Do you have a link to your forked repo with your contract added?
from truffle-plugin-verify.
yes here: https://github.com/Grandthrax/yearn-truffle-verify
YearnDaiCompStratV2.sol in contracts/strategies
from truffle-plugin-verify.
So looking into it a bit more it seems that 'Invalid constructor arguments provided error' just happens when the transaction data is a different length to the artifact.bytecode.length. So probably something I am doing wrong rather than an error on your end
from truffle-plugin-verify.
So the way the plugin works is it gets the contract creation transaction. The input data of that transaction is the contract bytecode + the constructor args. By splitting the input data on the bytecode length, what should be left over is the constructor args. But if the bytecode doesn't match, then it's possible that the split is wrong.
So are you absolutely sure that the compile settings that you used locally are exactly the same as the ones you used when deploying? i.e.:
compilers: {
solc: {
version: "0.6.12",
settings: {
optimizer: {
enabled: true,
runs: 200
},
},
}
},
from truffle-plugin-verify.
I compiled and deployed using brownie rather than truffle. So have redeployed (0xd1da63f8ab9b8ce335f0f0e40f0e2a05c20c93bf) using truffle from the repo i linked to above. Now constructor parameters look right but verify is still failing.
One thing I did have to do was edit the json build file for truffle-plugin-verify to work. I was getting "Cannot find module '/D/Source/....l'" so changed all /D/ to D:/. Would that change the result of verify?
from truffle-plugin-verify.
Which fields did you have to change the paths for in the JSON file?
from truffle-plugin-verify.
Also could you push the migration code that you used to the library?
from truffle-plugin-verify.
Closing this issue for inactivity. Feel free to open it with more information.
from truffle-plugin-verify.
Related Issues (20)
- Proxy handling working well only for initial deployment, not for update case HOT 1
- Unable to verify since 0.8.16 HOT 2
- verifying smart contract fails when using viaIR is true in truffle config HOT 8
- Etherscan has no support for network arbitrum_goerli with chain id 421613 HOT 2
- Zcore 3331 HOT 1
- support for sepolia HOT 2
- Add support for Subscan based verification HOT 2
- TypeError: (intermediate value).hostname.split(...).at is not a function HOT 4
- Fail with TypeError: (intermediate value).hostname.split(...).at at Goerli HOT 1
- Couldn't verify Contracts on Etherscan using truffle-plugin-verify HOT 4
- I cannot verify an updateable contract on the poligon testnet. HOT 2
- KAVA verification HOT 3
- Fail - Unable to verify. HOT 10
- Verification fails when contracts import "truffle/console.sol", etc. HOT 1
- sourcify fails with 500 error code HOT 9
- Failed to connect to Etherscan API at url - tunneling socket could not be established, cause=socket hang up
- Cannot read properties of undefined (reading "address") during verification HOT 2
- Cannot read properties of undefined (reading "address") during verification HOT 8
- Cannot read properties of undefined (reading 'includes') on verification HOT 3
- celo testnet explorer is not correct HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from truffle-plugin-verify.