What Are Multi-Sig Verifiers 

Compromised multi-sig verifiers have been the catalysts to more than $2.8 Billion in total money hacked via bridges in Web3. 

‍

Approximately $2.8 billion (almost 40% of total value hacked in Web3) has resulted from bridge hacks since 2022. Five of the most infamous bridge hacks: Alex Bridge, Multichain Bridge, Orbit Chain, Ronin and Harmony were all reported as exploits caused by compromised private keys within the multi-sig verifier. Interestingly, total crypto hacks also rose by 40% across 2024 with over $4.3 billion being drained via exploits and recently $1.5 billion was drained from Bybit by the Lazuras Group.  

‍

Cross-chain bridging sees $120 billion in volume annually with estimates suggesting this figure could reach anywhere between $200 - $300 billion (based on peak 2024 monthly volumes) by the end of the year. With hacks and volume both on the rise, 2025 represents a pivotal moment for cross-chain infrastructure to understand and review their security stacks. 

‍

This article examines the drawbacks of current, outdated multi-signature (multi-sig) verification approaches and highlights the industry need for hyper-specialized modular verification models. 

‍

Article Overview 

1. What Is A Multi-Sig  
2. Multi-Sig Challenges 
3. Why Protocols Use Multi-Sigs 
4. The Take-Away | App builders need better options

What Is A Multi Sig 

‍

Multi-sig, also called multisignature, is the requirement for a transaction to have two or more signatures before it can be executed. In the case of multi-sigs for cross-chain verification, if one or more of the required signatures are missing a transaction cannot be successfully verified and is reverted. Each signature within a multi-sig is issued by an owner with a private key. Private keys are used to confirm the signature of a verification message. If you use a wallet like Metamask, you use your private key every time you sign a confirmation message before executing a transaction. 

‍

Multi-sigs are an “M of N” design where M represents the mandatory amount of signers required and N represents the total number of signers available. Any combination can theoretically be used, however the most common cross-chain models used are 1/1 and 2/3.

‍

The general belief is the more mandatory signers required from the greater number of signers available, the more robust the multi-sig is. By increasing the mandatory threshold and total signers, more parties are required to sign verification, in theory reducing centralization risks. However, higher M/N models do not guarantee distribution and decentralization of keys, as we will explore in the following section. 

Multi-Sig Challenges 

‍

While higher signature thresholds theoretically enhance security, the number of signatures doesn't guarantee decentralization. This was evident in the Multichain Bridge hack of 2023, where multiple keys were allegedly controlled by a single individual—the CEO. In the multichain instance, once a hacker took control of the CEO’s device, all private keys were available on the device, representing an unnecessarily large single attack vector.  Key custody concentration highlights how multi-sig systems, among several other issues, can remain dangerously centralized despite requiring multiple signatures. 

Challenges Faced With Private Keys 

‍

1. Lack of transparency around key storage security

For end-users, very little to no information is provided from companies on the security measures taken to store private keys. Bad practices such as storing all keys behind a single password or on the same device can lead to malicious actors gaining control of multiple private keys in one attack. The importance of good practice was highlighted by a Halborn report that examined the 2024 Orbit hack - where at the time of writing it remained unclear about the storage of Orbit private keys. Projects like Axelar, require their validator sets to rotate keys periodically.

2. Collusion risks

Collusion risk refers to the probability of multiple parties with majority ownership of private keys operating together to sign and alter messages for their benefit, such as “infinite mint attack”.  As possibly experienced in the Multichain Bridge hack, a single owner or several owners could work together to alter cross-chain messages to trigger unauthorized events like altering of destination addresses. This risk is heightened when multiple keys are owned by single individuals.

3. Unnecessary Trust Requirements 

‍

While Web3 was designed for distributed, trust-minimized systems, relying on non-transparent, centrally managed multi-sig setups for cross-chain asset transfers introduces trust dependencies that compromise the decentralized nature of underlying interoperability infrastructure. This unnecessary trust is especially true when permissionless, trust-minimized systems with inherent decentralization, such as the SEDA IVM, exist. .

4. Downtime Risk

‍

While not directly related to hacks, downtime refers to a verifier going offline. This can occur due to a multi-sig being overwhelmed in periods of unexpected transaction throughput or even if protocols halt verification due to suspecting suspicious behaviour. In the event of unexpected transaction rate, multi-sigs may not be able to maintain function at the speed required, resulting in a period of inactivity stalling all transactions. While a positive sum event signalling the ongoing growth of leading cross-chain apps, recent multi-sig downtime is just another example why builders need better verification options. 

Why Do Protocols Continue To Use Multi-Sigs

‍

Multi-sigs are not necessarily a black and white, good or bad situation. The basic reason why multi-sigs continue to be used by message based bridges tends to be a combination of:

1. Developer Efficiency:
   By defaulting to use a single protocol operated multi-sig developers mitigate the need to configure custom verification stacks of various 3rd party multi-sigs. When building on top of the interop provider they can natively use the inbuilt verification (often a protocol multi-sig) and focus attention on their product. This mitigates the time required to understand each independent verifier's function, reach and security guarantees.
   
   
2. Single Security Zones:
   A security zone is the number of chains verified by a single or group of verifiers. When using a default protocol operated multi-sig, developers can verify state on all the chains operated by the provider. However, if developers want to distribute their verification mechanics across multiple verifiers, they must create custom stacks of verifiers that can service the chains they need. 

This can be a tedious process requiring the knowledge of each verifier's function within each new security zone. As a result the apps security is only as strong as their weakest zone, in that for long-tail routes only a default and relatively unknown verifier may be available. 

3. Faster Expansion: 

Building across multiple chains is not an easy task. For app developers it is possible that they are comfortable putting trust on the cross-chain provider to focus time and resources on building their product. 

‍

Additionally leading interop providers LayerZero created the concept of a “customizable security stack” in the release of their V2. Apps building on LayerZero can access a marketplace of verifiers, known as DVNs” and build out their own custom stacks to inherit security standards relevant to their application. While there are non-multi-sigs available, the majority of DVNs selected are 2/3  multisigs or LayerZero’s own operated 2/3 signature. 

‍

This suggests that either available verifiers within the marketplace do not offer significant security upgrades to warrant the time required to compose custom stacks, or that the majority of builders prefer to trust LayerZero more than unknown 3rd parties. 

‍

With compromised private-keys remaining a prominent vulnerability for cross-chain hacks, additional systems with significant security upgrades, are required to bolster traditional multi-sig models securing billions of dollars in value. 

The Take-Away | App Builders Need Better Options 

‍

With any technology it is natural that designs are optimized over time. While muti-sigs represented a “first iteration” solution for earlier eras of cross-chain technology, the current landscape of >$120 billion in cross-chain volume demands more robust systems. Additionally, the rise in new blockchain deployments demand interoperability providers continue to focus on service expansion, rather than directing resources to time-heavy commitments to build out new verification models. 

‍

The DVN Marketplace by LayerZero and Hyperlane's ISM verification marketplace offer developers many options for building custom security stacks. Yet most verification systems available are basic, trusted and unnecessarily centralized, using low-threshold 1/1 or 2/3 multi-signatures that serve only a few chains. Since there's limited value in configuring custom verification stacks and the demand on interop providers to expand, developers need permissionless access to decentralized and trustless verifiers across any network.  Verification marketplaces maintain their value by offering developers permissionless access to premium options like SEDA's IVM, ensuring applications benefit from interoperability providers without sacrificing security.

‍

Learn more about why builders are integrating the SEDA IVM alongside traditional multi-sig verifiers here. 

‍