The case for a Bitcoin LLM

BTC Before Light: Issue 49 ☀️

Jul 22, 2026

Good morning,

Today, I’m returning to a topic I briefly flagged last month about an effort to build an artificial intelligence (AI) model that reasons about the Bitcoin protocol. Below, I discuss the idea in more detail, its motivations, and how the community discourse is shaping around it.

Regarding Bitcoin Core development, this discussion is happening primarily on Delving Bitcoin, outside of discussions about Core development, as nothing proposed would require changes to Bitcoin or its reference implementation. For updates on Core, refer to the linked posts at the bottom of today’s newsletter.

As a note to subscribers, I’m going on a two-week holiday starting next week, July 27, so this newsletter will go on a short break. I’ll be back August 11 with a fresh new update on all things Bitcoin development and governance.

Let’s get into it.

Yours truly,

Christine D. Kim

☁️ To get early access to this week’s BTC Before Light newsletter, make sure you are signed up for a premium subscription:

⛅ Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for BTC Before Light:

☀️ I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business understand and stay ahead of protocol changes:

Protocol Watch

The side 🍳

The main 🥞

Last month, Thomas Suau, an artificial intelligence (AI) solutions architect based in France, posted on Delving Bitcoin about the creation of a language model (LLM) that can “genuinely think in Bitcoin.”

His initial observation was that information about Bitcoin, its development and usage, is rich and publicly available. Yet no AI model has been built to reason specifically about the protocol. The closest attempt, a model called Satoshi-7B released in 2024, was trained on Bitcoin culture and Austrian economics rather than protocol mechanics.

Seven weeks and eighteen replies later, Suau’s post has become something more concrete than a project pitch. Developers have substantially expanded Suau’s list of source material, offered new design constraints and considerations, and ideated benchmarks to test the reliability of a Bitcoin-native LLM in execution.

The motivation

As Suau explains in his initial post, a Bitcoin LLM could serve various purposes and stakeholders within the Bitcoin ecosystem.

Script reasoning: Every bitcoin is locked by a small program specifying the conditions under which it can be spent. Given one of these programs in raw form, the model should identify the type of construction, explain who can spend it and under what conditions, and flag anything unusual or risky.
Script recommendation: When a user describes a custody arrangement for their bitcoin in plain language, for example, “a two-of-three multi-signature key setup, with a recovery path that opens after six months,” the model should be able to build a correct construction for this arrangement and accurately explain its tradeoffs against other constructions.
UTXO graph traversal: Bitcoin has no account balances like Ethereum; instead, it uses discrete coins traceable to the transactions that created them. The model should be able to audit the creation and movement of each coin and provide high-level insights into usage patterns for informing chain tooling and services, not surveillance.
Protocol Q&A: Finally, the model should be able to answer questions about consensus rules and transaction formats, citing documentation such as Bitcoin Improvement Proposals (BIPs) that define them, as well as historical discourse that has shaped rough consensus on them.

In summary, the primary motivation for building a Bitcoin LLM is two-fold. First, it could serve as a tool to help users understand how to transact safely and self-custody their coins on Bitcoin. Secondly, it could serve as a resource for protocol developers to gain deeper insights into how Bitcoin is used and to clarify prior design choices, helping guide future decisions.

Source material

Now, the first design consideration in building an LLM for any of these purposes is the source material on which the LLM would be trained.

In his original post, Suau referenced BIPs, the Bitcoin Developer mailing list, the Delving Bitcoin forum archives, Bitcoin Core source code and functional tests, and on-chain transaction data as initial source material.

One user “sudocarlos” added the Bitcoin Stack Exchange and Bitcoin Optech as additional reference material.

“L0rinc,” who is also an active contributor to the Bitcoin Core codebase, added pull request review discussions, core developer transcripts, and technical books, such as Learn Me a Bitcoin.

Another user, “AdamISZ,” mentioned the Bitcoin Internet Relay Chat (IRC) logs, some of which have been archived as early as 2010.

Considering the extensive source materials for a Bitcoin LLM, a key design constraint highlighted by contributors such as l0rinc and later acknowledged by Suau was that the model should be trained not to seek answers directly, but rather to present arguments along with their sources.

