SVMLLM

A Solana VM compiled into transformer weights

SVMLLM runs reduced sBPF, the bytecode of Solana programs, inside hand-constructed transformer components. Attention-style lookups fetch and decode instructions, ReLU feed-forward blocks are the ALU, and Gated DeltaNet state is exact RAM for registers and memory. Nothing is trained. Every result is checked against a reference interpreter, which is itself cross-checked against Anza's solana-sbpf.

Run the demosSee how it worksGitHub: Verafyai/svmLLMBased on Qwenputer

How it works

One sBPF instruction is one pass through a fixed stack of hand-built blocks. Step through a real recorded run of the weights machine below; every value comes from results/weights_traces.json.

1

sBPF program

8-byte instructions written into a DeltaNet program memory with one-hot keys.

2

Fetch and decode

PC becomes a one-hot query; the read is attention over program slots. Decode is one linear layer.

3

ALU in the FFN

Exact lookup-table FFNs over 4-bit limbs: ripple adders, multipliers, shifters, comparators.

4

Exact RAM

Registers and memory are Gated DeltaNet state, gate 1, beta 0 or 1: an overwrite, never a blend.

5

Exit and CU

A 24-bit CU counter ticks once per instruction; exit or an error flag halts the driver loop.

Precomputed: weights machine run 

      

        
0
0
0
ready

        

        

        

      

    

  

  

    

    

  






  
Ten runnable programs

  
Pure compute, no accounts. Pick a program and a preset, edit the input words if you like, and press Run. Live: reference interpreter runs in your browser in JavaScript. Precomputed: weights machine shows the recorded run of the PyTorch weights for the same preset, so you can compare them.

  

  

    

      

      
    

    

      

      
      
      

      

    

  

  
Step trace


  
Paste your own program

  
Up to 256 instructions and 8 KB of source. The same reduced sBPF subset: 64-bit ALU (imm and reg), ldx/stx/st b/h/w/dw, jumps, lddw, call (stub), exit. Memory is two 128-byte windows: input at r1, stack below r10. This box runs on the reference interpreter only; the weights machine runs offline in Python.

  

    

    

      
      

      

    

  






  
Judgement filter

  
Some of the costliest smart-contract incidents involve code that ran exactly as written, with an outcome a sensible human operator would have stopped. Many others are ordinary bugs or key compromises; this project targets only the first kind. That first kind is what motivated this project: fuse the best of smart contracts (trustless, deterministic and decentralized execution) with the best of human intelligence (judgement based on context).

  

    
1. sBPF programruns in the VM: exact result and CU countin the weights

    

    
2. Review stepamount, destination, history patternrules, NOT in the weights

    

    
3. Verdictallow hold block with a reasonoptional LLM judge (stub)

  

  
The VM answers "is this valid by the code?". The review step answers "would a sensible operator let this through?". Today the review step is transparent rule-based heuristics in Python (svllm/judge.py) and JavaScript on this page. LLMJudge is a pluggable interface with a stub backend: it can escalate a verdict but never downgrade a rule block, and it never overrides a code-level rejection.

  
Rules, in order:
    
  1. Program error or nonzero exit code: block (the code already said no).
    2. 
    
  2. More than 3 withdrawals in 15 minutes moving at least 50% of the balance: block (drain pattern).
    3. 
    
  3. At least 50x the median past amount to a never-seen destination: block.
    4. 
    
  4. At least 10x the median past amount: hold.
    5. 
    
  5. New destination and at least 3x the median: hold.
    6. 
    
  6. Otherwise allow.

  






  
