The Coldcard hardware wallet theft has pushed an old crypto argument back into the spotlight: visible source code is not the same thing as security, and it is not automatically the same thing as open source.
In an article written by Juan Galt and translated by Foresight News, the incident is presented as a case study in how loosely the term "open source" is often used in Bitcoin and the wider crypto industry. The piece says users lost more than $100 million in bitcoin, or over 1,500 BTC, and argues that the event exposed how limited the understanding of open-source development philosophy and its failure modes can be, even among committed Bitcoin users.
Open source, free software, and source-available code are different categories
The article begins by separating terms that are often treated as interchangeable.
Free and Open Source Software, or FOSS, and Free/Libre/Open Source Software, or FLOSS, refer to software that meets formal definitions of user freedom. The Free Software Foundation, or FSF, defines free software through four basic freedoms: the freedom to run the program for any purpose; the freedom to study how it works and change it, which requires access to the source code; the freedom to redistribute copies; and the freedom to distribute modified versions, which also depends on source access.
FSF stresses that "free" means freedom, not price. The familiar slogan is that the word should be understood as in "free speech," not "free beer."
The Open Source Initiative, or OSI, adds a separate set of practical standards. According to the article, those include free redistribution without royalties, source code made available in a form suitable for modification, the right to create and distribute derivative works, and non-discrimination against persons, groups, or fields of use, including commercial use. A license can only be called open source in the formal sense if it satisfies all ten OSI criteria.
That is where "source available" or "source visible" diverges. Code may be public to read while still carrying license terms that restrict commercial sale. The article says Coldcard firmware is an example. It uses the MIT license with an added licensing condition that explicitly prohibits "selling" the software, defined as providing it to a third party in exchange for a fee or other consideration when the value of the product or service comes entirely or substantially from the software itself. Under that condition, the firmware cannot be used for commercial purposes.
The text says the license language is blunt: "Is this Open Source? No." Its reasoning is that once this extra restriction is added, the software may satisfy many elements associated with open source, but not all of them, so it should not be labeled open source.
That distinction matters to the author. Publishing source code only creates the possibility of inspection. FOSS, by contrast, means granting the full set of rights recognized in free-software or open-source definitions. Critics cited in the article argue that commercial freedom inside open-source licensing is what gives third parties a reason to test and scrutinize code; without that, the incentive may simply not exist.
Open source does not create security on its own
The article treats the four freedoms as the philosophical core of open source, but says the model also rests on an economic assumption: enough people with the right motivation will actually review the code.
When that assumption breaks, the result starts to look like the classic tragedy of the commons. A shared resource is either overused or neglected because each participant has a short-term reason to take more or contribute less, and the resource deteriorates as a result. In software terms, the key question is not whether code is public, but whether anyone with skill, time, and attention is really checking it.
One Bitcoin developer quoted in the piece puts it in harsher terms: "Using mocks and stubs as testing stand-ins for open source code is irresponsible and shortsighted. Open source code is considered safe because anyone can verify it. If you are unwilling to do even the minimum testing of functionality you actually rely on, then you are being a parasite."
The article’s point is direct. Open source does not generate security by itself; it generates the possibility of verification. Whether verification happens depends on incentives, skills, and attention. Historically, strong FOSS projects have become harder over time as bugs are found, disclosed, and fixed, eventually turning into durable foundations for others to build on. Linux is offered as the clearest example. The kernel powers most of the world’s servers, cloud infrastructure, Android devices, and embedded systems, making it one of the most widely deployed software projects ever.
Bitcoin Core as a working model of large-scale open development
The article then turns to Bitcoin Core, the reference implementation of Bitcoin, as another real-world example of large-scale open-source development. Bitcoin Core uses the MIT license, and its process is public by design.
Anyone can submit a pull request. Code review acts as the main filter and is also the usual entry point for new contributors. Reviewers use formal labels to signal their view of a proposed change: Concept ACK means agreement with the goal, Approach ACK means agreement with both the goal and the method, ACK with a specific commit hash means the reviewer has tested the change and approves merging it, and NACK signals disagreement backed by technical reasons.
Before merging code, maintainers weigh both contributor consensus and technical merit. Changes that touch consensus rules face a higher bar and typically require a Bitcoin Improvement Proposal, or BIP, along with years of discussion on the bitcoin-dev mailing list and IRC.
The article argues that there is no privileged class called "Bitcoin Core developers" operating above everyone else. Trust is earned through demonstrated competence over time. Maintainers exist for practical reasons such as auditing code before merge, managing releases, and handling basic review tasks, but what they produce is still pure open-source code that anyone can inspect, compile, fork, or run. People whose code is merged into Bitcoin Core are typically described as Bitcoin Core contributors.
Long-time open-source Bitcoin developer Calle is quoted as saying that people who imagine Core as some opaque institution working in the shadows are "either too lazy or too stupid" to look for themselves. In his words, everything they do is public, anyone can participate, and the result is pure open-source code.
Funding for that work, the article says, mainly comes from nonprofit and grant structures such as Brink, OpenSats, and Spiral rather than a traditional company product roadmap. Technical discussion happens in public on the bitcoin-dev mailing list and on Libera Chat’s #bitcoin-core-dev IRC channel, and proposals receive close scrutiny before and after a pull request is opened. Issues and pull requests on GitHub often carry comment histories stretching back ten years. The result is a culture that prioritizes correctness and auditability over speed or feature velocity.
The Coldcard case and the incentive problem
Most users of open-source or source-available software never read the code themselves. They rely on the assumption that somebody else is reviewing it. The article says the Coldcard incident shows how fragile that assumption can be.
A key entropy flaw remained in the public firmware for roughly five years before it was exploited and discovered. The bug was introduced during a major rewrite in 2021, which also removed the remaining GPL code inherited from Trezor.
Trezor is described in the piece as the first hardware wallet and currently the second-largest player in the self-custody sector. The library at the center of the issue, libngu, replaced trezor-crypto, but saw very little outside review. After more than five years of production use, the article says, libngu had only seven GitHub stars and fewer than 20 forks. By contrast, trezor-crypto had 512 stars and 212 forks, while the newer trezor-firmware had 793 forks and 1,800 stars.
The article explains that stars and forks are two core GitHub indicators of project popularity and activity. From that comparison, the author concludes that source visibility on its own did not produce the review that mattered. Critics argue the reason is incentive design: profit-seeking companies with funding and technical capability were restricted from using the code, so the commercial motivation to invest real attention was missing.
The stakes in Bitcoin are much higher than in most software sectors, the article says. A critical flaw can convert directly into liquid funds on open markets. It adds that the first half of the stolen Coldcard funds remains in a small number of addresses, so the attacker may yet be caught, but later copycats have acted more carefully. Some have already stolen additional bitcoin and laundered it. Citing Galaxy Research, the article says total losses have reached at least 1,700 BTC.
Bitcoin’s censorship resistance and irreversible transactions create strong incentives for attackers, but they also impose a Darwinian filter, according to the article. Projects that continue to attract serious review, and whose users and companies take protection seriously, stand the best chance of surviving over time.
Licensing shapes who has a reason to audit code
The article treats license choice as a force that shapes incentives.
A fully open-source license maximizes the pool of potential reviewers and forks. A restricted source-available license may reduce commercial free-riding, but it also narrows the group of people who both have the legal right and the economic reason to commit serious attention to the code.
That shifts the review burden back onto the company itself. In practical terms, the author argues, that pushes a project closer to a closed-source model than to an open-source one.
AI is changing both open-source review and closed-source security
The final part of the article focuses on AI and the way it is changing the balance between open and closed development.
After the Coldcard incident, a volunteer effort called Bitcoin Red Team began scanning open-source Bitcoin repositories with advanced AI models. The project is led by developers including Calle and AnchorWatch’s Rob Hamilton, with support from OpenSats.
During an intense stretch of activity, the article says, the team submitted thousands of findings. Dozens were classified as critical or high severity, covering hundreds of projects. The disclosure process was handled responsibly: maintainers were notified first, then issues were made public. In the author’s view, this showed that systematic AI-assisted review can surface vulnerabilities at a scale and speed that human teams previously struggled to match.
The article also makes a narrower observation: Bitcoin Red Team found that Chinese open-weight models were far more reliable than closed American models. It says even U.S. models with internet access and top-tier privileges refused to answer the team’s queries, to the frustration of American developers.
AI is also creating a new burden for FOSS maintainers. Reviewing AI-generated code often takes more time than generating it. The article says some open-source projects outside Bitcoin have already started limiting their issue trackers or adopting strict anti-AI contribution rules just to keep basic operations going.
On the closed-source side, the old idea of gaining safety through obscurity is being weakened. Modern AI models can read, de-obfuscate, probe endpoints, and reason about code at high speed. In practice, the difference between open and closed code is shrinking, with the main remaining gap concentrated in backend systems that have never been exposed online. For closed-source software, the article argues, security will come down to the quality of professional audits, the speed of patch deployment, and whether there is a structure of incentives that keeps people with access seriously engaged in review.
The article ends by saying Bitcoin and the broader crypto sector are putting unusual pressure on free and open-source software. Real monetary value, adversarial economics, and AI-driven analysis at scale are forcing software models to evolve. Returning to pre-digital analog systems is hardly an option for the infrastructure that supports modern society. Under pressure from AI-assisted attackers and digital-first finance, only heavily audited projects are likely to endure.