Smart contracts with an admin key

A smart contract is often presented as a program no one controls. In practice, many contracts in use have someone with special powers over them: an address that can pause the system, change fees, create new tokens or even replace the entire code.

These powers are called administrative privileges. They are not a flaw in themselves. They are used to fix bugs, respond to attacks and evolve the product. But they change the nature of the trust you place in the contract. This article explains what these powers are, where the risk lies and which mechanisms reduce it. If you are not yet familiar with how a smart contract basically works, start with What smart contracts are and how they work.

What administrative privileges are

A smart contract is a set of functions that anyone can call by sending a transaction. Some of them, however, are protected: they only execute if the transaction comes from an authorized address. This control over who can call what is called access control.

Ethereum’s developer documentation describes two common models (ethereum.org, Smart contract security):

• Single owner (the Ownable pattern): the contract records one address as the owner, and sensitive functions get a modifier, onlyOwner, that rejects calls from any other address.
• Role-based control: instead of an owner, there are distinct roles, such as “who can mint tokens” and “who can pause”, each assigned to different addresses.

The OpenZeppelin library, widely used to write contracts in Solidity, implements both models. According to the OpenZeppelin documentation, the role-based model has a default admin role that controls granting and revoking all the others. The documentation itself classifies it as high-risk and offers extra rules for it, such as a single admin and a two-step transfer with a delay.

What powers an admin key can have

What the admin can do depends on how the contract was written. The most common powers are:

• Pause: halt deposits, withdrawals or transfers. Ethereum.org calls this an emergency stop and notes that the feature increases the need to trust that developers will not trigger it improperly.
• Mint or burn tokens: create new units (which dilutes existing holders) or destroy them. How this affects a token’s supply is covered in Tokenomics: how to analyze it before evaluating a project.
• Change parameters: fees, borrowing limits, lists of accepted assets, price sources (oracles).
• Block addresses: prevent a specific wallet from moving tokens, a common feature in tokenized assets for compliance reasons, as explained in Smart contracts applied to real-world assets.
• Upgrade the logic: replace the code running behind the contract. This is the broadest power, and it deserves its own section.

The broadest case: upgradeable contracts

Code deployed at an Ethereum address cannot be changed. Ethereum.org explains how contracts are nonetheless “upgraded”: the user interacts with an intermediary contract, called a proxy, which stores the data and forwards calls to a second contract, the logic contract. To upgrade, the proxy is pointed to a new logic contract. The address you use stays the same, but the behavior changes (ethereum.org, Upgrading smart contracts).

The same page lists the costs of this design: the immutability guarantee is weakened, users have to trust that developers will not change the contract arbitrarily, the complexity creates new points of failure and, if access control is weak, it becomes easier for a malicious actor to carry out an unauthorized upgrade.

Who decides on the swap? In the OpenZeppelin proxy documentation, there are two main arrangements. In the transparent proxy, an admin address, often a helper contract called ProxyAdmin, performs the upgrades, and the owner of that contract can transfer this power. In the UUPS model, the rule on who can upgrade lives in the logic contract itself, in a function that must be protected. Without that protection, the documentation warns, anyone could upgrade the proxy.

In short: in an upgradeable contract, whoever controls the upgrade key effectively controls everything the contract holds.

Where the risk lies

Single point of failure. Ethereum.org states that registering a single address as owner introduces centralization risk and represents a single point of failure: if that address’s keys are compromised, attackers can attack the contract.

Access control failures. The OWASP Smart Contract Top 10, 2025 edition, ranks access control vulnerabilities first (SC01). According to OWASP, these flaws allow unauthorized users to access or modify the contract’s data or functions, and stem from missing or weak permission checks.

Bad-faith use. The risk is not only from hacks. Whoever holds the key can use it against users. The Financial Stability Board (FSB), which coordinates G20 regulators, notes that protocol developers may retain governance tokens and admin keys, so that a protocol described as decentralized may in fact be controlled by a concentrated group of interests. The report also mentions the risk of a rug pull, when those in charge abandon the project and take the funds with them (FSB, 2023).

Operational error. The OpenZeppelin documentation points to a mundane risk: transferring ownership to a wrong address that can no longer interact with the contract. The function loses its owner and there is no way to recover it. That is why there is a two-step variant, in which the new owner must accept the transfer.

Renouncing also has a cost. The owner can renounce control. According to OpenZeppelin, this permanently disables the restricted functions. The contract becomes more predictable, but loses the ability to pause or fix a bug discovered later.

A real case: when a multisig’s keys are compromised

Multiple signatures are not armor. In October 2024, the lending protocol Radiant Capital lost about 53 million dollars, according to an analysis by the security firm Halborn. The admin wallet required 3 of 11 signatures. According to the analysis, the attackers installed malware on signers’ devices: the interface displayed legitimate transactions while the hardware wallets signed different ones. With those signatures, control of a core contract was transferred to a contract owned by the attacker, who then upgraded the pool contracts to malicious versions and drained the funds (Halborn, 2024).

The case shows two things. First, the attack did not depend on a bug in the contracts’ logic: the upgrade power was enough to empty the protocol. Second, the weak link was operational: computers and signing processes, beyond the reach of a code audit, as explained in Smart contract audits: method and limits. The protocol’s current documentation states that its contracts sit behind a 72-hour waiting period for any action (Radiant, Security Timelock).

Similar losses, caused by validator keys rather than code bugs, appear in Blockchain bridges: how they work and where they fail.

What reduces the risk

The technical sources converge on a set of measures. None eliminates the problem; each one shifts or distributes trust.

• Multiple signatures (multisig): the action requires approval from several addresses. Ethereum.org describes it as an extra layer of security because it requires the consent of multiple parties. The case above shows that the security of the signers’ devices matters as much as how many signers there are.
• Separate roles: splitting powers (whoever pauses is not whoever upgrades) follows the principle of least privilege, recommended by OpenZeppelin.
• Waiting period (timelock): an approved action is executed only after an interval. The OpenZeppelin documentation says the delay gives users time to review the operation and exit the system if they wish. Ethereum.org notes the trade-off: the delay also slows down urgent fixes.
• Governance by vote: changes go through a vote by token holders, often in a DAO. The FSB warns that voting power is often concentrated and that tokens can be borrowed to sway votes. See What a DAO is and how its governance works.
• Transparency: publishing who holds each key, what the signature threshold is and what the waiting period is, and emitting on-chain events at every role change, so that anyone can follow along.

In the editorial team’s assessment, the useful question is not “does the contract have an admin?”, because most do. It is “what can the admin do, how many people need to agree and how much time do I have to react?”. The step-by-step process for answering that about a given protocol is in How to investigate the security of DeFi protocols.

Key takeaways

• Smart contracts are rarely fully autonomous. Admin functions make it possible to pause, mint, change rules and, in upgradeable contracts, replace all the code.
• The risk lies in the key: if it is stolen, poorly stored or used in bad faith, the contract obeys. Code audits do not cover this point.
• Multisig, separate roles and timelocks distribute and delay this power. They do not replace the question of who is behind the keys and how much you could lose if they fail, including the total loss of the amount deposited.