# From a fuzzer experiment to a security platform: the Trilocore story > How an offensive GPU fuzzer for deployed bytecode grew into BEVM and Janus — the Trilocore story. Engineering June 15, 2026 · 5 min read Trilocore did not start as a product. It started as a question: *could you run an offensive fuzzer fast enough to attack contracts that are already live on mainnet — from bytecode alone, with no source?* This is how that question turned into BEVM and Janus. > **Update, September 2026.** This is the story as it happened, kept in its own vocabulary. BEVM — our bytecode-level EVM engine — now ships inside what the product calls the [Auditing IDE](https://trilocore.com/platform/auditing-ide), one of three workbench surfaces beside the [Contract IDE](https://trilocore.com/platform/contract-ide) and the [Architecture Explorer](https://trilocore.com/platform/architecture-explorer), and the platform now covers Solana programs alongside EVM contracts. Janus AI is in development and not yet available — the Janus capabilities described below are from our development builds. ## 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, an interactive security workbench 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](https://app.trilocore.ai/) 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 an intercepting web-security proxy, the layout will feel familiar: a **Composer** to hand-craft and replay a transaction with any sender, 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 day to day — not something rationed to a scarce, multi-week engagement. ## Chapter 4 — Janus, an attacker-minded analyst **Availability, September 2026.** Janus AI is in development and not yet available — nothing in the product calls it today. This chapter describes our development builds. Raw scanner output still needs interpretation. [Janus](https://app.trilocore.ai/) 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 — September 2026 - The **Auditing IDE** is live — the visual workbench with a static detector suite, the CFG graph, and mainnet-fork replay. - **Janus AI** — a chat console backed by an EVM-specialized model, plus an agent that drives proof-of-concepts — is in development and not yet available; the workbench runs fully without it. - **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](https://trilocore.com/posts/orphan-block-delegatecall), and [a retrospective on the Euler attack](https://trilocore.com/posts/euler-donation-retrospective). 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. [Open the workbench →](https://app.trilocore.ai/) [← All research](https://trilocore.com/research/) --- [Canonical HTML version](https://trilocore.com/posts/from-monorepo-to-security-platform)