Research note, September 3, 2026. This article distinguishes confirmed facts, vendor statements, on-chain estimates, and our own analysis. Coinkite’s formal technical postmortem was still unpublished when this article was prepared. Loss totals changed as investigators attributed additional transactions, so figures below are dated snapshots rather than a final accounting.

In July 2026, Bitcoin disappeared from thousands of addresses whose owners believed their keys were protected by Coldcard hardware wallets. The first and most important correction is also the most revealing: the devices were not remotely taken over. A firmware error had weakened the randomness used when some wallets were created. Attackers could search the reduced key space elsewhere, recover candidate private keys, compare derived addresses with the public Bitcoin blockchain, and spend matching funds without touching the hardware.

A vault can be physically formidable and still fail if the secret placed inside it was predictable from the beginning.

That is why this incident matters far beyond one vendor. It challenges a comforting shortcut: hardware equals secure, more components equal more protection, and a long feature list equals high assurance. None of those statements is a threat model. Security comes from the complete system—entropy, firmware, hardware, build process, distribution, interface, backups, operator behavior, and physical safety—and from evidence that lets outsiders test its claims.

What happened to Coldcard

Coinkite’s official advisory says affected firmware used a faulty seed-generation path. Wallet seeds created on Mk2 or Mk3 firmware 4.0.1 through 4.1.9 were at risk unless sufficient private, independent dice entropy had been added or a strong, unique BIP39 passphrase created an additional barrier. The advisory also covers seeds generated on Mk4, Mk5, and Q devices before their fixed standard or Edge releases. For those later devices, Coinkite reported about 72 bits of entropy rather than the intended 128 bits.

The failure originated in firmware released in March 2021 and remained latent for years. Hardware protection worked on the secret it was given; the problem was that the secret-generation process did not provide the expected uncertainty. Once an attacker could enumerate plausible seeds at feasible cost, the public blockchain supplied a perfect membership test: derive addresses, look for value, and sign with any recovered key. No phishing prompt, USB session, stolen package, or physical access was required.

Why weak entropy is catastrophic

A wallet seed is not secure because it looks random to a person. It is secure when no adversary can feasibly distinguish or enumerate the underlying possibilities. Each bit of entropy doubles the search space. Moving from 128 bits to 72 bits does not make a seed “a little weaker”; it removes 56 doublings of work. An even smaller effective search space changes an astronomically impossible search into an engineering project.

The recovery words remain syntactically valid. The addresses look ordinary. The hardware signs normally. Backups restore correctly. This is a silent failure: every visible ritual can succeed while the security premise has already collapsed. That is precisely why random-number generation needs deterministic tests around the wiring, real-device instrumentation around the entropy source, and release evidence that connects reviewed source to shipped firmware.

The theft unfolded in waves

On July 30, the first reported sweep moved roughly 594 BTC from about 500 addresses in approximately 25 minutes. Later attribution expanded the incident. A TRM Labs assessment published August 5 described a running tally near 1,816 BTC—about USD 116 million at that snapshot—from more than 5,200 addresses across four waves. Other investigators used different confirmation rules and later reported somewhat different totals. These figures should therefore be read as evidence of scale, not a settled final ledger.

Coinkite’s current security-status page explicitly says the formal postmortem remains in progress and does not claim that every reported loss has been individually attributed. That uncertainty is not a reason to minimize the incident. It is a reason to preserve the difference between verified mechanism, observed transactions, analytical attribution, and final forensic conclusion.

Updating firmware does not repair an old seed

This is the operational fact affected users cannot miss. Fixed firmware corrects future seed generation; it cannot add entropy retroactively to a seed that already exists. A wallet restored from that seed onto new hardware remains controlled by the same vulnerable secret. Replacing the metal enclosure, installing a mobile app, or moving the words to another brand does not change the key. Funds have to move to addresses derived from a newly generated, independently protected seed.

