Hot answers tagged

10

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


8

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


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

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 constructor(myparams....) {...} from now on. Read more here.


6

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


6

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


6

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


6

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


6

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


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.


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

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


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

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


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

You could add a function to your smart contract that mimics what the CryptoKitties contract does in function tokensOfOwner, which Returns a list of all Kitty IDs assigned to an address /// @title The facet of the CryptoKitties core contract that manages ownership, ERC-721 (draft) compliant. /// @author Axiom Zen (https://www.axiomzen.co) /// @dev Ref: ...


4

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


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

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

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


4

You have a lot of questions in there. Let's find the relevant references first. Specification The standard is specified at https://eips.ethereum.org/EIPS/eip-721 The specifications are the tokenURI documentation: /// @notice A distinct Uniform Resource Identifier (URI) for a given asset. /// @dev Throws if `_tokenId` is not a valid NFT. URIs are ...


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


4

as Smart Contracts instead of using Tokens As Laurie points out, this is not really a choice. It's all smart contracts. ERC721 is a standard interface. The advantage is interoperability with other contracts and wallets that understand the contract you wrote about the assets your contract's ledger represents. Hope it helps.


4

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


4

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


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

If your NFT is ERC721 compliant, then no, according to the non-finalised ERC721 Standard, this is not possible. A requirement of the standard is that your NFT token contract contain the following function. function ownerOf(uint256 _tokenId) external view returns (address); The function takes a single argument (the tokenId) and returns the address of the ...


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