Backdoors: map who can change the rules after you enter

The short answer

A backdoor is a hidden or materially undisclosed capability that lets a controller bypass the rules traders believe they accepted. It may enable new supply, selective freezes, forced transfers or burns, extreme fees, blocked exits, arbitrary external calls, or replacement of the contract's logic.

Administrative and upgrade features are not automatically malicious. Teams use them for recovery, compliance, bug fixes, and staged launches. The threat comes from the combination of capability, disclosure, controller, delay, monitoring, and evidence of use. Write what an authority can do before guessing what its holder intends to do.

Build a capability map, not a keyword score

• Supply: mint, rebalance, rebase, burn from another holder, or alter which balances count.
• Transfer: pause, freeze, blacklist, allowlist, redirect, cap, tax, or reject selected sends and sells.
• Custody: move or burn holder tokens through a delegate or privileged program path.
• Market: change fees, limits, pool addresses, router behavior, treasury destinations, or liquidity controls.
• Code: replace the active implementation, upgrade a Solana program, change a beacon, or route calls through mutable external logic.
• Permission: grant, revoke, rotate, or administer every other role from a higher-order authority.

Search names such as owner, admin, operator, minter, pauser, upgrader, manager, delegate, hook, authority, implementation, and beacon—but follow the actual call graph and live configuration. A harmless name can hold dangerous code, and a dangerous-looking function can be unreachable.

On Solana, inspect the mint and every program it depends on

For a legacy SPL token, record the mint authority and freeze authority, including whether either has been removed. Then identify the token program, metadata authority, pool and launch programs, and any custom program invoked by the trading path. A custom Solana program normally has an upgrade authority that can update or close it; the official deployment docs state that removing that authority makes the program permanently immutable.

Token-2022 expands the control surface. A permanent delegate can transfer or burn tokens from any account for that mint and cannot be revoked by individual token holders. Transfer hooks can invoke additional program logic during transfers. Transfer-fee, default-account-state, pausable, confidential, and other extensions have legitimate uses, but their live settings and authorities must be included in the risk model.

On EVM chains, find the active implementation and every privileged role

Start with the address users call. Determine whether it is a proxy, which implementation currently receives delegated calls, who controls the proxy or beacon, and how that controller can change. OpenZeppelin's proxy documentation is explicit: the logic contract can be replaced while the proxy address remains unchanged. Source verification at the familiar address does not make the system immutable.

Enumerate owner and role-based access, including the admin of each role. Review modifiers and internal paths attached to mint, burn, pause, blacklist, fee, maximum-transaction, wallet-limit, router, rescue, external-call, and upgrade functions. Also resolve external contracts whose addresses can be changed; an apparently limited token may delegate meaningful behavior elsewhere.

“Ownership renounced” can be literally true and materially incomplete

An EVM owner can renounce the functions protected by an ownership modifier while minter, pauser, default-admin, proxy-admin, beacon-owner, or external-manager privileges remain. On Solana, removing a mint authority says nothing about freeze authority, extension authorities, metadata, or program upgrades.

Reconstruct the full permission graph and role-event history. Identify who can grant a supposedly removed role back, whether a role is held by another contract, and who controls that contract. Treat a deployer's public claim as a statement to verify against the current chain state, not a substitute for that state.

Evaluate how the capability is governed

For every material action, record the controlling address, signer threshold, signer independence, execution delay, cancellation power, public monitoring, change events, and documentation. A one-of-one hot wallet with instant upgrade power is a different exposure from a distributed multisig behind a meaningful timelock—even if both systems are technically upgradeable.

OpenZeppelin documents timelocks as a way to delay maintenance operations so users can review and exit. A timelock is still only as strong as its configured minimum delay, proposers, executors, cancellers, and administrators. Verify live values and past changes rather than inferring safety from a contract name.

Read state, history, and behavior together

Static code shows possible paths. Current state shows which paths are enabled. Event and transaction history shows how permissions changed or were used. Simulation can test representative buys, transfers, approvals, and sells, but a successful simulation only describes that state and input; an administrator may be able to change the result later.

Use the contract-reading workflow for instruction decoding and the approvals guide when a path asks your wallet to delegate token control. If privileged action can cause an exit failure, compare it with the mechanism taxonomy in the rug-pull guide.

A retained-control audit workflow

1. Resolve the execution path. Save chain, mint or contract, token program, proxy and implementation, pool, router, and custom programs.
2. Inventory capabilities. List every supply, transfer, custody, market, code, and role-management action regardless of its label.
3. Read live configuration. Record authorities, extensions, roles, implementation slots, external targets, fee values, and pause state.
4. Resolve controllers. Follow owners through multisigs, timelocks, managers, beacons, and upgrade authorities to their actual signers.
5. Trace history and disclosure. Compare grants, revocations, upgrades, setting changes, docs, audits, and public claims by block or slot.
6. Write capability-first. State what can happen, who can trigger it, what constrains them, whether it happened, and what remains unknown.

What belongs in the journal

Record chain, contract or mint, code and token program, proxy and active implementation, program upgrade authority, mint and freeze authorities, every extension and controller, owner and roles, role admins, external dependencies, multisig threshold, timelock values, change history, source and audit versions, tested transactions, public disclosures, block or slot reviewed, alternative legitimate purpose, material unknowns, and capability-based conclusion.

Primary sources