As verified on September 3, 2026, Coldcard’s status page listed Mk4/Mk5 standard 5.6.1 and Q standard 1.5.1Q as the recommended standard releases. Its minimum fixed versions were Mk2/Mk3 4.2.0 or later; Mk4/Mk5 standard 5.6.0 or later; Q standard 1.5.0Q or later; Mk4/Mk5 Edge 6.6.0X or later; and Q Edge 6.6.0QX or later. Release tracks matter: a numerically higher Edge version is not automatically equivalent to a fixed standard release.

If you may be affected

  1. Stop relying on the enclosure. Determine the model, release track, firmware used when the seed was generated, and whether the official independent-dice exception clearly applies. If you are unsure, treat the seed as affected.

  2. Use only official instructions. Open the Coldcard advisory and security-status page directly, verify signed firmware and published hashes, and reject unsolicited “migration help.” No legitimate helper needs your recovery phrase.

  3. Create an entirely new seed in a fixed environment. Do not edit, shuffle, or append words to the old phrase. A new wallet needs new entropy. For a material balance, consider an independent implementation or a properly designed multisignature policy so one vendor’s seed path is not the only root of trust.

  4. Verify recovery before funding. Record the backup privately, recover it in a controlled process, and confirm the expected public fingerprint or receive address. A backup that was never tested is an assumption.

  5. Move a small test, then the remainder. Verify the destination and confirmation before moving the full balance. Avoid rushed improvisation, but do not confuse calm procedure with permission to delay an exposed seed.

  6. Retire the old seed. A firmware update and a strong passphrase added later do not repair it. Keep records needed for tax or legal purposes without retaining unnecessary copies of the secret.

Coinkite says at least 50 fair, independent, private dice rolls in the affected Add Dice Rolls workflow contributed at least 128 bits from the dice alone; 99 or more contributed about 256 bits. The exact conditions matter. If the sequence was recorded, observed, biased, non-independent, or uncertain, do not invent safety from the count. A strong pre-existing BIP39 passphrase may add a barrier, but Coinkite still advises migration and does not describe a passphrase as repairing the seed.

The device was not hacked—and that is the deeper warning

Calling every loss a “hardware-wallet hack” compresses several different failure classes into one dramatic phrase. That obscures the controls that would have helped. In the Coldcard incident, the attacker did not defeat the case, keypad, USB controls, or secure element in each victim’s possession. The attacker went around the device because the root secret was enumerable.

A security boundary only protects what crosses it. If the key entering a secure element is weak, if malicious firmware leaks it through signatures, if the screen displays an attacker-controlled destination, or if a person is coerced into authorizing a transfer, the existence of dedicated hardware does not answer the attack.

Hardware-wallet losses do not all look alike

Several documented incidents and research demonstrations show why the category needs precision. They do not prove that hardware wallets are useless. They show that hardware moves risk into a different system of chips, firmware, supply chains, host software, signing protocols, backups, and human procedures.

1. Fault injection and physical seed extraction

In 2020, Kraken Security Labs disclosed a voltage-glitching technique against Trezor One and Model T devices. Kraken reported that approximately 15 minutes of physical access could enable extraction of encrypted seed material and that a short PIN could then be brute-forced. Its practical mitigation was a strong BIP39 passphrase not stored on the device. Kraken documented a similar class of attack against KeepKey.

This is a different threat from Coldcard. It requires possession of the target device and laboratory-style fault injection. It demonstrates that tamper resistance depends on the chosen microcontroller and storage design, and that a PIN is not necessarily a high-entropy encryption secret.

2. Compromised software around a genuine hardware signer

In December 2023, the Ledger Connect Kit supply-chain incident injected malicious code into dApps that loaded a compromised package. According to Ledger, the code tricked EVM users into signing draining transactions. The hardware devices did not spontaneously reveal their seeds; the system around them presented malicious intent to legitimate signers.

This failure class is why “the key never left the device” is necessary but insufficient. A secure key can faithfully authorize the wrong transaction when the user, host, or display cannot reliably understand what is being signed. Clear transaction decoding, trustworthy displays, narrow permissions, dependency controls, and resistance to blind signing are part of custody security.

3. Malicious firmware that leaks secrets through normal signatures

