Update ERC-7634: Move to Last Call

Merged by EIP-Bot.

Author: OniReimu

ERCS/erc-7634.md

@@ -1,10 +1,11 @@
 ---
 eip: 7634
 title: Limited Transfer Count NFT
-description: An ERC-721 extension to limit transferability based on counts among NFTs
+description: An ERC-721 extension that caps how many times an individual token can be transferred
 author: Qin Wang (@qinwang-git), Saber Yu (@OniReimu), Shiping Chen <[email protected]>
 discussions-to: https://ethereum-magicians.org/t/erc-7634-limited-transferable-nft/18861
-status: Review
+status: Last Call
+last-call-deadline: 2025-12-16
 type: Standards Track
 category: ERC
 created: 2024-02-22
@@ -13,70 +14,72 @@ requires: 165, 721
 
 ## Abstract
 
-This standard extends [ERC-721](./eip-721.md) to introduce a mechanism that allows minters to customize the transferability of NFTs through a parameter called `TransferCount`. `TransferCount` sets a limit on how many times an NFT can be transferred. The standard specifies an interface that includes functions for setting and retrieving transfer limits, tracking transfer counts, and defining pre- and post-transfer states. The standard enables finer control over NFT ownership and transfer rights, ensuring that NFTs can be programmed to have specific, enforceable transfer restrictions.
-
+This standard extends [ERC-721](./eip-721.md) with a mechanism that lets token owners/minters cap how many times a specific token can be transferred. It specifies functions to set and read a per-token transfer limit, to query a per-token transfer count, and defines transfer-time hooks to enforce the cap. The goal is fine-grained, enforceable transfer restrictions while preserving ERC-721 compatibility.
 
 ## Motivation
 
-Once NFTs are sold, they detach from their minters (creators) and can be perpetually transferred thereafter. Yet, many circumstances demand precise control over NFT issuance. We outline their advantages across three dimensions.
+Once NFTs are sold, they detach from their minters and can be perpetually transferred. Yet many situations require tighter control over secondary movement.
 
-Firstly, by imposing limitations on the frequency of NFT sales or trades, the worth of rare NFTs can be safeguarded. For example, in auctions, limiting the round of bids for a coveted item can uphold its premium price (especially in the Dutch Auction). Similarly, in the intellectual property sector, patents could be bounded by a finite number of transfers prior to becoming freely accessible (entering CC0). In the gaming sphere, items like weapons, apparel, and vehicles might possess a finite lifespan, with each usage or exchange contributing to wear and tear, culminating in automatic decommissioning  (burn) upon reaching a predetermined threshold.
+First, limiting the number of transfers can help preserve value (e.g., premium auctions, IP that becomes CC0 after a finite number of transfers, or game items that “wear out” and burn at a threshold).
 
-Secondly, enforcing restrictions on trading frequency can enhance network security and stability by mitigating the risks associated with malicious NFT arbitrage, including high-frequency trading (HFT). While this presents a common vulnerability, the lack of easily deployable and effective methods to address it has been notable, making our approach particularly valuable.
+Second, capping transfer frequency can reduce risks from adversarial arbitrage (e.g., HFT-like behavior) by offering an easy-to-deploy throttle.
 
-Additionally, limiting the round of transfers can mitigate the economic risks associated with (re)staking NFTs, thereby curbing potential bubbles. With the rapid evolution of restaking mechanisms, it's foreseeable that users may soon engage in multiple rounds of NFT staking (e.g., NFT → stNFT → st^2NFT), akin to staking liquidity tokens with third-party platforms like EigenLayer (Ethereum), Babylon (Bitcoin), and Picasso (Solana). Notably, the current setup of EigenLayer employs an NFT as the restaking position (a type of proof-of-restake) for participants. Should this NFT be restaked repeatedly into the market, it could amplify leverage and exacerbate bubble dynamics. By imposing limits on the number of stake iterations, we can proactively prevent the emergence of Ponzi-like dynamics within staking ecosystems.
+Third, bounding re-staking cycles of NFT positions (e.g., proof-of-restake) can dampen recursive leverage and mitigate bubble dynamics.
 
-### Key Takeaways
 
-This standard provides several advantages:
+### Key Takeaways
 