L0rinc wrote:

There often is not a central “truth” here, but different experts arguing for different tradeoffs. … ideally a Bitcoin-native LLM would not just try to produce the answer, but preserve which expert argued what, in what context, and what assumptions or compromises each side is making.

Fine-tuning vs. special tooling

Another key design consideration that developers discussed in the thread was the methodology for building the model’s specialized knowledge on Bitcoin.

Suau’s initial proposal was to take an existing open-source model and further train it on Bitcoin-related material. This approach in training specialized LLMs is called “fine-tuning.”

Several developers who chimed in on Suau’s post argued against this methodology, instead advocating for techniques that do not require special training but rather special tooling that any open-source model can use to produce informed answers about the Bitcoin protocol.

One of these techniques is called Retrieval-Augmented Generation (RAG), which has the model search a curated library of outside sources and answer from what it finds, rather than from its own training. For example, in the context of a Bitcoin LLM, the model would first search a curated collection of Bitcoin documents, pull the relevant pages, and then generate a response.

About the advantages of RAG, David Gumberg, another active contributor to Bitcoin Core, wrote:

I expect that the corpus of Bitcoin related text is relatively small compared to the corpuses that frontier models are trained on … domain specific finetuning is rarely worth the time and effort compared to building something general like RAG that you can just plug the latest frontier model into.

Another advantage of this approach is that new documents can be iteratively added to the library, and the model can always pinpoint which documents it pulled from to generate its answers.

Breno Brito is a machine learning engineer who worked on the first Bitcoin-trained LLM, Satoshi-7B, in 2023. Brito explained that while Satoshi-7B was fine-tuned, the main reason was due to the poor ability of all LLMs at the time to follow instructions.

Brito explained:

The main reason we were building Satoshi-7B and other fine tuned models was because the models were really bad at instruction following. That’s not the case anymore. Most of what you said above should be done via skills (with scripts doing the deterministic parts inside a skill folder).

In other words, Brito suggests that models have improved significantly over the last few years at following instructions, such that specialized knowledge mostly no longer needs to be fine-tuned or trained into a model. Instead, Brito explained, this knowledge can be packaged as “skills,” bundles of written instructions paired with scripts that an AI agent can load to perform specific tasks.

Brito is currently building an open-source library of these called Freedom Skills, covering Bitcoin, Nostr, related privacy tools, and other freedom technologies.

Benchmarking

In addition to the source material and methodology for training a Bitcoin LLM, developers have also discussed the appropriate benchmarks for evaluating different models.

Alex Waltz, a Bitcoin researcher and filmmaker, suggested a standardized knowledge test on Bitcoin protocol trivia that could assess which models are more accurate than others.

Waltz recommended questions like:

1. Give all the examples where consensus rules were grandfathered in.
2. Was SegWit a block increase?
3. Were the following events hard or soft forks and why? Bitcoin releases 0.3.5 ; 0.8.0 ; 0.15.0 ; BIP30, SegWit?

Suau proposed something more formal, such as a public evaluation set of 200 tasks with programmatically verifiable answers. The tasks, such as script parsing and descriptor compilation, would be split equally to test the model's abilities against the four main objectives.

Suau wrote:

Anyone can then test their preferred approach: frontier model plus search index, frontier model plus node tools, fine-tuned 7B, or any combination. … Happy to draft the benchmark structure if there is interest.

Bottom line

Much like the Bitcoin protocol itself, the development of a Bitcoin LLM is benefiting from community input and involvement.

From crowdsourced input on the right source material to the firsthand experience of other developers working on similar ideas to public benchmarks for the best model, Suau’s post about Bitcoin LLMs has sparked significant interest and discussion within the Bitcoin developer community.

While developers are coalescing on a comprehensive suite of source material for a potential Bitcoin LLM, as well as a methodology for training it on this specialized knowledge, there are still several open questions about such a model, such as the model size, reasoning about rough consensus, and design tradeoffs related to the model’s performance vs accessibility for users.

Thus, while the design for a Bitcoin LLM is by no means settled, the consensus that has already formed around the rough blueprint and motivation for such a tool appears promising.

Discussion about this post

Ready for more?