EVMLLM is an EVM interpreter compiled to RV32IM and run on Qwenputer, a RISC-V CPU whose every weight was set by a compiler: attention heads fetch and decode, feed-forward units do the arithmetic, and Gated DeltaNet heads hold exact RAM. Ten Solidity contracts run on it, and every result here is checked against a reference EVM.
What runs where, honestly.browser reference VM live runs in this page: a JavaScript port of the same EVM, so you can try anything. Not the transformer.firmware on ref machine precomputed: the C EVM compiled to RV32IM, run on Qwenputer's bit-exact reference of the circuit, checked against py-evm.circuit (weights) precomputed: the same jobs free-run on the compiled weights (fastexec on CPU), every generated token compared with the reference trace.
How it works
A real program, stepped one EVM opcode at a time: . The token stream is the real trace this step produced on the reference machine.
1. Bytecode
Solidity compiled to EVM bytecode, packed into the firmware's job block in RAM.
2. Fetch and decode
Attention heads look up pc, registers and ROM words. The EVM opcode is fetched by RV32 loads.
3. ALU in the FFN
Feed-forward units add, shift, multiply and compare 32-bit limbs; a 256-bit word is 8 limbs.
4. Exact RAM
Gated DeltaNet heads with one-hot keys store stack, memory and storage bytes exactly.
5. Result
Each emitted token is fed back as the next input. Output bytes are BYTE tokens.
pc
opcode
gas used
RV32 tokens this step
stack (top first)
token stream from the reference machine (real)
Ten runnable contracts
Pick a contract and an input, press Run. The live run uses the browser reference VM; the checks below it are precomputed from the firmware, py-evm and the circuit.
Paste your own bytecode
Runtime bytecode (hex), up to 3,072 bytes, the firmware's CODE_MAX. Calldata up to 256 bytes. Runs on the browser reference VM only.
Judgement filter
Some 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 (trustlessness, deterministic and decentralized execution) with the best of human intelligence (judgement based on context).
Transaction
EVM runexact, deterministic
Rule-based reviewNOT part of the weights
LLM judge (optional)pluggable, stub by default
allowholdblock
The VM decides what the code allows, exactly. The review then looks at amount, destination and history and returns allow, hold for a human, or block, with a reason. An LLM judge can only make a decision stricter, never looser. The scenarios below use synthetic histories.
Test results
Code: build the weights and run it
Build the circuit and free-run a contract on it (Python, PyTorch)
Quickstart
Limitations
The circuit runs here use Qwenputer's compiled chip weights on CPU (its fastexec executor, fp32, sparse). They are not yet run inside the full 18.8 GB merged Qwen3.5-4B checkpoint, which needs a 24 GB GPU.
Opcode subset: no KECCAK256 (so no Solidity mappings), no CALL/CREATE/LOG, no SDIV/SMOD/SIGNEXTEND/ADDMOD/MULMOD, no precompiles.
Build limits: 3,072 bytes of code, 256 bytes of calldata, 2 KB memory, a 96-entry stack, 48 storage slots per run.
Single call, no state trie or persistence between runs; gas refunds are not tracked.
It is slow: across the 23 demo runs a whole run costs 87 to 194 tokens per executed EVM opcode, overhead included, and runs range from 16,370 to 605,944 tokens. The batched CPU runs on the weights averaged under 200 tokens per second.
The judgement filter is ordinary code with simple heuristics and synthetic histories. It is a design sketch, not a security product.
Future steps
Untested, not a claim. Merge the compiled machine into a Qwen-class model, as Qwenputer's merged Qwen3.5-4B checkpoint does for its CPU, so one model does both language judgement and exact execution of the EVM firmware. Its size would be dominated by the base model: Qwenputer's checkpoint is 18.8 GB and needs a 24 GB GPU, while the CPU layers and the firmware are small by comparison.
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. The compiled CPU here matched the reference trace token for token on CPU in fp32, but agreement across GPUs and software versions has not been tested, and a full Qwen-sized model is a much bigger problem.
Cost and speed. A tiny program takes tens of thousands of tokens, and every validator would repeat it. Here a whole demo run costs 87 to 194 tokens per executed EVM opcode, and even the smallest run is 16,370 tokens.
Compute limits. The model run would need to be metered and bounded by gas like any other execution.
The judgement filter is illustrative heuristics on synthetic histories, not a security product.
Support
Drop me some ETH if you want to support me to keep working on this.
EVMLLM
