For Dragonfly managing partner Haseeb Qureshi, the most striking aspect of the GLM 5.2 experiment was its cost: "GLM 5.2 running for 20 minutes costs about $2. So what does that mean? It means we are in a new world."

Dragonfly is a crypto-focused venture capital firm, and Qureshi's observations carry weight in an industry where software flaws have enabled some of the largest thefts on record. The model reportedly rediscovered the vulnerability linked to the recent ColdCard theft after researchers directed it toward the affected software. ColdCard, manufactured by Coinkite, is a popular hardware wallet among Bitcoin self-custody users. There is no evidence that the thieves used AI. The test instead demonstrates how cheaply both attackers and developers can now examine code that safeguards large amounts of cryptocurrency.

Why the $2 Cost Matters

Serious vulnerability research has traditionally demanded specialist knowledge and many hours of manual effort. Even an experienced researcher can inspect only a limited number of firmware releases, smart contracts, and cryptographic libraries.

AI allows far more code to receive an initial review. Researchers can assign several models to the same codebase, ask them to investigate different failure paths, and repeat the process whenever a stronger model becomes available.

Most searches may produce nothing useful. That becomes less significant when an individual attempt costs only a few dollars. Someone looking for weaknesses can examine many targets without needing every run to succeed. One valid flaw in software protecting millions of dollars could justify the cost of thousands of unsuccessful attempts.

AI has not eliminated the need for security expertise. It has lowered the cost of generating leads, testing theories, and covering more code than a human researcher could inspect alone.

What the GLM 5.2 Test Actually Shows

Qureshi said researchers asked several models to examine the software after the ColdCard incident had already focused attention on it. According to him, the models were not told where the vulnerability was located, and GLM 5.2 found it in roughly 20 minutes.

The context matters. Researchers already knew that the relevant software contained a serious problem. The model was not searching blindly across every hardware wallet or discovering an attack without a starting point.

Identifying a bug is also different from exploiting it at scale. An attacker may still need to:

• Determine which devices or wallets are affected.
• Reconstruct usable private keys.
• Identify wallets containing valuable balances.
• Move funds before users or manufacturers can respond.

Qureshi's comments do not show that GLM 5.2 performed those steps or that an AI system participated in the original theft. What the experiment establishes is more limited but still important: a general-purpose model reportedly rediscovered the underlying technical weakness quickly and at negligible cost.

AI Is Here Before the Quantum Threat

Much of the long-term security debate around Bitcoin has focused on quantum computing. A sufficiently capable quantum machine could eventually threaten the signature schemes protecting coins, forcing networks and users to migrate to new cryptography. That risk requires advance preparation.

AI-assisted code analysis presents a different problem because the tools can already be used against software running today. AI does not need to defeat Bitcoin's underlying mathematics. It can search the surrounding code for mistakes such as weak random-number generation, exposed secrets, faulty cryptographic implementations, and unsafe recovery functions.

Previous analysis of the AI and quantum threats facing crypto examined the same distinction. Quantum computing could eventually create a network-wide cryptographic problem. AI can already be directed at wallets, bridges, libraries, and applications currently protecting user funds.

The immediate concern is therefore a human mistake in the software around Bitcoin rather than AI breaking Bitcoin itself.

Attackers and Developers Have Access to the Same Tool

AI has no preference for stronger security or a successful attack. Its effect depends on the task people give it.

An attacker can use a model to scan old firmware, automate repetitive analysis, and test possible weaknesses. A wallet manufacturer can use the same model before release, directing it toward key generation, transaction signing, and recovery procedures.

Developers can also revisit products released before modern coding agents existed. Software audited five years ago can now be examined with tools that were unavailable when it reached customers. Several blockchain security firms have already begun incorporating AI-assisted analysis into their audit workflows, though the technology remains a supplement to human review rather than a replacement.

