# ERC-1167: Minimal Proxy Contract

Source: https://www.eipsfordesigners.com/standards/ERC-1167
Agent brief: https://www.eipsfordesigners.com/standards/ERC-1167/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-1167
Last reviewed: 2026-09-18
Last updated: 2026-09-18

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

## UX Impact

Minimal clones delegate to a fixed implementation address encoded in their bytecode. Show the clone address, shared implementation and the evidence behind any source or audit label. This is not an upgradeable-proxy mechanism; do not offer an implementation-upgrade flow or infer safety from the shared code alone.

## Summary

ERC-1167 defines minimal clones that delegate calls to a fixed implementation address. Many instances can share code while keeping separate storage. The small runtime can reduce deployment gas, but the actual fee and confirmation time depend on the factory, initialization and network.

## For Designers

- Show a current estimate for deploying the clone and initializing its state.
- You can design UI that delivers clone factory creates instances cheaply.
- You can each user gets their own contract cheaply in the interface.

## Applicability

### When to Use

- A product uses minimal clones with a fixed implementation target.
- Users or operators need to inspect the clone address and its shared implementation.

### When to Avoid

- The product requires changing the clone’s embedded delegation target.
- You are presenting an upgradeable-proxy lifecycle as a property of a minimal clone.

## Problems It Solves

### Deploying contracts is expensive

Impact: critical

Old way: Deploy the full implementation bytecode for each instance

New way: Deploy a small clone runtime plus the required initialization

### Factory patterns cost too much

Impact: critical

Old way: Each user's vault/collection is full deployment

New way: Clone factory creates instances cheaply

### Can't afford per-user contracts

Impact: high

Old way: Share one contract, complex accounting

New way: Each user gets their own contract cheaply

### Code duplication on chain

Impact: medium

Old way: Same bytecode stored thousands of times

New way: One implementation, many proxies

## Anti-Patterns

### Hiding that contract is a proxy

Severity: high

Users deserve to know how their contract works

Instead: Show "Powered by [Implementation]" with link

### Not linking to verified implementation

Severity: high

User can't verify the code their proxy uses

Instead: Always link to implementation on block explorer

### Confusing proxy address with implementation

Severity: medium

User looks up wrong address, sees weird bytecode

Instead: Clearly label "Your contract" vs "Implementation"

### Not explaining gas savings

Severity: medium

User doesn't understand the value they're getting

Instead: Show estimated savings only from a current like-for-like gas comparison

### Using clones for upgradeable contracts

Severity: medium

ERC-1167 clones are immutable, confuses with upgradeable

Instead: Clarify: "Your clone points to fixed implementation"

## UI Components

### CloneDeployer

Form for creating new clone instance
States: configuring, deploying, deployed, error
Props: factoryAddress, initParams, onDeploy

### GasSavingsIndicator

Shows savings from using clone vs full deploy
States: calculating, ready
Props: fullDeployCost, cloneCost, savings

### ProxyVerificationBadge

Badge showing proxy points to verified impl
States: verified, unverified, loading
Props: proxyAddress, implementationAddress, isVerified

### FactoryCloneList

List of all clones from a factory
States: loading, loaded, empty
Props: clones[], onCloneClick

### CloneExplainerTooltip

Explains how minimal proxy works
States: collapsed, expanded
Props: showDiagram

## Key Takeaways

- ERC-1167 = tiny proxy pointing to shared implementation
- A small clone runtime can reduce deployment gas; quote actual network fees
- Always link to the verified implementation
- Explain to users their clone uses audited code
- Clones are immutable—not upgradeable proxies

## UX Patterns

### One-Click Contract Creation

User creates an instance through a supported factory

User flow:

- User fills in contract parameters
- Sees cost comparison (clone vs full)
- Clicks create
- Track submission and inclusion before showing the deployed address
- Gets their own contract address

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

### Factory Dashboard

View all clones created from a factory

User flow:

- Admin views factory dashboard
- Sees all clones created
- Monitors adoption and gas savings
- Links to implementation for verification

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

### Clone Verification

Show user their clone points to verified code

User flow:

- User checks their contract
- Sees it's a proxy (not full code)
- Views implementation it delegates to
- Confirms implementation is verified/audited
- Trusts their clone is safe

### Personal Vault Creation

User gets their own vault contract

User flow:

- User selects vault type
- Sees low deployment cost
- Can learn why it's cheap (clone pattern)
- Creates vault
- Gets personal contract address

## Technical Notes

ERC-1167 minimal proxy is exactly 45 bytes of bytecode that delegatecalls to a hardcoded implementation address. All storage lives in the proxy, logic in the implementation. The proxy cannot be upgraded—it permanently points to one implementation. This is different from upgradeable proxies (ERC-1967) where the implementation can change. The clone delegation target is fixed in its bytecode. An upgradeable-proxy illustration does not describe this clone. Any displayed deployment-cost example is illustrative; quote current gas and network fees for the actual deployment.