Infrastructure

Skinny CREATE2

Contract addresses are predictable before deployment — enables 'pay to future address' patterns. Design implications: show users their contract address upfront during deployment flows, enable deposit UIs for addresses that don't exist yet, support counterfactual wallet onboarding where users can receive funds before activating their wallet. Design decisions: balance showing predictable addresses (builds trust) vs. complexity of explaining 'this address exists but has no code yet'. Multi-Chain Checklist recommends CREATE2 at Medium priority for consistent addresses across L2s ('one address everywhere'). Cross-chain address consistency is a designer-facing decision — users expect the same address on every network.

Category: Infrastructure

Minimal Proxy Contract

Many contracts share identical code via lightweight clones — same interface, different addresses. Design implications: when displaying contract info, detect clones and show the 'master' contract's verified source/audit status, group clone contracts in portfolio views, indicate 'Clone of [verified contract]' badges. Design decisions: whether to surface clone relationships prominently (transparency) or hide complexity (simplicity); how to handle trust signals when master contract upgrades.

Category: Infrastructure

Proxy Storage Slots

Proxy contracts have standardized slots revealing implementation address and admin — enables reliable upgrade detection. Design implications: show 'Upgradeable' badges on proxy contracts, display both proxy and implementation addresses in contract details, alert users when implementation changes, show admin address for governance transparency. Design decisions: how prominently to warn about upgradeability risks vs. normalizing the pattern; whether to show upgrade history timeline.

Category: Infrastructure

Diamonds, Multi-Facet Proxy

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).

Category: Infrastructure

Blueprint Contract Format

Blueprint contracts store deployment code on-chain but cannot be called directly — they're templates. Design implications: mark blueprint contracts distinctly in explorers ('Blueprint - Not Callable'), prevent interaction UI from rendering for blueprints, show 'deployed from blueprint' lineage for contracts. Design decisions: whether to hide blueprints from regular contract lists (cleaner) or show them with clear non-interactive status (complete).

Category: Infrastructure

Namespaced Storage Layout

Storage is organized into named namespaces preventing upgrade collisions — enables safer contract evolution. Design implications: in developer tools, show storage namespace annotations, display namespace IDs in storage explorers, indicate namespace-safe upgrades. Design decisions: mostly invisible to end users but critical for developer UX; surface namespace conflicts as clear errors during upgrade simulations rather than cryptic storage collision warnings.

Category: Infrastructure