Proxy contracts: when the code you audited is not the code you trade

You can read a token's code, verify it on Etherscan, confirm it has no honeypot, and still get rugged. With a proxy contract the logic lives in a separate, swappable contract: the owner can repoint it after you buy and turn a clean token into a honeypot without changing its address. Here is how the rug-by-upgrade works and how to spot it before you ape.

You can read a token’s code, verify it on Etherscan, confirm it has no honeypot, and still get rugged. The reason is a pattern called a proxy contract: the code you checked is not guaranteed to be the code that runs tomorrow.

What a proxy contract is

A normal contract keeps its logic and its data in the same place. A proxy splits them in two:

  • The proxy holds the address everyone uses, the token balances, and all storage. It never changes.
  • A separate implementation contract holds the actual logic: transfer, approve, the tax rules. The proxy forwards every call to it with a low-level delegatecall, so the logic runs as if it lived in the proxy.

The key property is that the proxy can be told to point at a different implementation. Same token address, different brain.

PROXYyour token addressfunds + storagenever changesIMPLEMENTATION v1the code you auditlooks cleanIMPLEMENTATION v2swapped in laterhoneypot / blacklist / mintdelegatecall (now)upgrade() anytimesame address, swappable logic

Why proxies exist (the legitimate use)

Upgradeability. Smart contracts are immutable once deployed, so if a real protocol ships a bug it cannot just patch the live code. Proxies are the standard fix: keep the address and the funds stable in the proxy, and correct the logic by swapping the implementation. USDC and most large protocols are proxies. There is nothing inherently wrong with the pattern.

The scam angle: rug-by-upgrade

That same swappability is a clean exit scam. A token launches with an implementation that looks honest: no honeypot, normal tax, selling works. People audit it, buy in, liquidity grows. Then the owner calls upgrade() and points the proxy at a new implementation that adds a blacklist, a 99% sell tax, a hidden mint, or a flat sell block. Nothing about the token address changes. The chart looks the same. The exit just closed.

The lesson: auditing a proxy tells you what the code does right now, not what it is allowed to become. An audit of an upgradeable contract is a snapshot, not a guarantee.

How to spot it

  • Is it a proxy at all? Most follow the EIP-1967 standard, which stores the implementation address in a fixed storage slot. Explorers label these “Proxy” and expose a “Read as Proxy” tab.
  • Who can upgrade? Look for an admin or owner address with an upgradeTo or upgrade function. If one wallet can repoint the proxy, one wallet can rug by upgrade.
  • Is that power renounced? If the admin is the zero address or a timelock, the risk drops sharply. If it is a fresh externally-owned wallet, treat the clean code as temporary.
  • Is the implementation even verified? An unverified implementation behind a proxy means you cannot read the code that actually runs.

Where RektRadar fits

We flag proxy_contract and pair it with ownership_not_renounced, because a proxy is only as safe as whoever holds the upgrade key. We resolve and read the implementation behind the proxy, not just the proxy shell, and we track whether that implementation changes over time. A token that looked clean last week and is upgradeable by a single wallet is exactly the setup a rug-by-upgrade needs. Combined with the honeypot checks and the other scam signals, an owner-controlled upgradeable proxy moves a token from “looks fine” to “handle with care”.

Paste any Ethereum token into the free rug pull detector at app.rektradar.io to see whether it is a proxy, who controls it, and whether selling actually works.