If a contract doesn't use a proxy pattern and can't be upgraded, does that mean it's automatically safer?
Directionally yes, but not absolutely. A non-upgradeable contract does eliminate the attack path of "the team later swaps out the entire logic" — the code deployed on-chain stays exactly as it is forever, which is a clear advantage over an upgradeable contract. Uniswap V3's core contracts (Factory, Pool, NFT Position Manager), for instance, were deliberately designed to be non-upgradeable and have been battle-tested for over three years — that design philosophy is itself a kind of safety commitment.
But non-upgradeable doesn't mean zero administrative-permission risk. Some contracts, while their core logic can't be swapped out, still retain other forms of admin privileges — the ability to pause the contract, adjust fee parameters, freeze specific accounts, and so on — and those privileges can equally be concentrated in a small number of hands and abused. So the check can't stop at "is this a proxy contract" — you also need to dig further into what other functions in the contract are still protected by onlyOwner or similar modifiers, and what those functions are actually capable of doing. That's what gives you the complete picture.
A multisig sounds like it's already much safer than a single Private Key — can I just relax once I see one?
A multisig is indeed safer than a single EOA address — that direction is correct. It requires multiple independent keys to sign off together before an action executes, so a single compromised key isn't enough to cause a loss, which is precisely the layer of protection Multichain lacked. But a multisig's actual security still depends on a few easily overlooked details. First is the threshold setting — a "2 of 5" multisig means only two of the five keys are needed to approve an action. If the real-world holders of those five keys know each other well and are closely connected (say, all core members of the same team), the multisig's actual protection against an "insider collusion" risk can end up much weaker than the surface impression of "five-party checks and balances" suggests.
Second is whether these key holders actually each hold and safeguard their keys independently — if several of those keys are, in practice, all handed over to the same person or the same custodial system, a multisig that looks like a high bar on paper can end up with an attack surface not much different from a single private key. When verifying a multisig, it's worth going a step further and checking that wallet's past signing history — whether a different address actually completed the signature each time — which reflects the real degree of decentralization far better than simply seeing "this is a multisig address."
Does a timelock's one-or-two-day delay before an upgrade takes effect actually stop malicious upgrades?
A timelock's protective value depends on whether that delay period is actually used for meaningful monitoring — the delay itself doesn't automatically produce protection. If a queued upgrade proposal sits in a timelock for 48 hours with nobody and no monitoring system actually checking what's queued during that window, those 48 hours are just a pure waiting period that doesn't turn into defense on its own — which is also why some security researchers emphasize that a timelock only genuinely protects when someone is actually watching, rather than treating the timelock itself as a cure-all.
Also worth noting: a timelock's delay mechanism typically relies on the blockchain's timestamp (Block.timestamp) for its calculation, and blockchain validators have a small Margin (typically within ±15 seconds) to manipulate that timestamp — though this margin is far smaller than a 24-to-48-hour delay and isn't enough for an attacker to meaningfully bypass a timelock, it's a reminder that a timelock provides a substantially higher probability of being detected, not a cryptographic-grade, mathematically absolute guarantee against being bypassed. What's actually worth doing is making use of that public delay window — proactively checking a protocol's governance forum or multisig wallet records to see whether there's an upgrade proposal already queued but not yet executed — rather than assuming a timelock has already done the checking for you automatically.
Before depositing funds into a protocol, what order should I actually check these governance-permission details in?
The first step is confirming whether the contract is a proxy — open the contract's page on Etherscan, switch to the "Contract" tab, and look for a "This is a proxy contract" banner. If it's not a proxy, you can further check for other onlyOwner-protected high-risk functions (pausing, freezing accounts, adjusting parameters); if it is a proxy, the next step is mandatory — find out who holds the upgrade authority.
The second step is finding the owner or admin address and pasting it into Etherscan's search to see whether it's an ordinary EOA wallet or a multisig contract like a Gnosis Safe. If it's an EOA, upgrade authority is concentrated in a single Private Key — the highest risk tier. If it's a multisig, continue checking its signing threshold (like "X of Y") and its past signing history to confirm the addresses actually participating in signatures are genuinely diverse and independent. The third step, if you find a timelock contract, is checking how long its configured delay period is, and proactively checking the protocol's governance forum or a Block Explorer to see whether there's an upgrade proposal already queued but not yet executed. Together, these three steps let you arrive at a concrete, verifiable answer — before depositing funds — to questions like "could this protocol's logic be swapped out without your consent, how many people would need to agree to do that, and would you have a chance to spot it in advance" — rather than relying on a vague impression like "this protocol sounds big, so it's probably safe."
On July 6, 2023, Cross-Chain Bridge protocol Multichain (formerly Anyswap) saw roughly $126 million in assets transferred out within just a few hours, with bridge liquidity pools on Fantom, Moonriver, Dogechain, and other chains drained almost simultaneously. Blockchain security firm CertiK later confirmed the incident stemmed from a compromised Private Key, stating directly that "this exploit appears to be the result of a private key compromise, and as such falls outside the scope of the audits we conducted" — and CertiK had in fact audited Multichain twice, flagging no critical issues either time. That statement captures a fact most DeFi users overlook: a Smart Contract audit verifies whether the code logic has vulnerabilities, but it typically doesn't tell you who holds a key that can bypass that logic entirely and move funds directly, or how many people hold that key and how well it's protected.
Most people assume that once a smart contract is deployed on-chain, it can never be changed. In practice, though, a significant share of DeFi protocol contracts use a "proxy pattern" — the contract address users actually interact with (the proxy contract) contains very simple logic that just forwards every call to a separate address holding the actual business logic (the implementation contract). A protocol team can simply point the proxy at a new implementation address to swap out the entire executing code without ever changing the address users interact with. This design was originally well-intentioned — fixing bugs or upgrading features without forcing users to migrate assets — but it also means that any upgradeable contract necessarily has some party holding the power to swap out its logic. If that power falls into an attacker's hands, the effect is equivalent to controlling the entire protocol outright, with no need to find a single logic flaw in the original code. Per the 2026 OWASP Smart Contract Top 10, "Proxy and Upgradeability Vulnerabilities" climbed from #7 the previous year to #3, reflecting exactly how much more attention attackers are now paying to this attack surface.
The most direct way to check whether a contract is a proxy is to open that contract's page on Etherscan and switch to the "Contract" tab — if it is a proxy contract, you'll typically see a banner reading "This is a proxy contract." Etherscan automatically reads the fixed storage slot defined by the EIP-1967 standard for storing the implementation contract's address (located at 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bb) and displays the implementation address it currently points to. If you see that banner, it means the logic you're interacting with can be swapped out by the protocol team at any time — the behavior pattern you approved of today isn't guaranteed to still hold tomorrow.
Once you've confirmed it's a proxy contract, the next step is identifying who has the authority to execute an upgrade — this role is typically called the admin or owner. Look for an administrative function on the contract page (like owner() or admin()); calling it returns an address, which you then paste back into Etherscan to look up. If it resolves to an ordinary Externally Owned Account (EOA, meaning a regular wallet address), the upgrade authority rests in a single private key — the moment that key is compromised or its holder acts maliciously, the protocol's entire logic can be swapped out instantly, which is exactly what happened in the Multichain incident. If the address you find is itself a contract, and specifically a multisig wallet like a Gnosis Safe, an upgrade requires multiple independent keys to sign off together, so a single compromised key isn't enough to trigger one. If that leads further to a timelock contract (TimelockController), it means that even after the multisig approves an upgrade, a public delay period must pass (commonly 24 to 48 hours) before it actually takes effect — giving outside observers a window to spot a suspicious proposal and raise the alarm in advance.
Multichain used multi-party computation (MPC) technology to manage its private key, theoretically splitting the key into fragments distributed across different nodes to avoid a single point of failure. But per subsequent reporting, Multichain's CEO, known as Zhaojun, was taken in for questioning by Chinese police in May 2023, and the team later confirmed it had lost contact with him — and he was precisely the person who controlled the access keys operating the MPC Node servers. In other words, this theoretically distributed key system was, in actual operation, still heavily dependent on a single individual. On July 6, the bridge liquidity pools began showing abnormal withdrawals, starting with a mere $2 test transfer that escalated within two hours into $31 million in WBTC being transferred out, followed by the Moonriver and Dogechain bridge pools being drained in succession. None of this involved exploiting any code vulnerability or bypassing any smart contract logic — all it took was the key that was supposed to be distributed but was, in practice, concentrated in one person's hands.