A few months ago I was working with a EU bank on code for its non-custodial transfer solution. The code was good, but I noted there was only a single admin behind a multisig, a fragile pattern that has caused billions in losses.

They responded to my feedback with the classic "trusted actor, intended design" and after a long meeting their last standing argument was, and I quote, "This is an issue for OpSec, it's fine as long as they do their job."

This is the siloed thinking that keeps producing compromised key hacks, the idea that you can just separate on-chain code and off-chain operational security. You can't. They are ONE system. The on-chain design determines the shape, size and value of the off-chain attack surface. Any contract that concentrates all power with a simple multisig design does not have "a trusted admin". It has a publicly advertised single point of failure with a $ sign attached.

A giant bullseye brightly painted on the single lock protecting all the treasure.

Admins & Multisigs

Privileged Actors - A Necessary Evil

In an ideal world every protocol would be designed as an immutable system without the need for any privileged actors or emergency procedures. And while some systems do come close (e.g. Uniswap V2), time has shown us the persistent need for a superuser to act when and where the code has no automated response, to adapt configurations to an ever-changing market or to allow an upgrade to let the protocol itself evolve.Yet this necessary entity is at the same time the ideal target for attackers. The admin role is the master key, worth precisely as much as everything it opens. The same capacity to aid the protocol is also the catastrophic risk that it carries.

Multisigs - The Default Incomplete Answer

The near-universal response to the dangers posed by the superuser has been to put the admin behind some kind of multi-signature setup so that the number of actors needing to be compromised goes from 1 to N. These can be N-of-M contract wallets like Safe, MPC wallets or a custodial policy engine such as Fireblocks.While this is certainly better than using a single key, it does not solve the fundamental issue of access control. Yet the multisig is then almost always treated as an unbreakable trusted actor for all downstream security analysis. The cybersecurity industry is complicit in this. How many times have we seen the phrases "centralisation risks are out of scope", "The admin is trusted", "privileged actors are assumed to be honest" and silently accepted them as a design flaw? It has become a hallowed axiom rather than a tested component of the threat model.

The Transparent Bank

To fully understand why this is such a problem, let us compare criminals breaking into a traditional bank's vault with them attacking a DeFi protocol. For the traditional bank:

• How much is in the vault? They can only guess
• How exactly is it secured? Unknown
• What kind of keys are required to unlock and how many are there? No clue
• Who holds them and can they actually open the vault? Perhaps the managers. Can they open it alone? Maybe.

It is incredibly difficult for nefarious actors to even acquire the information to decide if robbing the bank is possible or worth it. Real life is not an Ocean's Eleven movie where this information just magically falls from the sky.This opacity is a layer of security in its own right!Now the DeFi protocol:

• How much is in the protocol? Known to the last cent
• What secures it? Perfectly readable in the contract
• How many signers are there? Frequently visible on-chain
• Who are the signers? Members of the protocol who almost always have a social media profile
• How do we get the keys? By any means

With almost complete information, the targeting becomes trivial. Criminal groups list all protocols with significant value, filter on naive access control, then filter again on social media presence or physical location of the company. Near instantly and at no cost, a giant bullseye is painted on the softest protocols and an endless barrage of attacks against your OpSec commences.

The War on OpSec

The multisig never truly removed the problem of access control, it merely relocated it out of the contract and into the laptops, homes and families of the people who sign. Those people are now the perimeter, and every technique in the adversary's catalogue gets pointed at them:

• Malware: The interface shows a routine transaction while a different payload reaches the wallet. They approve their own robbery (Radiant Capital $50M / Bybit $1.5B).
• Social Engineering: An avalanche of fake emails, poisoned job offers and trojaned meeting apps. Waiting for a single person to make a single mistake (Ronin Bridge $625M).
• Infiltration: No need to hack the company if you're part of it. North Korean developers join under false identities to gain and exploit trust (Munchables $62M).
• Physical Violence: Kidnapping, coercion and torture (Ledger co-founder).

The last category should make you stop and realise that this goes beyond numbers on a screen. A true nightmare is not a drained contract, it is a voice on the phone showing you a video of your 7-year-old daughter leaving school, asking if you want to see her again. That is what it means to make humans the sole lock on a fortune.

The Solution

When we've lost more than $4B to these kinds of hacks since 2024, when it already represents 76% of all money lost this year (TRM Labs, H1 2026) and when in extreme cases it can mean violence against you and your loved ones, then surely this problem must be almost impossible to resolve, right?Because if not, why on earth have we not fixed it yet?Yet the solution is embarrassingly simple, easy to implement and already sitting in nearly everyone's trusted dependency tree. A timelock and a guardian straight from OpenZeppelin's TimelockController.

Timelock Delay

Every admin action that can meaningfully damage the protocol (withdrawals, oracles, upgrades) must be locked behind a delay of at least one week. This breaks the atomic nature of the attack, where hackers drain the funds the moment the multisig is compromised, long before anyone is aware or can take any action to mitigate the damage.

Guardian Role

Use the canceller role from the OZ contract and assign it to a separate multisig owned by an external partner, a DAO or a security company, whose only authority is to veto the admin's queued actions.It is essential that this partner is separate from you, since a veto held by the same group of people who sign leaves the attackers with the same single target, while an unrelated organisation forces them to break two separate systems simultaneously.

Attacker's Math

This is all it takes to fundamentally alter the attack dynamics. A few lines of code and some change management when planning admin actions.Then, picking the first lock does not grant them anything but the ability to queue a theft and hope no one notices. In the vast majority of cases, users will withdraw all funds or the guardian will veto their attempt. When the prize drops from an instant, guaranteed fortune to a slim chance at some cash, the giant bullseye becomes a tiny dot.A correct criticism of the above is that this solution does not perfectly fit all cases, some emergency admin actions are not suited for a timelock, guardians add real overhead and a determined enough attacker can still find a way through. But being perfectly unhackable was never the goal. Enough friction is all it takes for the attack to stop being worth the effort and an attacker hunting for a guaranteed fortune will not spend months chasing a maybe.

Call To Action

To Security Researchers

My friends, we should no longer accept the standard phrases of "trusted actor, intended design" when it covers one of the most critical attack surfaces in existence. This should trigger the conversation, not prevent it.So have that conversation and make sure it is dead center in the report. Not as a buried informational note, but as a named risk with mitigations attached so that shipping a single-layer admin becomes a documented and deliberate choice rather than a default nobody cared to examine.We are not stenographers for our clients' risk appetite. We are highly paid to discover and discuss every issue that puts the client at risk. And yes, as it did with the UK neobank client, this can cause some serious friction. But that is preferable to watching silently as it costs them half a billion dollars, a finger or worse.

To Protocol Developers

I am writing this for your own good, and I mean it in the most literal sense of the word.Yes, a timelock and a guardian might sound like an annoying addition and useless overhead when all you're thinking about is making the launch a success and praying that you hit product-market fit. I get it. But it is equally important to prepare for the day when you realise those dreams.So please add the timelock and the guardian. Shrink the bullseye. Protect your users, protect your protocol and protect yourself. Do not let your dreams turn into a nightmare.