4
The solidity compiler does some "magic" when you include multiple files and do contract inheritance as is done in the ERC721 token contract. Ultimately it flattens the contract files into a single file and treats the inheritance and overridden functions in a deterministic way:
https://solidity.readthedocs.io/en/v0.4.21/contracts.html#inheritance
All ...
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
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.
3
Potential areas to look at which could be causing your problem when using the default emission Crowdsale:
Set an appropriate rate
Need to transfer (enough) tokens to the Crowdsale
For information on the rate: https://docs.openzeppelin.org/v2.3.0/crowdsales#crowdsale-rate
Understanding the rate of a crowdsale is super important, and mistakes here are a ...
3
In case of truffle the stored values will not remain in the upgraded contract whereas in proxy approach it is possible to obtain the stored values in the upgraded contract too.
In truffle upgrade a new version of contract is being deployed to the network and we will be obtaining a new contract address. If try to console the contract address in migrations ...
3
Smart contracts are immutable (code cannot be changed) by design.
Truffle and ZeppelinOS are platforms for the development of smart contracts for Ethereum based blockchains.
Truffle migrate manages the deployment of contracts to blockchain(s). Each time you migrate a contract you deploy a new instance to a new public address. To use the new smart ...
2
Current version of open-zeppelin (2.0.0) relies on solc version 0.4.24.
Current version of truffle (5.0.0) relies on solc version 0.5.0.
Between solc 0.4.x and solc 0.5.x there are breaking changes.
Previous version of truffle (4.1.14) relies on solc version 0.4.24.
So in order to use open-zeppelin in conjunction with truffle, set in your package.json ...
2
As of Solidity 0.5.X, contract types do not include the address members. Per the documentation:
Contract types do not include address members anymore in order to
separate the namespaces. Therefore, it is now necessary to explicitly
convert values of contract type to addresses before using an address
member. Example: if c is a contract, change c....
2
...how to properly price an ICO
Use a mechanism that allows for price discovery during the ICO itself. This is in contrast both to the case of setting a static price during the ICO, and the case of the markets deciding the price after the ICO, and once the token is being openly traded.
Such crowdsales are, however, more complex to run. (I can't immediately ...
2
As you can see the function
function _getTokenAmount(uint256 _weiAmount) internal view returns (uint256) {
return _weiAmount.mul(rate);
}
It states that for 1 wei, the no of tokens will be 1*rate.
for example, I want to sell 1 token at cost of 1 ether then what
should i pass here ?
This depends on number of decimals in your toke contract. For ...
answered Jun 21 '18 at 17:10
Prashant Prabhakar Singh
5,9933 gold badges24 silver badges50 bronze badges
2
contract ERC20 is IERC20
Interpret that this way:
ERC20 is an implementation of the Interface defined in IERC20.
IERC20 defines function signatures without specifying behavior; the function names, inputs and outputs, but no process. ERC20 inherits this Interface and is required to implement all the functions described or else the contract will not deploy....
answered Oct 21 '18 at 17:50
Rob Hitchens - B9lab
36.2k7 gold badges53 silver badges91 bronze badges
2
Option 1 seems like the simplest option, but Ethereum has "precompiles" (hardcoded smart contract like keccak256 etc.) at some of those low-numbered addresses. If you want to avoid those, you could pick a bigger address. If you just want the tokens inaccessible, it doesn't matter what address you pick, as long as no one has the private key. But if you want ...
2
solc can't get things over a network - it can only import local files, which was your initial error.
I'm assuming your npm install step is still leading to failure because the compiler is still looking in the wrong place. (I'd assume the OpenZeppelin stuff has gone into the node_modules folder.)
Take a look at how to manually map in localised - i.e. ...
2
ERC721Token inherits from ERC721BasicToken.
When a new token is minted, _mint is called from ERC721Token, which then calls super._mint which is the _mint implementation from ERC721BasicToken.
super._mint calls addTokenTo from the top level implementation (ERC721Token).
addTokenTo does additional logic to update the ownedTokens array in addition to calling ...
2
ERC20Capped inherits from ERC20Mintable, which inherits from ERC20.
So if you inherit from ERC20Capped, then you don't need to inherit from ERC20.
Therefore (though without verifying it via compilation), I'm pretty sure that you can do:
contract SimpleToken is ERC20Detailed, ERC20Capped {
uint8 public constant DECIMALS = 18;
constructor (uint256 ...
2
Suggest you look at the OpenZeppelin v1.12 test for RefundableCrowdsale for how to test that refunds are denied.
RefundableCrowdsale.test.js
it('should deny refunds before end', async function () {
await expectThrow(this.crowdsale.claimRefund({ from: investor }), EVMRevert);
await increaseTimeTo(this.openingTime);
await expectThrow(this....
2
Figured it out.
Check the comments here relating to _mint() https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC20/ERC20.sol
and also here: https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226
Starting with OpenZeppelin v2 this pattern is not only discouraged, but disallowed. The variables ...
2
The reason you are getting that error is because num is of type uint8, and the sub() function of SafeMath is looking for type uint256. Additionally you declare using SafeMath for uint;, which confirms that it only works with uint256 (as uint is an alias for uint256).
There are two ways to fix it:
1) Make num a uint256 type. Your code would look as follows:
...
2
takeOwnership was in a draft of the ERC721 standard
function takeOwnership(uint256 _tokenId)
Assigns the ownership of the NFT with ID _tokenId to msg.sender if and only if msg.sender currently has approval (via a previous call to approveTransfer). A successful transfer MUST fire the Transfer event (defined below).
takeOwnership is not in the final ...
2
Ensure you have installed openzeppelin-solidity in your project
npm install openzeppelin-solidity
Your imports are then as follows:
pragma solidity ^0.5.0;
import "openzeppelin-solidity/contracts/token/ERC20/ERC20.sol";
import "openzeppelin-solidity/contracts/token/ERC20/ERC20Detailed.sol";
contract DemirelToken is ERC20, ERC20Detailed {
constructor(...
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!
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 ...
1
Yes. It's about compatibility.
With a fixed-supply token, the deployer gets the supply initially and then can send an allowance to a crowdsale contract which will then sell them from inventory.
With a minted token, the sale contract calls the tokens mint() function with each sale to create the needed tokens on-the-fly.
If you mix up incompatible types, ...
1
I forgot to answer my own question, so if there are people still confused here is the answer:
1) open https://remix.ethereum.org
2) create a file token.sol
3) select compiler matching your token.sol (in my case 0.4.23)
4) paste original code to the window
5) press compile
6) Go To “RUN”
7) Select token.sol
8) list of Functions will appear, past values ...
1
I got this to compile with solidity 0.4.18;
pragma solidity ^0.4.17;
import "https://raw.githubusercontent.com/OpenZeppelin/openzeppelin-solidity/v1.6.0/contracts/token/ERC20/StandardToken.sol";
contract MyToken is StandardToken {
string public name = "MyTok";
string public symbol = "MTK";
uint8 public decimals = 2;
uint public ...
1
For future reference, this was unfortunately just a typo. I hope you found this quickly.
It is RefundableCrowdsale not RefundableCrowdSale
For information on using OpenZeppelin Crowdsales, please see the documentation:
https://docs.openzeppelin.org/v2.3.0/crowdsales
If you have any questions on using OpenZeppelin you can always ask in the community forum
1
If I'm not mistaken, the issue is token.transfer.selector is trying to work out the signature from the source code.
It would be equivalent to abi.encodeWithSelector(bytes4(keccak256(bytes(signature)));
https://solidity.readthedocs.io/en/v0.5.2/units-and-global-variables.html?highlight=selector#abi-encoding-and-decoding-functions
Differentiation is not ...
1
Modifier code is merged with the modified function. _ is the wildcard that tells the compiler where to put the function code relative to the modifier code.
Have a look over here for explanation, examples: Using a modifier as a function in Solidity
Hope it helps.
1
I guess there are no current solutions for this situation besides implementing Dapps layer to directly call transferFrom(msg.sender, {Caller.contractAddress}, _tokenid) from ERC721 contract side. Since it's always revert when checking require(_isApprovedOrOwner(msg.sender, tokenId)); part.
https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/...
1
If I'm not mistaken, you would use the ERC20Capped.sol and mint() tokens as a second step in the migration/deployment process.
This seems sensible to me as a mintable token can do everything a non-mintable token could do. The "capped" variant puts a limit on minted supply and seems like the replacement for the old style that initialized the supply and ...
Only top voted, non community-wiki answers of a minimum length are eligible
