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 ...
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.
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:
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-...
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 ...
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.
This answer uses Node.js. First, create this package.json:
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 ...
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.
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.
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 ...
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'...
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) ...
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 ...
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.
Here is an example contract which can deposit tokens and then auction them off. All the while it records which person originally deposited it.
Here is the setup. First we have to import the ERC-721 headers. I am using the reference implementation for ERC-721 for this:
pragma solidity 0.5.1;
Metadata of a non-fungible ERC-721 token are hosted on a public HTTP address. The content of this metadata JSON file can be changed. ERC-721 standard does not prevent you to add smart contract logic for changing token's URI.
Following is a complete test which you can replicate using Node on your development machine. This test will require access to a web3 provider. I am using Infura which you will a password to use.
The mint function is not part of the ERC-721 standard but there is an example of a mint implementation in the ERC-721 reference implementation.
There is no transfer in ERC-721. Source:
transferFrom is superior because you may have authority from multiple people to send any given NFT. That means a transfer is ambiguous whether it is coming from yourself or from someone else that authorized you to send it.
But I know I’m sending it from myself because I’m ...
Yes, you are on the right track. Below is a fully usable contract which implements the feature you are requesting.
Fortunately, the reference implementation of ERC-721 from 0xcert happens to include a little extra code to implement Ownable (which is similar to the OpenZeppelin implementation).
I have made the subtle assumption that you will implement more ...
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 ...
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 ...
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 ...
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....
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
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)', '...
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 ...
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 ...
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 ...
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 ...
This is a UX bug. Please report it to MetaMask. And if you can please post a comment link here so I can give you a thumbs up.
Here’s what’s happening. MetaMask understands ERC-20 just enough. And it does not yet understand ERC-721. So it thinks your transaction applies to a ERC-20 token.
The ERC-20 transfer function is similar to ERC-721 except that ...