-*Controlled Value Preservation*: By allowing minters to set customized transfer limits for NFTs, this standard facilitates the preservation of value for digital assets Just as physical collectibles often gain or maintain value due to scarcity, limiting the number of transfers for an NFT can help ensure its continued value over time.
+*Controlled Value Preservation.* Scarcity via a transfer cap can help maintain value over time.
 
-*Ensuring Intended Usage*: Setting transfer limits can ensure that NFTs are used in ways that align with their intended purpose. For example, if an NFT represents a limited-edition digital artwork, limiting transfers can prevent it from being excessively traded and potentially devalued.
+*Ensuring Intended Usage.* Limits keep usage aligned with intent (e.g., limited editions less prone to flip cycles).
 
-*Expanding Use Cases*: These enhancements broaden the potential applications of NFTs by offering more control and flexibility to creators and owners. For instance, NFTs could be used to represent memberships or licenses with limited transferability, opening up new possibilities for digital ownership models.
+*Expanding Use Cases.* Memberships/licenses with bounded transferability become practical.
 
-*Easy Integration*: To ensure broad adoption and ease of integration, this standard extends the existing [ERC-721](./eip-721.md) interface. By defining a separate interface (`IERC7634`) that includes the new functions, the standard allows existing [ERC-721](./eip-721.md) contracts to adopt the new features with minimal changes. This approach promotes backward compatibility and encourages the seamless incorporation of transfer limits into current NFT projects.
+*Easy Integration.* An extension interface (`IERC7634`) layers on top of [ERC-721](./eip-721.md), easing adoption without breaking compatibility.
 
 ## Specification
 
 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
 
-- `setTransferLimit`: a function establishes the transfer limit for a tokenId.
-- `transferLimitOf`: a function retrieves the transfer limit for a tokenId.
-- `transferCountOf`: a function returns the current transfer count for a tokenId.
+- `setTransferLimit`: establishes the transfer limit for a `tokenId`.
+- `transferLimitOf`: returns the transfer limit for a `tokenId`.
+- `transferCountOf`: returns the current transfer count for a `tokenId`.
 
