Key Management for Protocols: Multisig, MPC, and HSMs

An attacker who reads your contracts carefully will usually find that the cheapest path to the treasury does not go through the code at all. It goes through whoever holds the key that can upgrade the proxy, change the oracle, or pause and drain the vault. Admin keys are the one component of a protocol that cannot be audited into safety, because they are held by people, on devices, in places, under laws, and every one of those is an attack surface the Solidity never sees.

Some of the largest losses in the industry's history have come from signer-key compromise rather than from contract bugs. The pattern repeats: a well-reviewed codebase and a privileged role controlled by too few keys, held too close together, by people who could be phished, pressured, or fooled into signing something they could not read. The code did what it was told. The problem was who could tell it.

This article is for the teams who hold those keys and the people who decide how. It covers the threat model, the choices between multisig, MPC and hardware, the human layer that defeats all three when ignored, tiering authority by risk, and planning rotation and recovery before an incident forces you to improvise.

The threat model for admin keys

Start by listing every privileged action in the system and the worst outcome if an adversary could perform it. Upgrading an implementation usually means total loss. Changing an oracle or a fee recipient means slow or fast drain. Pausing means denial of service and possibly stranded user funds. Minting means dilution to zero. Each action has a key or set of keys that can trigger it, and the threat model is the list of ways those keys fall into the wrong hands.

The ways are fewer than teams expect, and more mundane. A signer's laptop is compromised by malware delivered through a fake job offer or a poisoned dependency. A signer is socially engineered into approving a transaction they believe is routine. A hot key is left on a server that is later breached. An insider acts alone, or two insiders act together. A seed phrase backup is photographed, found in a cloud drive, or seized. A hardware device is used to sign a payload it cannot display, so the human verifies nothing.

Each of these defeats a single key. Several defeat a multisig whose signers share the same laptops, office, chat channels and assumptions. Everything that follows exists to ensure that no single failure, and no plausible pair of failures, is enough.

Remove the single point of failure

The first move is to require more than one key for every action that matters, and the usual tool is an on-chain multisig: a contract that executes a transaction only when a threshold of its registered signers have approved it.

The threshold is a trade-off between compromise resistance and availability. A two-of-three can lose one key and keep operating but falls to two compromised signers. A four-of-seven tolerates three losses and resists three compromises. For roles that can cause total loss we favour thresholds where more than half of the signers must agree and losing a third does not freeze the protocol; the exact numbers depend on how many trustworthy, reachable signers the team can field.

Signer count is only meaningful if the signers are diverse. Seven keys held by seven employees on seven company laptops in one city, all in one Slack workspace, is a one-of-one with extra steps, because a single phishing campaign reaches all of them. Diversity means different organisations where possible, different device types, different approval channels and different locations. External signers, such as trusted partners or independent security firms, raise the bar for collusion and coercion.

The human and social layer

Most multisig failures are human failures wearing a technical costume.

Signer compromise is the obvious one, and the defence is to assume it will happen and to size the threshold so that one compromised signer achieves nothing. Collusion is harder. Two or three insiders with the same incentives can be a threshold. The mitigation is to make sure no group with a shared interest holds enough keys, which is another argument for external signers and for separating the people who write the code from the people who authorise its deployment.

Social engineering of signers is the attack we see most. A request that looks routine arrives in the usual channel from what appears to be the usual person, with a reason to hurry, and the signer approves because approving is what they do every week. The defence is procedural: every transaction has a written proposal with a reason, the proposal is confirmed through a second channel that the attacker is unlikely to control, and at least one signer is expected to independently reconstruct and verify the calldata rather than trust the summary.

Blind signing undoes all of it. If the signer's device shows a hash, or a wallet shows a decoded summary produced by the same front-end the attacker controls, the human step is theatre. Signers should verify the target address, the function selector and the arguments on a device whose display they trust, using a tool that decodes the calldata independently of the interface that produced it. Contract-interaction signing flows that cannot be displayed on hardware should be redesigned until they can.

MPC and TSS versus on-chain multisig

Multi-party computation and threshold signature schemes produce a single ordinary signature from key shares held by several parties, without any share ever being assembled. To the chain it looks like one externally owned account. The advantages are real: no on-chain multisig contract to audit or upgrade, lower gas, compatibility with chains that lack multisig contracts, and no public map of who the signers are.

The costs are equally real. Security now depends on the MPC implementation and its coordination layer, complex software that is far harder to review than a multisig contract, and usually on the vendor that operates it. Signing policy lives off-chain, so there is no public record of who approved what, and an attacker who compromises the coordination server may be able to drive the policy engine. Custody failures have traced to the provider's own infrastructure rather than to any customer's keys.

Our view: on-chain multisig for governance and upgrade authority, where public verifiability matters most; MPC for operational signing at volume, where the vendor's security has been assessed as seriously as your own. An MPC wallet acting as one signer in an on-chain multisig is often the right compromise.

Protect keys with hardware

Whatever the scheme, each share or key should live in hardware that will not export it and that requires physical confirmation to sign.

