diff --git a/EIPS/eip-721.md b/EIPS/eip-721.md index 0fd68f60..0c36f5a8 100644 --- a/EIPS/eip-721.md +++ b/EIPS/eip-721.md @@ -47,9 +47,8 @@ pragma solidity ^0.4.20; import "./ERC165.sol"; /// @title Required part of ERC-721 Distinguishable Assets Registry -/// @author William Entriken (https://phor.net) /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md -/// Note: the ERC-165 (DRAFT) identifier for this interface is 0xb3a99827 +/// Note: the ERC-165 identifier for this interface is 0xb3a99827 interface ERC721 /* is ERC165 */ { /// @dev This emits when ownership of any asset changes by any mechanism. /// This event emits when assets are created (`from` == 0) and destroyed @@ -121,7 +120,7 @@ interface ERC721 /* is ERC165 */ { /// @param _approved True to appove an operators, false to revoke approval function setApprovalForAll(address _operateor, boolean _approved) payable; - // CONFORMANCE TO ERC-165 (DRAFT) ////////////////////////////////////////// + // CONFORMANCE TO ERC-165 ////////////////////////////////////////////////// /// @notice Query if this implements an interface /// @param interfaceID The interface identifier, as specified in ERC-165 @@ -137,9 +136,8 @@ The **metadata extension** is OPTIONAL for ERC-721 implementations (see "caveats ```solidity /// @title Optional metadata extension to ERC-721 Distinguishable Assets Registry -/// @author William Entriken (https://phor.net) /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md -/// Note: the ERC-165 (DRAFT) identifier for this interface is 0x2a786f11 +/// Note: the ERC-165 identifier for this interface is 0x2a786f11 interface ERC721Metadata /* is ERC721 */ { /// @notice A descriptive name for a collection of assets in this contract function name() external pure returns (string _name); @@ -163,15 +161,15 @@ This is the "ERC721 Metadata JSON Schema" referenced above. Learn more about [JS "type": "object", "properties": { "name": { - "type": "string" + "type": "string", "description": "Identifies the asset to which the DAR grants ownership", }, "description": { - "type": "string" + "type": "string", "description": "Describes the asset to which the DAR grants ownership", }, "image": { - "type": "string" + "type": "string", "description": "A URI pointing to a resource with mime type image/* representing the asset to which the DAR grants ownership. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive.", } } @@ -182,9 +180,8 @@ The **enumeration extension** is OPTIONAL for ERC-721 implementations (see "cave ```solidity /// @title Optional enumeration extension to ERC-721 Distinguishable Assets Registry -/// @author William Entriken (https://phor.net) /// @dev See https://github.com/ethereum/EIPs/blob/master/EIPS/eip-721.md -/// Note: the ERC-165 (DRAFT) identifier for this interface is 0x5576ab6a +/// Note: the ERC-165 identifier for this interface is 0x5576ab6a interface ERC721Enumerable /* is ERC721 */ { /// @notice Count assets tracked by this contract /// @return A count of valid assets tracked by this contract, where each one of @@ -228,7 +225,7 @@ interface ERC721Enumerable /* is ERC721 */ { The 0.4.20 Solidity interface grammar is not expressive enough to document the ERC-721 specification. A contract which complies with ERC-721 MUST also abide by the following: -- [Solidity issue #3412](https://github.com/ethereum/solidity/issues/3412): The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: `payable`, implicit nonpayable, `view`, and `pure`. Your implementation must meet the mutability guarantee in this interface or you may meet a stronger guarantee. For example, a `payable` function in this interface may be implemented as nonpayble (no state mutability specified) in your contract. Workraound: until Solidity fixes this issue, you can edit this interface to add stricter mutability before inheriting from your contract. +- [Solidity issue #3412](https://github.com/ethereum/solidity/issues/3412): The above interfaces include explicit mutability guarantees for each function. Mutability guarantees are, in order weak to strong: `payable`, implicit nonpayable, `view`, and `pure`. Your implementation must meet the mutability guarantee in this interface or you may meet a stronger guarantee. For example, a `payable` function in this interface may be implemented as nonpayble (no state mutability specified) in your contract. We expect a later Solidity release will allow your stricter contract to inherit from this interface, but a workaround for version 0.4.20 is that you can edit this interface to add stricter mutability before inheriting from your contract. - [Solidity issue #3419](https://github.com/ethereum/solidity/issues/3419): A contract that implements `ERC721Metadata` or `ERC721Enumerable` SHALL also implement `ERC721`. ERC-721 implements the requirements of interface [ERC-165](https://github.com/ethereum/EIPs/pull/881). - [Solidity issue #2330](https://github.com/ethereum/solidity/issues/2330): If a function is shown in this specification as `external` then a contract will be compliant if it uses `public` visibility. - Solidity issues [#3494](https://github.com/ethereum/solidity/issues/3494), [#3544](https://github.com/ethereum/solidity/issues/3544): Use of `this.*.selector` is marked as a warning by Solidity, a future version of Solidity will not mark this as an error. @@ -287,9 +284,9 @@ Creating of new assets and destruction of assets is not included in the specific **ERC-165 interface** -This specification includes a function `supportsInterface` which is standardized in [ERC-165](https://github.com/ethereum/EIPs/pull/881) (draft pending acceptance). So any contract MAY query your contract to see if it complies with ERC-721 and the extensions. This creates a dependency, which is a risk. However, ERC-165 is an extremely simple proposal, has implementations deployed in the wild for years and the draft meets all EIP requirements for acceptance, including [the new requirements](https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2031.md#10957-decision-process-for-eips) that aren't even documented yet. The lead author of this standard is also the official champion for ERC-165. One EIP reviewer [has "ACK"ed the draft](https://github.com/ethereum/EIPs/pull/881#pullrequestreview-97124296). +This specification includes a function `supportsInterface` which is standardized in [ERC-165](https://github.com/ethereum/EIPs/pull/881). So any contract MAY query your contract to see if it complies with ERC-721 and the extensions. -We chose ERC-165 over competing standard ERC-820 because of maturity. We consider ERC-165 low risk. But ERC-820, as recently as two weeks ago, [discovered a complete show-stopping flaw](https://github.com/ethereum/EIPs/issues/820#issuecomment-362049573). ERC-820 may be a great option, but we deem dependency on that standard an unacceptable risk at this time. +A future EIP may create a global registry of interfaces for contracts. We strongly support such an EIP and it would allow your contract to to implement ERC721Enumerable, ERC721Metadata, or other interfaces by delegating to a separate contract. **Gas and complexity** (regarding the enumeration extension)