Can You Cram All of Solana Into an LLM?
What "all of Solana" means, which part could live in neural network weights, and why the rest can't.
This article started as a 23-post thread on X from the Verafy Foundation. Read the original thread on X.
We already put a tiny Solana-style virtual machine inside neural network weights. It's called svmLLM. So it's a fair next question: can you cram all of Solana into an LLM?
First we have to answer a simpler one: what does "all of Solana" actually mean?
Each section below has a "simple version" first, then the technical detail. We also mark clearly which numbers we measured and which parts are our reasoning.
What Solana is, and where the SVM fits
Simple version: Solana is a network of computers that agree on one shared ledger. Each one runs validator software. Agave, built by Anza, is the main one.
Inside Agave is a smaller engine that actually runs programs. That engine is the SVM.
Think of Agave as the whole restaurant: the front door, the order book, and the managers who agree on what was served. The SVM is the kitchen. It takes an order and cooks it exactly the same way, every time, in every restaurant.
Advanced version:
- Agave receives transactions, talks to peers, stores the ledger and accounts, builds and replays blocks, and votes.
- The SVM loads the accounts a transaction touches, runs each program in the sBPF VM, charges compute units, and returns the new account state.
How they fit together
Simple version: every kitchen cooks the same order and compares plates. Same plate, you vote yes. Different plate, you're out.
A leader builds a block. Every other validator replays it through its own SVM, checks that the result matches, then votes.
Advanced version: leaders come from a stake-weighted schedule, 4 slots in a row. Slots are 200 ms now.
Since Oct 21, voting runs on Alpenglow's Votor, which replaced TowerBFT. Validators send votes to each other and bundle them into certificates. The SVM didn't change.
How big is each piece?
We counted the Rust in Agave master on Nov 1, 2026 with cloc, skipping test folders and inline test modules:
- Agave repo: about 326K lines
- SVM crates in Agave: about 24K lines
- sbpf VM (its own repo): about 12K lines
So the SVM plus the sbpf VM is about 36K of about 338K lines (Agave plus sbpf). That's roughly 11%.
The other 89% or so is networking, block propagation, storage, voting, RPC and tools.
The file that steps through sBPF instructions one by one, interpreter.rs, is about 640 lines.
Two very different questions
So "all of Solana in an LLM" can mean two very different things:
- A. The whole Agave validator. About 338K lines with sbpf, mostly networking and disks. That doesn't belong in weights.
- B. Just the SVM. About 36K lines. That's the part svmLLM is aiming at.
Where svmLLM is today
svmLLM is a standalone PyTorch machine with 1,130,672 weights. All of them were written by code (hand-constructed), and none were trained.
It runs a reduced sBPF v0: 63 of 91 opcodes, with no syscalls, no accounts and no cross-program calls. It's a slice of the sbpf VM, not the whole SVM yet.
Can all of Agave go in an LLM?
Not by itself.
Simple version: a model is a brain in a jar. It can think, but it has no hands, no phone line, no filing cabinet and no clock. A validator needs all of those, all day, every 200 ms.
Advanced version: weights only do math on the numbers you feed in.
Agave also opens network sockets, reads and writes disk, keeps time, signs with secret keys and runs many threads. Anza recommends 256 GB+ of RAM and terabytes of disk.
None of that runs inside a model.
An LLM needs a harness
So an LLM can only be one part of a validator. It needs a harness.
Simple version: a harness is the body around the brain.
Plainly: it's ordinary code that wraps the model. It runs on a real machine, handles network, disk, time and keys, feeds the model its inputs, takes its outputs, and runs the loop.
Why not stuff the whole validator in?
Because most of it isn't computation.
By our line count, about 89% of the code is I/O and orchestration: peers, terabytes of ledger and accounts, 200 ms timing, vote signing. That stays outside a model anyway. The SVM plus sbpf is about 11%.
Then there's speed. The SVM slice in weights is about 560,000x slower than the real interpreter, and network and disk code gains nothing by becoming weights.
Putting all of it in weights would be slower and would add nothing. The better split is real Agave as the harness, with the LLM only at the SVM swap point. This is our reasoning, not something we measured.
Option A: real Agave as the harness
This is the realistic option. The harness is real Agave, and we change one step: where Agave hands programs to the sbpf VM (program-runtime/vm.rs), it calls the LLM instead.
That's the really crappy AI validator. In theory, yes, it could work. Not today: it needs every opcode and syscalls first. We have not built or tested this swap.
Option B: the LLM supplies all of Agave's logic
In option B, the LLM supplies all of Agave's logic and the harness only does I/O. It's an emulator of an emulator.
Theoretically possible. Practically meaningless. Our guess, which we have not measured, is that it would be vastly slower than option A, and option A already can't keep up (see the next section). It would never be part of consensus.
Would it ever be included in consensus?
No.
Leaders are picked by stake, not speed. But every validator must replay each block and vote in time, and slots are 200 ms.
- svmLLM: about 2.8 ms per instruction
- solana-sbpf: about 5 ns per instruction
That's about 560,000x slower.
A full block can hold 30M+ compute units at 200 ms slots, and a simple instruction costs 1 CU.
At 2.8 ms per instruction, one full block takes about 23 hours to replay. Even a block 100x lighter takes about 14 minutes.
It would fall behind within seconds and never catch up.
Would it be fun? Yes.
And there are useful versions that never touch consensus:
- A cross-checker that re-runs transactions next to a real node and says agree or disagree
- Execution you can inspect weight by weight
- Security research tooling
Getting it inside a real LLM
Getting this inside a real LLM builds on Qwenputer by @divagr1925: a RISC-V CPU compiled into Qwen3.5-4B.
There are two routes. One is to run an sBPF interpreter as firmware on that CPU. The other is to compile svmLLM in as native layers. Neither is done yet.
You can read the Qwenputer write-up at divagr.com/blog/qwenputer.
Honest status
svmLLM is a research prototype with no security audit.
It's tested against solana-sbpf 0.12.2 on our own 134-case suite plus 1,000 random programs. These are not Firedancer's fixtures.
Do not use it for anything that holds funds.
Learn more
We have not launched any token.
- Live demo and numbers: svmllm.rexstjohn.com
- Source: github.com/Verafyai/svmLLM
- The EVM sibling project: github.com/Verafyai/evmLLM
- Qwenputer, the project that inspired this: divagr.com/blog/qwenputer
Read the original thread on X: x.com/verafyfoundtn/status/2116946463666368785