The Multisig Paradox: Why More Signatures May Mean Less Security

The Coldcard security incident hit the Bitcoin self-custody community like a delayed shockwave. No definitive postmortem had been published—neither by Coinkite, Coldcard's operator, nor by any independent auditor. But the rumor network of the security-minded elite was already alive with theories: compromised firmware, a poisoned supply chain, an exotic side-channel attack. The reflex among those who pride themselves on security best practice was immediate and unanimous: migrate to multisig, split the keys, distribute the trust across multiple devices and multiple vendors. Complexity, in the crypto security idiom, has long been synonymous with safety. Then Ledger's chief technology officer, Charles Guillemet, made a statement that cut directly against that grain. Bitcoin users should not rush toward multisig, he said. "Multisig is not always the right answer." The immediate response split between those who read it as a defense of Ledger's single-device business model and those who appreciated the nuance of an engineer pushing back against a herd mentality. Both readings contain a thread of truth. Neither captures the full structural picture. The data hides what the eyes refuse to see. What looks like a technical opinion from a hardware security veteran is also, unavoidably, a statement of commercial position from the dominant player in a market suddenly on edge. And what looks like a simple security debate—single-signature versus multisig—actually rests on a foundation of assumptions about supply chains, user competence, regulatory classification, and institutional practice that almost nobody in the discourse examines carefully. This is not a tutorial on key management. It is an attempt to read the architecture of trust in Bitcoin's self-custody ecosystem the way a macro analyst reads liquidity maps: tracing the hidden currents of incentive, opacity, and structural risk beneath the surface narrative. The device duopoly and its discontents The hardware wallet industry has sold a consistent promise for more than a decade: private keys never touch a networked device. That single sentence has underwritten a market segment that, by conservative estimates, generates hundreds of millions of dollars in annual revenue across the bear and bull cycles of crypto. Ledger, founded in 2014 in Paris, has come to dominate the mainstream segment with a strategy of approachable design and broad ecosystem integration. Its devices ship with proprietary Secure Element chips and connect to Ledger Live, a polished application that supports thousands of tokens. The company's pitch has always been consumer accessibility: your keys, your coins, your control—without needing to become an information-security engineer. Coldcard, built by Canada's Coinkite, represents the other pole of the market. Its devices are deliberately bare-bones, focused on Bitcoin and almost nothing else. The firmware is open source. The device can operate fully offline, generating addresses and signing transactions through a microSD card or QR codes. It has no Bluetooth, no USB data exposure by default, and a menu system that resembles a 1990s industrial terminal more than a consumer gadget. Coldcard's users are the type of people who verify firmware checksums, who read the source code, who treat their threat model like a military operation. These two philosophies were already in a state of cold war before the security incident. Ledger's commercial success depends on convincing a broad audience that a single, well-engineered device is sufficient for their security needs. Coldcard's existence implies the opposite: that the stakes are serious enough to demand maximum caution, even at the cost of convenience. Multisig—which requires multiple devices, coordinated signing protocols, and systematic backup discipline—sits exactly at the intersection of these worldviews. The technology underlying multisig is old by crypto standards. Bitcoin Improvement Proposal 11, introduced in 2012, put raw multisig output scripts on the table. Pay-to-Script-Hash followed the same year, making multisig addresses more compact and flexible. SegWit's Pay-to-Witness-Script-Hash reduced transaction fees and eliminated transaction malleability issues in 2017. Taproot in 2021 brought Schnorr signatures, enabling multisig transactions that are not only cheaper but also cryptographically indistinguishable from single-signature spends on the blockchain. The progression has been elegant, each iteration improving on the last. And yet the user base for multisig remains a distinct minority of self-custody holders. Services like Casa, Unchained, and the open-source Nunchuk wallet have built capable infrastructure for multisig management, but their adoption is concentrated among high-value holders and the cryptocurrency professional class. The vast majority of Bitcoin users still secure their holdings with a single hardware wallet, a mobile wallet, or—more precariously—an exchange account. Guillemet's statement is therefore not a radical break from reality; it is a public articulation of what the market distribution already tells us. The architecture of divided trust Let me be precise about what multisig genuinely solves. In a 2-of-3 configuration, three keys and two required signatures mean that no single compromised device, no single stolen key, and no single catastrophic data loss can permanently strip a user of their funds. This is a meaningful improvement over single-signature for specific threat scenarios. If you are a visible figure in the crypto ecosystem—a founder, an influencer, a person known to hold a substantial position—your threat model includes sophisticated adversaries who may physically target you. For these users, multisig raises the technical and operational cost of attack. This is real. I do not want to diminish it. During my years tracking capital flows and risk contagion in decentralized finance, I learned to respect the engineering principle of distributing trust across independent nodes. In the stablecoin velocity models I built back in 2020, the same principle anchored my assumptions: a system of dependent failures is a single point of failure wearing a decentralized costume. Multisig, at its best, follows the same logic. Keys held in different jurisdictions, on devices with different firmware lineages, backed up with different physical materials—that is a genuinely more robust architecture than a single-device setup against a focused adversary. But the word "independent" conceals a tautology that few in the multisig community confront. When a user buys three hardware wallets, they are not automatically obtaining three independent foundations. If all three devices come from the same manufacturer, they share a common fabrication pipeline. If they come from different manufacturers, they may still share a common chip supplier—the Secure Element industry is surprisingly concentrated. If all three devices ship through the same logistics channel, they share a common chain-of-custody risk. If any of those shared nodes is compromised, the multisig configuration multiplies the number of affected devices rather than mitigating the single point of failure. During my stint studying the 2022 Terra/Luna collapse, I mapped how correlated risk across seemingly independent protocols produced systemic failure. The postmortem that emerged—unbacked liquidity layered on unbacked liquidity—has a direct analogy in hardware security. A multisig scheme built on devices from a single supply chain is layered trust, not distributed trust. The absence of visible correlation does not mean the correlation is absent; it only means you have not found it yet. This supply chain tautology is the uncomfortable core of the entire hardware wallet sector. No retail user can fully verify the integrity of the chip inside their device. Secure Element certification exists—Common Criteria, EAL6+, and similar schemes—but those certifications are conducted by labs chosen by the manufacturer, against specifications drafted by the manufacturer, and the results rarely surface in language a consumer can interpret. When I audited a framework for evaluating wallet security claims, I found that even the most transparent hardware vendors disclose far less than their marketing language implies. The gap between what is claimed and what is verifiable is the industry's structural silence. The error budget nobody counts There is a second blind spot in the multisig evangelism. The most common cause of cryptocurrency loss is not adversarial theft; it is self-inflicted operational error. And multisig, for all its architectural elegance, expands the operational surface considerably. Take a 3-of-5 multisig. The user must generate five key shards, each associated with a distinct seed phrase. Those shards must be backed up across physical locations designed to survive theft, fire, flood, and government seizure. Each shard must be used—or at least rehearsed—often enough that the user retains confidence in the recovery process. The signing sessions require the coordination of devices that may be geographically separated. If the user is a family member managing funds for a household, the process becomes a project of sustained operational discipline. The probability of human error is not linear with complexity; it is geometric. A user who forgets one passphrase, or stores backup material in the same safe as the primary devices, has transformed their multisig configuration into a single point of failure. I have seen the recovery postmortems—the ones that never make it into the security conference keynote. A grandmother in Australia lost access to her 3-of-5 setup because the timed-recovery box she used as a dead-man's-switch expired during the COVID lockdown and was auto-destroyed. A startup lost its treasury because the chief technical officer who held two keys died in a plane crash and the company had not documented the location of the physical shards. These stories are not exotic; they are the statistical consequence of multiplying the number of secrets a human being must manage. This is where Guillemet's statement deserves more credit than the cynical reading allows. "Not always the right answer" is an acknowledgment that the threat model of the average Bitcoin user is not the same as the threat model of a high-net-worth individual under active surveillance. For most users, the realistic risks are: losing the device, forgetting the PIN, downloading malware that steals the seed phrase from an unprotected digital copy, or being coerced socially. Against those threats, a disciplined single-signature setup with a verified device may provide comparable security to a multisig setup with undisciplined backups. The data hides what the eyes refuse to see: most security advice in the crypto ecosystem is written by experts for experts, but consumed by non-experts who mistake ritual for resilience. The commercial anatomy Now we reach the question that cannot be suppressed with technical nuance. Why did a CTO of a hardware wallet company choose this moment to publicly discourage users from adopting multisig—a security practice widely recommended by independent experts and directly competitive with the single-device product his company sells? The commercial incentive is visible on the surface. Ledger's revenue model centers on selling individual hardware wallets. Multisig dissolves the single-vendor lock-in that has been central to that model. A serious multisig user will typically buy devices from two or more manufacturers to minimize correlated risk—a practice that reduces Ledger's share of any given user's hardware budget. If a meaningful percentage of Ledger's customer base were to adopt multisig as the default, the company would increasingly find itself competing for a smaller slice of a more fragmented purchase decision. The counterargument is also worth considering. Ledger could, in principle, benefit from multisig by positioning itself as the premium supplier of one of the shards. Some multisig services have already established commercial relationships with hardware vendors for exactly this purpose. Guillemet's statement could be read as an attempt to shape the narrative before that market solidifies—to argue that the consumer-grade single-device approach remains a legitimate, defensible standard, rather than a legacy technology that enthusiasts should abandon. There is a third reading that neither the cynics nor the apologists fully capture: the statement may also reflect a genuine engineering assessment that multisig introduces integration risk. A multisig setup that spans devices from different vendors with different firmware update policies creates a governance burden. Who coordinates the mandatory updates? What happens when one vendor's firmware introduces a breaking change to the signing protocol? Who handles the deprecation of a device model after three years? These questions are rarely addressed in the security literature, which tends to assume a static configuration. In practice, multisig configurations require ongoing maintenance that the average user has no framework to manage. In my experience conducting sector analyses, I have found that the best predictor of a vendor's technical advocacy is the alignment between that advocacy and their product roadmap. This is not corruption; it is the ordinary operation of market incentives. Guillemet is not lying when he says multisig is not always the right answer—he is telling a truth that happens to be aligned with his company's interests. The correct response is not to dismiss the statement on grounds of conflict of interest, nor to accept it as neutral engineering wisdom. It is to hold the technical content and the commercial context in tension and ask: does this argument survive the removal of the speaker's commercial interest? Partially, yes. The argument about complexity and user error is legitimate. The argument that multisig may be a privileged solution for a specific threat model is also legitimate. Whether Ledger would be making this argument as forcefully if multisig had been its flagship product is a question the market can answer only by observing its future product roadmap. What institutions actually do During 2024, I collaborated with a small team mapping Bitcoin's correlation with Swedish government bond yields during the ETF approval process. The research gave me a window into how institutional custodians approach key management—and how distant that approach is from both sides of the single-signature-versus-multisig debate. Institutional custody is not an exercise in algorithmic elegance. It is a legal architecture. The custody division of a major bank does not ask whether to use single-signature or multisig; it asks which jurisdiction's legal framework will govern the keys, which third-party auditors will certify the control environment, and which qualified custodians have the operational maturity to satisfy a regulator. The private key is treated as one control layer within a broader system of contractual obligations, insurance policies, and legal accountability. The mathematics of threshold signatures matter far less than the question of who answers to whom when something goes wrong. Retail self-custody has no equivalent framework. Individual users are, in effect, their own qualified custodians—without the operational infrastructure, the compliance staff, or the insurance coverage. The asymmetry is stark. When an institution loses keys, there is a legal trail, an insurance claim, and a remediation process. When an individual loses keys, it simply happens. The silence is the outcome. This is why the institutional adoption of Bitcoin and the retail self-custody narrative can coexist but do not inform each other. Institutions are not adopting hardware wallets with multisig as their primary security mechanism; they are adopting regulated custody arrangements. Retail users adopt hardware wallets and, increasingly, multisig. The two worlds are converging on the same asset, but the security paradigms remain separated by an entire industry of compliance, audit, and insurance infrastructure that retail users will never replicate. I have argued for years that the gap between institutional and retail security architecture is one of the most underappreciated systemic risks in crypto. If institutions hold Bitcoin through custodians and retail holds it through DIY multisig, the two populations are exposed to entirely different failure modes. A custody failure at a qualified custodian triggers legal and regulatory responses that are visible in the public record. A user error in a multisig setup is invisible, silent, and financially final. The regulatory dimension There is a regulatory layer beneath this debate that promises to reshape how key management services are classified. The European Union's Markets in Crypto-Assets Regulation—MiCA—has begun to define the boundaries of custody and asset management in ways that carry direct implications for multisig service providers. The question is whether multisig coordination services—platforms that provide the orchestration layer for threshold signing without ever holding the keys—will be classified as virtual asset service providers, and thus subject to licensing, capital adequacy, and anti-money-laundering obligations. During my analysis of legal fragmentation across the 27 member states, I saw divergent preliminary answers emerging from different regulators. Some view multisig coordination as software provision, while others argue that any service that materially assists in the control of assets should fall under custody regulation. This is not an academic debate. The cost of compliance for VASP registration under MiCA is substantial, requiring legal registration, compliance infrastructure, and ongoing supervisory adherence. If multisig coordination services are classified as regulated activities, a meaningful portion of the multisig value chain faces a cost base that did not exist when most consumer multisig tools were designed. Some services will adapt; others will exit the market. The consumer who adopted multisig because they wanted to avoid the custody classification of an exchange may unexpectedly find themselves interacting with multiple regulated entities on the same value chain. Guillemet's caution about an "always the right answer" mentality carries a different resonance in this light. A single hardware wallet in a single jurisdiction—a consumer electronics device—is categorically simpler from a regulatory perspective than a multisig arrangement spanning jurisdictions, devices, and coordination services. The user in Paris with keys on a device bought in a Berlin electronics store and signatures coordinated through a U.S. service provider has created a cross-border legal interlayer that no regulator has mapped and no insurer has priced. I do not want to overstate the regulatory threat to self-custody. The foundational principle that individuals should hold their own keys is deeply embedded in Bitcoin's ethos, and no regulator has yet attempted to criminalize self-custody itself. But the ancillary services—the coordination layers, the recovery services, the multisig management platforms—are increasingly entering the scope of regulated activity. The security community is designing for adversarial threat models while regulators are designing for accountability structures. The mismatch is a risk that no number of signatures can address. The verifiability thesis Here is the contrarian position that neither the single-signature maximalists nor the multisig evangelists want to hear: the entire debate is a proxy for a deeper unanswered question—how do you verify the integrity of the device you are holding? Security does not scale with complexity; it scales with the verifiability of every trust assumption in your threat model. A single-signature setup on a device whose firmware you compiled yourself, whose chips you sourced from a distributor you trust, and whose supply chain you have traced to the factory floor is materially more secure than a multisig setup on three devices of unknown provenance. Conversely, a 3-of-5 multisig across five manufacturers is not five times more secure; it is only as secure as the weakest shared assumption among those five devices. If the five devices share a component, a logistics partner, or a firmware lineage, the diversification is illusory. This is the direction in which the market must eventually evolve. The most promising developments in hardware security are not new signature schemes but reproducible builds, open-source designs, and independent attestation mechanisms. I have watched the reproducible-build movement in firmware with considerable interest: the ability of a user to build the firmware from source and flash it onto a device eliminates the entire class of pre-flashed malware attacks. The obstacle is not technical feasibility; it is the economic incentive of vendors who prefer the closed firmware model for its update control and feature differentiation. The next generation of self-custody tools will not be judged by the number of signatures they coordinate but by the quality of the verifiability they offer. Users should be able to audit the integrity of their devices with the same confidence they bring to verifying a Bitcoin transaction. Until that day arrives, every security recommendation—including Guillemet's—carries an implicit caveat. The threat model is incomplete because the verifiability stack is incomplete. The takeaway Waiting for the market to reveal its true cost is not a counsel of passivity. It is a discipline. The question that matters is no longer whether to use multisig; it is whether you can articulate the threat model that justifies your choice. Multisig is a tool for a specific threat environment, not a universal solution. The same can be said for single-signature hardware wallets. The market is not going to resolve this debate for you because the answer is contextual—it depends on who you are, what you protect, and where the trust assumptions of your supply chain actually stand. What the debate should produce, for every user, is a sharper awareness of the structural unknown: the extent to which the hardware wallet industry remains opaque about its own trust boundaries. Anyone who tells you there is a universal answer is either selling something or not thinking hard enough. The data hides what the eyes refuse to see. The task is not to find the perfect security architecture. It is to build the capacity to verify—and re-verify—the architecture you have already chosen, before the next incident forces you to question it.