AI Scan of 150 Bitcoin Repositories: One Claim Per Hour, Zero Hashes to Verify

I. The Announcement August 9, 2025. A voluntary security team announces it has scanned approximately 150 code repositories adjacent to Bitcoin core projects. Over a dozen vulnerabilities. Wallets. Cryptographic libraries. Infrastructure components. Every one of them discovered with the assistance of advanced AI models. The model list is specific: Kimi K3. OpenAI's GPT Sol. Anthropic's Claude Fable. Opus models. Z.ai's GLM 5.2. The announcement is lean. Too lean. No repository names. No commit hashes. No CVE identifiers. No proof-of-concept code. No date of first contact with affected maintainers. The only quantitative claim is striking: on average, one critical vulnerability discovered per analyst per hour. In the past twelve hours, the team reports, security reports were submitted to multiple projects. The names of those projects are withheld. I have done this work. I have sat with decompiled bytecode and a spreadsheet of function entry points. I have traced wallet cluster behavior across block explorers when a bridge's type-casting error was staring at me from the Solana runtime. I know what one critical vulnerability per hour looks like. It does not look like a press release. Let me be direct: the findings may be real. The discoveries may be legitimate. A volunteer team using frontier models could, in principle, find bugs that eluded human reviewers for years. But "could" is not "did." The burden of proof sits with the claimant. That is the only rule that has ever kept Bitcoin safe. Ledgers do not lie, only the interpreters do. II. Context: The Machine Has Entered the Audit Room This announcement did not happen in a vacuum. Security research has been an arms race since the first disputed transaction replay. But the recent timeframe changed the terms. Coldcard, the hardware wallet manufacturer, disclosed security incidents that involved AI-assisted analysis of firmware and side-channel behavior. Boltz, the Bitcoin Lightning and swap protocol, reported attack activity consistent with AI-accelerated vulnerability identification. Attack surface and defense capability are scaling at the same rate. The voluntary team's scan claims to cover roughly 150 repositories "related to Bitcoin core projects." That scope definition is worth examining. Bitcoin Core itself is a single repository with a carefully controlled review process. A developer who finds a remote code execution vector in Bitcoin Core does not submit it to a generic form. They email the security mailing list. They wait. They coordinate. This process exists for a reason: disclosure without coordination is how users lose money. What does "150 repositories related to Bitcoin core projects" mean? It is a category, not an inventory. It likely encompasses Bitcoin Core's own tree, plus popular wallets, Lightning implementations, hardware wallet firmware repositories, and cryptographic libraries used by all of the above. Fifteen such repositories would be a serious campaign. One hundred fifty is either unprecedented scope or a shotgun blast across GitHub forks, mirrors, and abandoned dependencies. The distinction matters. A vulnerability in a fork no one uses is a vulnerability. But it is not the same risk class as a flaw in the code that signs your transaction. The timing is also a signal. August sits between conference seasons. Security teams often schedule disclosures around quiet periods to allow maintainers to breathe. The choice of August 9, in the middle of the northern summer, suggests either an urgency that could not wait or a desire to release without maximum press coverage. Neither reading is flattering when the affected projects are unnamed. And there is the wider frame: we are in a bear market. Capital is scarce. Teams are smaller. Maintenance cycles are stretched. A vulnerability disclosed today is more dangerous than the same vulnerability disclosed during a hiring boom, because the response capacity is thinner. Users need to know if their assets are safe. This announcement does not answer that. It raises the question and then declines to answer it. III. The Verification Imperative: Code First, Claims Later Here is my protocol. It has not changed since 2017, when I reviewed the "Project Aether" ICO, found zero deployed contracts, and said so while the marketing team was selling a supply chain revolution. Verify the executable reality before analyzing the narrative. Apply that protocol to the August 9 announcement and the ledger entries are missing. There are no repository URLs. There is no disclosure timeline. There are no patch diffs. There is no list of maintainers notified. There is no second-party confirmation from any affected project. The entire claim rests on the reputation of an unnamed team and the inferred credibility of the model names attached to it. This is not skepticism for its own sake. It is the direct lesson of every security incident I have examined. When Terra's UST depegged in May 2022, the on-chain evidence did not come from a blog post. It came from four days of chasing USDT withdrawal patterns in Anchor vaults, identifying a wallet cluster that offloaded $4.2 billion before the peg broke. The data trail was publicly readable. Anyone could verify it. Anyone can still verify it. A claim of a dozen critical vulnerabilities offers no equivalent trail. That is a flag. Mark my words: AI-assisted auditing is real. The code analysis capabilities of frontier models in 2025 are materially beyond what existed in 2023, when I reported a type-casting vulnerability in the Wormhole bridge implementation on Solana and watched the core team delay a fix for two weeks because of, in their words, "audit fatigue." The models can parse function signatures. They can detect integer overflow patterns. They can reason about reentrancy. They can generate supporting documentation that reads like a senior audit report. But they can also do something else. They can hallucinate a vulnerability's exploitability. They can flag a pattern that is technically present and practically unreachable. They can generate a report that is internally coherent and externally wrong. This is the central problem of AI-assisted security: the documentation quality is no longer evidence of the finding quality. The team says the models "generate supporting documentation." Nice. In my experience, the documentation is the easiest part. A model will cheerfully draft a five-page analysis of a race condition it invented. The proof is in the PoC. The proof is in the reproducible test case. The proof is in the patch that actually fixes the disclosed issue. None of that is present. IV. The Rate Equation: One Critical Vulnerability Per Hour Let me do arithmetic. This is my default state. In 2020, while influencers were quoting 400% APY on Uniswap V2 liquidity pools, I built spreadsheet models that showed 28% principal erosion against holding ETH during high volatility. Math does not care about headlines. Neither does this. The team claims one critical vulnerability discovery per analyst per hour. That is eight per standard workday. That is forty per week. At that rate, a five-person team operating at full capacity would produce two hundred critical-level findings per week. Cold, hard numbers follow. Critical severity, by convention, means remote exploitation, no prior authorization, and meaningful economic or integrity impact. In 2023, after the Wormhole disclosure, my work rate was closer to one critical every three weeks, when the stars aligned, when I was looking at exactly the right code, when the model outputs were cross-validated manually. One per hour reframes what "critical" means. Either the severity bar is lower in this team's taxonomy, or the scoped repositories include a very large set of low-hanging fruit. Both are plausible. Both collapse the strength of the claim. Here is what one per hour actually looks like in practice: a researcher feeds a repository to a model, gets a list of suspicious patterns, automates a triage filter, and then manually confirms the interesting ones. The AI "discovery" is really an AI suggestion. The human confirmation is where the time goes. Models surface patterns. Humans convert patterns into vulnerabilities. The team's claim, read charitably, measures the suggestion rate, not the confirmed vulnerability rate. Read uncharitably, it measures the generation rate of the documentation, which is the least expensive step in the entire pipeline. I have test harnesses. I have memory-error sanitizers. I have fuzzing corpora. I have used all of them. None of them report vulnerabilities per hour. They report inputs per hour. The vulnerability attribution is always human. The final judgment always lands on a human read of the code path. The unnamed team could be operating at a different confidence threshold. They could be reporting "candidate criticals" as criticals. This is exactly why the disclosure process matters. If the reports going to affected projects are as unverified as the public announcement, the maintainers will spend their week triaging false positives. That is not a gift. That is an attack on their attention. Ledgers do not lie, only the interpreters do. The same applies to AI-generated vulnerability reports. There is another arithmetic angle. The team says each person can discover about one critical vulnerability per hour. That is not an average; that is a ceiling claim. Sixty minutes per finding, including model query time, documentation generation, and human verification. In my chain-of-custody practice, verifying a single real vulnerability takes longer than an hour when I have to prove exploitability rather than pattern repetition. The act of proving is what separates a finding from a suspicion. A suspicion is not a vulnerability. A vulnerability is a state of code that can be reached by an attacker. The proof of reachability is the technical artifact that matters. The announcement does not provide it. V. What "150 Repositories" Actually Means Scope is the second arithmetic problem. Bitcoin's software ecosystem can be divided into layers. The consensus client layer: Bitcoin Core, Bitcoin Knots, libbitcoin. The wallet layer: Electrum, Sparrow, BlueWallet, hardware wallet firmware from Coldcard, Trezor, Ledger, and others. The infrastructure layer: Lightning implementations like LND, Core Lightning, and Eclair, plus DLC oracles, hardware signing devices, and sidechain clients. The cryptographic layer: secp256k1 bindings, BIP32 derivations, base58check encoders, and the various libraries that pass around private key material. One hundred fifty repositories is enough to cover that entire ecosystem twice. It is also exactly the size of a scrape of every archived GitHub repository with "bitcoin" in its name and at least five stars. Both are "related to Bitcoin core projects." One is a surgical campaign. The other is a keyword search. The difference is not academic. A surgical campaign finds meaningful flaws in actively maintained code. A keyword search finds abandoned code, commented-out logic, and the detritus of a decade of experimental Bitcoin-adjacent fun. Reporting the second category as a security discovery campaign produces statistically impressive numbers and practically negligible impact. I am not accusing the team of the latter. I am stating that the announcement does not distinguish between the two. And when a claim is intentionally ambiguous, the ambiguity is the message. The Coldcard and Boltz incidents complicate this further. Both indicate that AI is being used on the attack side as well. Coldcard's hardware wallet products have a well-earned reputation for security; if attackers are using AI to analyze firmware updates and side channels, the effective attack surface of every hardware wallet user just increased. Boltz operates in the Lightning space; an AI-accelerated finding in swap contract code could be catastrophic for channel liquidity. When both sides of the arms race accelerate simultaneously, the value of coordinated disclosure rises. The value of press releases falls. The wording "related to Bitcoin core projects" carries another subtlety. It could mean repositories with a direct code lineage. It could mean repositories that merely import a Bitcoin library. The threat model is entirely different. A vulnerability in the main repository of a wallet is a direct user risk. A vulnerability in a dependency that ships inside a wallet is a supply-chain risk. A vulnerability in a test helper that never ships is a research curiosity. All three count as "related." All three have different severities in practice. The team says the vulnerabilities affect wallets, cryptographic libraries, and infrastructure projects. That is still a category list. Wallets vary from mobile apps to multisig vaults to hardware devices. Cryptographic libraries vary from audited C implementations to unmaintained JavaScript bindings. Infrastructure varies from Lightning nodes to block explorers to indexers. The category list tells me nothing about the actual user impact. VI. The Model Portfolio Analysis The model list deserves attention. Kimi K3, GPT Sol, Claude Fable, Opus, GLM 5.2. A security team running five distinct models across the same repository set is not wasting compute. They are cross-validating. Each model has a different training distribution. A false positive in one model is likely to be filtered by the consensus of others. That is genuine methodology. I respect it. But that methodology generates a shared weakness. All frontier models are trained on broadly similar public code corpora. They will all be excellent at finding patterns that appear in popular repositories. They will all be weak in the same places: proprietary protocols, unusual language idioms, and branch-new attack surface that does not resemble training data. A consensus of models that all fail the same way is just a larger failure. The good news is that Bitcoin code is old. It is documented. It is copied widely. The corpus is gigantic. The models have all seen it. This explains why AI-assisted scanning of Bitcoin-adjacent code could produce a high volume of findings. The low-hanging fruit in the corpus is heavily represented in the training data. The bad news is that the high-severity vulnerabilities in Bitcoin history were rarely the low-hanging fruit. They were interactions. Fee handling interacting with mempool eviction. Transaction ordering interacting with RBF. Signature malleability interacting with second layers. These are not single-function bugs. They are composite failures across abstractions. Whether the models caught composite failures is exactly what the announcement does not say. There is also the question of version pinning. A repository scanned at its latest commit may include dependencies that are vendored, forked, or pinned to outdated versions. A model that reports a vulnerability in an outdated dependency produces a finding that exists in a specific historical state. The current code may already be patched. The severity then drops from critical to informational. The announcement's refusal to name repositories prevents any independent verification of version state. VII. False Positives and the Hallucination Tax AI model hallucination is not a bug. It is a feature of sampling from a probability distribution over tokens. The model generates documentation that maximizes likelihood, not documentation that maximizes truth. The reader of that documentation cannot distinguish the two without running the code. I have run model-generated exploit code. It fails in the funniest ways: wrong function names, inverted salt values, off-by-one errors at the moment of exploitation. The reports that accompany these attempts are spectacular. They read like audit reports written by someone who has read thousands of audit reports. This is because they were trained on exactly that corpus. The critical word in the team's announcement is "assisted." The models assisted in discovering. The models generated supporting documentation. That framing is compatible with a workflow where the human does the verification. It is also compatible with a workflow where the model output is forwarded to maintainers after a glance. The announcement does not tell us which. The consequences of the second workflow are not trivial. Maintainer time is scarce. Bitcoin Core's review process is deliberately slow because every change requires consensus. Every false report consumes that scarce attention. A hundred and fifty repositories of AI-generated candidate findings, processed at one critical per hour, and routed to projects, would hammer the ecosystem's response capacity. That is a denial-of-service attack on the security review process, even if every report was generated in good faith. This is why the verification step is not optional. It is the entire point. The pattern-matching aspect deserves further drilling. Models excel at recognizing CWE patterns they have seen in training: buffer overflows in C, reentrancy in Solidity, unchecked return values in Rust. They are less reliable at recognizing context. A buffer overflow in a function that only processes local data is not remotely exploitable. A reentrancy guard that is present but misordered may be a finding, or it may be unreachable. The difference between pattern and exploitability is the difference between a scan result and a vulnerability. The team's per-hour rate strongly implies pattern-level triage. Generating a finding from a suspicious pattern takes minutes. Proving reachability takes hours. The rate claim, therefore, is the most honest part of the announcement if read as a scan-rate claim. It is the most misleading part if read as a confirmed-critical claim. VIII. The Disclosure Black Box Let me be uncompromisingly practical. Over the past twelve hours, the team says, they submitted reports to multiple projects. Which ones? The answer matters for a reason beyond curiosity: the affected maintainers are the only people who can confirm the findings. Their silence protects the disclosure. The public announcement saves no one. The responsible model is well-established: coordinated disclosure. The reporter documents the vulnerability, proves it is exploitable, contacts the maintainer privately, provides the PoC, and agrees on a patch window. The public gets the news after the patch, or after the window expires. This is not bureaucracy. It is the mechanism that stops the Coldcard users and Boltz traders from being the test population for an unpatched critical flaw. When I discovered the Wormhole bridge vulnerability, I reported it privately. The team delayed. I disclosed the exploit mechanism and PoC publicly. The patch landed immediately after. I learned the lesson twice: transparency is a threat when the fix is slow, and the process has to be intrusive. The August 9 team may be following this exact playbook. If so, the public announcement is just the first draft. The confirmation will come when the affected projects push patches. But as of this writing, there is no confirmation. There is no patch. There is no project that will confirm to a journalist or a researcher that they received a credible report. Anonymity in security research has a long and respectable history. It protects researchers from retaliation when they break new ground. But it also makes verification harder. An anonymous team claiming one critical per hour, with no evidence trail, is asking the ecosystem to trust a claim that has the shape of a press release and the substance of a rumor. There is also a liability question. In the European Union, the Digital Operational Resilience Act places obligations on financial entities regarding ICT incident reporting. MiCA, fully in effect in 2025, extends compliance expectations to crypto-asset service providers. If a critical vulnerability affects software used by European users, the regulatory conversation will begin. The announcement does not mention any regulator. It does not mention any timeline for public disclosure. It does not mention responsible disclosure windows. That is a compliance gap in the announcement itself. I conducted a compliance gap analysis of fifteen decentralized exchanges in Warsaw in 2025. Twelve of them failed to implement real-time chainalysis for high-value transactions. Three were suspended. The lesson was simple: the wild west era is over, and security process is now a legal requirement, not a courtesy. An AI-assisted security team that bypasses coordinated disclosure is not protected by the novelty of its tools. The legal framework does not care whether the vulnerability was found by a human or a model. It cares whether the disclosure was responsible. IX. The Governance and Delegation Problem There is a quieter structural issue here. The announcement invites the ecosystem to delegate its security verification to an anonymous team of volunteers. That delegation has a familiar shape. In DAO governance, delegation is supposed to improve decision quality by routing votes to experts. In practice, users are too lazy to research and simply delegate to KOLs. The result is governance that is more centralized than the direct democracy it replaced. Security verification is undergoing the same shift. Users increasingly rely on audits, scanners, and now AI-assisted volunteers to tell them which software is safe. The August 9 announcement asks users to accept a finding set without any primary evidence. That is delegation without accountability. The team cannot be questioned. The team cannot be audited. The team cannot be held responsible if a claimed critical turns out to be a hallucination. Trusting an anonymous team's summary is not the same as trusting the code. The code is public. The repositories are public. The verification path exists. The announcement simply does not provide it. In a bear market, where survival matters more than gains, this distinction is existential. Users want to know if their assets are safe. The only honest answer to that question is a reproducible technical record. The only way to build that record is to publish enough information for independent confirmation. The August 9 team has published almost none. X. What Is Verifiable Today Let me inventory what can be verified from the public record. The announcement itself: verifiable as a published statement. The models named: Kimi K3, GPT Sol, Claude Fable, GLM 5.2 — verifiable as existing products. The number 150: unverifiable. The number of vulnerabilities, and their severities: unverifiable. The identity of affected projects: unverifiable. The fact that reports were submitted: unverifiable without the projects' confirmation. The date, August 9, is verifiable. That is the extent of the ledger. This asymmetry is not acceptable. The users of Bitcoin software are the ones who will lose money if a listed critical is exploited before the patch. The holders of Lightning channels on Boltz are the ones who will face the consequence of a swap vulnerability. The families with funds on Coldcard devices are the ones who will suffer from a firmware flaw. They have a right to know whether they are exposed. The voluntary team may intend to publish full details after the patch window. That would be the correct move. But the decision to make a public announcement before the patches exist transfers risk to the users with the least information. That is the opposite of protective disclosure. In the 2017 ICO era, code-first verification was an anomaly. "Audit" meant "read the whitepaper" to most investors. That era should have taught us everything: a team can generate infinite documentation and zero truth. The August 9 announcement has the texture of that lesson, reapplying itself to AI-generated audits. XI. Contrarian: What the Bulls Got Right I have spent this article dissecting the announcement. Fairness requires the other side. The bull case is not empty. First, the direction is right. AI-assisted vulnerability discovery is the only security strategy that scales with the size of the codebase. Human review does not. A voluntary team scanning 150 repositories in a short window is evidence of a capability whose future is bright. Any tool that finds more bugs faster is a net positive for users, assuming the disclosure pipeline works. Second, adversarial AI is already here. The Coldcard and Boltz incidents are not speculative. If attackers can use models to accelerate their analysis, defenders need the same acceleration. The voluntary team is on the right side of that arms race. Third, the per-hour rate, if even partially accurate, represents a step change. Even ten real criticals from a scanning campaign is a win. The announcement may be sloppy, but sloppy process does not invalidate a finding. Fourth, the cross-model methodology is sophisticated. Running five frontier models is expensive. Doing so voluntarily, for the public good, without asking for money, is the kind of activity that builds the ecosystem's resilience. They deserve credit for the intent and the effort. Fifth, the choice to remain anonymous is protective. High-profile security researchers face legal threats. A volunteer team that names itself publicly invites pressure from every project it flags. Privacy in security work is a feature. The loss of verification is the price. As long as the post-patch disclosures land, the price is worth paying. My skepticism is not a dismissal. It is a specification for what must follow: patches, confirmations, and PoCs. If the team delivers that, I will be the first to update my position. I did the same after Terra. I followed the on-chain trail, found the evidence of insider behavior, and submitted the data to regulators. The outcome was a conviction about the mechanism, not about my own analysis. Evidence wins. It always does. Vulnerabilities are not opinions. They are states of code. The code can be executed. The exploit can be run. The patch can be tested. When the team publishes that executable reality, the debate closes. XII. Takeaway: Verification Before Veneration The AI-assisted security era is here. It will not be repealed. It will reshape how bugs are found, how audits are performed, and how attackers are caught. The August 9 announcement is an early artifact of that era. It deserves the same treatment as any artifact: examination, not applause. The users of Bitcoin software — the Coldcard holders, the Boltz traders, the hardware wallet families across Europe and beyond — deserve a verification standard. Not a narrative. Not a model name. A verification standard. I will wait for the patches. I will check the CVE identifiers. I will test the PoCs when they are released. The ledger will show the truth. It always does. Ledgers do not lie, only the interpreters do.