The two sides do not operate under equal conditions, however. An attacker can act as soon as a useful vulnerability is confirmed. A developer must reproduce the finding, understand which users are affected, prepare a safe fix, and distribute it without revealing enough information to accelerate exploitation.

Models can also misunderstand code, produce false positives, or describe attacks that fail in practice. Human researchers remain responsible for verifying the result and deciding how urgently the project needs to respond.

AI widens the amount of code that can be examined. It does not replace the expertise or incident response required after a serious weakness is found.

Self-Custody Still Depends on the Wallet

Qureshi described the affected users as people who had followed the usual security advice: "People who are doing all the right things."

They had moved Bitcoin away from exchanges and stored it in dedicated hardware wallets. Yet self-custody still depends on the device creating and protecting its keys correctly.

Qureshi said the affected firmware used a weaker source of randomness than intended. If a private key is generated from predictable inputs, keeping the device offline cannot make the key stronger afterward. An air gap can reduce exposure to remote attacks against a properly generated secret. It cannot repair a secret that was weak from the moment it was created.

Hardware-wallet users therefore rely on more than their own handling of a recovery phrase. They also trust the manufacturer's firmware, hardware design, cryptographic libraries, and random-number generator. Years without a known exploit can show that software has survived ordinary use. They do not prove that every serious weakness has already been identified.

Old Wallet Code Needs to Be Reviewed Again

Cheaper AI analysis makes old code easier to revisit. Software that previously attracted little attention can now be examined repeatedly and at scale.

Wallet manufacturers and crypto protocols should rescan older releases when major models improve, especially when the code creates private keys, signs transactions, or controls wallet recovery.

A firmware update will not solve every problem. When a flaw affects how existing keys were created, correcting the software may protect new wallets while leaving older ones exposed. Users may need to generate new keys under the repaired system and transfer their funds. Providers should therefore be able to identify affected versions, contact customers quickly, and explain how to migrate safely.

That process also creates opportunities for scammers. Security incidents often produce fake support accounts, malicious migration websites, and messages asking users to verify their wallets. Users should never provide a seed phrase or private key to a support representative, website, social-media account, or AI chatbot. A legitimate recovery process does not require another person or service to receive those secrets.

Security Review Can No Longer Be a One-Time Event

AI-assisted analysis should become part of normal development rather than a tool used only after funds have been stolen. Crypto companies should consider:

• Scanning new code before release.
• Re-examining older firmware and libraries as models improve.
• Using several models to approach the same code from different directions.
• Having experienced researchers reproduce serious findings.
• Preparing emergency communication and wallet-migration procedures.
• Maintaining responsible-disclosure and bug-bounty programs.

The models provide broader and faster coverage. Security teams still need to separate genuine vulnerabilities from incorrect reports, develop a fix, and manage the consequences for users.

The Security Race Is Becoming Cheaper

Qureshi's example does not show that AI can break Bitcoin. It shows that software protecting Bitcoin can now be tested for vulnerabilities at a cost that is rapidly becoming negligible.

That development can produce better security or cheaper attacks. Developers can use AI to challenge their own products and catch mistakes before release. Attackers can direct it toward forgotten code, repeat searches across many targets, and act on the first useful result.

The technology is available to both. The outcome depends on who uses it, how accurately the findings are checked, and how quickly defenders can respond. Projects that continually reassess their software can benefit from the same tools that make attacks easier. Those relying on old audits or assuming that a long-hidden bug would already have been found leave that opportunity to someone else.

Disclaimer: This article is for informational purposes only and does not constitute security, financial, or investment advice. The reported experiment does not establish that AI was used in the ColdCard theft or that GLM 5.2 can reliably identify every software vulnerability.

Methodology: This analysis uses public comments from Dragonfly managing partner Haseeb Qureshi concerning the ColdCard incident and the reported GLM 5.2 test. The comparison between AI and quantum risk distinguishes currently available vulnerability-research tools from longer-term threats requiring cryptographically capable quantum hardware.