# Agent instructions

You are advising on UX and product design for **ERC-5496: Multi-privilege Management 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-5496: Multi-privilege Management NFT

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

| Field | Value |
| --- | --- |
| Status | Last Call |
| Chain | both |
| Category | Security & Trust |
| Journey stages | Approving & Permissioning |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-5496 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-5496 |

## UX Impact

ERC-5496 adds per-user NFT privileges queried with hasPrivilege(tokenId, privilegeId, user) and provider-defined expiry. Assignment/revocation rules and optional clonePrivilege support are implementation-specific; separate privilege holder from owner.

## Summary

ERC-5496 extends ERC-721 with multiple privileges that can be assigned to users and checked independently of NFT ownership. A privilege has a provider-defined expiry through privilegeExpires, and an optional cloneable extension can copy a privilege; implementations decide assignment authority and the practical access policy.

## For Designers

- You can show one NFT's separate privilege slots and their current holders.
- You can grant a privilege to a user without transferring the NFT when the implementation authorizes it.
- You can call hasPrivilege(tokenId, privilegeId, user) and show privilegeExpires for the selected user.

## Applicability

### When to Use

- An NFT needs separate privilege assignments for named users with queryable expiry.
- The product can check hasPrivilege(tokenId, privilegeId, user) for the actual user.
- Clone controls are shown only when the optional IERC721Cloneable interface is supported.

### When to Avoid

- The NFT does not implement the privilege interface or the target user/privilege lookup.
- The product needs expiry or cloning guarantees the deployed implementation does not provide.
- The UI cannot distinguish token owner from privilege holder.

## Problems It Solves

### NFTs represent only single permissions

Impact: critical

Old way: Need separate NFTs for VIP access, parking, and merch discount

New way: One NFT can expose multiple privilege slots with separate users and expiry timestamps

### Can't grant temporary access without full transfer

Impact: high

Old way: Lend entire NFT (and all privileges) or nothing

New way: The access check can ask hasPrivilege(tokenId, privilegeId, user) for a specific user

### No standard way to check multiple perks

Impact: high

Old way: Custom logic per project to track entitlements

New way: A product can show privilege holder and NFT owner as separate roles

### Privileges can't expire independently

Impact: medium

Old way: Whole NFT valid or invalid, no per-perk expiry

New way: The product can query privilegeExpires and display the deployed implementation's expiry rules

### Hard to revoke specific access without burning NFT

Impact: medium

Old way: Must issue new NFT with reduced privileges

New way: When the optional cloneable extension is supported, a privilege can be copied through clonePrivilege; reassignment or revocation remains implementation-specific

## MUST NOT (Anti-Patterns)

- **Not showing which privileges are delegated vs owned** (critical)
  - Why: Users confused about what they can actually use vs lend
  - Instead: Call hasPrivilege(tokenId, privilegeId, user) for the actual user and display privilegeExpires separately.

- **Allowing privilege use after expiry without clear error** (high)
  - Why: Frustrating when access fails at the gate
  - Instead: Explain expiry as a timestamp read from the deployed contract; do not assume one universal duration or automatic renewal.

- **No revocation UI for delegated privileges** (high)
  - Why: Users can't retract access they granted
  - Instead: Show the implementation-supported reassignment or revoke action; offer clonePrivilege only when IERC721Cloneable is advertised.

- **Bundling all privileges into one indistinguishable token** (medium)
  - Why: Users can't see or manage individual perks
  - Instead: Itemized privilege list with individual management

- **Not showing remaining uses for consumable privileges** (medium)
  - Why: User doesn't know if they have uses left
  - Instead: Show "2/5 uses remaining" for limited privileges

## UX Patterns

### Multi-Privilege NFT Card

Display all privileges on a single NFT

User flow:

- User opens a privilege-bearing NFT
- App reads privilegeIds and current assignment
- App checks hasPrivilege(tokenId, privilegeId, user) for the connected user
- Shows privilege holder, NFT owner, and privilegeExpires separately

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

### Privilege Delegation

Show the privilege holder, expiry timestamp, and action scope for the selected user.

User flow:

- User selects NFT to share from
- Picks specific privilege to delegate
- Enters recipient address
- Sets duration/expiry for delegation
- Confirms transaction
- Recipient gains privilege access

Mockup registry key: `generic/vault-deposit` (React UI on the live standard page).

### Privilege Verification Gate

Offer privilege sharing only when the deployed contract supports setPrivilege or the optional cloneable extension.

User flow:

- Gate displays required privilege
- User scans QR or connects wallet
- System checks hasPrivilege()
- Verifies not expired
- Shows if direct ownership or delegated
- Grants or denies access

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

### Privilege Management Dashboard

Show assignment and optional clone controls; expose revocation only when the deployed implementation supports it.

User flow:

- User opens privilege manager
- Sees outgoing and received assignments
- App shows any implementation-supported reassignment or revoke action
- Clone controls appear only when clonePrivilege is supported
- App refreshes hasPrivilege and privilegeExpires

Mockup registry key: `generic/token-transfer` (React UI on the live standard page).

## UI Components

### PrivilegeBadge

Visual indicator for a single privilege status
States: active, expiring-soon, expired, used, delegated
Props: privilegeId, name, expiresAt, isDelegated

### PrivilegeTimeline

Visual timeline of privilege validity
States: before, active, ended
Props: startDate, endDate, privilegeName

### DelegationCard

Shows assignment details and a revoke/reassignment action only when the implementation exposes one.
States: active, expiring, revoked
Props: privilege, delegatee, expiresAt, onRevoke

### PrivilegeVerifier

Real-time privilege checking component
States: checking, verified, denied, expired
Props: tokenId, privilegeId, address

## Key Takeaways

- ERC-5496 attaches multiple user privileges to an NFT.
- hasPrivilege requires tokenId, privilegeId, and user.
- Read privilegeExpires and the deployed assignment rules; expiry is not a universal product promise.
- Treat cloning as an optional extension and capability-gate its UI.
- Keep NFT ownership and privilege holding visibly separate.

## Technical Notes

ERC-5496 defines setPrivilege(tokenId, privilegeId, user, expires), privilegeExpires(tokenId, privilegeId), and hasPrivilege(tokenId, privilegeId, user). The specification recommends a maximum privilege number and says expires should be less than 30 days in the base interface guidance. IERC721Cloneable and clonePrivilege(tokenId, privilegeId, referrer) are optional.

## Official specification (reference only)

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