Block researchers have published a practical research attack in which compromised wallet firmware covertly encodes secret material into apparently normal signatures. Their threat model assumes firmware compromise through routes such as a supply-chain breach, insider action, build-system compromise, or signing-key compromise. An air gap does not help if the signed transaction itself becomes the exfiltration channel.

This is where reproducible builds, multiple independent builders, pinned dependencies, secure boot, and multisignature diversity become meaningful. They address specific links in a chain. They do not magically certify the design, the source, or the operator.

4. Backup exposure, address substitution, and coercion

Many real thefts never exploit silicon. Attackers steal or photograph seed backups, replace a receive address, impersonate support, compromise a purchase or shipping process, obtain a device plus a weak PIN, or force the owner to cooperate. The recovery phrase remains a portable master credential by design: anyone who obtains it can restore the wallet elsewhere, regardless of where the original device is.

Why more complexity can make security worse

Complexity is sometimes justified. A separate display can make transaction review more trustworthy. A secure element can raise the cost of physical extraction. Multisignature can remove a single key as the point of failure. But every added mechanism also creates interfaces, states, update paths, dependencies, recovery procedures, and assumptions. The correct question is not “Is this complex?” It is “Which threat does each component control, and what new failure modes does it introduce?”

The classic Saltzer and Schroeder principle of economy of mechanism says protection designs should be as simple and small as possible so inspection and understanding remain feasible. Modern NIST systems-security guidance similarly treats attack-surface reduction and large, difficult-to-analyze multifunction components as architectural concerns. Simplicity is not the absence of controls. It is the refusal to add controls whose behavior cannot be explained, tested, and operated correctly.

  • More code creates more possible defects. It also makes complete review more expensive and makes interactions harder to reason about.

  • More modes create configuration risk. Standard versus Edge firmware, multiple seed workflows, passphrase wallets, USB and air-gapped paths, and backup variants can each be secure in isolation while becoming confusing in combination.

  • More interfaces create translation risk. A hardware screen, host app, QR format, microSD workflow, browser connector, and network backend must agree on exactly what the user is authorizing.

  • More ceremony can reduce compliance. If the safe path is difficult, people skip verification, postpone updates, reuse backups, or follow emergency instructions without understanding them.

  • More confidence can amplify loss. A product marketed as “cold,” “air-gapped,” or “unhackable” may encourage a user to consolidate more value behind one seed. Concentration converts one hidden defect into a catastrophic outcome.

Defense in depth is valuable when layers are independent. Repetition of the same implementation, same entropy source, same vendor, or same recovery secret is not independent defense.

Open source, audits, reproducible builds, and AI review are not synonyms

The Coldcard record is unusually instructive because its firmware was public and reproducible-build documentation existed while the vulnerable path remained in releases for years. That does not make openness useless. It shows that availability of evidence and actual examination of the right property are different things.

  • Open source means outsiders can inspect the implementation. It does not establish that anyone reviewed every security-critical path or that the public tree produced the installed binary.

  • An independent audit is a bounded engagement. Its value depends on the named reviewer, exact commit or version, threat model, tested properties, exclusions, findings, and remediation evidence. “Audited” without scope is a slogan.

  • A reproducible build lets independent builders follow a published recipe and compare outputs. A match can connect source to a release artifact; it does not prove the source is correct.

  • App-store review and code signing establish distribution and platform controls. They do not, by themselves, prove that an App Store binary is bit-for-bit equivalent to a public repository.

  • AI-assisted review can search large codebases, generate adversarial hypotheses, compare invariants, and accelerate human analysis. A model can also miss context, accept a false premise, or produce a plausible but incorrect finding. AI review is another lens, not a certification authority.

Coldcard’s current status page models good scope language: it names targeted real-device RNG instrumentation, source reviews, a hotfix review, and a reproducible build plus dice-path trace, then explicitly says those checks are not a complete audit of every firmware binary and do not guarantee the absence of defects. That sentence is more valuable than an unqualified badge.

What Aperture can honestly claim

Aperture is built around a different custody architecture: a source-available iPhone and iPad application rather than a dedicated hardware signer. The public repository exposes the mobile client and build instructions under the MIT license. The published security model states that wallet secrets are stored through the app-scoped iOS Keychain using this-device-only protection, while the local database keeps opaque references rather than recovery phrases or private keys. Transactions are constructed and signed on the device before signed data is sent to network infrastructure.