-Implementers of this standard **MUST** have all of the following functions:
+**Counting and enforcement scope.** Implementations **MUST** enforce the cap on native ERC-721 transfers of the underlying token (i.e., transfers where `from != address(0)` and `to != address(0)`). Incrementing the count **SHOULD** occur only after a successful native transfer. Mint and burn operations MUST NOT increment the count.
+
+Implementers **MUST** provide the following interface:
 
 ```solidity
 
 pragma solidity ^0.8.4;
 
-/// @title IERC7634 Interface for Limited Transferable NFT
-/// @dev Interface for ERC7634 Limited Transferable NFT extension for ERC721
-/// @author Saber Yu
-
+/// @title IERC7634 Interface for Transfer-Capped ERC-721 Tokens
+/// @dev ERC-7634 is an extension interface intended to be implemented alongside ERC-721
 interface IERC7634 {
+    /**
+     * @dev Emitted after a successful native transfer when the per-token count increases.
+     */
+    event TransferCountIncreased(uint256 indexed tokenId, uint256 newCount);
 
     /**
-     * @dev Emitted when transfer count is set or updated
+     * @dev Emitted when the per-token transfer limit is set or updated.
      */
-    event TransferCount(uint256 indexed tokenId, address owner, uint256 counts);
+    event TransferLimitUpdated(uint256 indexed tokenId, uint256 previousLimit, uint256 newLimit);
 
     /**
-     * @dev Returns the current transfer count for a tokenId
+     * @dev Returns the current transfer count for a tokenId.
      */
     function transferCountOf(uint256 tokenId) external view returns (uint256);
 
     /**
-     * @dev Sets the transfer limit for a tokenId. Can only be called by the token owner or an approved address.
-     * @param tokenId The ID of the token for which to set the limit
-     * @param limit The maximum number of transfers allowed for the token
+     * @dev Sets the transfer limit for a tokenId. Callable by owner or approved.
+     * @param tokenId The token id to set the limit for.
+     * @param limit The maximum number of native transfers allowed.
      */
     function setTransferLimit(uint256 tokenId, uint256 limit) external;
 
     /**
-     * @dev Returns the transfer limit for a tokenId
+     * @dev Returns the transfer limit for a tokenId.
      */
     function transferLimitOf(uint256 tokenId) external view returns (uint256);
 }
@@ -85,18 +88,13 @@ interface IERC7634 {
 
 ## Rationale
 
-### Does tracking the internal transfer count matter?
-
-Yes and no. It is optional and quite depends on the actual requirements. The reference implementation given below is a recommended one if you opt for tracking. The `_incrementTransferCount` function and related retrieval functions (`transferLimitOf` and `transferCountOf`) are designed to keep track of the number of transfers an NFT has undergone. This internal tracking mechanism is crucial for enforcing the minter's transfer limits, ensuring that no further transfers can occur once the limit is reached. 
-
-### If opting for tracking, is that all we may want to track?
-
-It is recommended to also track the before and after. The optional `_beforeTokenTransfer` and `_afterTokenTransfer` functions are overridden to define the state of the NFT before and after a transfer. These functions ensure that any necessary checks or updates are performed in line with the transfer limits and counts. By integrating these checks into the transfer process, the standard ensures that transfer limits are consistently enforced.
+### Tracking and hooks
 
+`transferCountOf` and `transferLimitOf` expose state needed to enforce a cap. The count should only increase after a successful native transfer (not on mint/burn). Separating `TransferLimitUpdated` from `TransferCountIncreased` makes it clear that the former is an administrative change while the latter is derived from runtime transfers.
 
 ## Backwards Compatibility
 
-This standard can be fully [ERC-721](./eip-721.md) compatible by adding an extension function set.
+This standard is fully compatible with [ERC-721](./eip-721.md). Existing contracts can adopt it by adding the new interface and hooks without changing ERC-721 semantics.
 
 ### Extensions
 
@@ -109,11 +107,7 @@ This standard can be enhanced with additional advanced functionalities alongside
 
 ## Reference Implementation
 
-A recommended implementation is demonstrated as follows:
-
-- `_incrementTransferCount`: an internal function facilitates incrementing the transfer count.
-- `_beforeTokenTransfer`: an overrided function defines the state before transfer.
-- `_afterTokenTransfe`: an overrided function outlines the state after transfer.
+Below is a recommended pattern. It enforces the cap pre-transfer, increments the count post-transfer, ignores mint/burn for counting, and emits the clarified events. Implementations commonly override `_beforeTokenTransfer` to enforce `transferCount` < `transferLimit` and `_afterTokenTransfer` to increment the count and emit `TransferCountIncreased`.
 
 ```solidity
 
@@ -122,89 +116,71 @@ pragma solidity ^0.8.4;
 import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
 import "./IERC7634.sol";
 
