Mirror NFT Protocol ​

The Mirror NFT Protocol uses a pattern where calls are executed against the NFT contract during deployment to define settings, register different types of sales, grant roles, set metadata rendering and much more.

With the Mirror NFT SDK, we can define a simple object type and get transaction inputs (to, value, and data) as a result, with all the appropriate calls encoded. The results can then be used to submit transactions.

Protocol Design ​

The Mirror NFT Protocol is a robust ERC721 implementation that is flexible and easily extendable. The factory and the NFT implementation are completely immutable. The key components are:

• ERC721 Factory — a contract used to deploy new ERC721 Clones.
• ERC721 — an ERC721 implementation; each NFT contract deployed is a clone.
• Minters — contracts that implement minting logic.
• Metadata renderers — contracts that implement ERC721Metadata extension.

ERC721 Factory ​

The ERC721 factory is a simple contract that deploys clones using ERC-1167. The factory is always the first entry point for interacting with the protocol since it deploys the NFT contracts. The factory supports three types of deployments:

• create - Deploys an NFT contract with msg.sender as the creator/admin
• createWithSalt - Same as create but supports a salt parameter for deploying a contract with a specific address.
• createWithSignature - Deploys an NFT contract for a creator with their consent provided by a signature. See ERC-7015.

ERC721 ​

The ERC721 contract is the NFT implementation. Each clone deployed through the factory contract will have the same logic. The contract is implemented with ERC721A for minting multiple tokens with a low gas cost. Additionally, the contract implements the following:

• Role-based permissions for admin settings and minting tokens.
• Specifying a maximum supply of tokens.
• Setting default royalties for all token ids and each specific token id. It uses ERC2981.
• Flexible metadata rendering with the option to freeze metadata.
• Registering sales with minters.
• Ability to execute multiple self-calls on deployment and post-deployment. This allows for very flexible configuration.
• Implements ERC-7015 for creator attribution through signatures. Lazy minting.
• Soulbound (i.e. non-transferrable tokens). Non-transferrable tokens can always be made transferrable by the admin. However, not the other way around. The implementation requires transfers to be enabled at deployment time.

Minters ​

• FixedSaleMinter — implements a fixed-price sale with start/end times, a supply of tokens that can be minted in the sale, and the number of tokens that can be minted per address. Takes a flat fee per mint.
• SignatureMinter — implements a mint where a valid signature has to be provided to mint tokens.

Metadata renderers ​

• EditionMetadataRenderer — supports updating an imageURI, animationURI, and a description. Returns the same for all tokens
• ImmutableEditionMetadataRenderer — same as above but cannot be updated.
• WritingNFTMetadataRenderer — supports same fields as EditionMetadataRenderer plus and extra content parameter for an Arweave transaction hash.

Chains and Addresses ​

TODO: Add deployed contracts