Back to Blog
Compliance & Security

The COLDCARD Hack Shows That Proof of Wallet Ownership Is Not Proof of Wallet Security

Accredifi Team
•
The COLDCARD Hack Shows That Proof of Wallet Ownership Is Not Proof of Wallet Security

The July 2026 COLDCARD seed-generation vulnerability exposed an important boundary in crypto wallet verification: a valid signature can prove present control without proving secure or exclusive custody.

A COLDCARD user could produce a valid signature from an affected wallet while an attacker was independently capable of reconstructing the wallet's seed and moving its Bitcoin.

There is no cryptographic contradiction. The user and the attacker may both have access to the same signing authority.

That distinction is the central lesson of the July 2026 COLDCARD security incident: proof of wallet ownership is evidence of present signing capability. It is not, by itself, evidence of secure or exclusive custody.

This does not make proof-of-ownership systems ineffective. It shows why their claims must be defined precisely. Wallet verification can establish that assets exist on-chain and that a fresh challenge was answered using the relevant signing capability. It does not automatically establish how the key was created, who else may possess it or whether control will continue.

1. What Happened With COLDCARD?

Bitcoin wallet seeds must be created from unpredictable randomness. In a deterministic wallet, the seed is the starting point from which the wallet derives its private keys and addresses. If the seed comes from a sufficiently large and unpredictable set of possibilities, searching for it is computationally infeasible. If the possible set is much smaller or predictable, an attacker may be able to enumerate candidates.

On 30 July 2026, Coinkite published its COLDCARD Security Advisory. Block Bitcoin Engineering and Security published a separate early analysis, prepared with anonymous researchers, identifying an integration error in COLDCARD firmware. According to Block, calls intended to obtain random data through ngu.random resolved to MicroPython's deterministic Yasmarang software fallback instead of the intended STM32 hardware random-number generator. Block's report explains that the build configuration disabled MicroPython's hardware implementation, while an incorrect configuration check still allowed the fallback to be compiled and used.

The consequences differed between device generations.

For the affected Mk2 and Mk3 code path, Block concluded that wallet generation could be deterministic once the device identifier, timer state and previous RNG calls were sufficiently constrained. Timing uncertainty could leave candidates to test, but those inputs were not cryptographic entropy sources.

Later devices incorporated entropy from secure elements. Coinkite estimates that seeds created on affected Mk4, Mk5 and Q firmware had about 72 bits of entropy, rather than the intended 128 bits. Block's interpretation is more conservative: its code analysis found that only four bytes of a hash of the secure-element data reached the reseeding function. For a fixed fallback state and call history, Block argued that this produced no more than 2^32 securely distinguished output streams. It did not claim a complete end-to-end brute-force benchmark, and said practical exploitability would also depend on factors such as timing, device-state knowledge and RNG-call history. Coinkite's technical backgrounder and Block's analysis should therefore be read as distinct assessments, not collapsed into one entropy figure.

Coinkite's current advisory identifies the following affected seeds:

  • Mk2 and Mk3 seeds generated on firmware 4.0.1 through 4.1.9 inclusive
  • Mk4 and Mk5 seeds generated before standard firmware 5.6.0 or Edge firmware 6.6.0X
  • Q seeds generated before standard firmware 1.5.0Q or Edge firmware 6.6.0QX

Public information can help an attacker test candidate seeds. From each candidate, the attacker can derive addresses or public keys and compare them with a known address or extended public key. Block describes this as a candidate-validation "oracle": a match tells the attacker that the correct seed or key has probably been found.

Reports connected substantial Bitcoin thefts with the vulnerability. Bitcoin Optech reported unexpected transactions dated 29 July and estimated losses above 1,000 BTC in its 31 July newsletter. Later on-chain estimates were higher, but the figures were evolving and do not prove that every reported loss resulted from this vulnerability. Block said active exploitation appeared to be under way while describing its publication as early analysis without full empirical testing.

2. Why Did Affected Wallets Still Work Normally?

The defect concerned unpredictability, not whether the resulting keys were mathematically usable.

An affected wallet could still:

  • derive ordinary Bitcoin private and public keys
  • generate valid addresses
  • receive and display funds
  • produce valid message signatures
  • authorise valid Bitcoin transactions
  • appear normal in compatible wallet software

Hashing deterministic RNG output can make the result look statistically uniform, but it cannot create additional possibilities that were not present in the input. Block made the same point about the BIP-39 checksum: it may detect errors in a seed phrase, but it does not add entropy.

