I am a newbie in Solidity and Ethereum smart contract deployment. I have been trying to deploy some contract on Ethereum Testnet - Ropsten. I have successfully deployed and published
But, I received the error "Unable to Verify Contract source code." when trying to publish the following source code for this contract: https://ropsten.etherscan.io/address/0x811f7cf0f9534f54c4a56c383bbaed73dc88f609#code
I didn't know where did I do wrong.
pragma solidity ^0.4.0;
contract Test3 {
uint storageData;
function set(uint x) public {
storageData = x;
}
}
Any help would be appreciated.
Ok so I don't have enough reputation to comment otherwise I would have but there are very few things that could go wrong here so Ill just go over what you need to do. And you can chat with me on discord or something if you have any other questions. First I assumed you deployed with remix. So go to the settings tab and make sure that on etherscan you selected the same version that is displayed there, otherwise it will not work and then if the optimization box is not checked which is the third checkbox down then select no on etherscan otherwise again it wont work. then you just copy the exact source code into the box and type in the name of the contract and that is it.
Related
Our Dapp will have an NFT Auction functionality, which we are trying to automate 100% using chainlink. The auction winner will get the NFT and the Previous owner will get the highest Bid, Platform will get a small cut as well.
To do that, we are using CHainlink Keeper/Automation. I've set the checkUpKeep & performUpKeep, both are working fine when I'm doing everything manually. But when I am registering an upKeep for automaton.
When I input the deployed contract's address into the register upkeep box, it says Unable to verify if this is an Automation compatible contract. Why this warning?
How do I make the contract Automation compatible contract?
checkUpKeep is working good:
If I pass this performData into performUpKeep everything will work fine.
Code/Contracts: https://mumbai.polygonscan.com/address/0x7e2DA19C130cb3B483FA7f17C45c70716ABF5Fe8
Chainlink upKeep: https://automation.chain.link/mumbai/21891159634677518530356555981285976030474691922841692133624884405593696766700
Pls help, Thanks.
Unable to verify if this is an Automation compatible contract usually stems from a contract that is not verified on the block explorer. The contract you linked is verified and if you create an automation with it everything is good
Your checkUpKeep function does return true when supplied with the input you show(checkData). However, you have the checkData set to 0x in your automation.
With that input, it returns false.
You will need to change the checkData to match your screenshot.
so I encountered a weird issue with deploying bytecodes via a deployer contract. On 1 of 5 deployed contracts via the same compilation round & deployment flow I ended having a different deployedBytecode (but same bytecode) as with my original truffle compiled source. Therefore I can't get it verified. The issue seems that the address of the deployer contract is part of the deployedBytecode (while on my local file it is the null address). The issue is also only for 1 contract, while all 5 contracts share the same code (especially around the deployer address mentioned inside the contract.
So here i.e. is the deployer contract (+ verified source code):
https://polygonscan.com/address/0xd54716865c58d11e7c39c3cf634d9e919c0c6cce#code
I deployed my contract (SignerVaultV1.sol) via that tx:
https://polygonscan.com/tx/0x4d6e3a002b448e675ba6a2374737d4eaf0e18b163a57a66c09109ba332c8c5e3
The bytecode of it is exactly the same as on my local file, but if the deployedBytecodes are compared, 3 changes can be seen: Diff between online vs offline deployedBytecode (I can't post pics yet^^)
The difference in it is the address of the deployer contract (d54716865c58d11e7c39c3cf634d9e919c0c6cce). But like I said, the deployerContract delivered multiple contracts, all are correct, only this one is having that issue and I cant figure it out why.
I personally would like to get that contract verified without having to redeploy it (and maybe rund into the same issue...) I tried already to alter the source code to match the online deployedBytecode, but it seems also a harsh idea :D
Well after testing different ways, I dont honestly why, but sending a verification request via hardhat got it working... I couldn't manually verify or via truffle, but hardhat seems to know the magic for the last contract :)
I'm working on a uni project based on blockchain, and I have to audit our system, check known attacks, ect.
This the the document that I check, principaly, since i start to work on smart contracts issues first :
Known-attack ethereum smart contract
I have trouble understanding the example used in the "Dos With (unexpected) revert attack" part. I share the code :
// INSECURE
contract Auction {
address currentLeader;
uint highestBid;
function bid() payable {
require(msg.value > highestBid);
require(currentLeader.send(highestBid)); // Refund the old leader, if it fails then revert
currentLeader = msg.sender;
highestBid = msg.value;
}}
They say that an attacker could force the call of bid to revert everytime so no-one is able to bid, which would make the attacker win the auction by default.
But.. How would he do that, that's the part I don't get. Do we agree that at least this piece of contract is the "valid one", and isn't a payload ? If the payload is a contract, can anyone provide an exemple/explanation ?
I'll add that, if here I quote a solidity contract, we work with Vyper, but from what I read before, this is still a kind of issue that i'll find there too.
Thanks in advance !
If send() target address is a smart contract it will execute the fallback function.
If the currentLeader points to a smart contract that has a fallback function that has been intentionally made to revert on failed send, the bid() won't work for any participants until currentLeader has been changed.
More information here.
This is not a "DoS" attack but simply gotcha in Solidity programming.
I am trying to implement this Airdrop: https://github.com/odemio/airdropper/blob/master/Airdropper.sol
Initially, I started writing tests for our use-case, but the airdrop was not working.
function airdrop(address source, address[] dests, uint[] values) public onlyOwner {
// This simple validation will catch most mistakes without consuming
// too much gas.
require(dests.length == values.length);
for (uint256 i = 0; i < dests.length; i++) {
require(token.transferFrom(source, dests[i], values[i].mul(multiplier)));
}
}
Then I moved to Remix to goe through the whole airdrop process, including our Contract deployment, token minting and allowance.
In Remix debugger I found out that the issue is on the line
require(token.transferFrom(source, dests[i], values[i].mul(multiplier)));
I also tested the transferFrom function directly on our contract using the same values on Remix.
The error I get when trying to airdrop is:
transact to Airdrop.airdrop errored: VM error: revert.
revert The transaction has been reverted to the initial state.
Note: The constructor should be payable if you send value. Debug the transaction to get more information.
What could cause this issue and how can I debug this further? :)
Thanks and have a nice day!
The error could be for several reasons:
source doesn’t have enough tokens to cover all of the transfers.
One or more destination addresses are invalid.
The approve wasn’t done correctly (it’s the airdrop contract that needs to be approved, not the initiator of the transaction).
You can narrow it down by removing the require and see if any drops are successful (the way you have it coded, one failure will roll back the entire transaction).
I'm trying to deploy the following contract on Ropsten using an injected web3 environment (i.e. metamask) on remix.ethereum.org/
pragma solidity ^0.4.16;
contract Coin {
// The keyword "public" makes those variables
// readable from outside.
address public minter;
mapping (address => uint) public balances;
// Events allow light clients to react on
// changes efficiently.
event Sent(address from, address to, uint amount);
// This is the constructor whose code is
// run only when the contract is created.
function Coin() public {
minter = msg.sender;
}
}
I've been able to create contracts with ease using remix before. I'm not sure what has changed, but I can't create contracts at all because of the gas limit thing. I've even gone as far as setting the gas limit to 2 full Ethers (i.e. value 1 ether with max of 2). I have close to 3 ethers in my metamask wallet. The remix "Account" dropdown also displays my metamask address correctly so it seems that the injected environment is connected.
When I try to create this contract I can't get past the gas required exceeds limit 2 error. I'm scratching my head as to why this simple contract would exceed the cost of 2 full Ethers.
Other parameters for remix in use:
optimize=false&version=soljson-v0.4.20+commit.3155dd80.js
Is there a setting on remix that I've forgotten? I'm Trying to deploy this from Chrome.
edit: I'm still scratching my head on this one. I was able to create the contract above for a brief moment after refreshing my page, but I came in today to try and run the code from https://www.ethereum.org/token and I can't get past the exceeds gas error with a value of 20 Gwei and a limit of 3000000. Note, I tried using the simple sample contract above and I'm back to where I was when I started - even the simple "Coin" contract above apparently exceeds the gas limit.
edit 2: Well, I think I'm getting somewhere. I've changed the compiler version from "soljson-v0.4.20+commit.3155dd80.js" to "soljson-v0.4.19+commit.c4cbbb05.js". Then I refresh the page 3 times. After that I wait a couple of minutes and things seem to be working again. There is something else happening here because when I reject the transaction in metamask and then return to remix to create again, I encounter the gas exceeded error. I don't believe the issue here is metamask as I've tried to connect locally using testrpc - localhost:8545 - and experience the same issue. All I can say is that the same code that I try to create fails to submit because of the gas error most of the time but occasionally works regardless of compiler version.