EVMLLM

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. A VM can tell you a transaction is valid by the code. It cannot tell you whether anyone sensible would let it through.

I wrote an EVM interpreter in C, compiled it to RV32IM and ran it as firmware on Qwenputer, a RISC-V CPU whose every weight was set by a compiler. The EVM is not hand-weighted; the CPU it runs on is compiled transformer layers. Ten Solidity contracts (solc 0.8.24) run on it, and a small rule-based judgement filter reviews each result for allow, hold or block.

Two things are easy to blur, so I keep them apart. The weights execute the CPU. A small Python driver feeds tokens and loops, as in Qwenputer. All runs so far use Qwenputer's compiled chip layers on CPU, not the full 18.8 GB merged Qwen checkpoint, which needs a 24 GB GPU.

The cost is speed. A whole demo run costs 87 to 194 tokens per executed EVM opcode, runs are 16,370 to 605,944 tokens, and the batched CPU runs averaged under 200 tokens per second. The opcode set is reduced: no KECCAK256, so no Solidity mappings, and no CALL, CREATE or LOG. The judge is illustrative heuristics on synthetic histories, not a security product.

Every number on the page comes from the results files in the repo. All 23 demo runs match py-evm on outcome and gas, 2,000 random programs match, and 12 runs covering all ten contracts reproduced the reference trace token for token on the weights.

The realistic place for this today is a sidecar next to the chain software, an off-chain audit, or a review step in front of a wallet. It affects only the operator who runs it, not consensus. It is a demo, not a node replacement.