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


3

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


2

Take a look at ERC-1155, https://github.com/ethereum/EIPs/issues/1155. This was designed by the Gnosis Team to address the problem of using ERC20 and ERC721 tokens in a case where when unique tokens would emerge. You can do that, and decompose/recompose according to rules to configure you will have the problem of gas cost for deploying a new contract each ...


2

Let's take the open-zeppelin implementation of ERC721: _mint() function /** * @dev Internal function to mint a new token * Reverts if the given token ID already exists * @param to The address that will own the minted token * @param tokenId uint256 ID of the token to be minted by the msg.sender */ function _mint(address to, uint256 ...


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


1

ERC20 and ERC721 are, by definition, interfaces. You cannot attach extra data to the prescribed functions, e.g. transfer() because that will break compatibility with the standard interface. You didn't say what you want to achieve so it's not possible to be specific about the solution. Two common approaches spring to mind. ERC20 is for fungible assets - ...


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

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


1

I Googled zcash and fungibility, found this one article from @dnaleor on Steemit. Assuming that's the one you meant, the article was saying that in a cryptocurrency world where every transaction is globally visible, privacy is important for fungibility. Let's say you're running an organization which is being censored by the government and you're paying ...


1

The identity consists of two main parts: Keys that owns and controls the identity and Claims that belong to that identity. ERC725: Identity Keys Is used to manage unique identity for humans, groups, objects, and machines. This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third ...


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 deploy as many tokens as you want with the same structure, each token will have a unique contract address. The contract address can then be used to identify the particular token among all the tokens which follow the same structure in future contracts. Is this what you're looking for? otherwise you can look into NFTs as mentioned by @qCazelles in ...


1

Are you looking for non-fungible tokens ? There is EIP 721 (ERC-721 tokens) https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md Each token has an id. The token is your object. Example : CryptoKitties. Every kitty is an ERC-721 token.


1

This technique was presented on stage at NFT.nft by yours truly using a combination of ERC-721, ERC-998 (ish) and ERC-1167. Also the technique is explained in Su Squares at https://github.com/su-squares/ethereum-contract It is surely too much code to paste in this answer so I'll summarize: You can only create N tokens at once efficiently during contract ...


1

As of today 2019-01-25 in mainnet the block gas limit is 8M. If minting a single token consumes 50K gas then you can at most create 160 tokens. 8000000 / 50000 = 160 If you have to mint 1000 tokens I'd suggest to try a different approach. For example you can store only the root of the merkle tree of the new tokens. If someone wants to redeem tokens they ...


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


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