Hot answers tagged

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

There is nothing wrong. When you do your first token transfer it will automatically be visible.


3

The interface identifier 0x150b7a02 is for the ERC721TokenReceiver interface. That is, contracts that implement onERC721Received, and just implies that the contract was designed to receive ERC-721 tokens. This doesn't in any way guarantee that this receiver contract was written to execute any/all of the functions on your ERC-721 Token contract.


3

The standard was designed so as to minimize the number of required functionalities. (Not joking.) At the time it was finalized (June 2018), minting with that interface was not implemented in the vast majority of existing implementations so it was not added to the standard. Even still I do not think minting is implement that way everywhere so I don't think ...


3

Yes, the ERC-721 specification specifically allows attaching a document to each token. Please see the metadata extension in the standard at https://eips.ethereum.org/EIPS/eip-721 One caveat, and maybe this is a subtlety. The token points to the document, but the document might not point to the token. People will need to recognize that you (your contract) ...


3

Per https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md, there's an optional "enumeration extension". If this is implemented for the token you're interested in, then you can just call balanceOf to get the number of tokens owned by the account, followed by tokenOfOwnerByIndex in a loop to get each owned token ID. If it isn't implemented, then there'...


3

In ERC-721, each token is completely unique and non-interchangeable with other tokens. The key features of both are: ERC-20: For money and money-like tokens. ERC-721: For things and thing-like tokens. According to the nature of these tokens, nowadays most of the games are using ERC-721 tokens e.g. Cryptokitties because kitties are unique and non-...


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

Try this: https://coinmarketcap.com/tokens/ They are listed by market cap which might be a good indicator. is mostly outdated and can't get compiled any more with latest solidity compiler versions That doesn't make sense. Contracts don't get outdated. Bytecode remains on the chain. Only the compiler evolves and with it the Solidity language (the most ...


2

I demonstrated at NFT.nyc in March this year a technique to create NF token with O(1) cost. In other words, make as many as you want. This is the same technique as used in Su Squares and you can see the slides at http://nft.life


2

ERC721 gas costs are scale-invariant. It's just a matter of the amount of gas players would require to create new characters? Yes. That is correct. It is financially constrained. An important heuristic is to avoid introducing anything in your contracts that would increase in cost in proportion to scale. In case that sounds cryptic: https://blog.b9lab....


2

Interface support is advertised using ERC-165. This is documented in https://eips.ethereum.org/EIPS/eip-165 There are two cases where this is useful and these reasons motivated adding the feature as a requirement for all ERC-721 contracts: 1) Allowing off-chain entities (wallets, block explorers, Web3 clients) to recognize abilities of a contract. For ...


2

The function balanceOf actually returns the number of owned tokens and not the identifier of an owned token. Therefore I'd assume the process could go something like this: 1) Find out how many tokens an address has (balanceOf). If this is more than zero, continue the process. 2) Find out which tokens exist in the contract. The standard offers no direct ...


2

Alright, y'all are lazy so I did it myself. This is a super rough estimate. Here's a gist of my script to get all the function names in the top 1000 'verified contracts' on etherscan. The script downloads the abis for all the top contracts and checks for the existence of functions with the names in the following list: ['transfer(with bytes)', '...


2

I've noticed that the visibility of the function is public. Doesn't it mean that anyone can modify an operator which was previously set before? The public visibility just means that the function can be called from outside of the contract, ie, by another contract or from a wallet. The function you mentioned, setApprovalForAll, is used to give another ...


2

The main problem will be that all information on the blockchain is public. So you will not be able to store anything secret there. Therefore the process needs to include some elements outside the blockchain. Another problem you will face (as you noticed) is how to revoke access to the IPFS file. The only way I can think of is for the requests to come ...


2

If it is a genuine ERC-721 transfer transaction, then the msg.sender of the transaction will be the address of the ERC-721 contract. This transaction also contains data about which tokenId was just transferred to you. So you can call ownerOf(tokenId) on that contract, and if the address returned is your contract's address, then you can be confident that you ...


2

The problem with tokens is that they can be implemented in a million different ways and still be standard compliant. Also as a partial result of that problem, it's very difficult to say whether a contract is a token contract or not - and different platforms estimate the correctness differently. Let's have a look at the ERC721 standard: http://erc721.org/ . ...


1

It depends on the implementation of your mint, burnToken, addToken and removeToken functions. The ERC-721 pattern does not declare a mint function, in the same way that ERC-20 doesn't either. So, if your mint function requires that the token ID has not been used before, then the answer to your question is "no". Otherwise, it's probably "yes, just be careful"...


1

No, this is not possible. Here is a more general explanation which is relevant and then application to your specific instance. ENTRIKEN'S LAW: Your ownership of assets on a ledger is only as valid as your trust in the custodian who has physical control of the assets. In your case, IPFS is the custodian which physically controls access to the media. So no,...


1

Considering you are interfacing with an existing contract (i.e. calling it). You can send any data you want, such as a string converted to bytes. Here is just one example I have lying around on how to wrangle strings and bytes https://github.com/su-squares/ethereum-contract/blob/master/contracts/SuNFT.sol#L221-L239 The reason why you would do this is ...


1

Does this mean that when a function in the interface includes payable and when it is implemented, it can be changed to anything? Yes, payable is the least-strict form of mutability, so your implementation of the function can use a stricter mutability if you want it to. Also the definition Mutability guarantees is hard to understand. Can someone explain ...


1

The error is Undeclared identifier: browser/NFT.sol:39:21: DeclarationError: Undeclared identifier. require(index < balanceOf(owner), "ERC721Enumerable: owner index out of bounds"); ^-------^ In the contract as shown there isn't an implementation for the balanceOf function, so I assume that your contract is missing some code. I suggest ...


1

I believe this is related to sending your token info to Etherscan team. You can do this here https://etherscan.io/contactus and as subject select "Update Token Info".


1

Well, tokens are smart contracts. All tokens are based on a smart contract - there can be no tokens without a smart contract. For example an ERC20 token is simply a standard which defines how a smart contract stores a ledger of token owners. So the contract itself basically contains information about which address owns how many of its tokens and some ...


1

There is basically no way to easily view all owned tokens. My Ethereum wallets own probably lots of random worthless tokens which someone has airdropped and I don't even know about it. Some services (wallets) display many of the owned tokens. I'm unsure how exactly they do that but most likely they simply have a database of known token contracts and they ...


1

Yes you can. Provided you keep the interface compliant with the ERC721 standard you are free to implement any kind of logic you like, including additional functions. ERC721 defines what it must have, not what it must not have. In terms of "how" you can adapt this or similar approach to your use-case. Contracts can hold Eth. By extension, and ERC721 can ...


1

As long as you don't modify the functions, events and member variables of the standard, you are good to go.


1

You can remove the errors with this implementation: function onERC721Received( address, address, uint256, bytes calldata )external returns(bytes4) { return bytes4(keccak256("onERC721Received(address,address,uint256,bytes)")); } The parameters are there for implementations that want to use them. Perhaps for doing an accounting of ...


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