The press release landed like a banner: 4,962 software issues found across 390 Bitcoin-related open-source projects. Sixteen security researchers, 30 hours, a lead developer called Calle, support from OpenSats, OpenCode, and an AI-inference sponsor. The headline numbers were clean. 4,962 findings. 720 critical or high severity. 166 issues per hour. 2.3 critical/high issues per researcher per hour. The implication was obvious: artificial intelligence just broke Bitcoin’s security bottleneck.
I got out a calculator before I got out any coffee.
Divide 720 by 16 researchers. Divide again by 30 hours. The result is 1.5, not 2.3. The gap is roughly 35 percent. Maybe the campaign didn’t last 30 hours for every participant. Maybe the AI did the heavy lifting and the humans only triaged the output. Maybe the 2.3 figure counts only active review time, or only time spent on critical findings, or only time after the first automated pass. All of those are possible. None of them are disclosed in the original article.
That discrepancy is not a typo. It is a methodological scar. Hype is a mask; the ledger is the face beneath it. And in a security campaign funded by open-source organizations, the ledger should be open.
Context
Bitcoin’s open-source ecosystem is a maintenance problem that nobody wants to price correctly. Wallets, Lightning implementations, taproot libraries, ordinal indexers, PSBT tools, hardware signing middleware, fee-estimation libraries, descriptor languages, partial signing devices, sidechain bridges, transaction analyzers, code used every day to move billions of dollars. Most of these projects are maintained by tiny teams. Some are maintained by a single person who hasn’t taken a vacation since the last cycle’s price peak.
Traditional audits are slow. A reputable audit firm will take one to four person-weeks for a single medium-sized codebase. That means a 390-project ecosystem would need thousands of person-weeks to receive complete manual coverage. The queue is measured in years. In the meantime, new code gets deployed daily. New race conditions become old race conditions. New assumptions become old assumptions. The Bitcoin ecosystem is not unique in this way, but it is the most expensive environment in which mistakes are made.
The AI campaign was not a new protocol. It was a methodology experiment. Sixteen security researchers were assembled. The lead organizer goes by Calle, a pseudonymous developer with a history of blunt, usable tooling. OpenSats provided support for free and open-source work. OpenCode provided a coordination rail. An AI-inference sponsor provided compute. The target was a wide net: 390 Bitcoin-related open-source repositories. The campaign lasted 30 hours. The output, as reported: 4,962 findings, with 720 labeled critical or high severity.
The goal was straightforward: use human-led AI assistance to scale the kind of security review that would otherwise take years. Every participant used different prompts and different methods. That detail, buried in the coverage, is the most important detail in the entire story.
Before I go further, let me place my own experience on the table. I have spent two decades around blockchain infrastructure. In 2017, I worked through the Parity wallet multisig freeze by parsing raw Geth logs, reconstructing transaction graphs, and manually tracing how a single library update froze 513 million ETH in an instant. The cause was not a single malicious attacker. The cause was a set of unstated assumptions about how libraries would be called. That lesson stayed with me: the worst vulnerabilities are the ones that live between modules, not inside them.
In 2020, I reverse-engineered a Compound oracle manipulation and proved on a local testnet that a price feed tied to one low-liquidity DEX pair could be skewed by 15 percent with a $1 million attack. The protocol patched it. The point was not that Compound was evil. The point was that centralized assumptions hide in decentralized narratives.
By 2021, I was tracking wash trading in 12,000 Bored Ape transactions and calculating that about 40 percent of the apparent volume was self-dealing. The numbers were cold. The conclusion was ugly. The floor price had become a fiction.
All of those experiences shape how I read a security headline. The AI campaign is not a fraud. It is an event with real output. But the numbers need to be pulled apart before anyone builds a strategy on them.
Core: The Arithmetic
Let me start with what checks out.
4,962 findings divided by 30 hours equals 165.4 findings per hour. Rounded, that is 166. The hourly rate is consistent with the article. Good.
Now move to the per-researcher calculation. Sixteen researchers. Thirty hours. The maximum possible person-hours, assuming everyone worked every minute, is 480. If the campaign produced 720 critical/high findings, then the critical/high yield per person-hour is 1.5. To get 2.3, the actual denominator would have to be about 313 person-hours. That would mean the average researcher contributed 19.6 hours of active review time, not 30.
Is that possible? Absolutely. A 30-hour live event rarely means 30 hours of continuous focus for every participant. People sleep. People run model queries. People wait for outputs to regenerate. People switch from one repository to another. The average active time could easily be 19.6 hours. If the campaign counted only time spent reading code and validating findings, then 2.3 is a plausible figure.
But the article does not say that. A reader walks away believing that each researcher, for every hour in the campaign, produced 2.3 critical findings. That is materially false. The proper statement is: 720 critical/high findings were generated over a 30-hour campaign involving 16 researchers, which equates to 1.5 findings per maximum person-hour. Whether the true active yield is higher depends on undisclosed time-tracking.
Why does this matter? Because security infrastructure choices are made on numbers like these. A project maintainer reading “2.3 critical/high per researcher-hour” will assume that AI-assisted auditing is more efficient than it is. A funding entity deciding where to allocate open-source support will assume a higher return on compute. Those assumptions get baked into budgets, roadmaps, and safe-harbor decisions.
Numbers have no emotions, only consequences.
The Severity Label Problem
The 720 “critical/high” figure is the second most misleading number in the release.
Severity labels are not vulnerabilities. In traditional static analysis, a tool like Slither or Mythril flags a pattern: unsafe external call, integer overflow, reentrancy path, missing zero check. Those flags are signals, not proof. A good auditor takes each signal, traces it through the actual state machine, and decides whether it can be exploited in the real deployment.
The same logic applies to AI-assisted findings. A large language model may look at a piece of code and recognize something that resembles a vulnerability it has seen in training data. It may label it critical because the pattern usually is a critical risk. But whether that pattern can be triggered depends on the entire surrounding protocol. The model does not hold the full context of the repository, the deployment environment, the upgrade mechanism, or the governance process.
This is not a theoretical limitation. In 2026, I audited a DeFi lending contract generated by an LLM. The contract was about 500 lines. The syntax was clean. The comments were readable. The naming conventions were consistent. It looked like the output of a disciplined developer. Then I traced the borrow function and found a race condition. A user could submit a borrow transaction and a collateral-deposit transaction in the same block. The collateral check passed after the deposit, but the borrow limit was updated before the liquidation check. The result was an unlimited borrow on paper.
The LLM had followed the pattern of a secure contract but missed the ordering dependency between two storage updates. It could write correct-looking code. It could not reason about the full state machine. And this is exactly the class of issue that an AI scan, especially a quick campaign scan, might flag as “medium” or miss entirely.
The campaign deserves credit for sending proof-of-concept demonstrations and re-testing results to maintainers for at least some of the findings. That is not the behavior of a team running a purely automated script. It means they tried to demonstrate exploitability. It means some findings were validated beyond the raw-flag stage.
But the article does not tell us the false-positive rate. It does not tell us how many of the 720 critical/high findings survive a full manual audit. It does not tell us how many maintainers accepted the report, how many rejected it, and how many stayed silent. The phrase “many maintainers quickly confirmed the reports” is a qualitative signal, not a quantitative dataset.
A false positive on a security report is not harmless. It creates noise. It trains maintainers to ignore the next report. It makes the next genuinely critical warning easier to miss. If the precision rate is high, this campaign is a breakthrough. If it is low, it is another layer of security theater.
We need the raw data before we can know which one this is.
The Missing Model Disclosure
The article mentions AI inference sponsorship but does not name the model. It does not disclose whether the team used a single model or multiple models. It does not provide version numbers, temperature settings, sampling parameters, prompt templates, or benchmark results. It does not explain how the “critical/high” rubric was defined. It does not describe the process by which a raw finding gets promoted to a PoC.
This is a transparency failure. Open-source security work is built on reproducibility. If a researcher wants to reproduce the 4,962 findings, that researcher needs the exact prompt set, the exact model versions, the exact order of operations, and the exact classification algorithm.
The campaign’s central innovation is the idea that different prompts and different methods catch weaknesses that a single method would miss. That is an ensemble learning strategy. In machine learning, ensemble methods improve recall by combining weak learners with diverse biases. Here, the human researchers are not just writing prompts; they are choosing which attacks to simulate, which corner of the Bitcoin protocol to interrogate, and which failure models to pursue. One researcher might focus on cross-input signature aggregation. Another might focus on the timing of fee updates. Another might focus on malicious PSBT fields. Another might focus on interactions between a hardware wallet and a watch-only wallet. That diversity is the value.
But the diversity also makes reproducibility harder. If every researcher used a different prompt, then the results are a function of sixteen different thought processes, not a single algorithm. That is not an argument against the method. It is an argument for publishing the method.
The Ensemble Insight
I have run enough forensic analyses to know that the most important vulnerabilities are not the ones that jump out. They are the ones that hide behind a plausible assumption. In 2017, the Parity multisig failure happened because someone assumed that the library initialization code could be executed only once. It was a valid assumption for the intended use case. It was not valid in the broader Ethereum transaction model. The resulting freeze removed 513 million ETH from circulation.
No static analyzer would have found that. The pattern was not an out-of-bounds read or a reentrant call. It was a protocol-to-blockchain mismatch. A human auditor, assisted by an AI that could read documentation and think about architectural boundaries, would have a better chance. That is the promise of this campaign.
Let me be clear about what happens in an ensemble audit. One researcher asks the model: “Assume this wallet is designed to be used by one person with a single seed phrase. Find ways to steal funds if the seed phrase is compromised.” Another asks: “Assume this wallet is a multisig with N-of-M threshold. Find ways for one signer to block all others.” A third asks: “Assume this wallet is a portfolio manager’s tool that handles liquidity across multiple Bitcoin addresses. Find ways that outputs created by one user can be spent by another.” The same codebase gets examined from different adversarial perspectives. The model’s blind spots are different for each prompt. The union of findings is larger than any single prompt can produce.
That is a real advancement over the deterministic pattern-matching of legacy static analyzers. Slither is an excellent tool. But Slither cannot hold a conversation about a protocol’s economic assumptions. It cannot say, “Wait, this validator is supposed to be reserved for the coordinator, but in this path it can be called by any user.” An LLM, with enough context, can begin to make that judgment. It will make mistakes. It will hallucinate. But the ensemble method reduces the risk because the mistakes of one prompt tend to be different from the mistakes of another.
So the bulls are right on the methodology. Human-guided diversity plus machine speed is a powerful combination.
The Cost Curve
Now let’s talk about the economics, because the press release matters less than the budget.
A traditional security audit of a medium-sized smart contract project costs between $80,000 and $200,000, depending on the firm and the complexity. It takes one to four person-weeks. For 390 projects, the cost would be in the tens of millions. The time would be measured in years. No entity in the Bitcoin ecosystem has the staff to send every critical project through that pipeline.
The AI campaign compressed the time dimension. Sixteen researchers, 30 hours, 4,962 candidate findings. The compute cost for the AI inference is not disclosed. Let’s say, for the sake of arithmetic, that each model run costs a few cents and the campaign ran thousands of runs. Total compute cost might be in the thousands of dollars. Human time is more expensive, but even at $250 per hour per researcher, 16 researchers for 30 hours is about $120,000. That is less than a single traditional audit of one medium project. And it covered 390 projects.
Even if 80 percent of the 4,962 findings are false positives, the remaining 20 percent is about 992 candidate vulnerabilities. A traditional audit would need years to reach that number. The raw efficiency is real.
But efficiency is not the same as effectiveness. The entire exercise is only useful if the findings are triaged by skilled humans. If a project receives 200 findings from an AI campaign, and 160 are false positives, the maintainer still has to review all 200. The triage burden is not zero. It can be substantial. A maintainer with a day job and a newborn will not be excited by a giant report full of “critical” labels that turn out to be irrelevant.
The ideal workflow is a layered pipeline. First, AI generates candidate findings. Second, a human researcher reviews each finding against the surrounding code. Third, the researcher writes a proof-of-concept or a clear reproduction path. Fourth, the maintainer receives a small, prioritized list of actionable issues. The campaign appears to have done this for at least some of the findings. The question is whether it did so for all 720 critical/high issues, or only for a selected subset.
The release implies that PoCs were sent “along with” the findings. If every critical/high finding had a PoC, that would be extraordinary. Sixteen people writing 720 PoCs in 30 hours is 45 PoCs per person. That is possible only for relatively mechanical exploit classes such as integer overflow or unchecked external calls. For deeper logic bugs, a PoC can take hours. So either the PoCs were shallow, or the count is small, or the 720 number includes many findings that did not have PoCs.
This is not a reason to dismiss the campaign. It is a reason to ask for the breakdown.
The False Sense of Safety
The most dangerous outcome of any security scan is the feeling that the scan has made the project safe. It has not. A security scan is a snapshot, not a certification. It says, “at this point in time, with these prompts, this model found these patterns.” It does not say “no vulnerabilities exist.” It does not say “the architecture is sound.” It does not say “this wallet will not lose funds in a novel attack six months from now.”
The Bitcoin ecosystem has a particular problem with security theater. People love the ritual of the audit badge. They love the idea that a group of researchers looked at the code and found 720 critical issues and fixed them. That feeling of safety is what allows a project to grow faster than its engineering discipline.
I have seen the inverse as well. I have seen maintainers who receive a report, ignore it, and then get exploited. I have also seen maintainers who receive a report, panic, apply a patch, and introduce a worse bug. The best security outcome is not a large number of findings. The best outcome is a small number of precisely framed findings, each with a reproducible demonstration and a suggested fix.
The AI campaign’s 4,962 findings are not a small number. They are a large pile of raw material. The value of that pile depends entirely on the human sorting process after the campaign ends.
Oracle Lessons, Applied Here
The Compound oracle episode taught me something that applies directly to this campaign. The vulnerability was not hidden in the price-feed contract. It was hidden in the relationship between the price-feed contract and the rest of the protocol. A single DEX pair with low liquidity was feeding a price that controlled billions in borrowing power. An attacker did not need to hack the contract. The attacker needed to manipulate the input.
In the AI campaign, the input is the prompt. A model’s output depends on the prompt the researcher chooses. If all researchers write prompts that assume the library is called from a trusted contract, they will miss the attack from an untrusted caller. If all researchers write prompts that assume transaction ordering is irrelevant, they will miss reentrancy across multiple transactions. If all researchers write prompts that assume a wallet’s entropy source is secure, they will miss a weak-randomness bug that has been sitting in the code for years.
The solution is not to use “better” prompts. The solution is to use deliberately diverse prompts. This campaign did that. It is the right choice. But the diversity must be tracked, published, and analyzed. Which prompt found the most critical issues? Which prompt produced the most false positives? Which kind of researcher background produced the best results? Without that metadata, the campaign is a one-off experiment, not a repeatable methodology.
The Contrarian Case
The headline number is inflated. The methodology is underdocumented. The severity labels are ambiguous. Yet the campaign is still a genuine signal of a structural shift.
Let me say it plainly: the bulls are right in a specific, technical sense.
The maintainer acknowledgment is the strongest evidence. Maintainers are the most skeptical audience in the world. They have read their code for years. They know exactly where the bodies are buried. If they quickly confirm a report, that report has passed a much harder test than any model benchmark. The fact that “many” maintainers confirmed reports tells me that at least a meaningful slice of the campaign’s output was not noise.
The second thing the bulls get right is the scale. A traditional manual audit of 390 projects is impossible in any reasonable time. The campaign compressed what would have been many person-years into 480 maximum person-hours. The architecture of the model will only improve. The next campaign, with better prompt engineering and better triage automation, will likely produce more actionable findings in less time.
The third thing the bulls get right is the direction of the industry. Security will become a machine-assisted discipline. The auditor who refuses to use AI will become the auditor who is too slow and too expensive. The auditor who uses AI without understanding blockchain logic will become a producer of false positives. The auditor who combines AI speed with human forensic judgment will be the only auditor who really protects users.
The campaign is a proof-of-concept for that hybrid role. It is not a replacement for human review. It is a radical upgrade to the front end of review.
The Contrarian Blind Spot
The bulls’ blind spot is the same blind spot that every large-scale security effort has: volume can be mistaken for clarity.
A project with 4,962 findings can feel well-scanned. But a project with 4,962 findings may simply be a project whose code is messy, whose libraries are old, or whose functions are long. The findings may be genuine but low-impact. Meanwhile, a project with 10 findings may have one catastrophic logic flaw that the AI missed because the flaw does not follow any training-data pattern.
The Bitcoin ecosystem already has enough security clutter. There are countless repos with outdated dependencies. There are countless unnecessary uses of unverified third-party libraries. The campaign will generate thousands of findings about those issues. That is useful. But the existential vulnerabilities are more likely to be in the interaction between a Bitcoin address, a PSBT, a hardware wallet, and the human being holding it. Those vulnerabilities do not look like code patterns. They look like protocol assumptions.
If the campaign only makes maintainers fix the easy, pattern-matching issues, it has created an illusion of progress. The deeper issues require manual reasoning about the entire network. That manual reasoning cannot be fully replaced by LLMs, no matter how many prompts are used.
What a Proper Follow-Up Looks Like
I want to see the raw output. Not an article. Not a summary. A repository.
For each finding: the project name, the commit hash, the file path, the line number, the severity label, the category, the prompt used, the model used, the reproduction steps, the proof-of-concept, the maintainer response, and the current status.
That dataset would be worth more than every security tweet in the next three years. It would let the industry benchmark, iterate, and improve. It would show exactly which prompt styles found which classes of bugs. It would turn the campaign from a one-time event into a reusable corpus.
I have audited enough code to know that this kind of dataset is not easy to produce. It takes discipline. It takes time. It takes the willingness to admit that many findings are false positives. It also takes the courage to publish the models that were used, including their known limitations.
If the organizers publish this dataset, they will set a standard that future campaigns must follow. They will change how the industry thinks about security infrastructure. If they do not publish the dataset, the 4,962 number becomes just another statistic in a long line of unverifiable crypto claims.
The Takeaway
Do not accept the arithmetic on faith. Accept only the data behind it. The 2.3 per researcher-hour figure is either a misunderstood denominator or an extrapolation error. The 4,962 number is raw output, not fixed vulnerabilities. The 720 critical/high severity labels are valuable starting points, not proof of exploitability.
The campaign is still a good thing. Human-guided AI audits are the future. But the future will not be built on unverified headline numbers. It will be built on open datasets, reusable prompts, and honest false-positive rates.
I have been watching the blockchain long enough to know that every transaction leaves a scar on the chain. Every dubious statistic leaves a scar on the industry too. The best way to honor this campaign is not to celebrate the round number. The best way is to demand the raw ledger underneath it.
Hype is a mask; the ledger is the face beneath it. The people behind this campaign have a chance to show us the face. I hope they take it.
Numbers have no emotions, only consequences. The consequence of a genuinely transparent AI security dataset could be the first truly scalable path to safer Bitcoin code. The consequence of an opaque one is another season of security theater.
I’m waiting for the repository.