# Agent instructions

You are advising on UX and product design for **EIP-1014: Skinny CREATE2**.
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.

---

# EIP-1014: Skinny CREATE2

Source: https://www.eipsfordesigners.com/standards/EIP-1014
Agent brief: https://www.eipsfordesigners.com/standards/EIP-1014/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-1014
Last reviewed: 2026-04-05
Last updated: 2026-04-05

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

## UX Impact

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.

## Summary

EIP-1014 introduced CREATE2, allowing contracts to be deployed to predictable addresses. Instead of addresses depending on the deployer's nonce, CREATE2 uses a formula: address = hash(deployer, salt, bytecode). This means you can know an address before the contract exists, enabling counterfactual wallets, gasless onboarding, and trustless contract deployments.

## For Designers

- You can address is deterministic: same inputs = same address always.
- You can design UI that delivers share future wallet address.
- You can design UI that delivers same CREATE2 params = same address on every EVM chain.

## Applicability

### When to Use

- Your product addresses: contract addresses were unpredictable.
- Your users needed deployed wallet before receiving funds.
- The flow should deliver: address is deterministic: same inputs = same address always.
- Connect flows must list wallets with names, icons, and explicit user choice.

### When to Avoid

- Clear messaging: "Address reserved, wallet deploys on first use".
- Show "Deployed ✓" or "Not deployed, will deploy on first tx".
- Use CREATE2 for consistent cross-chain addresses when possible.
- Protocol plumbing is invisible and never surfaces in user-facing UI.

## Problems It Solves

### Contract addresses were unpredictable

Impact: critical

Old way: Address depends on deployer nonce, changes if any tx happens first

New way: Address is deterministic: same inputs = same address always

### Users needed deployed wallet before receiving funds

Impact: critical

Old way: Deploy wallet first, then share address, then receive funds

New way: Share future wallet address, receive funds, deploy later

### Cross-chain address consistency was impossible

Impact: high

Old way: Same wallet had different addresses on each chain

New way: Same CREATE2 params = same address on every EVM chain

### Factory contracts couldn't guarantee addresses

Impact: high

Old way: User deploys, gets whatever address results

New way: User knows exact address before deployment

## MUST NOT (Anti-Patterns)

- **Not explaining counterfactual addresses** (high)
  - Why: Users confused why address exists but wallet doesn't
  - Instead: Clear messaging: "Address reserved, wallet deploys on first use"

- **Hiding deployment status** (high)
  - Why: Users don't know if they can transact yet
  - Instead: Show "Deployed ✓" or "Not deployed - will deploy on first tx"

- **Showing different addresses per chain for same wallet** (medium)
  - Why: Users think they have multiple wallets, send to wrong address
  - Instead: Use CREATE2 for consistent cross-chain addresses when possible

- **Requiring deployment before showing address** (medium)
  - Why: Adds friction, costs gas before user even receives funds
  - Instead: Show CREATE2 address immediately, deploy lazily

## UX Patterns

### Counterfactual Wallet Setup

Show user their wallet address before deployment

User flow:

- User starts wallet creation
- CREATE2 address calculated immediately
- Address shown before any transaction
- User can receive funds right away
- Wallet deploys on first outgoing tx

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

### Same Address Everywhere

Show consistent address across chains

User flow:

- User views their universal address
- See deployment status per chain
- Same address shown for all chains
- Can deploy to new chains on demand
- Receive funds on any chain with same address

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

### Pre-Deployment Fund Receipt

Receive and display funds before wallet deployment

User flow:

- Funds sent to CREATE2 address
- User notified of incoming funds
- Balance shown even without deployment
- Clear explanation funds are safe
- Option to deploy and access immediately

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

## UI Components

### PredictedAddressDisplay

Shows address that will be created via CREATE2
States: calculated, deployed, has-balance
Props: address, isDeployed, balance, onCopy

### DeploymentStatusBadge

Shows whether address is deployed or counterfactual
States: not-deployed, deploying, deployed
Props: isDeployed, chainId, deployedAt

### CrossChainAddressView

Shows same address with deployment status per chain
States: loading, loaded, error
Props: address, chains[], deploymentStatus{}

## On Monad

### Fast Deployment

Ethereum: Deployment transaction takes 12+ seconds

Monad: Sub-second deployment confirmation

Design implication: Deployment feels instant, can happen transparently on first tx

### Same Address on Monad

Ethereum: CREATE2 gives same address on all EVM chains

Monad: Works identically, same address available on Monad

Design implication: Emphasize "same address on Monad" for cross-chain users

### Deployment Cost

Ethereum: Deployment can be expensive ($50+ in high gas)

Monad: Much cheaper deployment costs

Design implication: Can be more aggressive about deploying rather than counterfactual

## Related Standards

- ERC-4337: Account abstraction uses CREATE2 for counterfactual wallet addresses — https://www.eipsfordesigners.com/standards/ERC-4337/agent.md

- EIP-1167: Minimal proxies often deployed via CREATE2 for deterministic addresses — https://www.eipsfordesigners.com/standards/EIP-1167/agent.md

- EIP-5202: Blueprint contracts use CREATE2 for efficient contract deployment — https://www.eipsfordesigners.com/standards/EIP-5202/agent.md

- EIP-7702: Smart wallet features work with CREATE2-deployed wallets — https://www.eipsfordesigners.com/standards/EIP-7702/agent.md

## Official specification (reference only)

https://eips.ethereum.org/EIPS/eip-1014