2

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


2

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


2

Ran into this myself as well. Are you using ethers.js with Buidler? The safeTransferFrom method is overloaded and generally with ethers.js the bare definition is the default method used. If you run console.log( Object.keys(token) ) you'll see the methods on the token and you'll likely see two definitions of safeTransferFrom. Pick the one you want to use then ...


1

If a Developer would update his contract That's a bit vague, but let's assume you mean the developer is a single EOA which is the sole admin for upgrades the upgrades follow the proxy upgradable pattern, simply changing the implementation contract which calls are forwarded to via delegatecall. In this scenario, technically the balances cannot be deleted, ...


1

If you run npm uninstall @openzeppelin/contracts and then npm install @openzeppelin/contracts@2.3.0, then retry the import, then it should work. Also, check your truffle-config.js file and see if the root directory is configured properly to find your node_modules folder properly.


1

You can use one of the 2 following options: Via interface contract: ContractA.sol: pragma solidity ^0.5.11; contract A { uint256 public testVariable = 5; function getTestVariable() public view returns(uint256) { return testVariable; } } ContractB.sol: pragma solidity ^0.5.11; contract B { A a_contract_instance; ...


1

Yes, first of all you need to create a contract that can distribute token on certain conditions. Now you can actually deploy a erc20 contract and put the above contract address while minting. i.e constructor(uint256 initialSupply,contractAddress) public ERC20("SimpleToken", "SIM") { _mint(<contractAddress>, initialSupply); } ...


1

TL;DR: If you want to get your setup to work as it currently is, you will need to call the approve function of your deployed ERC20 contract from the msg.sender account displayed above, with the contract address of what you have deployed as the spender (you will also need to set the owner in the constructor), however, it would probably be better to mint the ...


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

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


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