Auditing IDE

The Auditing IDE is the security workbench. You point it at a deployed contract, it forks the chain around that contract, and every panel then works against that fork: send a transaction, watch the storage move, fuzz an input, sweep the bytecode, map who controls what.

Open it at app.trilocore.ai and choose Auditing IDE, or drive the same thing from the API:

curl -X POST https://api.trilocore.ai/api/v1/bevm/sessions \
  -H "Authorization: Bearer $TRILOCORE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"network": "eth", "rpc_url": "https://your-node.example/eth", "target_address": "0xYourTargetContract"}'

If you have not opened a session before, start with the Quickstart.

The panels

Seven panels are always in the strip; the rest sit in the secondary row. All of them read the one session, so a slot you notice in Storage is the same slot Composer just changed.

Primary

Panel	What it is for
Composer	Craft and fire one transaction against the fork, then read exactly what it did. The main loop.
Blocks	The contract's basic blocks, with a detail view per block and multi-contract scope.
Heap	EVM memory during execution, plus the call profile — where the gas and the allocations went.
Storage	Read and write fork storage slots directly, including mapping-key computation.
Recovery	Recover structure from bytecode when there is no source: control flow, selectors, execution paths.
Architecture	The Architecture Explorer — see below.
Contract IDE	The developer surface, reachable without leaving the workspace. See Contract IDE.

Secondary

Panel	What it is for
Fuzzer	Drive one or more input positions with generated or listed values.
Graph	Control-flow graph, filterable by selector.
Multichain	Cross-chain and cross-contract checks over the same target set.
Decoder	Encode and decode calldata against an ABI, both directions.
MorphVM	Decode obfuscated byte-VM dispatchers — contracts that hide behind a single selector and interpret their own instruction set.
Findings	The findings ledger for the session: what was found, by what, with what severity.
Prober	Targeted probes for specific problem classes, including asset-flow routing and transient storage.
Dataflow	Trace how a value reaches a sink — the dataflow tracer.
Comparer	Diff two states or two transaction results side by side.
Passive	The static detector sweep over the target's bytecode.

Composer

Composer is where a suspicion becomes a demonstration. You give it a target, a function signature and arguments; it fires the call against the fork and reports gas, value deltas, return data, the revert reason if it reverted, and every storage slot that changed with its before and after value.

The behaviour to decide up front is whether sends accumulate:

• Isolated (the default) rolls back after each send, so twenty variants all start from identical conditions. This is the mode for "which of these inputs behaves differently".
• Stateful (persist: true) commits each send, so step three sees what step two did, and the mined block climbs. This is the mode for a real multi-step reproduction.

Every send becomes a durable execution, so a sequence you built today can be cited and replayed later. Sends are mutating calls and require an Idempotency-Key; reuse the same key on a retry and the stored result is replayed instead of firing a second transaction.

Reference: Execution, State and storage.

Fuzzer

The Fuzzer drives input positions — the places in a call you want varied — using one of four strategies:

Strategy	Behaviour
Single-position	One position varies, everything else is held fixed
Shared-list	One list of inputs, applied to every marked position at once
Parallel	Several positions advance together, in lockstep
Combinatorial	Every combination of the positions' inputs

Runs are resources: you start one, poll it, advance or stop it, and read its inputs and corpus entries as it goes. Findings raised during a run land in the same ledger as everything else.

Reference: Fuzzing.

MorphVM

Some contracts do not expose functions at all. They present one selector, take an encoded program as calldata, and interpret it with their own instruction set — a virtual machine inside the EVM. Ordinary disassembly shows you the interpreter loop and nothing about what it actually does.

MorphVM fingerprints these dispatchers and decodes the inner program, so the handler bodies become readable and the real control flow becomes visible.

Reference: Bytecode and decoding.

Architecture Explorer

The Architecture Explorer answers the governance question: who can change what? It builds a graph of the protocol's contracts, the roles and owners attached to them, and the control edges between — reading the actual authority slots on the fork rather than trusting the documentation.

From that map you get:

• Reachability paths — how control flows from an account to a privileged action, including multi-hop routes through proxies and modules.
• Rules — checks over the map, such as a single key holding sole authority over a critical function.
• Snapshots and diffs — freeze the map, then compare it after an upgrade or a governance action to see exactly which edges moved.
• Trace overlay — project an execution onto the map to see which authority edges a transaction actually used.

Reference: Architecture. Taking a snapshot is a mutating call and requires an Idempotency-Key.

Findings and the detector sweep

Passive runs the static detector registry over the target's bytecode — 1769 detectors covering the usual pattern classes plus a long tail of protocol-specific ones — and files what it finds into the ledger.

Detector output is a starting point, not a verdict. The workflow the product is built around is: sweep to get candidates, use Composer to try to reproduce one on the fork, and keep the ones that reproduce. A finding backed by an execution is worth something; a detector hit on its own is a lead.

Findings can be exported for a code-scanning pipeline, and filed against an audit in a workspace so they carry through to a report. See Core concepts.

Reference: Analysis and findings.

Working with more than one contract

Real targets are not one address. A session can hold several contracts in scope — named explicitly when you open it, or pulled in automatically from addresses hard-coded in the target's bytecode — and the panels follow: Blocks, Graph and the Architecture Explorer all work across the whole scope rather than one address at a time.

Reference: Targets and contracts.

Where the work is kept

Executions, findings and audit events are durable and attributed to a workspace and project, so an audit remains reconstructable after the session is closed. What is not durable unless you save it explicitly: the in-session panel state, such as open Composer tabs and local history. Snapshot the fork or file the finding when a result matters.

Next: Core concepts for the model underneath the panels, or the Endpoint reference to automate any of this.