One of the first things people learn about blockchains is that code deployed on chain cannot be changed. That is mostly true, and it is a big part of why smart contracts are trusted with real money. But if you have ever looked up a token or a dapp on Basescan and seen the label "Proxy Contract," you have run into the exception. Some contracts are built specifically to be upgraded after launch. Understanding how that works helps explain both a legitimate and widely used piece of engineering, and a pattern that scam projects sometimes lean on.
The problem proxies solve
Once a contract is deployed, its bytecode really cannot be edited. If a team finds a bug, wants to add a feature, or needs to fix a security issue, they cannot just patch the existing contract the way you would patch an app on your phone. Normally the only option would be to deploy a brand new contract and ask every user to move over to it, which is disruptive and, for anything holding funds or a large user base, often impractical.
The proxy pattern works around this by splitting a contract into two pieces. A proxy contract holds the permanent address that users and other contracts interact with, along with the actual data and token balances. A separate implementation contract holds the logic, meaning the code that decides what functions do. The proxy does not run its own logic for most calls. Instead it forwards, or "delegates," each call to whatever implementation contract it currently points to, while keeping the data in its own storage. To upgrade, the team deploys a new implementation contract and points the proxy at it. The proxy's address never changes, so nothing about how users interact with it needs to change either.
This is genuinely useful. Large, long-lived protocols on Base and elsewhere use proxies to fix bugs without asking every user to migrate, and to add functionality over time without redeploying an entire ecosystem of integrations. Some widely used token standards and DeFi protocols are proxies for exactly this reason.
How the mechanics work, briefly
The delegation happens through an opcode called delegatecall. When the proxy delegates a call to the implementation contract, the implementation's code runs, but it operates on the proxy's storage, not its own. This is what lets the logic live in one place while the balances and state live in another.
A subtlety this creates is that the implementation contract's storage layout has to line up carefully with the proxy's, or an upgrade can accidentally corrupt data. To avoid that problem, a standard called EIP-1967 defines specific storage slots, calculated so they are extremely unlikely to collide with any variable a normal contract would use, for storing the proxy's own bookkeeping, like the current implementation address and who is allowed to upgrade it. Most modern proxies on Base follow this standard, which is also what allows tools like Basescan to reliably detect that a contract is a proxy and show you which implementation it currently points to.
What this looks like on Basescan
When a contract is verified as a proxy, Basescan shows the code of the current implementation contract, along with "Read as Proxy" and "Write as Proxy" tabs so you can interact with the real functions instead of the empty forwarding logic in the proxy itself. If the implementation is later swapped out, re-verifying the proxy updates which implementation address it shows. Basescan also flags this relationship on the contract page, though it is worth knowing that not every contract using delegatecall is actually an upgradeable proxy; some contracts use the same opcode for other purposes, like sharing library code, without being upgradeable at all.
Why this matters for your safety
Proxies are a normal, well established pattern, not inherently a red flag. But they change what "verified" and "audited" mean in a way that is easy to miss.
The logic you are trusting can change after you have already checked it. A verified, audited implementation contract can be swapped for a completely different one, including one that was never audited, at any time, if whoever controls the upgrade decides to do it. Checking a proxy's code today tells you what it does today. It does not guarantee what it will do tomorrow.
Who controls the upgrade matters as much as the code itself. Upgrade permissions are usually held by a single admin address, a multisig, or a governance process with a time delay. A single admin key that can swap the logic instantly is a meaningfully different risk than a multisig with a public timelock that gives users advance notice before a change takes effect. Reputable protocols are often explicit about this setup; if you cannot find any information about who can upgrade a contract or under what conditions, treat that as missing information rather than assume it is safe.
It is a pattern scams have used, too. A malicious actor can launch a token or dapp behind a proxy with a clean, verified implementation, build up trust and liquidity, and later point the proxy at a new implementation that behaves very differently, for example by disabling withdrawals or adding a hidden fee. The proxy's address stays the same the whole time, so on the surface nothing looks different.
Practical takeaways
You do not need to read Solidity to act on this sensibly. A few habits help. When checking a contract on a block explorer, notice whether it is flagged as a proxy, and if so, look at whether the project discloses who controls upgrades. Prefer projects where upgrade authority sits with a multisig or a timelock over a single wallet, since that spreads out or delays the ability to make an unwanted change. Keep in mind that contract verification and audits describe the code as it exists at a point in time, and a proxy can make that point in time less permanent than it looks. None of this means avoid every upgradeable contract. It means factor upgradeability into the same judgment you already apply to contract age, audit history, and who is behind a project, rather than treating a proxy as either automatically safe or automatically suspicious.
Sources: Basescan Information Center, Proxy Contracts, EIP-1967: Standard Proxy Storage Slots