diamond pattern (EIP-2535)

The diamond pattern is a proxy that delegates not to one implementation but to many. Picture a central hub — the diamond — surrounded by interchangeable facets, each a separate contract supplying some of the system's functions. The hub looks up which facet owns each incoming function and delegatecalls it. To callers it presents a single address with one large, unified interface.

Mechanically (EIP-2535), the diamond stores a mapping from each 4-byte function selector to the facet address that implements it. Its fallback reads the selector, finds the matching facet, and DELEGATECALLs into it, so the facet's code runs against the diamond's shared storage. A standard function, diamondCut, adds, replaces, or removes selector-to-facet mappings and emits a standard event, keeping the full interface introspectable through 'loupe' functions. The headline benefit is sidestepping the 24,576-byte EIP-170 contract-size limit by spreading code across as many facets as you like.

The cost is genuine complexity. Because all facets share one storage space, you must manage layout with great discipline — the Diamond Storage and AppStorage conventions place each module's variables at a fixed, namespaced struct slot to avoid collisions, since a naive shared layout would let one facet clobber another's state. The extra indirection and storage discipline make diamonds harder to reason about and audit than a single implementation, so they pay off mainly for very large, modular systems (a sprawling game or protocol) rather than ordinary contracts, where transparent or UUPS proxies are simpler and safer.