Slither's raw output is a wall of detector codes, severity flags, and impact ratings that doesn't tell you what to fix first. Here's the 4-column mental model every Solidity dev needs.

You ran Slither on your contract. You got 47 findings. You are scrolling through INFO-level detector codes like solc-version, naming-convention, and external-function, wondering which ones actually matter, and whether the one HIGH at the bottom of the list is going to drain your vault.

This post is the mental model we use internally at AEDSC to triage a raw Slither dump in five minutes. The same model is what our LLM uses when it rewrites a Slither finding into plain English.

The four columns

Every Slither finding can be reduced to four properties. Sort by these and the noise disappears.

Column	What it answers
Severity	Does this bug let an attacker steal funds?
Confidence	How sure is the detector?
Reachability	Can a user actually trigger the vulnerable path?
Fix shape	Is the fix mechanical, architectural, or "by design"?

Slither prints the first two. You have to figure out the last two yourself. That's the whole secret.

Severity

Slither uses four levels: High, Medium, Low, Informational. Treat them as a rough first sort, not gospel.

High is reentrancy, unchecked transfers, arbitrary delegatecall, uninitialized storage pointers. Triage these first.
Medium is centralization risk, weak randomness, timestamp dependence, missing input validation on critical paths.
Low is gas inefficiencies that have a security flavor (e.g., public that should be external).
Informational is style, naming, version pinning. Read once, ignore on rescans.

Confidence

High confidence = the detector is sure. Medium confidence = the pattern matches but the detector can't prove the issue is exploitable. Low confidence = there might be a false positive.

We start by reading everything at High severity + High confidence. That's usually 1–3 findings on a typical contract — the ones you have to fix today.

Reachability

This is the column Slither does not give you. You have to read the code.

A reentrancy finding inside a function that only the owner can call, when the owner is a multisig you trust, has a different real-world impact than a reentrancy in a function any user can call. The detector cannot know that. You do.

When we triage at AEDSC, every High-severity finding gets a manual reachability tag: public path, owner-only, internal-only, or dead code. About 30% of High findings in a typical scan are owner-only or dead code — still worth fixing, but not "stop the world."

Fix shape

The last column is what you actually do about it.

Mechanical fix: swap two lines, add a require, change public to external. Our AI patch layer writes these for you.
Architectural fix: redesign the access control, add a timelock, change the trust model. No tool writes these for you. A human audit catches them.
By design: e.g., your contract uses delegatecall to a hardcoded trusted library and Slither flags it. You acknowledge it, add a //slither-disable-next-line comment, and move on.

The 5-minute triage workflow

Filter to severity >= Medium. Save the rest for a quieter day.
Within that, sort by confidence descending.
For each finding, in order: read the function, decide reachability, decide fix shape.
Group findings: fix now (mechanical, reachable) → fix this week (architectural, reachable) → acknowledge (by design or unreachable).
Open one PR per group.

Where AEDSC fits

We run Slither (plus Mythril and Aderyn) and we do steps 1–3 for you automatically. The output is a clean dashboard sorted by severity × reachability × fix shape, with plain-English explanations and a draft PR for the mechanical fixes. You spend your 5 minutes on the architectural ones.

Try a scan free →

How to read a Slither report without crying