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/...
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 ...
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.
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.
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.
You got the function selector right (0x2f0c92d3), but you failed to correctly ABI encode the address parameter. It should be left-padded with zeros so that it's 32 bytes wide. Try this instead:
As noted by Richard:
Roadmap says "2020 Q2 - Egretia Public Chain 1.0 Release". (egretia.io)
This means that its own blockchain will be launched then and its own coin released. This does not, however, say anything about when the token will be migrated into the new blockchain. But it's quite probable that the migration happens immediately when the new ...
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 ...
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 ...
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.