I was so kind to verify the contract source for you.
This is a very common problem I also experienced. (It's extremely frustrating)
Compiler Version: 0.4.24
Contract-Code: Copy the Coin.sol file
Optimization: YES !!!!!!! (most likely you were missing that)
Here is the link of your verified contract: https://etherscan.io/...
Contract Source Code is published and publicably verifiable by anyone.
Immediately after deploying your Smart Contract, as we did for GreatestShow in the ComeOneComeAll project, you could go to Etherscan and view the contract at its deployed address. As you can see, the
Code tab showed a bunch of random looking hex digits starting with 0x60806… which is the ...
This question has other answers.
Your contract has ^ in the pragma, so no one can be sure what compiler was used. Its presence is a sign that the code hasn't received an appropriate critical review. An audit would likely flag that practice since it casts doubt about other possible problems. The compiler itself can be the source of trouble so there should ...
BlockScout.com supplies an ability to export transactions on the specific address to CSV.
Take a look, for instance, at the bottom of the page https://blockscout.com/eth/mainnet/address/0x2c2391f793f4f81475d87fffe366458ce5380a13/transactions. Download SCV button is there.
getsourcecode Etherscan API endpoint returns the name of a contract. You can find the description of the endpoint here: https://etherscan.io/apis#contracts
It returns `` in the resulting JSON:
I successfully verified your contract in Etherscan and Blockscout:
I think the problem was with the wrong constructor arguments provided. But since Etherscan made the possibility to ...
See my comment about why I don't think this is feasible.
As a general heuristic, let the currency be a currency - a simple unit of account, a medium of exchange and possibly a store of value. A dollar doesn't know why it moves but the machinery that accepts it usually does. Token contracts spell out the supply and look after basic accounting.
As I mentioned in comments to the other answer: in theory it is possible to add such functionality (by for example calling another function before the real transfer) but, in my opinion, in reality it's not feasible. Mostly because I doubt any third party wants to implement such extra features at their end. The point of standards is that they are standard and ...
Yes this is possible.
You have to modify the transfer function of your token contract.
Doing this would be a bit complicated. Keep in mind you need to pay attention to still comply with the EIP20 Standard.
I would go about this by creating a new function with the same parameters as transfer and you additional paramets, save your information and then call ...
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 ...
Can you ensure that version of the compiler you used to compile the deployed bytecode is the same that you use in Etherscan for verification?
If you use truffle, type truffle version and check the 'Solidity vX.X.X' output
By default all full nodes contain every single contract and transaction on the Ethereum network.
I don't know how you would filter only contracts though and there would also be far to many contracts to check them all.
Mabye you could make a system where a user would post about a smart contract instead of reviewing one.
You can do this by querying the blockchain directly instead of using your web scraper. For this, you would need to run a node and check each block's transactions to see if the associated addresses are contracts.
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.
I think what he meant is if there is a difference between the transaction creation time and transaction execution time or equivalently as you two put in your answers, block creation time. I did not find any information on if transaction creation time is logged. It's supposed to be a functionality of wallets, yet, they may not do the logging.
There's no way for you to get them back, tokens sent to that particular contract that you're referring to, are stuck there forever. The contract that you link to has no way to withdraw tokens mistakenly sent to it.
Perhaps your best chance is to reach out to the MWAT team and explain your situation, perhaps they can try to resolve it in someway.
On Ethereum, the all transactions in a block are processed at the same time and given the same timestamp. This is the same as the timestamp of the block that it is included.
In order to get the timestamp of a specific transaction, simply look up the timestamp of the block that that transaction is included in.
There is no way to cancel the transaction (even if you know the tx hash)
It is most likely pending for a long time, because of the low gas price.
It might take you a few days until your transaction gets through.
If you know your transaction's gas price is under 3 it takes a long time.
For current gas prices see here: https://www.ethgasstation.info/
You can't cancel a transaction if it's broadcast into the blockchain already. But exchanges may work in mysterious ways and it might not be even broadcast (yet). Having the tx hash wouldn't help you cancel it but would make sure that it's broadcast and therefore uncancellable.
The only thing you can do is contact the exchange.