Apple’s platform-security documentation describes mandatory code signing, identified developers, automated and human App Store review, sandboxing, and runtime signature enforcement. Its Keychain documentation describes per-item protection and Secure Enclave involvement in Keychain key handling. These are real platform controls. They are not a claim that Aperture’s blockchain private keys themselves are Secure Enclave keys, and Aperture does not make that claim.

Aperture also deliberately narrows product surface. It does not operate a custodial account or a company-held recovery copy, and its core design avoids turning the wallet into a buy/sell desk, swap engine, or general in-wallet browser. Version 2.40.12 added physical-randomness health checks for extreme repetition, dominance, and predictable cycles when users build entropy from dice, coin flips, or digits. Those checks can detect obvious failure patterns; they cannot prove a physical process was fair or private.

Can Aperture be safer than a hardware wallet?

For some threat models, yes. As a universal claim, no. A phone wallet can avoid a dedicated device’s manufacturing and shipping path, reduce the number of objects that visibly signal valuable custody, use a platform with rapid signed updates and mature sandboxing, and place an inspectable implementation in a familiar interface that users are more likely to operate correctly. A smaller feature surface can also remove whole classes of browser, swap, approval, and cross-device translation risk.

For other threat models, a well-designed separate signer is an important boundary. If the phone operating system or wallet process is compromised, physical separation and an independently trustworthy display can prevent a networked host from obtaining or misusing a key. For institutional or life-changing value, the stronger architecture may be a carefully tested multisignature policy using independent implementations, independent entropy, separate locations, and documented recovery—not a contest between one phone and one hardware box.

The word “hardware” should therefore never end the analysis. An iPhone is hardware too. The relevant differences are which code executes, how it was built and distributed, where secrets are available, what the user can verify, how transactions are displayed, how updates occur, and which single failures can move funds.

The evidence boundary matters for Aperture too

Aperture’s website currently states that the app is independently audited and reproducibly built. Its public audit registry is designated as the canonical place for reviewer names, exact scope, dates, reviewed versions, reports, findings, remediation, hashes, and reproducibility material. At publication time, that registry did not yet display those concrete artifacts. The public GitHub repository also had no release artifacts against which an App Store binary match could be independently reproduced.

Therefore this article does not claim that “every line in the App Store binary has been proven safe,” that several companies have certified every behavior, or that AI has verified the whole application. Those statements would exceed the available public evidence. The technically correct distinction is that source code is published on GitHub, while Apple distributes a signed compiled binary through the App Store. Connecting the two requires a public build recipe, immutable source revision, dependency lock, captured App Store artifact, normalization procedure for Apple signing effects, matching result, and independent attestation.

Verification is strongest when a claim includes enough evidence for a skeptical stranger to reproduce it. Aperture should be judged by that standard as firmly as any hardware-wallet vendor.

What a university-grade verification package should contain

For researchers, auditors, journalists, and institutional evaluators, a credible wallet-security claim should be a navigable evidence chain rather than a badge wall. At minimum, ask for:

  1. A precise threat model. Name remote compromise, physical extraction, malicious updates, build-system compromise, weak entropy, transaction substitution, backup theft, coercion, and availability separately.

  2. An immutable reviewed revision. Identify the commit, dependency graph, compiler and SDK versions, build flags, entitlements, and configuration that were in scope.

  3. A named independent report. Publish the reviewer, methodology, dates, exclusions, severity criteria, findings, and the evidence used to close each remediation.

  4. Source-to-binary reproducibility. Provide a complete recipe and independent build results tied to the exact public release. Explain any nondeterministic or signing-generated differences.

  5. Entropy-path evidence. Test the source on real hardware, verify failure behavior, reject silent fallback, and trace the exact path used by the release build. Statistical output tests alone cannot prove the generator was wired correctly.

  6. Adversarial transaction tests. Exercise recipient substitution, fee manipulation, hostile metadata, blind-signing boundaries, interrupted broadcasts, and parser disagreement between every display and signer.

  7. Recovery and update drills. Test the instructions under realistic time pressure, including partial information, old versions, migration, lost devices, and the possibility that an update cannot repair existing secrets.

  8. Continuous, diverse review. Use deterministic tests, static analysis, human specialists, fuzzing, real-device testing, and AI-assisted review as complementary methods. Record what each method did and did not establish.

