From a fuzzer experiment to a security platform: the Trilocore story

The premise: defenders read Etherscan by hand

Smart-contract exploits drain billions every year. The defenders' toolchain, though, is mostly static and source-leaning: linters that flag patterns, symbolic engines that are slow, and fuzzers that need the source plus hand-written properties. Attackers, meanwhile, operate on deployed bytecode and automate everything. We wanted to flip the asymmetry — give defenders an offensive tool that works on the same artifact attackers do: the bytecode on chain.

Chapter 1 — the GPU fuzzer

The first real component was an EVM fuzzer built to run on the GPU, inspired by the IEEE S&P 2024 work on smart-contract fuzzing on GPUs. Instead of a few thousand executions per second on a CPU, a SIMD EVM interpreter with a register-based IR lets us push 1024 parallel threads and reach order-of-magnitude higher throughput. Speed is not a vanity metric: more executions per second means deeper coverage in the same time budget, which means reaching the weird, rarely-taken branches where the exploitable bugs hide.

Around the fuzzer we grew an arsenal — a register IR, a control-flow lifter, taint and reentrancy oracles, owner-gate-bypass analysis, flash-loan profit modeling, proxy-collision and multi-actor modules, and a static detector suite. That arsenal became scslib, the shared core every Trilocore tool is built on.

Chapter 2 — confirmation, not warnings

A fuzzer that flags a "maybe" is just another source of noise. The thing that makes a finding worth a human's time is proof. So the pipeline doesn't stop at a hit: it re-runs the candidate transaction on an Anvil mainnet fork and applies a multi-layer verdict — did it revert, did it reach the target PC, did the attacker's balance actually go up? Only a strictly positive, replay-verified outcome is reported. The unit of truth became a measurable on-chain delta, not a string a tool printed.

The differentiator we kept coming back to: run offensive fuzz on already-deployed mainnet contracts, and confirm exploitability with fork replay — not just static warnings.

Chapter 3 — BEVM, a Burp Suite for the EVM

The engine was powerful but lived behind a terminal. Auditing a contract meant a CLI and a stack of scripts — fine for us, useless for everyone else. So we put it in the browser. BEVM is a visual security workbench: attach by address or paste bytecode, and within a second you see the contract's selectors, its control-flow graph, and its storage laid out in front of you.

If you've used Burp Suite for web apps, the layout will feel familiar: a Repeater to hand-craft and replay a transaction with any sender, an Intruder that drives the GPU fuzzer at marked payload positions, a Scanner that validates issues by execution rather than heuristics, a CFG Graph, and Storage and Decoder tabs to set up the exact state an exploit needs. The point is to make deep, replay-verified analysis something any builder can run — not a $250K, multi-week engagement.

Chapter 4 — Janus, an attacker-minded analyst

Raw scanner output still needs interpretation. Janus is our EVM-specialized AI analyst: give it a contract, a finding, or an attached source file and it explains the vulnerability, walks the attack chain, and turns machine output into an audit-ready write-up in plain language.

Under the hood, Janus is two things wearing one name. There's the model you chat with in the console. And there's the agent — an autonomous, attacker-minded loop that reasons, reaches for tools, composes multi-step attacks, and verifies them on a fork. The agent recently grew a more disciplined control loop: it keeps an explicit plan of attack hypotheses, refuses to declare a contract safe until it has genuinely tried the untried surface, and fans out focused sub-investigations per selector. It also draws directly on scslib's research detector library and a corpus of distilled, real-world exploit patterns — so it attacks with prior knowledge instead of guessing.

Chapter 5 — from monorepo to platform

For a long time everything lived in one giant monorepo. That was great for moving fast and terrible for shipping. In 2026 we split it into a clean set of independent repositories around the shared scslib core: the BEVM backend and frontend, the Janus console and agent, a single sign-on app, and an API gateway that meters access by key. The principle is plug-and-play — clone the piece you need, declare scslib as a dependency, and it builds and runs on its own. That's what turned a research project into a platform.

Where we are now

• BEVM is live — the visual workbench with GPU fuzzing, a static detector suite, the CFG graph, and mainnet-fork replay.
• Janus is live — a chat console backed by an EVM-specialized model, plus an autonomous agent that proves exploits end-to-end.
• One arsenal — both are built on scslib, so every detector and every fuzzing improvement lifts both products at once.

What this blog is for

This is where we'll publish what the tools find: retrospectives on public hacks walked through our pipeline, methodology deep-dives on vulnerability classes most tools miss, and field notes from building offensive security infrastructure for the on-chain world. First up: the exploit hiding in dead code, and a retrospective on the Euler attack.

Throughput and coverage figures in this post are order-of-magnitude and depend on target, hardware, and configuration. Trilocore builds security tooling; nothing here is an endorsement to attack systems you do not own or have explicit permission to test.