Ronin Lost $625M: Is Multisig Still Safer Than Threshold Signatures?

Ronin made the multisig vs. threshold debate immediate

The Ronin breach put custody back at the center of the security conversation. The bridge was exploited for over $625 million, and the stolen payload was 173,600 ETH and 25.5 million USDC. Even after recovery efforts, the sanctioned wallet still held 138,433.136 ETH valuing close to $402 million. That is a practical reminder of what can go wrong when attackers find a shortcut through custody.

Ronin exposed operational failure more than abstract design

Multisig remains popular because it keeps approval logic visible and on-chain. But Ronin showed that the failure point is often operational, not just mathematical: 4 of the 9 multisig keys were held by Sky Mavis, and attackers exploited weak key separation and centralized storage rather than breaking the 2-of-9 concept itself.

Threshold-signature advocates point to the older model's core weakness: one private key, one signer, one transaction. In that setup, whoever holds the full key is the weak link. Threshold architectures aim to remove that single target by splitting signing material and avoiding a full-key reconstruction step. That does not make them immune, though. Bad process, poor key-storage hygiene, or weak operator separation can still create a breach path.

Multisig still scales, but the failure surface splits by implementation

After Ronin, the question is less whether multiple approvers matter and more where the main failure surface sits. Safe secures tens of billions of dollars across more than a dozen EVM chains, which shows that multisig can work at scale. The trade-off is that the enforcement layer is usually a smart contract, so configuration, upgrades, and module hooks become part of the security perimeter.

Contract-based multisig and native multisig face different weaknesses

On EVM chains, multisig typically depends on deployed wallet contracts. That brings transparency and mature tooling, but it also means the contract layer is another component to secure. Native multisig removes that contract surface, yet it introduces a different problem: it is chain-specific and static, and changing signers often means moving to a new address.

That distinction matters for teams managing multiple chains or frequent signer changes. Contract-based multisig can bring integration complexity; native multisig can feel rigid. Both models can be safe, but the weak point changes depending on how they are deployed.

Threshold signatures reduce single-key risk, but execution still matters

Threshold signatures change the custody model by splitting signing material instead of relying on one assembled private key. That directly targets the old production pattern of one private key, one signer, one transaction. The benefit is not that attacks become impossible, but that a single key compromise is no longer enough on its own to move funds.

Why threshold signatures attract custody operators

A threshold signature appears on-chain as a standard single signature. That can simplify integration because networks do not need special multisig validation logic. It also helps teams avoid the smart contract risk that can come with contract-based multisig wrappers, while avoiding the chain lock-in and inflexibility of native multisig.

Demand reflects that trade-off. Approximately twenty different providers have announced threshold wallet products or licensable technology. That does not prove threshold is safer in every scenario, but it does show that many operators see value in simpler deployment, broader chain coverage, and a smaller custom-contract footprint.

How to choose between the two in practice

Neither model eliminates human risk. The better test is the specific threat model:

• Multisig works well when the priority is straightforward on-chain approval logic and the team can manage key custody and process carefully.
• Threshold signatures can be stronger when the goal is to reduce the value of a single key compromise and simplify cross-chain deployment.
• The real failure point in either case is usually operational: key storage, signer discipline, and operator separation matter more than the label on the product.

Ronin did not settle the debate by proving one architecture perfectly safe. It showed that custody design should be judged by where failure becomes cheapest for an attacker, and whether the operating process can actually contain that risk.