Ether – How to Create an ERC-721 Creator Contract

erc-721etheropensea

I am trying to create a smart contract (for ERC721) that artists can use to mint on their own contract instead of the shared contracts of OS, Rarible etc.

The contract is ready, but we have one bug we can't seem to resolve..

So i deploy the contract from my wallet, then I do an transferOwnerShip to the creator.
When the creator the mints, the contract shows me as creator because i deployed the contract.

Does anybody have a solution for this?

i'll paste my mint method here, so you can see what we have:
(i am extending the ERC721.sol from openzeppelin)

'''

/**
 * @dev Mints a NEW Token.
 * Only allowed for addresses that have the minter role.
 */
function mint(string memory _tokenURI) external onlyMinter
{
    require(bytes(_tokenURI).length != 0, "ERC721Creator: Missing tokenURI");
    _lastTokenId += 1;
    _safeMint(msg.sender, _lastTokenId);
    _setTokenURI(_lastTokenId, _tokenURI);
    tokenCreators[_lastTokenId] = msg.sender;
}

'''

Best Answer

The "clones" proxy was set up exactly for this purpose.

Please see the specification in EIP-1167 and their use cases.

But in general:

You deploy your template code once
For each customer deployment, you deploy a proxy to the underlying contract
During customer deployment, you initialize any permissions necessary to vendor it for them

Related Solutions

ERC-165 Query – Understanding ERC-165 Query on ERC-721 Implementation

supportsInterface shouldn't be used to check individual functions. Each interface should have a single interfaceID which, as you can 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)')) ^
    ...
    bytes4(keccak256('functionN()'));

In the case of the ERC165 interface, there is only one function in that interface, supportsInterface, so the interfaceID is just

bytes4 constant InterfaceID_ERC165 =
    bytes4(keccak256('supportsInterface(bytes4)'));
//0x01ffc9a7

But it's important to note that when you call supportsInterface on 0x01ffc9a7, you are testing to see if your contract supports the whole ERC165 standard. It just so happens that there is only one function.

So you shouldn't be calling supportsInterface on 0x8462151c, this would be checking for an interface which only contained the function tokensOfOwner().

Instead, you should be checking against the interfaceID of the whole ERC721 interface. If your contract supports the whole interface, then by definition it will support any of the functions contained therein.

The idea is that anyone can find the specification for the interface, and just check the interfaceID of that interface against your contract.

BUT, there are two problems with the implementation posted. First of all, they didn't provide the ERC721 or 165 interfaces. They just provided an abstract contract which contains a few related functions. So they didn't really give the thing you should be checking against.

Also, I don't think this implementation is an up-to-date or proper implementation of ERC721. The standard is still a work in progress, but you can see the non-finalised standard here.

There are actually interfaces for 3 standards here:

ERC721 (0x80ac58cd)

ERC721Metadata (0x5b5e139f) (optional)

ERC721Enumerable (0x780e9d63) (optional)

ERC721 just implements the basic requirements of a NFT, ERC721Metadata adds name, symbol and URI data functionality, and ERC721Enumerable adds some other functionality to do with token indexes.

This is relevant to what you posted because basic ERC721 does not implement any of the following:

name() (this is from ERC721Metadata)

symbol() (this is from ERC721Metadata)

totalSupply() (this is from ERC721Enumerable)

transfer(address,uint256) (this is from ERC20 spec, 721 uses transferFrom and safeTransferFrom)

tokensOfOwner(address) (not part of the standards).

There are also some functions in the standard which you will see aren't implemented in the one you provided. It's likely that it was written when the standard was at a much earlier age. And indeed, this sort of situation is partially the purpose of the ERC165 specification.

If standards are developing and evolving over time, then ERC721 version 0.0.1 (a number I just made up) may have an interfaceID of 0x9f40b779 (which is the value of InterfaceID_ERC721 in the contract you provided). However, version 0.0.2 may add, change, or remove a function, which would completely change the interfaceID to something else. So as long as you specify that your contract complies to ERC721 0.0.1, someone else can look up the interface, and check it against your contract.

So the very short answer to your question is, you shouldn't be checking supportsInterface against a single function, but rather against the whole interface.

But I also don't think you should be using the contract you provided because it seems out of date, and the whole purpose of standards is to be compliant.

[Ethereum] How to import files into remix (ERC721 contract)

import "github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC721/IERC721.sol";
import "github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC721/IERC721Receiver.sol";
import "github.com/OpenZeppelin/openzeppelin-solidity/contracts/math/SafeMath.sol";
import "github.com/OpenZeppelin/openzeppelin-solidity/contracts/utils/Address.sol";
import "github.com/OpenZeppelin/openzeppelin-solidity/contracts/drafts/Counters.sol";
import "github.com/OpenZeppelin/openzeppelin-solidity/contracts/introspection/ERC165.sol";

This compiles. I am not sure about the v2.0.0 on counter. I replaced that with master.

Best Answer

Related Solutions

ERC-165 Query – Understanding ERC-165 Query on ERC-721 Implementation

[Ethereum] How to import files into remix (ERC721 contract)

Related Topic