The fresh Bybit exploit in an Ethereum smart contract has revived long-standing debates about the security trade-offs built into the Ethereum protocol.
This new incident draws attention to the limitations of the Ethereum Virtual Machine (EVM) and its reliance on complex, stateful smart contracts—particularly when it comes to securing multisignature (multisig) wallets.
The Core Problem with Ethereum Multisig
Multisig wallets serve as a fundamental security layer by requiring more than one signature to move funds. On Bitcoin and the Liquid Network, implementing multisig is straightforward thanks to native opcodes (e.g., OP_CHECKMULTISIG), or Schnorr-based interactive multisignatures, which keeps the code surface small and less prone to bugs.
On Ethereum, however, developers must create custom code to replicate multisig functionality—leading to additional complexity and greater risk. These contracts must manage on-chain state, handle reentrancy (where an attacker calls a contract in the middle of its own execution), and ensure that the logic for multiple signers is correctly enforced.
Mistakes in these areas can introduce critical vulnerabilities, as we have seen with high-profile incidents like the Parity wallet hack in 2017.
Systemic Challenges in Ethereum’s Design
- Lack of Native Multisig
Bitcoin’s design includes built-in scripting commands for multisig transactions. Ethereum does not offer a direct equivalent, so you must write a contract that handles multiple signatures, tracks the current state on-chain, and updates each time a signature is added. This approach makes audits more difficult and increases the likelihood of bugs.
- Highly Expressive Scripting Environment
The EVM allows for almost any type of computation: loops, arbitrary function calls, and interactions with multiple contracts. While this flexibility enables complex decentralized applications (dApps), it also makes formal security audits more challenging. Developers have to consider:
- Reentrancy: When a contract calls out to another contract, that contract can call back into the original one, sometimes before state updates are finalized.
- Shared Global State: Many contracts share the same global key-value store. A bug in one contract or library can open up vulnerabilities that affect completely different contracts.
- Gas Constraints: Every operation costs gas. Running out of gas at the wrong time can freeze or break contract logic.
- Global Key-Value Store
Ethereum uses an account-based model with a universal state tree. Each contract update can influence or interact with data used by other contracts. In contrast, Bitcoin’s UTXO (Unspent Transaction Output) model localizes state changes to individual transactions, reducing the risk that one contract’s flaw will leak into another’s operation.
thank you. so many wise guys on threads today, who do not understand anything. it's not just ledger, all HWW do this with ETH because HWW are far too low power to interpret and contain the information to verify EVM over-complex scripts and state. https://t.co/6m1ymhum78
— Adam Back (@adam3us) February 24, 2025
Why Ethereum’s Multisig Model Fails
Ethereum users seeking enhanced security with multisig generally face three choices:
- Single Key Management
Straightforward, but if someone gains access to the single private key, they control all the funds.
- Complex Multiparty Computation (MPC)
Advanced cryptographic techniques, like threshold ECDSA, reduce single points of failure. However, they often require specialized libraries and can be computationally demanding.
- Custom Smart Contract Multisig
The most common method on Ethereum, yet also the most dangerous. It exposes users to bugs in the underlying contract code, which can be catastrophic if attackers find a loophole.
The latest incident illustrates how Ethereum’s complexity increases reliance on potentially flawed interfaces, where users trust the frontend to display correct transaction details, only to be misled into signing harmful transactions with hardware that does no independent verification.
By contrast, Bitcoin’s native multisig opcode keeps things simpler. You only need to specify how many signatures (e.g., 2-of-3) are required, and the protocol enforces it without complex contract logic.
A Glimpse into the “Post-Simplicity” Future
While Ethereum contends with repeated contract exploits, Bitcoin and its sidechains are evolving toward more robust multisig approaches.
On Bitcoin, cryptographic schemes like MuSig aggregate multiple signatures into one, making multisig transactions look like standard singlesig. This benefits both privacy and efficiency.
Looking further ahead, the proposed Simplicity language on Liquid aims to provide the flexibility of a higher-level scripting language while retaining Bitcoin’s careful approach to security.
Rather than offering Turing-complete smart contracts, Simplicity focuses on formally verifiable scripts (easier to audit and prove correct) and advanced features like covenants and custom sighash types, all designed to avoid the pitfalls seen with the EVM’s unbounded computations.
A Cautionary Note for Expressive Smart Contracts
The latest Ethereum multisig hack underlines a crucial lesson: the more complex your scripting environment, the more you have to worry about hidden security holes.
Ethereum’s flexibility demands constant vigilance in contract coding, auditing, and updates. By contrast, Bitcoin’s multisig solution is built directly into the protocol, significantly reducing the possibility of critical failure due to coding errors.
As the blockchain industry matures, it’s increasingly evident that security must be a top-level design choice—not a feature layered on after the fact.
Ethereum’s struggles with contract-based multisig make a strong case for protocols that offer robust security primitives natively, rather than placing the burden on developers to reinvent the wheel (and risk reinventing the vulnerabilities) every time they need a secure multisig solution.