Once generated, the resulting keys remain valid within Bitcoin's cryptographic system. A verifier checks the signature against the message and the relevant public key or spending conditions. It does not ask whether the private key originated from 128 bits of secure randomness, a copied backup or a short list of attacker-searchable candidates.

This is the difference between functional correctness and security. The wallet performed its visible signing functions correctly. Its problem was that another party might be able to reproduce the secret that enabled those functions.

3. What Does a Wallet Signature Actually Prove?

A robust proof-of-control flow gives the user a unique, time-bound challenge containing details such as a nonce, session identifier, purpose and expiry. The wallet signs that message, and the verifier checks it against the specified address or wallet structure.

When implemented correctly, this can establish that:

  • the specified challenge was signed
  • the response satisfies the relevant wallet's signing conditions
  • the signature belongs to the defined verification session
  • someone participating in the flow had access to the required signing capability at that moment

Bitcoin's BIP-322 signed-message specification formalises message signing for a wider range of Bitcoin scripts and includes a proof-of-funds variant. The specification itself warns that a signature becomes historical as soon as it is created and cannot prove that the signer will retain control or would sign a real transaction.

A signature also does not establish legal ownership by itself. An employee, custodian, trustee, co-signer or attacker may possess signing authority without beneficially owning the assets. Cryptographic control may support a legal claim, but the two are not identical.

It helps to separate five possible claims:

  1. Asset existence: Bitcoin exists at the relevant on-chain addresses or outputs.
  2. Present control: The fresh challenge was answered using the relevant signing capability.
  3. Exclusive control: No unauthorised party can also reproduce or use that capability.
  4. Secure key provenance: The seed and keys were generated from adequate, unpredictable entropy.
  5. Continuing control: The verified party remains able to control the assets after verification.

On-chain data can help establish the first claim. Challenge-response verification can establish the second. Neither automatically establishes the third, fourth or fifth.

4. Control Is Not Necessarily Exclusive Control

Bitcoin does not assign identity, legitimacy or seniority to two parties holding the same private key. If either party can produce a valid signature satisfying the same spending condition, their cryptographic authority is indistinguishable to the network.

Non-exclusive control can arise in many ways:

  • another person copied the seed phrase
  • an unprotected backup was photographed or stolen
  • malware extracted key material
  • the original seed was predictable
  • a former employee retained organisational signing material
  • an undisclosed co-signer or custodian can authorise transactions
  • the wallet was restored onto several devices

The COLDCARD vulnerability is an unusually visible example of this broader category. The user could retain the device while an attacker independently recreated the same secret.

Consider an illustrative scenario:

  1. Alice generates a wallet using affected firmware.
  2. She retains the device and signs a fresh challenge presented by a wallet-verification platform.
  3. The platform correctly verifies the signature.
  4. An attacker independently reconstructs the seed because its entropy was inadequate.
  5. The attacker can also sign messages and spend the Bitcoin.
  6. The verification was not cryptographically wrong. The verified claim was narrower than "Alice alone controls this wallet securely".

A signature proves that the signing condition was satisfied. It cannot reveal how many other parties could satisfy it.

5. What Financial Institutions Should Verify

Institutions assessing self-custodied Bitcoin should treat wallet verification as a layered risk process.

Layer 1: On-Chain Asset Verification

Confirm that the declared addresses, outputs or wallet structure correspond to assets observable on the relevant blockchain.

The evidence should be timestamped and its scope made explicit. An address list may show selected holdings without demonstrating that it is complete. BIP-322 similarly notes that a proof over chosen UTXOs cannot prove that no additional UTXOs exist.

Layer 2: Fresh Proof of Control

Require a challenge generated for the current verification session, rather than screenshots, copied addresses or old signed messages.

A fresh signature connects the response to a defined request and time. It is stronger evidence than a screenshot, but remains proof of control, not a guarantee of legal title or secure custody.

Layer 3: Wallet-Security Declarations

Where proportionate, collect structured information about:

  • signing-device model
  • firmware version
  • approximate seed-generation date
  • whether the seed was created on the device or imported
  • possible coverage by a published security advisory
  • migration from any affected seed
  • single-signature or multisignature architecture

Unless supported by independent device attestation or other evidence, these are user-provided declarations and risk signals, not cryptographically proven facts. A valid signature does not silently verify the accuracy of the answers.

Layer 4: Continuing Verification

For an ongoing lending, wealth-management or compliance relationship, the initial signature should not be treated as permanent evidence.

