status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Add implementation, thank you Nastassia Sachs

This commit is contained in:
William Entriken 2018-02-15 12:06:18 -05:00 committed by GitHub
parent 2b32af6ae6
commit 7046c02cd6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
EIPS/eip-721.md
View File

@ -3,7 +3,7 @@
``` ```
EIP: <to be assigned> EIP: <to be assigned>
Title: ERC-721 Deed Standard Title: ERC-721 Deed Standard
Author: William Entriken <github.com@phor.net>, Dieter Shirley <dete@axiomzen.co> Author: William Entriken <github.com@phor.net>, Dieter Shirley <dete@axiomzen.co>, Nastassia Sachs <nastassia.sachs@protonmail.com>
Type: Standard Type: Standard
Category ERC Category ERC
Status: Draft Status: Draft
@ -308,9 +308,9 @@ Note: "Limited edition, collectible tokens" like [Curio Cards](https://mycurioca
Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable. Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.
## Implementation ## Implementations
**TO DO** ERC721ExampleDeed, by Nastassia Sachs: https://github.com/nastassiasachs/ERC721ExampleDeed
The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.