Don't Sign Blind: Can a Local SLM or LLM Explain an Ethereum Transaction?

A local SLM for Web3 runs in the browser and explains a simulated Ethereum transaction. TSA is that local LLM: a Qwen3.5-4B fine-tune via WebLLM, about 2.4 GB.

October 12, 2026Simon Jentzsch

A local SLM for Web3 is a small language model that runs in the browser or in an app and explains an Ethereum transaction after Colibri has simulated it on verified state. The prompt stays on the machine. The Transaction Security Agent (TSA) is a working prototype of that local LLM: a fine-tune of Qwen3.5-4B, run with WebLLM, about 2.4 GB the first time it is downloaded. The model does not decide whether the transaction is safe. It explains the proven simulation in plain language.

You wouldn't sign a contract you haven't read, would you?

Before you sign a contract, you read it. More importantly, you make sure you understand what will happen once your signature is on it: what you give, what you get, and what you are now obligated to.

On Ethereum, we do the exact opposite every day. A transaction is just a sequence of bytes. In most cases a dApp prepares those bytes, the wallet shows a contract address, a hex blob and maybe a function name, and the user clicks "Confirm". The user can only hope that what they sign actually matches what they intended. This is blind signing, and it is one of the largest attack surfaces in the ecosystem.

The Transaction Security Agent (TSA) is our attempt to change that. It simulates a transaction locally on verified state, decodes everything that happens, and lets a small language model running in your browser or app explain it in plain language, before you sign. TSA is a working prototype; the playground below is a preview.

Blind signing is not a theoretical risk

Two incidents show how expensive the gap between "what I see" and "what I sign" can be.

Bybit, February 2025 (more than $1.4 billion). On 21 February 2025, attackers drained over 401,000 ETH from Bybit's Safe multisig cold wallet, the largest crypto theft on record. They had injected malicious JavaScript into the Safe{Wallet} web interface via a compromised developer machine. The code only activated for Bybit's signers: the UI showed a routine transfer, while the payload sent to the hardware wallets was a delegatecall to an attacker contract that overwrote the proxy's implementation slot. Three experienced signers approved it. (NCC Group analysis, Blockworks)

Permit phishing, 28 September 2024 ($32.4 million). A single user lost 12,083 spWETH after signing an off-chain permit message on a phishing site operated with the Inferno Drainer kit. No transaction was sent by the victim at all. A typed, "readable" signature was enough to hand over the tokens. (Cointelegraph, BeInCrypto)

In both cases the signer could not see what the signed data would actually do on-chain.

Why EIP-712 is not enough

EIP-712 was a big step forward: instead of an opaque hash, the wallet can show typed, named fields. But it only describes the input of a call, not its effect on state.

EIP-712 makes the static parameters of a call readable. It says nothing about what happens when those parameters hit the EVM. A field called to with an address and a field called data with some bytes are perfectly "readable", yet the Bybit signers still could not tell that data combined with operation = 1 would rewrite the storage slot holding their wallet's implementation. NCC Group reached the same conclusion: EIP-712 cannot render nested operations and cannot decode what a complex contract call will do. (NCC Group)

The permit case is even simpler. The message was well-typed and displayed, but the user had no way to see the consequence: an allowance that lets someone else move all their tokens.

What a user actually needs to know is the outcome: which balances change, which approvals are granted, which storage is written, which contracts are called. A signing format cannot show that; a simulation can.

Signatures are not transactions, but their effect can be simulated. For a Safe transaction, TSA simulates the execTransaction call the signatures will authorize. For a permit, it simulates permit followed by the transferFrom the spender can then execute.

How TSA works

TSA turns a raw transaction into a verified, decoded and explained outcome in three steps.

Simulate on verified state. colibri_simulateTransaction takes the same arguments as eth_call. Colibri fetches a Merkle proof for every account and storage slot the transaction touches and verifies it against a state root that Colibri itself has verified through the consensus proof. It then executes the transaction locally in its own EVM. Nothing is taken from the RPC provider without proof. The result records state changes, storage reads with their proven pre-state values, logs, internal calls, the verified codeHash of every account, keccak preimages of hashed storage keys, and the executed JUMPDEST program counters per code address.

