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


2

The problem is that eth.sign returns a signature where v is 0 or 1 and ecrecover expect it to be 27 or 28. A note in the documentation for web3 v0.20 is clear: Note that if you are using ecrecover, v will be either "00" or "01". As a result, in order to use this value, you will have to parse it to an integer and then add 27. This will result in ...


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!


1

Your contract that inherits from ERC20Capped can either set the cap in your constructor or can pass on a constructor parameter. ERC20Mintable doesn't have any constructor parameters. Example token with the cap specified in the constructor: pragma solidity ^0.5.0; import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v2.3.0/contracts/token/...


1

They are still internal functions of the ERC-20 contract, see docs. So you can simply create a new contract that inherits from that one and add the mint function: pragma solidity ^0.6.10; import "@openzeppelin/contracts/access/Ownable.sol"; import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; contract MintableToken is Ownable, ERC20 {...


1

One feature of the extension that you are using is that it enables Solium (now Ethlint). This is a linter that checks your code for errors and warnings, such as no-trailing-whitespace: Line contains trailing whitespace. The best solution is to fix these warnings in your code, since the warnings are suggestions to follow best practices when writing Solidity. ...


1

Your deployment seems to be incorrect. The contract you deployed has only an empty fallback function that reverts: https://kovan.etherscan.io/bytecode-decompiler?a=0x87B62aAcEc6d304c26d4514ccD9Cb4F6Bc3bc114. My guess is that in Remix you clicked on ERC20 (or some other incorrect contract) instead of ERC20FixedSupply. pragma solidity 0.6.9; import "https://...


1

Cryptokitties was deployed on 2017-11-28, which is a few months before the ERC721 spec got its first commit and only two months after the ERC721 spec even got drafted. Because of this, Cryokitties had to implement ERC721 prior to the spec being complete, which is why they may not include certain, expected functionality. With that said, Cryptokitties helped ...


1

In your example, there is no restriction on who can mint tokens, so tokens are unlikely to have significant value as anyone can mint additional tokens (unless there is value in having low token IDs). Assuming you already have this deployed, you could look at doing a migration to a V2, where the ability to mint is restricted. This would mean creating a new ...


1

Answer from the OpenZeppelin Community Forum: https://forum.openzeppelin.com/t/proxy-that-routes-to-multiple-logic-contracts-based-on-param/2595/2 Is there a reason that you can’t use OpenZeppelin upgradeable contracts and just have a single logic contract? See Upgrading Smart Contracts Learn guide. I would suggest looking at this first to see if it meets ...


1

In contract DemoContract is ERC20,ERC20Detailed,ERC20Burnable,ERC20Mintable, ERC20Pausable: Each one of contracts ERC20Detailed, ERC20Burnable, ERC20Mintable and ERC20Pausable already inherits from contract ERC20, so you should not inherit from this contract as well. For example, compiling the following code gives the same error as yours: pragma solidity ...


1

As you are using OpenZeppelin contracts you should be quite safe from various exploits - unless you have such in your own code which utilizes OpenZeppelin. OpenZeppelin is well known, widely used and battle-tested. As for your questions: 1) The code is secure as you are just using OpenZeppelin's functionality and not doing anything strange/fancy yourself. ...


1

Rob, I see that you have already resolved (which is great). For future readers: For OpenZeppelin Contracts you can check the documentation for more information, in this case the Cryptography section: https://docs.openzeppelin.com/contracts/2.x/utilities#cryptography The tests for the contracts can be helpful to look at, in this case ECDSA.test.js: https://...


Only top voted, non community-wiki answers of a minimum length are eligible