Your multisig might be one laptop away from being compromised

Most protocols can upgrade their onchain code. This is contrary to the belief of most web3 newbies, who tend to think that smart contracts are immutable. There is some truth in that statement, but we have had the upgradeable proxy pattern in Web3 since March 2016, when Ethereum introduced the DELEGATECALL opcode (EIP-7) in the Homestead hard fork. We've also seen a similar thing happening on other chains like Solana that introduced the BPFLoaderUpgradeable in late 2020. This is fine, and it's exactly how it should be, since you need a way to fix bugs and ship features. However, the most important question that more project users and investors should be asking is: "Who can push that upgrade and how?"

The Problem

I'm not sure what the current state of affairs is but my biggest fear would be that the answer is: "Our main dev has the master key on his laptop and he can push the update whenever is needed". Sometimes it's a multisig that looks good on paper, like 3 of 5 or 5 of 9. But when you look at who holds those keys, it's often the same few people at the same company. Sometimes it's the same machine. An attacker who gets into one team, or one laptop, gets enough keys to push whatever code they want.

• Ronin (2022), $624M. The bridge needed 5 of 9 signatures. The attacker got into Sky Mavis and took 5 keys, because Sky Mavis controlled that many.
• Harmony Horizon bridge (2022), $100M. 2 of 5 multisig. Both keys were compromised from the servers they were running on.
• Orbit Chain (2024), $81.5M. 7 of 10 signers compromised.

Check the rekt.news leaderboard and count how many entries come down to compromised keys. Private key compromises alone were roughly 44% of all crypto stolen in 2024. None of those losses needed a bug in the smart contract. The threshold was high enough, but the keys weren't independent.

That's the problem secure governance solves.

The Solution: Secure Governance Services

We join your upgrade multisig as an independent, external signer. Our keys are on hardware wallets, with backups on metal plates stored in safety deposit boxes in separate physical locations. They aren't on your team's machines, in your Slack or on your laptops. If someone phishes or compromises your team, they still don't have our key.

Our key isn't one person either. The address we add to your multisig is itself a multisig on our side. Several people on our team each hold a hardware wallet, so no single person at Adevar can sign for us, and compromising one of us isn't enough. Every key has a backup stamped into a metal plate, stored securely and in separate locations. We use metal instead of paper because it survives fires and floods.

You can go even further and make our signature required. For example, set up the quorum so an upgrade needs approval from your internal signers AND from the independent signer group. Then nobody can upgrade your protocol by compromising your team alone. You don't have to do this, but it's the setup that gives you the most protection.

We don't sign blindly

This is the part people don't expect. We aren't there to add a signature so the multisig looks more decentralized. If you ask us to sign an upgrade we haven't reviewed, we won't sign it.

Here's how it works in practice:

1. You build a new feature or a fix. We review it. That doesn't have to be a full audit, since this fits with PR reviews or a continuous security retainer. We review the change at a specific commit hash.
2. Once the code and the fixes look good, we compile it ourselves and record the hash of the binary we reviewed.
3. When the upgrade proposal comes in with the deployment transaction, we check that the hash of what you're about to deploy matches the hash we recorded.
4. We sign only if they match. If a few lines slipped in after our review, the hashes won't match and we won't sign.

We also won't sign an upgrade that looks like a rug, or one that ships a critical or high severity issue from our review that hasn't been fixed.

This is a mature way to deploy code. It gives you proof that what runs onchain is exactly what was reviewed. It also protects you against the kind of team-wide compromise behind most of the losses above.

"What if we want to switch auditors at some point?"

We get this question a lot. People worry that once we're on the multisig, they're stuck with us. They're not.

Removing a signer is a normal multisig transaction, like rotating any other key. If we're one of several signers, your other signers can remove us, lower the threshold or change the setup whenever they want.

If you've made us a required signer, removing us also goes through us. That's on purpose. Otherwise, an attacker who compromises your team could remove us first and then push whatever upgrade they want. We'll sign a handover to another independent signer.

If your upgrade keys all belong to people who sit in the same office or you have other questions or concerns, it's probably worth talking to us.