Seven Hacks Cryptograph Was Built to Stop
Cryptograph was not designed in the abstract. Every choice in the architecture is an answer to an attack that has already happened, often more than once, often to someone famous. This post walks through seven of the most well-known wallet failures of the last several years and pairs each with the part of the architecture that would have cut it.
The full mechanism reference (key derivation, encryption parameters, signing-authorization gates, recovery encoding) lives at the Technical Security Overview. This post is the readable case-by-case companion.
1. Bybit / Safe{Wallet}, February 2025
The largest crypto theft in history. Lazarus Group compromised a Safe{Wallet} developer’s machine and modified the JavaScript that served Bybit’s signing UI. When Bybit’s signers, using hardware wallets, approved what appeared to be a routine transfer from a cold wallet, the bytes they actually signed carried a delegatecall that handed control of the wallet’s logic to an attacker-controlled contract. The hardware wallets did exactly what they were asked to do. They signed precisely the payload they were given. The payload did not match the screen.
About 1.5 billion dollars left in a single signature.
What this exposed is the gap between what the user sees and what gets signed. The hardware wallets in the loop were not broken in any cryptographic sense. They were obedient. They signed the bytes the host sent them, and they trusted the host to be telling the truth about what those bytes meant.
What Cryptograph does instead. The watch decodes the raw payload itself. The display source and the signing source are the same bytes inside the watch. Even a fully compromised phone cannot show you a routine transfer while the watch signs a delegatecall to a malicious contract. The decoded transaction (token, amount, recipient, contract, action) is rendered on the watch from the watch’s own parse of the raw bytes, and the signature is produced over exactly that. There is no host-supplied summary anywhere in the signing path.
2. Slope, August 2022
Roughly 9,200 Solana wallets were drained for approximately 4.1 million dollars. The root cause was prosaic. The Slope mobile wallet sent the user’s seed phrase to a third-party logging service (Sentry) as part of its diagnostic telemetry, stored in readable text. Anyone with access to the Slope Sentry account had a list of seeds.
What this exposed is the difficulty of keeping a seed phrase off a smartphone. Modern phones run dozens of integrations from dozens of vendors. A wallet that handles the seed in process is a wallet whose seed can leak through any of them. It takes one analytics library, one crash reporter, one over-eager log line.
What Cryptograph does instead. The mnemonic is generated on the watch and never crosses the wire to the phone, encrypted or otherwise. The iPhone app could include every logging vendor on earth and there would be no seed material in scope to log. The phone is a display and a network proxy. There is nothing on the phone for an integration to exfiltrate.
3. G. Love’s stolen Bitcoin, April 2026
On April 11, 2026, Philadelphia musician Garrett Dutton (G. Love, of G. Love & Special Sauce) was setting up his Ledger hardware wallet on a new MacBook. He downloaded what appeared to be the official Ledger Live companion app from the Mac App Store. The listing was published under the name “Leva Heal Limited,” unrelated to Ledger, and the publisher had fabricated an update history that walked the app from version 1.0 to 5.0 over two weeks to make it look established. When the counterfeit app asked for his 24-word seed phrase, he typed it in. His wallet was drained of 5.92 BTC, approximately 430,000 dollars, almost instantly.
G. Love was one of more than fifty victims of the same campaign, which stole over 9.5 million dollars between April 7 and April 13, 2026 before Apple removed the app. Blockchain investigator ZachXBT traced the laundering through more than 150 KuCoin deposit addresses, distributed by a mixing service called “AudiA6” to stay under exchange-compliance thresholds.
What this exposed is that the seed phrase, as an interface, is unfixable. As long as the recovery mechanism asks the user to type twelve or twenty-four words into a computer, there will always be an app that pretends to be the right place to type them. App stores cannot reliably filter convincing counterfeits at scale. Brand trust does not survive a convincing icon and a believable version history.
What Cryptograph does instead. There is no flow in which the user types a seed phrase into any device, ever. The mnemonic exists, but it lives encrypted on the watch and is never asked for as user input. Recovery is two methods, both of which produce and consume encrypted blobs rather than word lists. The Recovery Sheet is an encrypted QR code you scan with your phone, which then forwards opaque ciphertext to your watch, which decrypts it inside the watch using a PIN or passphrase you set. The Photo Backup variant hides the same encrypted blob inside an ordinary JPEG. In neither flow does a string of mnemonic words exist anywhere outside the watch’s memory. A counterfeit Cryptograph companion app on the Mac App Store would have no field to phish, because the legitimate Cryptograph experience has none.
4. BadgerDAO, December 2021
A drainer attack against an EVM front-end. Attackers compromised BadgerDAO’s web UI (specifically the Cloudflare configuration) and quietly injected malicious JavaScript that asked users, mid-session, to approve token allowances to attacker-controlled contracts. Roughly 120 million dollars left in a few hours. Hardware wallets in the loop showed users opaque approvals: “smart contract interaction” with a long hex calldata blob, no decoded amount, no decoded spender. Users approved because they assumed the request matched the action they had just taken in the dApp.
What this exposed is that an approval transaction without a decoded spender, decoded amount, and decoded token is functionally a blank check. Hardware wallets that show “smart contract interaction” are asking the user to trust the host UI to have been honest about what is being approved. When the host UI is compromised, that trust is misplaced.
What Cryptograph does instead. Approval transactions are decoded on the watch: spender address, token, and amount, with an unmistakable warning when the amount is unlimited (MAX_UINT256 or its Permit2 cousin) and a second warning when the spender is not in the verified contract registry. Critical risk combinations (unlimited approval to an unverified spender) get prominent treatment. The user sees, on the watch screen, that they are about to grant an unlimited allowance to an unknown address, and can refuse. The same decoding layer handles Solana drainer instructions (durable nonce abuse is hard-blocked, not warned about) and ships new pattern coverage in app releases; the 1.1.3 release adds EIP-7702 delegation exploit detection.
5. Ledger CRM breach, July 2020
A breach of Ledger’s e-commerce database exposed around 272,000 customer records: names, physical addresses, email addresses, phone numbers. The data was posted publicly. In the years since, that database has fueled an ongoing campaign of phishing emails impersonating Ledger support and demanding seed-phrase entry to “verify your firmware.” Trezor experienced a structurally similar leak in April 2022 when its email list was exposed through a MailChimp breach.
What this exposed is that a wallet vendor’s operational posture matters as much as its cryptographic one. Any vendor that ships a physical device to a customer collects a name, an address, an email, and often a phone number. Any vendor that collects those records has built a list, any list can be leaked, and any leaked list becomes a targeting database for years afterward.
What Cryptograph does instead. Cryptograph collects no customer data of any kind. There is no account, no email collection, no shipping list (the app ships through the App Store; the company does not handle fulfillment). There is no customer support database, no marketing CRM, no analytics tying device IDs to wallet addresses. The wallet’s onboarding flow does not ask for an email address. There is no list to leak because the company has not built one.
6. Wrench attacks, 2025 onward
Once a vendor’s customer list is in the wild, every name on it is a candidate for an entirely different kind of attack. Several high-profile incidents in the past year have made the phrase “wrench attack” a regular fixture in crypto coverage. The January 2025 kidnapping of Ledger co-founder David Balland (whose finger was severed and sent to his business partner as part of an 11.5 million dollar ransom demand) and the May 2025 attempted kidnap of Paymium CEO Pierre Noizat’s daughter and two-year-old grandson in central Paris were both widely reported. CertiK’s tracking documented 72 confirmed wrench attacks in 2025, a 75 percent year-over-year increase, with France alone recording 19 incidents and accounting for the largest single-country share. The category is no longer hypothetical. Recognizable holders are being physically targeted, often after their addresses and identities have surfaced from breaches of the vendors they trusted.
What this exposed is that a hardware wallet, however well-protected cryptographically, is also a signal. Producing one from a luggage pocket announces that the carrier has crypto worth signing for. Once that signal lands on the wrong person, no amount of chip-level security helps. The attacker is not trying to read the keys; the attacker is asking the holder to sign.
What Cryptograph does instead. The watch on a wrist is not a recognizable wallet form factor. To a stranger it is a fitness device, indistinguishable from every other Apple Watch on every other wrist. Nothing about it suggests the wearer is worth approaching. When an attacker does approach, Time Lock caps how much can move in a session and forces a delay of 1, 3, or 7 days before larger amounts can be moved. Location Lock caps movement further when the watch is outside trusted zones. Changes to either setting are themselves delayed by the same interval, so an attacker who knows the gates cannot disable them on the spot. The system cannot distinguish consent under duress from consent given freely. What it can do is bound the worst-case loss and slow the timeline down enough to give the wearer recourse.
7. Ledger Connect Kit, December 2023
@ledgerhq/connect-kit is the JavaScript library that hundreds of dApps embed to handle Ledger hardware wallet connections in the browser. On December 14, 2023, a former Ledger employee’s NPM account was compromised through a phishing attack, and the attacker pushed three malicious versions of the package. Every dApp that loaded connect-kit from the public NPM CDN now served, alongside its normal connect-wallet flow, a fake drainer modal that proposed transfers and approvals to attacker-controlled addresses. Roughly 600,000 dollars left over the few hours it took to roll the package back. The Ledger hardware itself was uninvolved. The attack happened at the dApp UI layer.
From the user’s point of view this was BadgerDAO at fan-out scale. The same shape applied (a legitimate-looking dApp asks you to approve a transaction, you do, the bytes go somewhere bad), but the user did not have to visit a known-compromised site. They visited any one of hundreds of legitimate dApps that happened to share a dependency. One compromised package produced a coordinated drain across the entire ecosystem that used it.
What this exposed is structural, and bigger than Connect Kit specifically. The JavaScript ecosystem is the most reach-amplifying dependency graph in software history. A typical web project pulls in hundreds of transitive packages, each maintained by someone whose NPM credentials are one phishing email away from becoming the attacker’s. The Connect Kit compromise was unusual only in its profile; smaller NPM package compromises happen weekly and most do not make the news.
What Cryptograph does instead. No part of Cryptograph runs JavaScript. The watchOS and iOS apps are native Swift; the Android app is native Kotlin; the cross-platform cryptographic core is native Rust. There is no JavaScript engine in the signing path, no NPM packages anywhere in the dependency tree, no remote script loading at any layer. The dependency list is short and named: Trust Wallet’s WalletCore (BIP-39/BIP-32 derivation and signing across the EVM, BTC, SOL, LTC, DOGE, XRP, and Tron families), the Zcash protocol’s Rust crates for shielded transactions, the WalletConnect v2 protocol library, Apple’s and Google’s system cryptography frameworks, and the Cryptograph team’s own native code. Every entry is pinned to a specific version, or to a specific fork if we have audited and modified it. The full list is published at the Technical Security Overview. The Connect Kit compromise was a structural problem in the JavaScript ecosystem; the structural answer is to keep the signing surface out of that ecosystem entirely.
The pattern
Six of the seven cases above are species of the same problem: the user trusted a layer that turned out to be untrustworthy. A signing UI, a phone-resident wallet, a desktop companion app, a dApp front-end, a vendor CRM, a JavaScript package. The seventh case (wrench attacks) is different in kind, and the answer there is operational rather than cryptographic.
The architectural thesis behind all of them is the same. Reduce the number of layers the user is trusting, and pull as much of the decision as possible to a surface the user can directly perceive. The watch is small but it is yours, it is on your wrist, it decodes the bytes it is about to sign, and it shows you what they mean.
Cryptograph is available now on the App Store.
The Cryptograph Team