New answers tagged

0

Found the problem... Tried to send money from a contract that hadn't got the amount of token. So it was a careless mistake...


0

Etherscan knows the transaction input begin with 0xa9059cbb (which is the signature of calling ERC20 transfer function). They also know the target address is an ERC20 token. So the assume the user wanted to make a token transfer. For an ERC20 token transfer to be successful it should generate an Transfer event (Transfer event have topic id ...


6

I was so kind to verify the contract source for you. This is a very common problem I also experienced. (It's extremely frustrating) Compiling: Single-File-Solidity 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/...


0

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 ...


1

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 ...


0

one account (account A) can be seen as an owner of a token so that they can use them in other services(e.g. using its right to receive dividends) This you can implement with the existing interface as is and perhaps with a new function to calculate dividend. other accounts (lets say secondary owners) can prevent A to transfer token to others on Dex or any ...


2

Simply put, the answer is no - there is no standard way to do this, as how tokens are created isn't defined in ERC20. Additionally, you can't easily find out the holders of tokens directly from the blockchain, as the way storage data is encoded means that, even if you're looking at the raw data, you'll only be seeing the hashes of the token holder's ...


1

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. A line-of-...


3

An ERC20 contract must exactly implement the specification described here: https://eips.ethereum.org/EIPS/eip-20. This makes the critical behavior predictable so it will be compatible with wallets and exchanges. A contract may implement additional behaviour provided it doesn't interfere with the minimum functionality. It's worth noting that exchanges and ...


1

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 ...


1

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 ...


0

I suggest you use the new up to date erc20 standard call erc777. The erc777 is new and improve version of erc20 and it is still compatible with old erc20 contract. It has a tokenReceived function which the contract must register its on erc1820. It almost the same as the fallback ethereum function, if the balance of the registered address increases, execute ...


2

You need to send the tokens at least once first. Otherwise this will not work. Etherscan only recognises a contract as an token after its first Transfer event. After sending the tokens once it should work perfectly!


4

Etherscan will recognize your contract once it will log its first Transfer event. This is how it works. Though, even before the first Transfer event was logged, you may view your contract in token tracker: https://rinkeby.etherscan.io/tokens?q=0x5238fFeAEdfc9481bd635B6E0e5eF3b05b19762a


0

I didn't see where web3.eth.getAccounts() is used in your code, but this is javascript promise and you might wanna use it this way to get the accounts: web3.eth.getAccounts(function(error, accounts) { if(error) { console.log(error); } else { console.log(accounts); } });


1

It does mean that an entity has found a way to mine as much, (or more) 0xbtc than some particular mining pools, however, it doesn't have to mean that the public address belongs to a particular individual, it could also be an unidentified mining pool of people which operates like the other already identified mining pools. In regards to the mining process, ...


2

When calling associatedToken.transfer(address(this), _ammount) the caller of this transaction is your contract, so it tries to transfer contract's 82 DAI to itself. To transfer DAI you should be the caller of the transaction with transfer() function call. You should upload DAI's code to Remix and use "At address" button and then call transfer() function at ...


2

Where did you get the 0x382117315856a533549ea621542ccce13e54ae82 address from? If you click BitBall token in your token list, you'll notice that it leads to https://etherscan.io/token/0x06e0feb0d74106c7ada8497754074d222ec6bcdf?a=0xb8fd65fc6919c5b97453eaba6b895144597985b2 So the real token address is 0x06e0feb0d74106c7ada8497754074d222ec6bcdf


3

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.


0

It seems to me that the answer above misses the fact that we are dealing with a decentralized system, in which all participants (miners, validators, delegates - depending on the consensus mechanism) are able and must decide which fork to follow in the future. A centrally made decision made by the emitting party of a certain token might work for the emitter ...


2

pragma solidity ^0.5.0; //import ERC20 functionality ... contract Example { ERC20 public token; //@param _token the address of the DAI smart contract constructor(ERC20 _token) public { token = ERC20(_token); } function () external payable {} ...


1

If it's an ERC20 compliant token, then you cannot freeze the holdings of another token holder.To be able to freeze the holdings of another token holder, then you would have to implement custom freezing/pausing functionality to the token before deploying to the main net.


0

you should create fake abi include some common func of erc21 [ { "constant": false, "inputs": [ { "name": "to", "type": "address" }, { "name": "tokenId", "type": "uint256" } ], "name": "approve", "outputs": [], "payable": false, "stateMutability": "nonpayable", "type": "function" }, ...


3

Just don't use BN. You need to convert ETH to WEI. This is a very simple proccess. Web3 has some buildt in functions for this: const val = 0.15; // this guy var weiAmount = web3.toWei(val);


Top 50 recent answers are included