ERC-7634: Limited Transfer Count NFT

Abstract

This standard extends ERC-721 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 and can be perpetually transferred. Yet many situations require tighter control over secondary movement.

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).

Second, capping transfer frequency can reduce risks from adversarial arbitrage (e.g., HFT-like behavior) by offering an easy-to-deploy throttle.

Third, bounding re-staking cycles of NFT positions (e.g., proof-of-restake) can dampen recursive leverage and mitigate bubble dynamics.

Key Takeaways

Controlled Value Preservation. Scarcity via a transfer cap can help maintain value over time.

Ensuring Intended Usage. Limits keep usage aligned with intent (e.g., limited editions less prone to flip cycles).

Expanding Use Cases. Memberships/licenses with bounded transferability become practical.

Easy Integration. An extension interface (IERC7634) layers on top of ERC-721, 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: establishes the transfer limit for a tokenId.
• transferLimitOf: returns the transfer limit for a tokenId.
• transferCountOf: returns the current transfer count for a tokenId.

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:

Rationale

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 is fully compatible with ERC-721. Existing contracts can adopt it by adding the new interface and hooks without changing ERC-721 semantics.

Extensions

This standard can be enhanced with additional advanced functionalities alongside existing NFT protocols. For example:

• Incorporating a burn function (e.g., ERC-5679) would enable NFTs to automatically expire after reaching their transfer limits, akin to the ephemeral nature of Snapchat messages that disappear after multiple views.

• Incorporating a non-transferring function, as defined in the SBT standards, would enable NFTs to settle and bond with a single owner after a predetermined number of transactions. This functionality mirrors the scenario where a bidder ultimately secures a treasury after participating in multiple bidding rounds.

Reference Implementation

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.

Security Considerations

• Scope with wrappers. The cap applies only to native ERC-721 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 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

Copyright and related rights waived via CC0.