NoBey/openzeppelin-contracts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update docs (#2168)

Browse Source 
* Update docs for ERC20 and ERC721

* Add EnumerableMap to docs

* Update misc guides

* Apply suggestions from code review

Co-Authored-By: Francisco Giordano <frangio.1@gmail.com>

Co-authored-by: Francisco Giordano <frangio.1@gmail.com>
This commit is contained in:
Nicolás Venturo
2020-04-03 13:17:24 -03:00
committed by GitHub
parent 6668a4d05c
commit 402c6ab4cc
11 changed files with 53 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
contracts/token/ERC721/README.adoc
View File

@ -2,54 +2,37 @@
This set of interfaces, contracts, and utilities are all related to the https://eips.ethereum.org/EIPS/eip-721[ERC721 Non-Fungible Token Standard].
TIP: For a walkthrough on how to create an ERC721 token read our xref:ROOT:tokens.adoc#ERC721[ERC721 guide].
TIP: For a walkthrough 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.
Each interface is implemented separately in {ERC721}, {ERC721Metadata}, and {ERC721Enumerable}. You can choose the subset of functionality you would like to support in your token by combining the
desired subset through inheritance.
The fully featured token implementing all three interfaces is prepackaged as {ERC721Full}.
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. However, all three are implemented in {ERC721}.
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.
Finally, some custom extensions are also included:
* {ERC721Mintable} — like the ERC20 version, this allows certain addresses to mint new tokens
* {ERC721Pausable} — like the ERC20 version, this allows addresses to freeze transfers of tokens
Additionally there are multiple custom extensions, including:
NOTE: This page is incomplete. We're working to improve it for the next release. Stay tuned!
* designation of addresses that can pause token transfers for all users ({ERC721Pausable}).
* destruction of own tokens ({ERC721Burnable}).
== Core
{{IERC721}}
{{ERC721}}
{{IERC721Metadata}}
{{ERC721Metadata}}
{{ERC721Enumerable}}
{{IERC721Enumerable}}
{{IERC721Full}}
{{ERC721Full}}
{{ERC721}}
{{IERC721Receiver}}
== Extensions
{{ERC721Mintable}}
{{ERC721MetadataMintable}}
{{ERC721Pausable}}
{{ERC721Burnable}}
{{ERC721Pausable}}
== Convenience
{{ERC721Holder}}