# Agent instructions

You are advising on UX and product design for **ERC-2535: Diamonds, Multi-Facet Proxy**.
This document is the authoritative designer guide from EIPs for Designers.

- Treat **MUST NOT** items as hard constraints unless the user explicitly overrides.
- Use the **Vocabulary** section for UI copy; do not use avoided terms.
- Cite the canonical source URL when giving recommendations.
- Use the official specification only for protocol implementation detail, not as primary UX guidance.

---

# ERC-2535: Diamonds, Multi-Facet Proxy

Source: https://www.eipsfordesigners.com/standards/ERC-2535
Agent brief: https://www.eipsfordesigners.com/standards/ERC-2535/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-2535
Last reviewed: 2026-05-25
Last updated: 2026-05-25

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Infrastructure |
| Journey stages | Infrastructure |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/erc-2535 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-2535 |

## UX Impact

Diamond contracts can have unlimited functionality via multiple facets, all at one address. Design implications: show facet breakdown in contract explorers (which functions come from which facet), display upgrade history per-facet, indicate 'Diamond Contract' with expandable facet list. Design decisions: how to present complex multi-facet contracts without overwhelming users; balance between showing full architecture (power users) and simplified 'single contract' view (regular users).

## Summary

Diamond contracts can have unlimited functionality via multiple facets, all at one address.

## For Designers

- You can badge Diamond contract on address pages with optional View facets expand.
- Your default send flow treats diamond like any address — complexity only in advanced explorer.
- You can show per-facet upgrade history for auditors without showing it on every confirm screen.

## Applicability

### When to Use

- Contract explorer or developer tools display proxy diamonds.
- Users interact with known diamond deployments.
- Upgrade transparency is product value.

### When to Avoid

- End-user retail flows with no inspect need.
- Plain non-diamond contracts.
- Cannot resolve facet selector mapping.

## Problems It Solves

### Contract size limit blocks features

Impact: high

Old way: Deploy new address each upgrade

New way: Diamond adds facets same address

### Users confused by changing bytecode same address

Impact: medium

Old way: Looks like same contract different behavior

New way: Upgrade history explains facet changes

### Auditors cannot map functions to code

Impact: medium

Old way: Opaque proxy

New way: Facet breakdown panel

## MUST NOT (Anti-Patterns)

- **Facet list on every wallet confirm** (high)
  - Why: Overwhelms non-technical users
  - Instead: Facets only in contract explorer advanced

- **No upgrade history on diamond** (medium)
  - Why: Same address different behavior surprises
  - Instead: Upgrade timeline on contract page

- **Raw selector hex in default view** (medium)
  - Why: Meaningless to users
  - Instead: Function names grouped by facet

## Design Decisions

### Show facets on wallet confirm?

Recommendation: No — address and human summary only.

Rationale: Facets are auditor detail not consent detail.

### Diamond badge everywhere?

Recommendation: Explorer and contract pages only.

Rationale: Badge on send form adds noise.

### Facet naming?

Recommendation: Human labels from manifest; addresses in advanced.

Rationale: 0x facet addresses meaningless.

## States to Design

### Simple contract view

Trigger: Default user path.

User need: Send/interact normally.

Design response: No facet UI on confirm.

### Facets expanded

Trigger: User taps View facets.

User need: Audit architecture.

Design response: Facet list with function groups.

### Recent upgrade

Trigger: Facet changed.

User need: Know behavior may differ.

Design response: Recently upgraded banner on explorer.

### Unknown selector

Trigger: Function not in known facet map.

User need: Not broken UI.

Design response: Unknown function — check latest facet map.

### Developer upgrade sim

Trigger: Simulating facet add.

User need: Clear diff.

Design response: Before/after facet table.

## Vocabulary

- Use "Multi-part contract" instead of "Diamond proxy facets": Simpler architecture hint.

- Use "View components" instead of "List facets": Explorer action language.

- Use "Recently updated" instead of "Facet replaced via diamondCut": Plain upgrade notice.

## UX Patterns

### Diamond Facet Explorer

Expandable facet list on contract page.

Components: DiamondBadge, FacetList, UpgradeTimeline

User flow:

- Open contract
- See diamond badge
- Expand facets
- Inspect functions

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

### Simple Send to Diamond

Standard confirm without facet noise.

Components: AddressChip, ActionSummary, AdvancedToggle

User flow:

- Send to diamond
- Human summary
- Confirm
- Success

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

## What to Prototype First

### Diamond address overview

Default view for regular users stays simple.

Covers: Simple mode, Power expand

- Single address chip
- Diamond badge
- Expand facets link

### Facet breakdown panel

Power users audit which code runs.

Covers: Multiple facets, Single facet

- Facet name rows
- Function count
- Facet address copy

### Upgrade history timeline

Track facet adds and replacements.

Covers: Recent upgrade, Empty history

- Timeline
- Facet affected
- Tx link

### Send to diamond confirm

Confirm stays human — no facet dump.

Covers: Standard send

- Human action summary
- Contract address
- Facets in advanced only

## Mental Model

### Diamond address

One URL users save — never changes across upgrades.

### Facet

Module holding subset of functions.

### Selector routing

Function call hits correct facet — invisible to user.

### Upgrade

Facet swap changes behavior without new address.

### Simple vs power view

Retail default simple; auditors expand facets.

## Seen in the Wild

- Etherscan: Proxy and implementation contract display patterns. (https://etherscan.io/)

- OpenZeppelin: Diamond pattern documentation for developers. (https://www.openzeppelin.com/)

- Louper: Diamond facet explorer reference UI. (https://louper.dev/)

## On Monad

### Diamond deployments

Ethereum: Same UX patterns apply

Monad: Facet upgrades same address on Monad

Design implication: Support diamond badge in Monad explorers.

### Upgrade tx cost

Ethereum: Facet cuts costly

Monad: Cheaper upgrades enable iterative facet releases

Design implication: Show upgrade history more frequently on Monad.

## Related Standards

- EIP-1967: Proxy storage slot standard — https://www.eipsfordesigners.com/standards/EIP-1967/agent.md

- EIP-1167: Minimal proxy alternative — https://www.eipsfordesigners.com/standards/EIP-1167/agent.md

## Technical Notes

ERC-2535 diamonds: simple default UX for send; facet breakdown for explorers only.

## Official specification (reference only)

https://eips.ethereum.org/EIPS/erc-2535