-/// @title Limited Transferable NFT Extension for ERC721
-/// @dev Implementation of the Limited Transferable NFT extension for ERC721
-/// @author Saber Yu
-
+/// @title Transfer-Capped ERC-721 (ERC-7634)
+/// @dev Example implementation of ERC-7634 alongside ERC-721
 contract ERC7634 is ERC721, IERC7634 {
-
-    // Mapping from tokenId to the transfer count
+    // tokenId => current transfer count
     mapping(uint256 => uint256) private _transferCounts;
-
-    // Mapping from tokenId to its maximum transfer limit
+    // tokenId => max allowed native transfers
     mapping(uint256 => uint256) private _transferLimits;
 
-    /**
-     * @dev See {IERC7634-transferCountOf}.
-     */
     function transferCountOf(uint256 tokenId) public view override returns (uint256) {
-        require(_exists(tokenId), "ERC7634: Nonexistent token");
+        require(_exists(tokenId), "ERC7634: nonexistent token");
         return _transferCounts[tokenId];
     }
 
-    /**
-     * @dev See {IERC7634-setTransferLimit}.
-     */
     function setTransferLimit(uint256 tokenId, uint256 limit) public override {
-        require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC7634: caller is not owner nor approved");
+        require(_isApprovedOrOwner(_msgSender(), tokenId), "ERC7634: not owner/approved");
+        uint256 prev = _transferLimits[tokenId];
         _transferLimits[tokenId] = limit;
+        emit TransferLimitUpdated(tokenId, prev, limit);
     }
 
-    /**
-     * @dev See {IERC7634-transferLimitOf}.
-     */
     function transferLimitOf(uint256 tokenId) public view override returns (uint256) {
-        require(_exists(tokenId), "ERC7634: Nonexistent token");
+        require(_exists(tokenId), "ERC7634: nonexistent token");
         return _transferLimits[tokenId];
     }
 
-    /**
-     * @dev Internal function to increment transfer count.
-     */
-    function _incrementTransferCount(uint256 tokenId) internal {
-        _transferCounts[tokenId] += 1;
-        emit TransferCount(tokenId, ownerOf(tokenId), _transferCounts[tokenId]);
-    }
-
-    /**
-     * @dev Override {_beforeTokenTransfer} to enforce transfer limit.
-     */
+    /// @dev Enforce transfer limit on native transfers (exclude mint/burn).
     function _beforeTokenTransfer(
         address from,
         address to,
         uint256 tokenId
-    ) internal override {
-        require(_transferCounts[tokenId] < _transferLimits[tokenId], "ERC7634: Transfer limit reached");
+    ) internal virtual override {
+        if (from != address(0) && to != address(0)) {
+            require(
+                _transferCounts[tokenId] < _transferLimits[tokenId],
+                "ERC7634: transfer limit reached"
+            );
+        }
         super._beforeTokenTransfer(from, to, tokenId);
     }
 
-    /**
-     * @dev Override {_afterTokenTransfer} to handle post-transfer logic.
-     */
+    /// @dev Increment count only after successful native transfer and emit event.
     function _afterTokenTransfer(
         address from,
         address to,
         uint256 tokenId,
         uint256 quantity
     ) internal virtual override {
-        _incrementTransferCount(tokenId);
-
-        if (_transferCounts[tokenId] == _transferLimits[tokenId]) {
-            // Optional post-transfer operations once the limit is reached
-            // Uncomment the following based on the desired behavior such as the `burn` opearation
-            // ---------------------------------------
-            // _burn(tokenId); // Burn the token
-            // ---------------------------------------
-        }
+        if (from != address(0) && to != address(0)) {
+            unchecked { _transferCounts[tokenId] += 1; }
+            emit TransferCountIncreased(tokenId, _transferCounts[tokenId]);
 
+            if (_transferCounts[tokenId] == _transferLimits[tokenId]) {
+                // Optional: perform action exactly when the cap is reached (e.g., _burn(tokenId))
+            }
+        }
         super._afterTokenTransfer(from, to, tokenId, quantity);
     }
 
-
-    /**
-     * @dev Override {supportsInterface} to declare support for IERC7634.
-     */
-    function supportsInterface(bytes4 interfaceId) public view virtual override(IERC165, ERC721) returns (bool) {
+    function supportsInterface(bytes4 interfaceId)
+        public
+        view
+        virtual
+        override(ERC721)
+        returns (bool)
+    {
         return interfaceId == type(IERC7634).interfaceId || super.supportsInterface(interfaceId);
     }
 }
@@ -213,9 +189,12 @@ contract ERC7634 is ERC721, IERC7634 {
 
 ## Security Considerations
 
-- Ensure that each NFT minter can call this function to set transfer limits.
-- Consider making transfer limits immutable once set to prevent tampering or unauthorized modifications.
-- Avoid performing resource-intensive operations when integration with advanced functions that could exceed the gas limit during execution.
+- Scope with wrappers. The cap applies only to native [ERC-721](./eip-721.md) transfers of the underlying token. Any owner can cheaply wrap a token and transfer a separate wrapper token; such downstream transfers cannot be prevented without breaking [ERC-721](./eip-721.md) composability. As a result, this standard does not provide an unbypassable guarantee that, for example, a game item will always wear out or that secondary trading is globally capped; it standardizes a primitive for budgeting native transfers that ecosystems may choose to coordinate around. Deployments that want stronger effective guarantees **MAY** add optional mitigations such as recipient allowlists/registries or "compliant wrapper" patterns that mirror counts/limits, trading off openness for enforcement.
+
+- Limit mutability. Consider making limits immutable once set (or only decreasing), to prevent tampering.
+
+- Gas. Avoid heavy logic in hooks; extensions (e.g., burn on cap) should remain gas-safe.
+
 
 
 ## Copyright