Map bytecode back to source. For every touched contract we fetch the verified Solidity sources from Sourcify. We compile them and compare the resulting bytecode with the code proven during simulation, accounting for immutables, linked libraries and metadata the same way Sourcify does. Only if they match do we use the source. With the ABI, the storage layout and the keccak preimages, we can then decode every event, every call and every storage change: balances[0xabc…] instead of slot 0x7f3e….

Explain with a language model. The prompt contains the decoded events, calls and state changes, and the Solidity code that actually ran. To keep the context small, we use the executed JUMPDEST positions and the compiler's source maps to include only the functions that were really executed, not the whole contract. Any LLM can answer this prompt and explain to the user, in plain language, what the transaction will do.

The model does not have to guess what the transaction does; it only has to explain a proven execution, backed by the exact code that produced it. The decoded facts are shown next to the explanation, so the user can check it.

A simulation shows what would happen on the current state. If that state changes before your transaction is included, or a contract behaves differently depending on block parameters, the outcome can differ.

A local SLM that runs in the browser

The explanation step works with any remote API. But our goal was that the whole pipeline runs locally, in the browser or app, with nothing to install.

So we fine-tuned our own domain small language model on top of Qwen3.5-4B, the 4-billion-parameter member of Alibaba's open-weight Qwen3.5 family released in February 2026 under Apache 2.0. We trained it specifically on decoded simulation results and the matching Solidity code, then optimized and quantized it until it runs entirely client-side with WebLLM, which executes models on the GPU through WebGPU.

The first time you use it, the browser downloads the model once (about 2.4 GB). After that it is cached, and every transaction can be simulated and explained without a single request leaving your machine for the explanation.

Why local matters

Trust. Every simulation that runs on someone else's server, and every prompt sent to a third-party API, asks you to trust that the answer you get back is honest. That trust is fragile even when the provider is reputable. On 8 September 2025, a phished maintainer account was used to push malicious versions of debug, chalk and 16 other npm packages with over 2 billion weekly downloads combined. The injected code hooked fetch, XMLHttpRequest and window.ethereum in the browser, scanned responses for addresses and swapped them for lookalike attacker addresses before the user signed. (Check Point, Cycode) An attack like this can silently rewrite a remote simulation result or an LLM's answer in transit. A simulation verified against proofs and an explanation generated on your own GPU remove the remote server and the network path from that chain of trust. The code running in your browser still has to be trustworthy, which is why we publish it as open source.

Privacy. Simulating before signing only helps if the simulation does not leak the transaction. If you send the transaction or the prompt to a third party, you reveal your intent before it hits the chain. That opens the door to front-running and censorship. Running simulation and explanation locally keeps the transaction yours until you decide to broadcast it. One leak remains: to fetch proofs, Colibri still asks an RPC provider for the accounts and storage slots the transaction touches, along with your IP address. That access pattern can hint at your intent. Closing this gap is what our work on PAP is about.

Try it yourself

We have put everything into a playground: playground.colibri-proof.tech. The product page is at Transaction Security Agent. Paste a transaction, let Colibri simulate it on proven state, and let the model in your browser tell you what it will do before you sign it.

Read before you sign. Don't trust. Verify!

FAQ

What is a local SLM for Web3?

A local SLM for Web3 is a small language model that runs in the browser or in an app and explains an Ethereum transaction after it has been simulated on verified state. The prompt is not sent to a cloud model. The Transaction Security Agent is a prototype of that: a fine-tune of Qwen3.5-4B, run with WebLLM.

Can the model explain a transaction without the cloud?

Yes, when WebLLM is the provider. The browser downloads about 2.4 GB once, caches it, and runs the model on the GPU through WebGPU in current Chrome or Edge. Colibri still fetches proofs for the accounts and storage slots the transaction touches. The explanation itself stays on the machine.

How is this different from a general local LLM?

A general local LLM can talk about crypto from its training data. This model does not decide whether a transaction is safe. It explains a decoded simulation it was given: events, calls, and state changes, shown next to the facts you can check.

References

Don't Sign Blind: Can a Local SLM or LLM Explain an Ethereum Transaction? — Corpus Core Insights on corpuscore.tech.

Try Colibri — Ethereum stateless client

Verify blockchain data locally with cryptographic proofs. No trusted RPC required.

Learn about Colibri Open Sandbox