Kept & proven
The exploit executed on a mainnet fork and you get the working PoC. Criticals carry this burden; lower tiers stand on a concrete attack path tied to a broken invariant.
evidence: fork exploit · 142.8 ETH drained
The methodology
A security review that has to show its work.
Every contract is examined against a fixed taxonomy of exploitable bug classes, each finding is graded on impact and likelihood, and no verdict ships until the code itself justifies it — kept with a working exploit, or killed by a cited line.
01Coverage
The bug classes every audit hunts for.
Each class is a checklist of exploit patterns, not a keyword grep. We map the system first, then probe each class against your actual call graph and state flow.
- Reentrancy
-
Single-function, cross-function, and cross-contract reentrant callbacks; ERC-777 / ERC-721 receiver hooks; read-only reentrancy against view-priced math.
surfaces: vault withdraw / claim paths, router callbacks
- Oracle & price manipulation
-
Spot price read as an oracle, flash-loan-inflated reserves, stale or uninitialized feeds, missing staleness / heartbeat checks.
surfaces: liquidation math, collateral valuation
- Access control & privilege escalation
-
Unprotected admin entrypoints, role rotation that bypasses a timelock, uninitialized proxies, missing two-step ownership, guardian escalation.
surfaces: upgrade paths, role managers
- Accounting & invariant drift
-
Total-supply ≠ sum-of-balances, share / asset rounding to the protocol's loss, fee math under / overflow, queue state vs. token balance divergence.
surfaces: ERC-4626 vaults, fee accumulators
- Unchecked external calls & return values
-
Ignored transfer / call return, low-level call success not checked, gas-griefing on external hooks, unbounded loops over attacker-controlled arrays.
surfaces: token integrations, payout loops
- Validation & state-machine errors
-
Missing zero-address / zero-amount guards, out-of-order state transitions, signature replay or missing nonce, deadline / slippage omissions.
surfaces: permit flows, multi-step settlement
- Where a human still wins
-
Novel, bespoke attack paths and economic or game-theoretic design flaws — incentive misalignment, governance attacks, MEV strategy — need human judgment. We map the surface and flag the questions; we don't claim to design your tokenomics.
Where AI ends and humans begin →
02Severity
How a finding earns its severity.
Severity is impact × likelihood, judged against your system's invariants — not the model's gut feeling. Criticals carry a higher burden of proof than lows.
Tier What it means Burden of proof Raises / lowers it
Critical
Direct, unconditional loss of user funds or protocol insolvency.
Burden: A working exploit on a mainnet fork.
no privilege required · core invariant broken
High
Fund loss or protocol takeover under realistic preconditions — a specific role, a specific market state.
Burden: A concrete attack path tied to an invariant.
narrow precondition · privileged actor
Medium
Value at risk under narrow conditions, or a broken invariant with bounded harm.
Burden: A reproducible path with a defined blast radius.
harm bounded · external precondition
Low
Defensive-coding gaps and best-practice deviations with no direct exploit path today.
Burden: A demonstrated deviation, not an exploit.
no live exploit · hardening only
Info
Observations, gas optimizations, and hardening notes.
Burden: An argued recommendation.
no value at risk
The burden of proof in the third column is not a label — it's the bar the validator has to clear before the finding ships. That's the trial below.
03Validation
A kill has to be earned. So does a keep.
Independent AI models propose findings. We distrust every one of them. A finding is
kept only when it's grounded in your invariants — and for criticals, proven with a
working fork exploit. It's killed only when the validator can cite the exact line that
defeats the exact attack step. If neither holds, it stays in front of a human as
needs_manual — never silently dropped.
Killed — with the receipt
The validator quotes the defeating line and names the attack step it defeats. A false positive is dropped only when one reason from a closed taxonomy holds:
- Guard exists
- Path unreachable
- Wrong code claim
- Precondition impossible
- Harm bounded
- Documented by design
guard_exists · Vault.sol:142
needs_manual
No line defeats it and no exploit lands. The finding stays visible to a human, flagged for review — it is never hidden to make the report look clean.
disposition: awaiting human review
The refutation taxonomy is closed on purpose. The validator cannot invent a new reason to dismiss a finding — it has to fit one of these six, anchored to a line in your code, or the finding survives to a human.
04Grounding
Every finding is checked against an invariant.
Before hunting bugs, Guardix extracts your system's invariants, assumptions, and design decisions as first-class artifacts. A finding only stands if it breaks one — that's what keeps the report grounded instead of guessing, and it's the same invariant set the validator cites when it kills a finding.
Each invariant carries a threat if broken, so a finding's severity is read off the system's own design, not assigned by feel.
Architecture artifactsowner/vault-core
INV-001state
Total supply must equal sum of individual balances at all times
Threat if broken
Direct loss of depositor funds
INV-002ordering
Queue state transitions must be monotonic: pending → processing → done
Threat if broken
Double-processing of withdrawals
INV-003external
Oracle price feeds assumed fresh within 1-hour staleness window
Threat if broken
Incorrect liquidation at stale prices
INV-004access
Admin role changes cannot bypass timelock constraints
Threat if broken
Unauthorized privilege escalation
05Deliverables
What you can defend in the report.
The methodology ends in a document you can take to your team, your investors, or your own next review. Every finding carries its own evidence — this is what each one ships with.
See how scans are versioned and shared →- Prioritized findings
- Severity, exact file and line, the vulnerable snippet, the affected invariant, and the verdict with its evidence.
- Working fork exploits for criticals
- A runnable proof-of-concept plus the drained-value receipt from a mainnet fork — not a written-up hypothesis.
- Architecture artifacts
- The invariants, assumptions, and design decisions Guardix extracted before hunting, each a first-class object.
- The validation trail
- Every finding marked kept, killed, or needs_manual — with the cited defeating line attached to each kill.
- Versioned, shareable report
- Pinned to the exact commit and diffable against the last scan, so stakeholders see what engineers see.
Run a real security review.
Connect a GitHub repository, lock the commit, and get findings graded against your invariants — kept with a working exploit, killed by a cited line, or held for a human.