# Agent instructions

You are advising on UX and product design for **ERC-7634: Limited Transfer Count NFT**.
This document is editorial design guidance from EIPs for Designers. Official specifications control protocol facts.

- Treat **MUST NOT** items as editorial guardrails. Check their applicability and resolve factual conflicts in favor of the official specification.
- Use the **Vocabulary** section for UI copy; do not use avoided terms.
- Cite the canonical source URL when giving recommendations.
- Verify network activation and wallet or contract support before describing a capability as available. Specification status alone does not establish deployment.

---

# ERC-7634: Limited Transfer Count NFT

Source: https://www.eipsfordesigners.com/standards/ERC-7634
Agent brief: https://www.eipsfordesigners.com/standards/ERC-7634/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-7634
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | NFT Capabilities |
| Journey stages | Asset Management |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-7634 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-7634 |

## UX Impact

NFTs can cap native ERC-721 transfers. Design implications: show count and limit, warn before the final native transfer, and disclose the implementation-defined post-cap state; mint, burn, and wrapper transfers are outside the standardized count.

## Summary

NFTs can have a maximum count for native ERC-721 transfers. After the cap is reached, the implementation chooses the resulting state; locking, burning, or another action is not mandated by ERC-7634.

## For Designers

- You can show Transfers remaining: 2 of 5 on listing and detail before purchase.
- Your send confirmation can warn This is the last transfer when one remains.
- You can badge the configured post-cap state, including Transfer exhausted where the implementation blocks further native transfers.

## Applicability

### When to Use

- Collectibles intentionally scarce in secondary circulation.
- Artist policy limits flips.
- A deployed token implements the transfer-cap extension.

### When to Avoid

- Standard freely tradable NFTs.
- Cap not enforced on-chain.
- Users expect infinite liquidity.

## Problems It Solves

### Buyers unaware of remaining liquidity

Impact: high

Old way: Discover cannot resell after buy

New way: Transfers remaining on listing

### Accidental final transfer

Impact: high

Old way: Send then the configured post-cap outcome surprises the holder

New way: Last transfer warning modal

### Unlimited flipping undermines artist intent

Impact: medium

Old way: No transfer limits

New way: On-chain cap enforces the configured number of native ERC-721 transfers

## MUST NOT (Anti-Patterns)

- **Hiding transfer cap until send fails** (critical)
  - Why: Surprise lock destroys trust
  - Instead: Counter visible at purchase and send

- **Last transfer without extra confirm** (critical)
  - Why: Irreversible user error
  - Instead: Acknowledgment modal for final transfer

- **Same UI for exhausted and soulbound** (medium)
  - Why: Different implications confused
  - Instead: Transfer exhausted vs Non-transferable labels

## Design Decisions

### How alarming is last transfer?

Recommendation: Require checkbox acknowledgment in modal.

Rationale: Accidental final transfer is irreversible regret.

### Show counter on thumbnail?

Recommendation: Yes when ≤2 remain; always on detail.

Rationale: Scarcity affects price — surface early.

### Exhausted visual treatment?

Recommendation: Distinct badge, not hidden — collectors may still display.

Rationale: Proof of permanent collection piece.

## States to Design

### Full transfer budget

Trigger: New mint, all transfers available.

User need: Know policy exists.

Design response: Up to N transfers badge on detail.

### Low remaining

Trigger: 1-2 transfers left.

User need: Factor into sell/buy decision.

Design response: Amber counter on card and listing.

### Last transfer confirmation

Trigger: User sends with 1 left.

User need: Explicit consent.

Design response: Modal with irreversible warning.

### Transfer exhausted

Trigger: The native transfer count reaches the configured limit.

User need: Know what the configured cap outcome means.

Design response: Show the post-cap state and hide Send only when native transfers are blocked.

### Burned on exhaust

Trigger: Token burned after final transfer.

User need: Extreme warning before last send.

Design response: Show the configured post-cap outcome; warn that burn or another state applies only if the implementation defines it.

## Vocabulary

- Use "2 transfers left" instead of "Transfer count decrement remaining": Game-life metaphor.

- Use "Final transfer" instead of "Last allowed transfer before the configured post-cap outcome": Short warning label.

- Use "Cannot move again" instead of "Transfer budget exhausted": Plain permanence language.

## UX Patterns

### Transfer Budget Counter

Remaining transfers on card and detail.

Components: TransferCounter, WarningChip, PolicyTooltip

User flow:

- View NFT
- See 2 of 5
- Decide to buy
- Counter updates on transfer

Mockup registry key: `concept/nft-gallery` (React UI on the live standard page).

### Last Transfer Gate

Confirmation when one transfer remains.

Components: LastTransferModal, AckCheckbox, ConfirmSend

User flow:

- User sends
- One left detected
- Modal warns
- User acknowledges
- Transfer proceeds

Mockup registry key: `concept/verify-safety` (React UI on the live standard page).

## What to Prototype First

### Listing with transfer counter

Secondary buyers price scarcity of remaining transfers.

Covers: 5 of 5, 1 remaining, Exhausted

- Counter chip
- Tooltip explaining cap
- Price context

### Last transfer warning

Final move needs explicit consent.

Covers: Last transfer confirm

- Scary warning modal
- After this, the configured post-cap outcome applies
- Confirm checkbox

### Exhausted token view

Permanent hold state needs distinct treatment.

Covers: Transfer exhausted

- Exhausted badge
- Transfer history count
- No Send button

### Primary mint disclosure

First buyers accept transfer policy.

Covers: Policy at mint

- Max transfers stated
- Acknowledge checkbox

## Mental Model

### Transfer budget

Finite number of allowed moves — like lives in a game.

### Decrement on transfer

Each successful send reduces remaining count.

### Exhausted state

Zero native transfers remaining — show the implementation-defined post-cap state.

### Primary vs secondary

Mint may start count at max; secondary sees what's left.

### Burn on exhaust

Some implementations destroy token — must disclose upfront.

## Seen in the Wild

- Art Blocks: Artist policy on secondary markets informs transfer limit UX. (https://www.artblocks.io/)

- Foundation: Creator royalties and transfer policy display patterns. (https://foundation.app/)

- Zora: Creator-centric metadata for collection rules. (https://zora.co/)

## Related Standards

- ERC-6454: Transfer restriction detection — https://www.eipsfordesigners.com/standards/ERC-6454/agent.md

- ERC-721: NFT with transfer cap extension — https://www.eipsfordesigners.com/standards/ERC-721/agent.md

## Technical Notes

ERC-7634 standardizes transferLimitOf(), transferCountOf(), and setTransferLimit() for native ERC-721 transfers where from and to are both non-zero. Mint and burn do not increment the count. The standard does not mandate a lock or burn when the cap is reached, and wrappers can move separate wrapper assets outside the native cap; disclose the target implementation's configured outcome and scope.

## Official specification (reference only)

https://ercs.ethereum.org/ERCS/erc-7634