# Agent instructions

You are advising on UX and product design for **ERC-5216: ERC-1155 Allowance Extension**.
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-5216: ERC-1155 Allowance Extension

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

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

## UX Impact

ERC-5216 adds per-token-ID ERC-1155 allowances. Approved amounts are consumed by the extension's safeTransferFrom and safeBatchTransferFrom paths; feature-detect the extension and show each operator's remaining scope.

## Summary

ERC-5216 brings granular allowances to ERC-1155 multi-tokens. Instead of "approve all or nothing," users can approve specific amounts per token ID. Want to let a game use 5 of your health potions but not your legendary sword? Now you can. This prevents the dangerous "setApprovalForAll" pattern and gives users fine-grained control over their multi-token collections.

## For Designers

- You can design UI that delivers approve exactly 10 health potions, nothing else, using the extension's per-token allowance.
- You can design UI that delivers set allowance to specific amount (e.g., max 50 tokens).
- You can design UI that delivers approve only the tokens you intend to trade.
- Default to exact amount needed, let user increase if wanted.
- Always use granular allowances if ERC-5216 is supported.
- Show "8/10 potions remaining" after 2 are used.

## Applicability

### When to Use

- Your product addresses: eRC-1155 only offers all-or-nothing approval.
- Your product addresses: no way to limit how many tokens can be spent.
- The flow should deliver: approve exactly 10 health potions, nothing else.
- You are designing a granular approval selector experience with visible states and recovery paths.

### When to Avoid

- The collection does not implement the ERC-5216 allowance extension.
- The operation needs ERC-20 transferFrom semantics; ERC-1155 uses safeTransferFrom or safeBatchTransferFrom.
- The product cannot show per-token remaining allowance or a fallback to setApprovalForAll.

## Problems It Solves

### ERC-1155 only offers all-or-nothing approval

Impact: critical

Old way: setApprovalForAll gives access to EVERY token in the collection

New way: Approve an exact quantity for a token ID, then consume it through safeTransferFrom or safeBatchTransferFrom

### No way to limit how many tokens can be spent

Impact: critical

Old way: Operator can transfer unlimited quantity once approved

New way: Set allowance to specific amount (e.g., max 50 tokens)

### Users must trust platforms with entire collection

Impact: high

Old way: Marketplace approval = access to all game items

New way: Approve only the tokens you intend to trade

### Revoking requires removing all access

Impact: medium

Old way: Can only toggle full collection access on/off

New way: Reduce allowance for specific token IDs independently

### No transparency on what's actually approved

Impact: medium

Old way: "This site has access to your collection" - but which tokens?

New way: Clear list: "5 potions, 2 scrolls approved"

## MUST NOT (Anti-Patterns)

- **Defaulting to max allowance for convenience** (critical)
  - Why: Defeats the security purpose of granular allowances
  - Instead: Default to exact amount needed, let user increase if wanted

- **Falling back to setApprovalForAll when available** (critical)
  - Why: Users expect granular control when they see the UI
  - Instead: Always use granular allowances if ERC-5216 is supported

- **Not showing remaining allowance after partial use** (high)
  - Why: Users don't know how much the operator can still spend
  - Instead: Show "8/10 potions remaining" after 2 are used

- **Bundling all tokens into one approval prompt** (high)
  - Why: Users can't see or control individual token allowances
  - Instead: Itemized list with per-token amount controls

- **No indication when contract doesn't support 5216** (medium)
  - Why: User may think they have granular control when they don't
  - Instead: Clear warning: "This collection only supports all-or-nothing approval"

## UX Patterns

### Granular Approval Selector

Let users choose exactly how many of each token to approve

User flow:

- dApp requests token approval
- UI shows all tokens user owns
- User sets specific amounts per token
- Summary shows total approved
- Single transaction sets all allowances

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

### Approval Dashboard

View and manage all active allowances

User flow:

- User opens approval dashboard
- Sees all operators with allowances
- Expands to see per-token breakdown
- Can edit amounts or revoke per operator
- Changes reflected immediately

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

### Trade Flow with Exact Approval

Approve only what's needed for this trade

User flow:

- User selects items to sell
- UI calculates exact approvals needed
- Shows clear list of what will be approved
- Single click approves exact amounts
- Listing created with precise allowances

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

### Allowance Increase Request

Handle when more allowance is needed mid-action

User flow:

- User attempts action requiring more allowance
- UI shows current vs required
- Offers sensible preset amounts
- User picks or enters custom amount
- Allowance increased, action proceeds

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

## UI Components

### TokenAllowanceInput

Input for setting allowance per token ID
States: empty, valid, exceeds-balance, max
Props: tokenId, balance, currentAllowance, onChange

### AllowanceProgressBar

Shows used vs remaining allowance
States: full, partial, depleted
Props: used, total, tokenSymbol

### BatchAllowanceEditor

Edit multiple token allowances at once
States: viewing, editing, saving, saved
Props: operator, allowances[], onSave, onCancel

### ApprovalComparisonCard

Compare old (all-or-nothing) vs new (granular) approach
States: showing-old, showing-new, comparing
Props: collection, requestedTokens

## Key Takeaways

- ERC-5216 = ERC-20 style allowances for ERC-1155
- Default to exact amounts needed, not max
- Show remaining allowance after partial use
- Clearly indicate when collection doesn't support granular approvals

## Technical Notes

ERC-5216 adds allowance(owner, operator, tokenId) and approve(operator, tokenId, amount) to ERC-1155. The approved amount is consumed by safeTransferFrom and safeBatchTransferFrom according to the extension; it does not add ERC-20 transferFrom. Operators must be approved for each token ID they transfer.

## Official specification (reference only)

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