# Contract proxies: one address, replaceable implementation

A proxy contract forwards execution to implementation code, commonly using delegatecall while keeping state at the proxy address. Some proxies let an authorized party change the implementation. A permanent user-facing address therefore does not by itself mean that the application’s rules cannot change.

Evidence: [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy); [Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html)

Canonical: https://degreesofsatoshi.com/encyclopedia/contract-proxies/
Published: 2026-10-02
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:12:41.505Z
Data current through: 2026-10-02

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **State:** Delegated execution uses the calling contract’s storage context. ([Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html))
- **Implementation:** Proxy designs track which code address handles delegated calls. ([Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy))
- **Authority:** Transparent and UUPS patterns place upgrade checks in different parts of the design. ([Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy))

## Separate where assets live from which code runs

A reader may interact with one proxy address while the logic comes from another implementation address. The proxy’s storage holds the application’s state in the delegated execution model.

Looking only at the implementation’s own storage or balance can therefore be misleading. Inspect the proxy context as well as the current code.

Evidence: [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy); [Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html)

## Find who can change the implementation

An upgrade path may be controlled by a multisig, governance system or another role. Some designs restrict or remove upgrading; others retain broad authority. The word “proxy” alone does not answer which case applies.

Trace the actual authorization function and any delay. A public governance discussion is not equivalent to an enforced on-chain timelock.

Evidence: [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy)

## New code must understand old storage

Delegated implementations share the proxy’s existing storage. An incompatible layout can make new code interpret old values incorrectly even if both versions compile.

Initialization also matters: setup functions can assign critical roles and must be protected appropriately. Source verification of two contracts does not prove their combined deployment is configured correctly.

Evidence: [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy); [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/v0.8.30/internals/layout_in_storage.html)

## Questions

### Does every proxy mean someone can upgrade the contract?

No. Proxy mechanisms and upgrade authority vary. Inspect the actual implementation-selection and authorization paths instead of inferring them from the label alone.

Evidence: [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy)

## Claims and scope

### contract-proxies-quick-answer

A proxy contract forwards execution to implementation code, commonly using delegatecall while keeping state at the proxy address. Some proxies let an authorized party change the implementation. A permanent user-facing address therefore does not by itself mean that the application’s rules cannot change.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### contract-proxies-fact-state

State: Delegated execution uses the calling contract’s storage context.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### contract-proxies-fact-implementation

Implementation: Proxy designs track which code address handles delegated calls.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

### contract-proxies-fact-authority

Authority: Transparent and UUPS patterns place upgrade checks in different parts of the design.

Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null}

## Sources

- [Proxy contracts](https://docs.openzeppelin.com/contracts/5.x/api/proxy) — OpenZeppelin. Proxy implementation slots, delegated execution and upgrade authority. Locator: TransparentUpgradeableProxy; UUPSUpgradeable; ERC1967Proxy. Retrieved: 2026-10-02T17:03:43.024Z.
- [Solidity: Delegatecall and Libraries](https://docs.soliditylang.org/en/v0.8.30/introduction-to-smart-contracts.html) — Solidity contributors. Execution uses another contract’s code in the caller’s context and storage. Locator: Delegatecall and Libraries; Storage, Memory and the Stack; Logs; Message Calls. Retrieved: 2026-10-02T17:03:42.822Z.
- [Layout of State Variables in Storage and Transient Storage](https://docs.soliditylang.org/en/v0.8.30/internals/layout_in_storage.html) — Solidity contributors. Persistent storage slots, packing and mappings. Locator: Layout of State Variables; Mappings and Dynamic Arrays. Retrieved: 2026-10-02T17:03:42.820Z.

## Revision history

- 2026-10-02: First publication after primary-source research and independent automated verification.

## Cite this entry

Degrees of Satoshi editorial project. “Contract proxies: one address, replaceable implementation.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/contract-proxies/