The recent Coldcard hardware wallet hack, which led users to lose more than $100 million worth of bitcoin, or more than 1,500 BTC, has reopened a long-running argument in the Bitcoin world: what counts as open source, and what does not.
In an analysis published by Bitcoin Magazine, Juan Galt wrote that the incident did more than expose a wallet failure. It also showed that many people, including committed Bitcoin users, still blur the line between open-source software and code that is merely visible to the public.
Why the terminology matters
The article begins with definitions. Free and Open Source Software, or FOSS, and Free/Libre and Open Source Software, or FLOSS, refer to software that meets formal standards around user freedom.
According to the Free Software Foundation, free software is built around four essential freedoms: the freedom to run the program for any purpose, to study how it works and modify it, to redistribute copies, and to distribute modified versions. Access to source code is required for the freedoms tied to study and modification. The FSF also stresses that “free” refers to liberty rather than price, captured in the familiar line: “free as in free speech, not as in free beer.”
The Open Source Initiative adds 10 practical requirements to its Open Source Definition. Those include free redistribution without royalties, access to source code in the preferred form for modification, the right to create and distribute derivative works, and no discrimination against people, groups, or fields of use, including commercial use. A license must satisfy all 10 conditions to qualify under the OSI standard.
That is where “source-available” diverges. Code may be open for reading while the license still blocks resale or commercial deployment.
Galt points to Coldcard firmware as an example. The firmware is published under MIT terms plus the Commons Clause. That clause removes the right to “Sell” the software, including cases where it is provided to third parties for a fee or included in a product or service whose value is derived entirely or substantially from the software. In practical terms, the firmware cannot be used commercially.
The Commons Clause FAQ addresses the classification directly: “Is this ‘Open Source’? No.” The article says that distinction matters because public code inspection is only one part of the open-source model. What makes software FOSS or FLOSS is the full package of rights granted under the license, not simply the fact that source code can be viewed.
Open source creates the chance to verify, not verification itself
The article argues that the philosophical freedoms behind open source rely on a harder economic reality. Enough skilled and motivated people must actually examine the code. If they do not, the model can slip into a tragedy of the commons, where everyone benefits from shared infrastructure while too few contribute the time needed to check and maintain it.
One Bitcoin developer quoted in the piece put it bluntly: “Using mocks and stubs of Open Source code in tests is irresponsible and shortsighted. Open Source code is considered safe because anyone can verify it. If you aren’t willing to do the bare minimum of testing the features you actually depend on, then you are behaving like a leech.”
From that view, open source does not produce safety on its own. It produces the possibility of safety through verification. Whether that verification happens depends on incentives, technical skill, and sustained attention.
The article notes that many historical FOSS projects become stronger over time as vulnerabilities are found, disclosed, and patched. Linux is used as the clearest example. The Linux kernel powers most of the world’s servers, cloud systems, Android devices, and embedded infrastructure, making it one of the most widely deployed software projects ever built.
Bitcoin Core as the article’s model case
Galt presents Bitcoin Core, the reference implementation of Bitcoin, as a large-scale example of open-source development functioning in the open. The software is released under the MIT license and sits behind most Bitcoin-related infrastructure.
Its process is public by design. Anyone can submit a pull request. Code review serves as the main filter and is also the standard entry point for new contributors. Reviewers use a specific vocabulary: Concept ACK, Approach ACK, ACK tied to a commit hash, and NACK. Maintainers weigh contributor consensus and technical quality before merging changes.
For consensus-critical changes, the threshold is higher. Those proposals usually require a Bitcoin Improvement Proposal and often go through extensive discussion over multiple years on the bitcoin-dev mailing list and IRC.
The article says there is no privileged caste of “Bitcoin Core developers.” Trust is earned through demonstrated competence over time. Maintainers exist for practical reasons such as auditing and merging code, managing releases, and handling basic moderation. The output, however, remains pure open-source code that anyone can inspect, build, fork, or run. Developers whose commits are merged are broadly referred to as Bitcoin Core Contributors.
Longtime open-source Bitcoin developer Calle is quoted as saying: “People who think that core is some sort of intransparent institution operating in the shadows are either too lazy or too dumb to go have a look for themselves. Literally everything they do is public, anyone can chime in, and the result of their work is pure Open Source code.”
The funding model is also part of the comparison. The article says Bitcoin Core work is funded largely through nonprofits and grant structures, including Brink, OpenSats, Spiral, and others, rather than through a conventional corporate product roadmap. Technical debates play out publicly on the bitcoin-dev mailing list and in the #bitcoin-core-dev IRC channel on Libera Chat. GitHub issues and pull requests often carry comment trails stretching back a decade.
That has produced a development culture centered on correctness and auditability rather than commercial feature velocity.
What failed in the Coldcard case
Most users of open-source or source-available software never read the code themselves. They rely on the assumption that someone else is doing it. In the Coldcard case, the article says a critical entropy flaw stayed in publicly available firmware for about five years before it was exploited and, through that exploitation, discovered.
The bug was introduced during a major 2021 rewrite that also removed the remaining GPL-derived code from Trezor. The article describes Trezor as the first hardware wallet and now the second-largest player in the self-custody segment.
The library at the center of the entropy failure was libngu, which replaced trezor-crypto. According to the article, libngu drew little outside scrutiny despite more than five years in production use. It had only seven GitHub stars and fewer than 20 forks. By comparison, trezor-crypto had 512 stars and 212 forks, while the newer trezor-firmware had 793 forks and 1.8k stars.
The article’s argument is that source visibility alone did not produce meaningful review. Critics say one reason is that well-funded commercial firms were restricted from using the code and therefore had less legal and economic reason to invest serious review effort.
In Bitcoin, the cost of such failures is unusually high because a critical bug can be turned directly into liquid funds on the open market. The article says about half of the first stolen Coldcard funds remain parked in a handful of addresses and the hacker may still be caught. But, citing Galaxy Research, it adds that copycat attackers who came later were more careful, and some stole more bitcoin and laundered it successfully.
That dynamic, Galt writes, is tied to Bitcoin’s censorship resistance and immutable transactability. Those properties create strong incentives for attackers while also acting as a Darwinian filter for projects and users. Over time, the projects most likely to last are those that keep attracting competent review, along with companies and users that take security precautions seriously.
Licensing shapes review incentives
The article says critics of Coinkite’s licensing choices have argued for years that license design changes who is willing to review software and why. A pure 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 have both the legal right and the business incentive to examine the code deeply.
In that setup, the burden of review shifts back toward the company itself. In the article’s framing, that pushes the model closer to closed source than to open source.
AI is changing both the attack and defense side
Artificial intelligence is now altering the balance between FOSS and closed-source development as well. After the Coldcard incident, a volunteer effort called the Bitcoin Red Team was formed, led by developers including Calle and Rob Hamilton of AnchorWatch, with support from OpenSats.
The team used frontier AI models to scan hundreds of open-source Bitcoin repositories. During one intensive stretch, it filed thousands of findings, including dozens marked critical or high severity, across hundreds of projects. The article says those findings were disclosed responsibly to maintainers before wider publication.
For Galt, that exercise showed that AI-assisted review can uncover problems at a scale and pace that would have been difficult for human-only teams.
The article also makes a pointed observation about models themselves. It says the Red Team found Chinese open-weight models to be far more reliable than closed-source American models, which refused to answer Red Team queries even when given cyber permissions and high-level access. The article says American developers have lamented that trend.
At the same time, AI-generated code is creating a new burden for maintainers. Reviewing machine-generated output often takes longer than producing it. Some open-source projects outside Bitcoin have already restricted issue trackers or adopted strict anti-AI contribution rules just to remain functional.
On the closed-source side, the older advantage associated with security through obscurity is fading. Modern AI systems can read code, de-obfuscate logic, probe endpoints, and reason through implementations at high speed. The article says the practical gap between open and closed source now sits mostly in back-end code that never gets shared online.
As a result, closed-source security increasingly depends on the quality of professional audits, the speed of patch deployment, and whether capable people with access remain motivated to keep looking.
Pressure is rising on Bitcoin software models
The article closes by arguing that Bitcoin and the broader crypto sector put unusual pressure on free and open-source software. Real monetary value, adversarial incentives, and AI-scale analysis are combining to force software models to adapt.
Moving back to pre-digital infrastructure is not a workable option for systems that support modern society, Galt writes. Under pressure from AI-assisted attackers and digital-first finance, the projects most likely to endure will be the ones that receive the deepest and most continuous audit attention.
