Skip to content

Commit

Permalink
Restructure intro to ERC721 contract docs
Browse files Browse the repository at this point in the history
  • Loading branch information
frangio committed Jan 6, 2022
1 parent d746056 commit 1e815f3
Showing 1 changed file with 16 additions and 7 deletions.
23 changes: 16 additions & 7 deletions contracts/token/ERC721/README.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -7,18 +7,27 @@ This set of interfaces, contracts, and utilities are all related to the https://

TIP: For a walk through on how to create an ERC721 token read our xref:ROOT:erc721.adoc[ERC721 guide].

The EIP consists of three interfaces, found here as {IERC721}, {IERC721Metadata}, and {IERC721Enumerable}. Only the first one is required in a contract to be ERC721 compliant. The core interface and the metadata extension are both implemented in {ERC721}. The enumerable extension is provided separately in {ERC721Enumerable}.
The EIP specifies four interfaces:

Additionally, {IERC721Receiver} can be used to prevent tokens from becoming forever locked in contracts. Imagine sending an in-game item to an exchange address that can't send it back!. When using <<IERC721-safeTransferFrom,`safeTransferFrom`>>, the token contract checks to see that the receiver is an {IERC721Receiver}, which implies that it knows how to handle {ERC721} tokens. If you're writing a contract that needs to receive {ERC721} tokens, you'll want to include this interface.
* {IERC721}: Core functionality required in all compliant implementation.
* {IERC721Metadata}: Optional extension that adds name, symbol, and token URI, almost always included.
* {IERC721Enumerable}: Optional extension that allows enumerating the tokens on chain, often not included since it requires large gas overhead.
* {IERC721Receiver}: An interface that must be implemented by contracts if they want to accept tokens through `safeTransferFrom`.
Additionally there are multiple custom extensions, including:
OpenZeppelin Contracts provides implementations of all four interfaces:

* designation of addresses that can pause token transfers for all users ({ERC721Pausable}).
* destruction of own tokens ({ERC721Burnable}).
* support for voting and vote delegation ({ERC721Votes})
* {ERC721}: The core and metadata extensions, with a base URI mechanism.
* {ERC721Enumerable}: The enumerable extension.
* {ERC721Holder}: A bare bones implementation of the receiver interface.
NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC721 (such as <<ERC721-_mint-address-uint256-,`_mint`>>) and expose them as external functions in the way they prefer. On the other hand, xref:ROOT:erc721.adoc#Presets[ERC721 Presets] (such as {ERC721PresetMinterPauserAutoId}) are designed using opinionated patterns to provide developers with ready to use, deployable contracts.
Additionally there are a few of other extensions:

* {ERC721URIStorage}: A more flexible but more expensive way of storing metadata.
* {ERC721Votes}: Support for voting and vote delegation.
* {ERC721Pausable}: A primitive to pause contract operation.
* {ERC721Burnable}: A way for token holders to burn their own tokens.
NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC721 (such as <<ERC721-_mint-address-uint256-,`_mint`>>) and expose them as external functions in the way they prefer. On the other hand, xref:ROOT:erc721.adoc#Presets[ERC721 Presets] (such as {ERC721PresetMinterPauserAutoId}) are designed using opinionated patterns to provide developers with ready to use, deployable contracts.

== Core

Expand Down

0 comments on commit 1e815f3

Please sign in to comment.