The threat can leave the screen

Self-custody can remove a custodian, but it can also make a person the final authorization boundary. A thief who cannot break the cryptography may target the owner, family, home, workplace, or public identity instead. Dedicated hardware can sometimes make that targeting easier by visibly advertising that a person takes custody seriously or by creating a physical object an attacker expects to find. A phone can also reveal holdings if balances are visible. Neither form factor solves coercion.

A 2024 peer-reviewed study, “Investigating Wrench Attacks: Physical Attacks Targeting Cryptocurrency Users”, analyzed interviews, forums, and 146 news articles. Its filtered news dataset contained 105 physical-attack incidents, including 24 kidnappings and 6 murders as the dominant reported act. The authors emphasize underreporting and found that experienced security practitioners were not immune. These figures describe the study’s dataset, not the worldwide incidence rate and not proof that a particular wallet type caused each crime.

The danger is not theoretical. In 2024, the United States Department of Justice described convictions in a conspiracy that used surveillance, home invasions, kidnapping, assault, and threats to force victims to drain cryptocurrency accounts. The lesson is not to panic or hide from legitimate help. It is to treat operational privacy and personal safety as part of wallet design.

Human safety outranks asset recovery

  • Do not advertise balances or storage details. Public addresses, screenshots, conference conversations, social posts, shipping records, and discarded packaging can connect identity, location, and perceived wealth.

  • Separate everyday funds from reserves. A spending wallet should not reveal or control the complete long-term position. Avoid consolidating every asset and recovery path behind one immediately accessible secret.

  • Use independent authorization for material value. Well-designed multisignature can prevent one stolen device or one coerced location from being sufficient, but only when keys, implementations, and recovery materials are genuinely separated.

  • Protect what the interface reveals. Use app-lock and app-switcher privacy controls, avoid displaying full balances in public, and verify recipients without exposing unrelated holdings.

  • Plan with qualified local professionals. High-risk individuals and institutions should develop lawful physical-security, travel, incident-response, estate, and family-safety procedures with experts who understand their jurisdiction and personal circumstances.

  • Never risk a life for a wallet. No recovery phrase, device, transaction, or amount is worth physical injury. In an immediate threat, prioritize human safety and contact local emergency services when it is safe to do so.

The lesson is evidence, not tribal loyalty

Coldcard’s failure does not prove that every current Coldcard is unsafe, every hardware wallet is theater, or every phone wallet is superior. Coinkite has published fixed releases, migration guidance, targeted independent validation, and explicit limits on what those checks establish. Responsible analysis should acknowledge both the severity of the incident and the remediation record.

Likewise, Aperture should not inherit trust merely by criticizing another architecture. Its public source, narrow custody model, Apple platform controls, local signing, and reviewability are meaningful. They become stronger when a named third party publishes scope and findings, when researchers can reproduce the distributed binary from immutable source, and when AI-assisted review is paired with deterministic tests and accountable human judgment.

The durable conclusion is simpler: security is not the material of the box; it is the quality of the secret, the behavior of the complete system, the independence of its defenses, the clarity of its interface, and the evidence available to verify every important claim. Complexity may be necessary, but it must earn its place one controlled threat at a time.

Continue with Aperture’s guides to building entropy from physical randomness, BIP39 passphrases, the self-custody security model, and app passcode and privacy controls.

Primary and technical sources

Aperture has no affiliation with or endorsement from Coldcard, Coinkite, Trezor, Kraken, Ledger, Block, or the cited researchers. Product and company names belong to their respective owners. This article is security education, not individualized financial, legal, or emergency advice. Never provide a recovery phrase, private key, wallet passphrase, app passcode, or backup password to a website, support agent, researcher, or AI assistant.