Controls may include scheduled reverification, balance monitoring, review of wallet-migration events, notifications when access expires or assets move, and renewed verification after a material wallet-security advisory.

Layer 5: Risk-Based Custody Assessment

The appropriate assurance should reflect asset value, loan-to-value ratio, relationship duration, concentration risk, wallet architecture and the consequences of rapid movement.

A high-value Bitcoin-backed facility may justify additional controls that would be disproportionate for a low-value, one-off retail check. Layered verification does not require every user to undergo an invasive hardware audit.

6. Could a Verification System Detect This Vulnerability?

Ordinarily, no.

A platform examining addresses, balances and signatures cannot work backwards to measure the seed's original entropy. Nor can it determine whether an attacker, former employee or backup custodian possesses the same secret.

The blockchain contains no "securely generated" or "compromised" label. If a mathematically valid private key satisfies the required script, its signature is valid.

A verification system can still support risk controls. It could record a user's disclosed wallet platform, ask when and where the seed was generated, identify device-and-firmware combinations potentially covered by an advisory, require migration or enhanced review, trigger reverification after a disclosure and maintain an audit trail of the evidence collected.

These controls improve decisions. They do not prove that an undisclosed key copy does not exist.

Safety note
Never enter a seed phrase into a website or verification platform. Installing fixed firmware does not repair a seed generated on affected firmware. Potentially affected users should follow Coinkite's current official advisory and migration guidance. This article is explanatory and is not a substitute for the latest vendor guidance.

Coinkite advises affected users to generate a new seed using fixed firmware and migrate their Bitcoin. It states that at least 50 fair, independent and private dice rolls added during the original seed-generation process supplied sufficient independent entropy for this particular issue. A strong, unique BIP-39 passphrase creates a separate barrier, but Coinkite still advises passphrase users with affected seeds to migrate. Updating firmware prevents the same seed-generation problem in future; it does not retroactively change an existing seed.

7. What This Means for Accredifi

Accredifi is designed to help institutions request fresh cryptographic proof that a user controls a wallet and verify relevant self-custodied holdings without taking custody.

It can provide permissioned access to authorised wallet information, preserve verification history and audit evidence, support recurring reverification and deliver relevant verification or wallet-access events through webhooks.

Those capabilities answer defined institutional questions. They do not allow Accredifi to inspect a seed phrase, measure the entropy used to create it, prove that nobody else possesses it, guarantee a hardware wallet's security, establish legal ownership solely from a signature, detect every compromised wallet or protect funds from an attacker.

Accredifi verifies defined claims about wallet control and holdings. It does not convert those claims into a blanket guarantee about the wallet's complete security posture.

That distinction strengthens institutional trust. Reliable verification infrastructure should state what was established, the evidence supporting it, the time and scope of the check, and the questions that remain outside it.

Verification Should Be Precise, Not Absolute

The COLDCARD security incident does not invalidate Bitcoin proof-of-ownership systems. It demonstrates why their outputs must not be stretched beyond the claims they actually test.

Institutions need fresh cryptographic evidence rather than screenshots, clear definitions of each check, proportionate wallet-risk assessment and reverification when balances, access or security conditions change.

Most importantly, they need to distinguish cryptographic control from secure and exclusive custody.

For lenders, wealth managers and compliance teams that need to verify self-custodied assets without taking custody, Accredifi provides a structured way to collect and maintain that evidence while keeping its scope explicit.

Frequently Asked Questions

Can a Compromised Bitcoin Wallet Still Produce a Valid Signature?

Yes. If the private key is mathematically valid, it can produce a valid signature even when it was generated from weak randomness, copied or reconstructed by an attacker. Signature verification does not examine the key's history.

Does Proof of Wallet Ownership Prove That Only One Person Controls the Wallet?

No. It proves that the required signing capability was available for a particular challenge. Another person with the same seed, private key or sufficient co-signing authority may be able to produce an equally valid signature.

Can Updating COLDCARD Firmware Secure an Existing Affected Seed?

No. Fixed firmware corrects future seed generation, but it does not change a seed created on affected firmware. Coinkite advises affected users to follow its current guidance for creating a replacement seed and migrating funds.

Related Articles

Sources

Primary Sources

Secondary Reporting

Disclaimer: This article is for informational purposes only and does not constitute financial, legal, tax, investment, security or compliance advice. Potentially affected users should consult Coinkite's latest official advisory.

Back to Blog
August 4, 2026
•
Accredifi Team