Test results

  
From python run_tests.py. Three independent executions are compared: the Python reference interpreter, Anza's solana-sbpf 0.12 interpreter (Rust, SBPFVersion V0) and the weights machine. Status, r0, CU and the 128-byte input window are compared against solana-sbpf; the weights machine must also match every register and both memory windows.

  






  
Run it yourself

  
git clone https://github.com/Verafyai/svmLLM && cd svmLLM
python3 -m venv .venv && . .venv/bin/activate
python3 -m pip install -r requirements.txt
python -m svllm.demo fibonacci 10        # one demo on the weights machine, with its trace
python -m svllm.judge                    # judgement-filter examples
(cd xcheck && cargo build --release)     # optional: solana-sbpf cross-check
python run_tests.py                      # full suite, writes results/

  

    
What is in the weights
    
      
  • Instruction fetch: one-hot PC query against DeltaNet program memory.
    • 
      
  • Decode: one constant linear layer from the opcode one-hot to control signals.
    • 
      
  • ALU, branch conditions, address checks, CU meter: exact lookup-table FFNs, linear maps and ReLU gating.
    • 
      
  • Registers and data memory: Gated DeltaNet state with gate 1 and beta 0 or 1.

    
What is not
    
      
  • The driver loop: Python calls step() until the halt flag is set.
    • 
      
  • Fixed-depth ripple circuits are Python loops over unrolled blocks, not one fused layer stack.
    • 
      
  • Lazy mode skips ALU branches whose gate is exactly 0 (full mode computes all and is tested equal).
    • 
      
  • The judgement filter: rules in Python and JS, plus an LLM stub.
    • 
      
  • It is not yet inside Qwen weights; see next steps in the README.

  

  

    
Honest limitations
    
      
  • Reduced sBPF: no ALU32, no syscalls (call is a stub that zeroes r0), no accounts, no CPI, no internal calls.
    • 
      
  • Memory is two 128-byte windows, not Solana's full regions. Programs are at most 256 slots.
    • 
      
  • CU model is 1 per instruction. Real Solana charges syscalls and CPI differently.
    • 
      
  • CPU PyTorch, about 5 ms per simple instruction and roughly 65 ms for div or mod on one thread. A demo, not a validator.

    
Future possibilities
    
      
  • Accounts: serialize Solana account data into the input window and enforce owner and writable rules.
    • 
      
  • Syscalls: sol_log, memcpy, sha256 as extra FFN circuits.
    • 
      
  • CPI and internal calls: a call stack in DeltaNet memory.
    • 
      
  • A real CU model per instruction class and syscall.
    • 
      
  • Compile the same circuits into Qwenputer-style Qwen layers so a chat model can run sBPF in context.

  






  
Future steps

  
Untested, not a claim. Merge the hand-weighted machine into a Qwen-class model so one model does both language judgement and exact execution. Its size would be dominated by the base model: Qwenputer's checkpoint is 18.8 GB and needs a 24 GB GPU, while the SVM machine adds about 1.1M parameters.






  
Where this could run

  
This is a demo that exact computation can live in a model's weights. It is not a node replacement.

  

    
Realistic today
    
      
  • Sidecar next to the chain software. A node operator runs the model beside their own client to review, flag or hold transactions in their own RPC endpoint, mempool view or wallet guard. It affects only that operator, not consensus. This is the realistic path today.
    • 
      
  • Off-chain checker and audit. Re-run a transaction on the weights machine, compare it with the reference result and attach the review to an audit trail.
    • 
      
  • Judgement layer in front of a wallet or multisig. The exact VM result plus the review step decides allow, hold or block before a signer approves.

    
Research direction: part of consensus
    
      
  • Determinism. GPU floating point can differ across hardware and software versions. These weights use exact lookup-table style math, but a full Qwen-sized model is a much bigger problem.
    • 
      
  • Cost and speed. Each sBPF instruction is one full pass through the circuits, and every validator would repeat every pass. On one CPU thread that is about 5 ms for a simple instruction and roughly 65 ms for div or mod.
    • 
      
  • Compute limits. The model run would need to be metered and bounded by compute units like any other execution.

  

  
The judgement filter is illustrative heuristics on synthetic histories, not a security product.






  
Support

  
Drop me some Solana if you want to support me to keep working on this.

  
86pEFG22pV4hd9wH48TSnATLo8U9bAraM8C58NAmPtuy






  
Credits

  
Inspired by Qwenputer by divagr1925: a RISC-V CPU compiled into Qwen3.5-4B, with Gated DeltaNet layers as exact RAM. See the announcement and the weights on Hugging Face. Cross-checked with Anza's solana-sbpf. Sibling project: EVMLLM, an Ethereum VM executed by transformer weights.