Guide · Token security

Understanding proxy contracts
can a contract change after deployment?

A proxy lets the rules change after you have already checked everything else. Learn how upgradeable contracts work, why upgrade authority matters more than the code itself, and how to verify who controls future changes.

Analyze a contract

Free · No sign-up · EVM · Bitcoin · Solana · Tron

Every scan is powered by the XemaS Semantic Intelligence Platform · answers carry their evidence and coverage state

The basics

What is a proxy contract?

A proxy is a contract that holds the storage and the address users interact with, but forwards its logic to a separate implementation contract through a mechanism called delegation. Because the implementation can be swapped, the proxy lets a project upgrade the code after deployment while keeping the same address and the same balances.

User
Proxy (address + storage)
Implementation (logic)

Common patterns include the Transparent proxy, UUPS, and Beacon proxy. The pattern matters less than one question: who is allowed to swap the implementation, and what stops them from doing it maliciously? The code you read today is only as trustworthy as the authority that can replace it.

Why it matters

Safe today, different tomorrow

An upgrade can change behaviour you already verified. A single upgrade transaction can introduce any of these, with no change to the address you are watching:

Taxes and fees

A new implementation can introduce or raise buy and sell taxes, turning a low-fee token into one that is uneconomical to sell.

Permissions

Owner-only powers (pause, exclude, set limits) can be added or widened in an upgrade, even if the current code looks clean.

Blacklists

An upgrade can add a blacklist that blocks specific wallets from selling, converting a normal token into a honeypot.

Supply controls

A mint function absent today can be introduced tomorrow, letting the controller inflate supply and dump.

Governance rules

Quorum, voting periods, and who can propose or execute changes can themselves be altered, weakening the protections you relied on.

The key distinction

Not all upgrade authority is equal

The same proxy can be safe or dangerous depending entirely on who can push an upgrade. From weakest to strongest protection:

1

EOA admin

HIGH

A single externally-owned wallet can upgrade the contract instantly, with no delay and no second signer. One compromised or malicious key changes everything.

2

Multisig

MEDIUM

An upgrade requires several signers (for example 4 of 7). Better than one key, but the change can still execute immediately with no public warning.

3

Timelocked multisig

LOW

Upgrades must be queued and wait out a delay (for example 48 hours) before execution. The delay gives holders time to see the change coming and exit if needed.

4

Governance-controlled timelock

LOWEST

Changes require a token-holder vote to pass, then still wait out a timelock. Authority is distributed and transparent, the strongest common protection.

Under the hood

How XemaS evaluates upgrade authority

Most tools stop at "this contract is upgradeable." XemaS resolves who actually controls the upgrade, and how protected it is.

Implementation resolution

Resolves the proxy to its current implementation address and reads the real code you are trading against, not just the proxy shell.

Timelock collectors

Detects a timelock controller behind the admin and reads its minimum delay, so a "48-hour notice" is verified rather than assumed.

Multisig collectors

Identifies a multisig admin and its threshold (for example 4 of 7), distinguishing real distributed control from a single key.

Governance parameter collectors

Reads quorum, voting period, and proposal thresholds where a governor controls upgrades, so the protections are measured, not just named.

Upgrade-authority watchpoints

Flags who ultimately controls the upgrade and surfaces it as a watchpoint, with a coverage state (COLLECTED, PARTIAL, or UNVERIFIED) so an unconfirmed control is never read as safe.

What a verdict looks like

Same pattern, opposite risk

Two upgradeable contracts. The difference is entirely in who holds the keys.

ProtocolA
UPGRADE RISK: LOW
Proxy typeTransparent
AdminTimelock controller
Delay48 hours
Multisig4-of-7
GovernanceQuorum 15%, 7-day vote

Upgrades need a vote, then a 48-hour delay. Changes are visible before they execute.

ProtocolB
UPGRADE RISK: HIGH
Proxy typeUUPS
AdminEOA wallet
DelayNone
MultisigNone
GovernanceNone

One wallet can swap the logic instantly, with no delay and no warning.

Illustrative examples. Run a real contract to see its live upgrade-authority verdict.

Before you trust the code

Find out who can change the rules

Paste any contract and XemaS resolves the implementation, the upgrade authority, and the timelock, multisig, and governance controls behind it, with an honest coverage state. Free, no account required.

Create free account
FAQ

Proxy contract questions, answered