3

This sounds like a perfect use case for the now finalized ERC-1155 token standard, which allows one to manage any number of fungible and non fungible tokens in a single contract.


2

Okay i understand know the reason why the tutorial code work and your code doesn't work is because of this is because in new solidity the CrowdSale is actually: constructor (uint256 rate, address payable wallet, IERC20 token) public { require(rate > 0); require(wallet != address(0)); require(address(token) != address(0)); _rate = rate; ...


2

Because Solidity only supports integer numbers, there's no natural way to represent a value like "half a token" (0.5 tokens). To work around this, ERC20 tokens use a multiplier. For US dollars, you might use a multiplier of 100, or 10^2, for 2 decimal places. In code, you'd store the number of pennies rather than the number of dollars. So $1 becomes 100 ...


1

constructor ( uint256 rate, address payable wallet, address tokenContractAddress ) public Crowdsale(1000000000, wallet, IERC20(tokenContractAddress)) {} The type IERC20 cannot be created externally, and only basic types can be used if you invoke the constructor. So instead you have to pass the address ...


1

As you said view and pure function can't modify state so in order to update contributions you have to write another function. Quoting comments Crowdsale.sol of _preValidatePurchase @dev Validation of an incoming purchase. Use require statements to revert state when conditions are not met. * Use super in contracts that inherit from Crowdsale to ...


1

By having a quick look at the function () external payable it seems it doesn't implement restrictions on how much Ether can be sent (except for preICO). The implementation of buyTokens is not given so it's difficult to say if there are some restrictions there. In general there are two types of hard caps: based on token amount and based on Ether amount. A ...


1

If you deploying contract from Remix IDE you should select SampleCrowdsale in Run Tab.


1

You could use a few different approaches. If you want to keep the Open Zeppelin contract pristine, you could consider deploying one for each unique token. That process, could itself be managed with a contract factory pattern. The factory would be concerned with configuring the crowdsale instances and keeping track of them. Another approach would be to ...


1

Go to https://www.unixtimestamp.com/ as mentioned by @MathematicalRain to see the Timestamp converter. Enter the time and date you want then click convert it to change it to Unix Time Stamp (in seconds). go to Remix and put the seconds there.


1

Internal transactions are not visible via Web3 API and they leave no trace in blocks. Proper way for internal transaction to make some information visible is to emit an event like this: contract Foo { } contract Bar { event FooCreation (Foo indexed foo); function createFoo () public returns (Foo) { Foo foo = new Foo (); emit FooCreation (foo);...


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