We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

7

The ERC-721 standard only describes the smart contract interface for a non-fungible token on the Ethereum blockchain. It provides basic functionality to track and transfer NFTs. A token, in this case, can only belong to a to a physical address - to an account - which can be user's wallet or another smart contract. Probably the best you can do is to extend ...


6

The other answer is incorrect. See the ERC721 Standard for exactly how to do this. If a token contract properly implements the ERC721 Standard and the ERC721Metadata extension, it will always implement the function function tokenURI(uint256 _tokenId) external view returns (string); which will return a URI pointing to that token's metadata. It may be in ...


6

Since the version 0.4.22 of Solidity, you don't define the constructor as the function with the same name than the contract, you have to use function constructor(myparams....) {...} from now on. Read more here.


5

The one without _data doesn't send any data when it calls the other contract. (It sends a zero-length byte sequence.) The one with _data does.


5

The supportsInterface shouldn't be used to check individual functions, each interface should have a single interfaceID, which as you see in the ERC-721 implementation you posted, is constructed as follows bytes4 constant InterfaceID_someInterface = bytes4(keccak256('function1(address)')) ^ bytes4(keccak256('function2(uint,etc)')) ^ ... ...


5

I'm currently developing my own implementation of an ERC721 compliant token. I wrote a number of tests for it, which I have added to my Github so that you may use if you wish. The test file was written in NodeJS, using Ganache-cli, Web3 and Mocha for tests. Contracts were compiled using Solc. You will need to create and compile a valid and invalid "token ...


4

ERC-721 is a standard, published in the Ethereum EIPs project. Cryptokitties, cryptohorse, cryptotitties, etc. all went live BEFORE the standard. Therefore they are not ERC-721. Many people will refer to them as 721, but they are actually not 721. Any wallet that wants to work with these pre-standard applications will need to manually add support, one-off, ...


4

Etherscan, MetaMask and other wallets do not currently support the ERC-721 standard. The actual standard was just passed last week. We are hosting a conference this weekend in Dallas to discuss interoperability details for Dapps and wallets. MetaMask is a sponsor for the conference. I'm probably not supposed to say this, but you could infer from this that ...


4

It appears the answer is to do with mutability, from the "Caveats" section of the ERC721 spec, Solidity issue #3412: The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: payable, implicit nonpayable, view, and pure. Your implementation MUST meet the mutability guarantee in this ...


4

It's just an interface - you are free to implement it in any way you want. People assume the transfer function would transfer the token, but it's up to you to decide if it actually does it. So, yes, you can for example use a boolean to check whether the transfer should be allowed.


4

The most official documentation for this token is the request by itself on GitHub. The author of Non-fungible Token Standard is Dieter Shirley. He was first to implement it on 20 Sep 2017. I am also looking to see if I have basic code, how to deploy it on a testnet. There are too many good answers on this particular question and there are also multiple ...


4

This is the reference implementation noted from the standard: https://github.com/0xcert/ethereum-erc721/blob/master/src/contracts/tokens/nf-token.sol It is simply the ERC721 interface and it does not include the advanced optional functionality. You can worry about that stuff later.


4

The ERC721 Metadata standard does not enforce uniqueness of the returned tokenURI. It is allowable for two 721 tokens to return the same metadata. Whether this is appropriate is up to you to decide as you implement the 721 contract. Most likely in the code you run during the minting process you will assign the metadata and decide whether or not you want to ...


4

The problem of this standard is that it would not allow multiple owners of a token because each token is not divisible. Is there possibly confusion between the idea of divisibility and fractional ownership? They're quite different concerns. Divisibility is about division. For example, you can divide $100 into two $50 but you wouldn't want to saw a kitty ...


4

Not many crypto wallets do support the ERC721 Standard out there, TrustWallet is probably one of the few that has implemented the standard for some time now. You should definitely try TrustWallet, a simple, fast and fully decentralized wallet.


4

There currently is no standard defined for what you are describing as "semi-fungible". The ERC 721 standard is for truly unique assets which are therefore NFT(non fungible tokens). To implement what you want you should use a related series of contracts each with its own total supply. The 721 spec https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md ...


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


3

As you can see for example in this implementation, ERC721 contracts keep track of an owner (identified by its address) for each single token (identified by its token ID, a 256 bit number): mapping (uint256 => address) internal tokenOwner; Consequently, to transfer a token, a sender, a receiver, and the ID of the token to be transferred have to be ...


3

There are number of examples available. E.g.: https://github.com/OpenZeppelin/zeppelin-solidity/tree/master/contracts/token/ERC721 https://github.com/m0t0k1ch1/ERC721-token-sample


3

When using the safeTransferFrom function to send ERC721 tokens to a contract address, it will fail unless the receiving contract properly implements the ERC721TokenReceiver interface. (See the ERC721 Standard for details). Any implementation of ERC721TokenReceiver will have the onERC721Received function and will return bytes4(keccak256("onERC721Received(...


3

As per the documentation for the ERC721 standard, if you want your token to be ERC721 compliant, then the tokenId must be a uint256. Every NFT is identified by a unique uint256 ID inside the ERC-721 smart contract. This identifying number SHALL NOT change for the life of the contract. The pair (contract address, uint256 tokenId) will then be a globally ...


3

The ERC721 standard has no requirements about when tokens can or can't be created, so you're free implement token minting functions as you see fit. However, if you are implementing an ERC721 token contract for asset management, it probably does makes sense to mint new ones as assets are added to the system. The only alternative would be to pre-mint a ...


3

Problem statement We want to know if it is required and/or best practice to call onERC721Received on the receiving contract when creating ("minting") a new token. Literature review The ERC-721 standard can tell us if this behavior is required. The relevant text is in the documentation for the ERC721 interface: /// @notice Transfers the ownership of an ...


3

balanceOf does not return the number of a particular token. It returns the number of tokens that a particular user owns. For example, if you want to know "How many CryptoKitties does Jane own?", you could use the balanceOf function to answer that. The balanceOf function exists for two main reasons. First, it makes ERC721 backwards compatible with ERC20, ...


3

From the Etherscan support center: Etherscan tracks all ERC-721 (https://etherscan.io/tokens-nft) compliant tokens as per the finalized standard at https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md with the following caveats It must emit at least one ERC-721 compliant transfer event which looks something like: event Transfer(...


3

This is possible with ERC721 tokens and is built into to spec itself in the form if metadata. You cannot do this with ERC20 tokens, as there is no way to differentiate between individual tokens during a transaction.


3

Problem We are considering how to query the Ethereum blockchain using the Web3 JS API to collect events, summarizing this data to find the most recent recipient of each ERC-721 token. Running your own infrastructure (Geth / Parity) is outside the scope of this question. Answer This answer uses Node.js. First, create this package.json: { "dependencies":...


3

The function transferFrom in token contracts refers to the transfer of tokens that you do not own, but rather have been approved to spend. It is used together with the approve function, when an address establishes a certain allowance of tokens for another address to spend for them. Hence, when using transferFrom you establish what address the tokens that you ...


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


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


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