Update EIP-2135: Move to Final

Merged by EIP-Bot.

EIPS/eip-2135.md

@@ -1,7 +1,7 @@
 ---
 eip: 2135
 title: Consumable Interface (Tickets, etc)
-description: An interface extending EIP-721 and EIP-1155 for consumability, supporting use case such as an event ticket.
+description: An interface extending ERC-721 and ERC-1155 for consumability, supporting use case such as an event ticket.
 author: Zainan Victor Zhou (@xinbenlv)
 discussions-to: https://ethereum-magicians.org/t/eip-2135-erc-consumable-interface/3439
 status: Last Call
@@ -32,7 +32,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
 ```solidity
 pragma solidity >=0.7.0 <0.9.0;
 
-/// The EIP-165 identifier of this interface is 0xdd691946
+/// The ERC-165 identifier of this interface is 0xdd691946
 interface IERC2135 {
     /// @notice The consume function consumes a token every time it succeeds.
     /// @param _consumer the address of consumer of this token. It doesn't have
@@ -74,9 +74,9 @@ interface IERC2135 {
 }
 ```
 
-2. If the compliant contract is an [EIP-721](./eip-721.md) or [EIP-1155](./eip-1155.md) token, in addition to `OnConsumption`, it **MUST** also emit the `Transfer` / `TransferSingle` event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to `consume` method succeeds.
+2. If the compliant contract is an [ERC-721](./eip-721.md) or [ERC-1155](./eip-1155.md) token, in addition to `OnConsumption`, it **MUST** also emit the `Transfer` / `TransferSingle` event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to `consume` method succeeds.
 
-3. `supportsInterface(0xdd691946)` **MUST** return `true` for any compliant contract, as per [EIP-165](./eip-165.md).
+3. `supportsInterface(0xdd691946)` **MUST** return `true` for any compliant contract, as per [ERC-165](./eip-165.md).
 
 ## Rationale
 
@@ -85,29 +85,29 @@ interface IERC2135 {
 - who has the power to perform consumption
 - under what condition consumption can occur
 
-It does, however, assume the asset can be identified in a `uint256` asset id as in the parameter. A design convention and compatibility consideration is put in place to follow the EIP-721 pattern.
+It does, however, assume the asset can be identified in a `uint256` asset id as in the parameter. A design convention and compatibility consideration is put in place to follow the ERC-721 pattern.
 
 2. The event notifies subscribers whoever are interested to learn an asset is being consumed.
 
 3. To keep it simple, this standard *intentionally* contains no functions or events related to the creation of a consumable asset. This is because the creation of a consumable asset will need to make assumptions about the nature of an actual use-case. If there are common use-cases for creation, another follow up standard can be created.
 
-4. Metadata associated to the consumables is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface like `ERC721Metadata` from [EIP-721](./eip-721.md)
+4. Metadata associated to the consumables is not included the standard. If necessary, related metadata can be created with a separate metadata extension interface like `ERC721Metadata` from [ERC-721](./eip-721.md)
 
 5. We choose to include an `address consumer` for `consume` function and `isConsumableBy` so that an NFT MAY be consumed for someone other than the transaction initiator.
 
 6. We choose to include an extra `_data` field for future extension, such as
 adding crypto endorsements.
 
-7. We explicitly stay opinion-less about whether EIP-721 or EIP-1155 shall be required because
-while we design this EIP with EIP-721 and EIP-1155 in mind mostly, we don't want to rule out
+7. We explicitly stay opinion-less about whether ERC-721 or ERC-1155 shall be required because
+while we design this EIP with ERC-721 and ERC-1155 in mind mostly, we don't want to rule out
 the potential future case someone use a different token standard or use it in different use cases.
 
 8. The boolean view function of `isConsumableBy` can be used to check whether an asset is
 consumable by the `_consumer`.
 
 ## Backwards Compatibility
 
-This interface is designed to be compatible with EIP-721 and NFT of EIP-1155. It can be tweaked to used for [EIP-20](./eip-20.md), [EIP-777](./eip-777.md) and Fungible Token of EIP-1155.
+This interface is designed to be compatible with ERC-721 and NFT of ERC-1155. It can be tweaked to used for [ERC-20](./eip-20.md), [ERC-777](./eip-777.md) and Fungible Token of ERC-1155.
 
 ## Test Cases