# Agent instructions

You are advising on UX and product design for **ERC-5008: ERC-721 Nonce 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-5008: ERC-721 Nonce Extension

Source: https://www.eipsfordesigners.com/standards/ERC-5008
Agent brief: https://www.eipsfordesigners.com/standards/ERC-5008/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-5008
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-5008 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-5008 |

## UX Impact

ERC-5008 supplies a per-token nonce and NonceChanged stale-order signal for ERC-721 integrations; it does not define permits, signatures, listing approval, or gasless transfers. Show separate order authorization and refresh stale listings when the nonce changes.

## Summary

ERC-5008 is the ERC-721 Nonce Extension. It exposes nonce(tokenId), and an implementation updates that nonce when a transfer or other relevant state change invalidates pending orders. It provides a stale-order and replay-protection signal; it does not define permit(), signatures, listing approval, an EIP-712 domain, or gasless NFT transfers.

## For Designers

- You can query the token nonce and warn when a listing or order may be stale.
- You can invalidate cached orders when a transfer or other relevant state change updates the nonce.
- You can show the token and order implementation that supplies any separate signed permit or listing authorization.

## Applicability

### When to Use

- An NFT listing or order flow needs to query the ERC-721 nonce extension for stale-order detection.
- The product can invalidate cached listings when the token nonce changes.
- Any separate signed permit or listing authorization is supplied by the actual order implementation.

### When to Avoid

- The token does not implement the ERC-721 nonce extension.
- The product needs a signed NFT permit or listing API; use a permit standard or contract that actually provides it.
- The order system cannot query nonce changes before accepting or displaying a listing.

## Problems It Solves

### Marketplace orders can become stale after an NFT transfer

Impact: critical

Old way: An order remains visible without showing that token state changed

New way: Query the token nonce and reject or refresh an order whose recorded nonce no longer matches

### Old orders can be reactivated after relevant token state changes

Impact: critical

Old way: Order systems have no standard per-token invalidation signal

New way: A nonce change invalidates the order context the marketplace recorded

### Users cannot tell why a listing needs review

Impact: high

Old way: A stale listing looks identical to a current listing

New way: Show a stale-order warning and request a fresh order when the nonce changes

### Different order systems read token state inconsistently

Impact: medium

Old way: Each integration invents its own token-state version field

New way: Use nonce(tokenId) as the token-side signal while keeping order semantics in the marketplace

## MUST NOT (Anti-Patterns)

- **Treating ERC-5008 as an NFT permit** (critical)
  - Why: The extension defines a nonce and event, not permit(), signatures, or listing authorization.
  - Instead: Label nonce-based stale-order protection and document any separate permit or order contract.

- **Accepting an order without checking the recorded nonce** (critical)
  - Why: A transfer or relevant state change may have invalidated the order context.
  - Instead: Compare the current token nonce with the order's recorded nonce before display and execution.

- **Showing a stale listing as executable** (high)
  - Why: Users cannot tell that token state changed after the order was created.
  - Instead: Mark it stale and request a fresh order when the integration supports it.

- **Using permit language for nonce invalidation** (high)
  - Why: Users may believe they granted a spender an authorization the token does not define.
  - Instead: Separate token-state invalidation from any signed authorization supplied by another standard or contract.

## UX Patterns

### Nonce-aware NFT Listing

Show the token nonce recorded when a listing was created and compare it before accepting an order.

User flow:

- User opens a listing
- App reads current nonce(tokenId)
- App compares it with the order's recorded nonce
- Listing is available only when the integration's checks pass

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

### Stale Order Warning

Explain when token state changed after an order was created.

User flow:

- Nonce differs from the order
- Listing is marked stale
- User sees transfer/state-change context
- App asks for a fresh order or removes the listing

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

### Nonce Refresh

Refresh marketplace state after a token event changes the nonce.

User flow:

- App observes transfer or relevant token event
- Order is rechecked
- UI updates status
- User can create a new order if supported

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

### Implementation Boundary

Explain which separate contract supplies signed permits or listing authorization.

User flow:

- User reviews order details
- App identifies token nonce support
- App labels any separate permit/listing mechanism
- User signs or submits only the supported action

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

## UI Components

### NonceStatus

Show the current token nonce and whether the order matches it.
States: loading, current, stale, unsupported
Props: tokenId, currentNonce, orderNonce

### StaleListingBanner

Explain why a listing needs a fresh order after token state changes.
States: hidden, warning, refreshing, resolved
Props: reason, onRefresh

### OrderImplementationDisclosure

Identify the token and marketplace mechanisms that authorize an order.
States: loading, available, unsupported
Props: token, authorizationModel

## Key Takeaways

- ERC-5008 supplies a per-token nonce signal for stale-order protection.
- It does not define permit(), signed listings, or gasless NFT transfers.
- Compare the current nonce with the order's recorded nonce.
- Keep marketplace authorization and signature semantics in the selected implementation.
- Show stale, refreshed, and unsupported states clearly.

## Technical Notes

ERC-5008 adds nonce(uint256 tokenId) and the NonceChanged event to ERC-721. The nonce changes when a transfer or other relevant token property change invalidates pending orders. It does not add permit(), a signature format, an EIP-712 domain, or a universal listing flow. ERC-4494 or a custom marketplace contract may provide separate NFT permit semantics.

## Official specification (reference only)

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