Hardware wallets are the right tool for individual signers. They keep the key off the general-purpose computer, the device most likely to be compromised, and display the transaction for verification. Their limit is the display: long calldata may be shown as a hash, which brings back blind signing. Choose devices that support clear signing for the interactions your signers actually perform, and test it.

Hardware security modules suit automated or high-volume signing: pipeline deployers, keepers, treasury operations. An HSM enforces access policy, rate limits and audit logging around a key that never leaves it. It does not decide whether a transaction is a good idea; the service that calls it does, and that service is the new target. HSMs are only as strong as the authorisation layer in front of them, which deserves the same review as the contracts.

Separate authority by risk

Not every key needs the same protection, and giving every key the same protection usually means the important ones get too little.

Tier the keys. Cold keys, held offline on hardware by diverse signers behind a high threshold and a timelock, control upgrades, treasury, and role administration; they are used rarely and every use is an event. Warm keys, held on hardware with a lower threshold and short or no timelock, handle routine parameter changes and emergency pausing. Hot keys, which live on servers or in HSMs, perform automated operations such as keeper duties, oracle updates and reward distribution, and must be unable to do anything whose loss would be catastrophic.

The deployer key deserves specific attention. It is often a developer's personal hot wallet, it owns everything at the moment of deployment, and it is forgotten afterwards. Deployment scripts should transfer ownership to the cold multisig in the same transaction or immediately after, and the audit should verify on-chain that it happened. A protocol whose contracts still answer to the deployer six months after launch has a one-of-one admin and does not know it.

Timelocks and governance

A timelock between approval and execution turns a key compromise from an instant loss into a visible event with a response window. It gives users time to exit, gives monitoring time to alert, and gives the honest signers time to cancel. The delay should be long enough for those things to happen and short enough that legitimate emergencies can still be handled; emergency pausing should go through a separate, faster path with narrower powers.

A timelock is only useful if someone is watching the queue, so alerts on every scheduled operation, sent to people who are not signers, are part of the design. Token governance adds another layer: a vote before the timelock raises the cost of a hostile action but introduces governance attacks such as flash-loaned voting power, which need their own controls.

Key ceremonies, geographic and legal diversity

Keys and shares should be generated in a ceremony: on freshly provisioned devices, offline, with witnesses, a written record of where each part went, and backups sealed at the same time. Ceremonies feel excessive until the day you need to prove that nobody else ever had a copy.

Diversity across geography and jurisdiction defends against outcomes that technical controls cannot. Signers in one country can be reached by one court order, one police action or one regional outage. Spreading them across jurisdictions means no single authority can compel the threshold and no single event can take it offline. It complicates coordination, which is why procedures must be written down and rehearsed.

Plan rotation and recovery before you need them

Every key will eventually need replacing: a signer leaves, a device is lost, a compromise is suspected. If the first rotation happens during an incident, it will be improvised under pressure by people who are also doing everything else.

Write the rotation playbook now. For each key tier it should state who can initiate a rotation, what evidence of compromise triggers one, the exact sequence of transactions to remove a signer and add a replacement, how the new signer's key is verified before it is trusted, and how long the whole process takes. Rehearse it on a test deployment at least annually and after any change to the signer set.

Recovery is the other half. Decide in advance what happens if the threshold cannot be met because too many signers are unavailable. Options include a time-delayed recovery path controlled by a separate, larger set, social recovery through governance, or accepting that the protocol freezes. Any recovery mechanism is also an attack path and must be protected at least as well as the keys it recovers.

Finally, make the incident rotation fast. A suspected signer compromise should be followed within minutes by removal of that signer, cancellation of anything they have queued, and a review of every action they approved recently. Our article on the first 24 hours after a hack covers how this fits into the wider response.

How we audit key management

Key management review is part of every protocol audit we perform, alongside the contract items in our audit checklist, and it is available as a separate engagement for teams that have already been audited.

We begin by building the privilege map from the deployed contracts rather than from the documentation: every role, every owner, every timelock, and the on-chain address that holds each. We then resolve each address to what it actually is, which is where we find deployer keys that still own things, multisigs with a threshold of one, and signers who left the company.

We interview the signers and examine the process: how a proposal is created, how it is communicated, how each signer verifies it, and on what device they sign. We ask to watch a routine signing. Blind signing, single-channel approval and the absence of independent calldata verification are findings.

We assess the infrastructure around automated keys: HSM or MPC configuration, the authentication in front of it, the policy engine, logging and alerting, and for MPC the team's dependence on the vendor.

We test the playbooks by running a rotation on a staging deployment with a simulated compromised signer. Findings are ranked by how directly they translate into a lost treasury, and the report ends with a tiered design the team can implement in order.

Practical next steps

• Enumerate every privileged action and the on-chain address that can perform it, then resolve each address to real keys and people.
• Move all catastrophic powers behind a high-threshold, diverse multisig with a timelock, and confirm on-chain that the deployer owns nothing.
• Eliminate blind signing by verifying calldata independently on hardware for every signer.
• Tier keys into cold, warm and hot with powers matched to the protection each tier receives.
• Write and rehearse rotation and recovery on a test deployment before the first real incident.
• Monitor the timelock queue with alerts that reach people who are not signers.

Our review scope is described on the services page, and you can reach the team on Telegram.