What is proxy contract?

A contract that holds the state and forwards every call to a separate implementation contract, so the logic can be replaced while the address and balances stay put.

The forwarding uses a delegate call, and the implementation address is kept in a fixed storage slot defined by a standard so tools can find it (source: EIP-1967). This is how most upgradeable deployments work, including many large stablecoin and bridge contracts.

The pattern exists because deployed contract code cannot be edited. Fixing a bug would otherwise mean deploying a new contract at a new address and asking every user, integration, and exchange to migrate. A proxy keeps the address stable and swaps the code behind it, which solves a real operational problem and creates a governance one.

How it works

1. Two contracts. The proxy holds all the storage, including token balances, and holds no meaningful logic. The implementation holds the logic and, in normal operation, no state.
2. Delegate call. When you call the proxy, it forwards the call to the implementation using a delegate call, which executes the implementation's code in the proxy's own storage context. Balances therefore live at the proxy address throughout.
3. A known slot. The implementation address is stored at a fixed, standardized storage slot so wallets and explorers can locate it without guessing (source: EIP-1967).
4. Upgrade. An admin, which may be a single key, a multisig, or a governance contract with a timelock, writes a new implementation address into that slot. From the next block, calls run different code at the same address with the same balances.

The consequence worth sitting with: your balance is a number in the proxy's storage, and the rules governing that number can be rewritten by whoever holds the upgrade right.

Example

You look up a token on a block explorer and read the verified source. It is about forty lines that forward everything to another address. That is the proxy, and reading it tells you nothing about what the token does.

The explorer usually offers a "read as proxy" view. Following the implementation address takes you to the real code: transfer logic, any pause function, any blacklist, any mint authority. Checking only the proxy is like reading the cover of a book. Both addresses matter, and the one holding the upgrade key matters most.

Why it matters when you buy

Most large stablecoins and bridges use this pattern, so if you hold those assets an upgrade key already sits between you and your balance. What you can check is who holds it and whether upgrades pass through a timelock that gives users notice. Verifying a token contract walks through the lookup, and how to use a block explorer covers the tooling.

Related terms

upgradeable contract — the capability a proxy provides; smart contract — what is being forwarded to; block explorer — where you follow the implementation; multisig — a safer form of upgrade control; governance token — voting on upgrades; smart contract audit — reviews a snapshot only.

Questions

How do I tell whether a contract is a proxy?

Explorers flag it and offer a "read as proxy" option, and the verified source of a proxy is short and forwards everything. Following the implementation address shows the code that actually runs.

Can an upgrade take my tokens?

An implementation with the right code could move balances, freeze transfers, or mint supply, because it runs in the proxy's storage. Whether that can happen depends entirely on who controls the upgrade key and what constraints, such as a timelock, sit around it.

Is an upgradeable contract worse than an immutable one?

Neither is strictly better. Immutable code cannot be fixed when a bug is found; upgradeable code can be changed by whoever holds the key. The relevant question is which risk you prefer and how tightly the upgrade right is controlled.