Ledger CEO Says Multi-Chain Security Depends on Isolation and Practicality
Ledger CEO Pascal Gauthier responded to Adam Back, stating that system complexity can indeed undermine security, but what truly harms users is usually not the number of supported cryptocurrencies, but rather invisible implementation flaws and complex setups that are difficult to operate securely.
Gauthier believes that narrowing the product range is one way to reduce risk, but it is not the only answer; another method is to isolate each asset in independent, closed applications, avoiding direct sacrifices to Bitcoin's security capabilities due to multi-chain support.
He stated that under this isolation architecture, Bitcoin applications can independently support Schnorr signatures and multi-signatures without being downgraded to a "minimum common capability" for transactions and custody due to the functional constraints of other assets or chains.
Gauthier also acknowledged that multi-chain products inherently mean a larger attack surface, more code to validate, and more security trade-offs, and Ledger is no exception; the company chooses to accept these trade-offs and manage related risks through independent testing.
He emphasized that a simpler product functionality range alone does not constitute a proof of security. The true test is whether the security architecture can withstand years of scrutiny, real fund scales, and real attackers.
In market mechanisms, dedicated Bitcoin hardware wallets reduce the complexity of transaction parsing, signature logic, and user interfaces by converging asset ranges; Ledger's multi-chain approach exchanges asset coverage and user convenience for "independent asset applications + hardware security isolation + external testing." The former attracts users who emphasize long-term custody of BTC and minimal attack surfaces, while the latter serves users who need to manage multiple assets and on-chain interactions within the same hardware device. The security premium ultimately depends on application implementation, firmware supply chain, transaction readability, key isolation, and user operation processes, rather than merely the number of supported cryptocurrencies.
Source: Public Information
ABAB AI Insight
Pascal Gauthier's response shifts the debate from "single-chain or multi-chain" to "security boundary design." Adam Back's position is to reduce trusted code and transaction semantics by narrowing the support range; Ledger's stance is to place different assets into their own independent applications, allowing Bitcoin applications to retain Schnorr and multi-sign capabilities. Both acknowledge that complexity is a source of risk, with the difference being that the former prioritizes reducing system scope, while the latter prioritizes controlling complexity overflow through isolation.
The core capital of hardware wallets is not the device shell, but rather the secure elements, firmware signatures, application loading mechanisms, transaction parsing capabilities, and user confirmation interfaces. If asset applications can truly be isolated, vulnerabilities in new chains should not directly alter the signature rules of Bitcoin applications; however, users still operate on the same device, with the same recovery phrase, and in front of the same desktop or mobile interface, meaning multi-chain complexity can shift from the code level to the device supply chain, permission prompts, blind signing, and user behavior levels.
This can be compared to the sandbox architecture of operating systems: a phone can run a large number of applications, but that does not mean each application has core system permissions; security depends on whether isolation is real, permissions are minimized, and vulnerabilities can be independently discovered and fixed. Ledger's "independent asset application" logic is similar to application sandboxes, while Bitcoin-only wallets are closer to installing a clearly defined minimal system. The former gains ecological compatibility, while the latter reduces the scope that needs to be proven secure.
Essentially, this is an engineering governance issue beyond technical alternatives: security is not a product label, but a continuous validation process. The mechanism is that dedicated systems reduce attack surfaces but may still have supply chain, firmware, or recovery process vulnerabilities; multi-chain systems increase functionality and validation work but can reduce risks through strong isolation, independent testing, and long-term practical experience. For users, what matters most is not the promotion of "multi-chain" or "single-chain," but whether the device can clearly display transaction intentions, avoid blind signing, whether the recovery process is controllable, and whether large assets are physically or account-level isolated from high-risk dApp operations.
ABAB News · Law of Cognition
Simplicity reduces risk, isolation limits risk spread
Functionality is not a vulnerability; uncontrolled boundaries are
Security relies on architectural validation, not product stance