Auditing IDE¶
The Auditing IDE is the security-review surface of the workbench — the one for proving what a deployed contract actually does. 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.
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 | Opens the Architecture Explorer against the session — a workbench surface in its own right, documented on its own page. |
| Contract IDE | The developer surface, reachable without leaving the workspace. See Contract IDE. |
Secondary¶
| Panel | What it is for |
|---|---|
| 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.
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: State and storage.
Architecture Explorer¶
The Architecture panel opens the Architecture Explorer — a workbench surface in its own right, not a feature of the Auditing IDE. It answers the governance question who can change what? by reading the actual authority slots on the session's fork. The map, reachability paths, rules, snapshots and diffs, and the trace overlay are documented on its own page.
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.