Raven · Web3 security research
RootRavenRootRaven proves smart-contract vulnerabilities — it doesn’t just suspect them.
An evidence-first, autonomous security research system for Web3 and smart contracts. It investigates whether a protocol can be broken, and reports a problem only when it has proven it — by reproducing the attack in a controlled local sandbox and confirming it with a deterministic check.
// it is not an “AI hacker” — nothing it claims rests on a guess
The problem it solves
Two failure modes, directly addressed
Smart-contract tooling has a credibility problem: it either drowns teams in unproven warnings, or lets a clean scan masquerade as safety.
False positives
Most tooling floods you with hundreds of “potential issues” and leaves a human to sort out which few are real — alert fatigue, and reports nobody fully trusts. RootRaven only reports what it can prove, so its Findings are worth acting on.
False assurance
A clean scan is often misread as a clean bill of health. The absence of a warning is not evidence of safety. RootRaven refuses to ever claim a protocol is “secure,” so a clean run is never mistaken for a guarantee.
How it works
A proven finding, never a guess
Everything follows one path — the epistemic ladder. A claim climbs it one rung at a time, and only a claim that reaches the top becomes a reported result.
It reads and models the protocol and notices something worth questioning — a pattern, a privilege, an assumption that might not hold.
It turns that suspicion into a precise, testable claim about what could go wrong, and under what conditions.
It actually tries it: stands up a disposable local blockchain, deploys the protocol, and attempts the attack for real.
The experiment produces concrete artifacts — the transactions sent, execution traces, and the resulting on-chain state.
A deterministic check — no AI, no randomness — decides whether a declared security property was genuinely violated.
Only if verification confirms the violation does the result become a Finding, promoted through a single strict gate.
Signal ≠ Finding
A signal is a raw indicator — a scanner warning, a risky pattern, a plausible theory. It is the start of an investigation. A Finding is a verified violation of a declared security property, backed by reproducible evidence and a deterministic verdict — the only thing RootRaven reports as real. It even reports the funnel: how many raw signals it started from, how many it investigated, and how many became verified Findings.
Proven safely
It attempts the attack for real — in a lab, never in the wild
Proof comes from execution, not argument. That execution happens under safety boundaries that cannot be loosened by a user, an integration, or configuration.
Everything runs locally
Attacks are carried out on a fresh, disposable local blockchain, or on a local copy of real on-chain state. Execution never leaves that local environment.
There is no “attack the live network” mode
The ability to broadcast a real transaction to a public network does not exist in the system. No hidden flag, no setting, no escape hatch.
Testing real state requires authorization
Pointing it at a real deployed target requires a declared authorization — owner, scope, allowed actions. Without it, the request is refused before any research begins.
Permissions can only be narrowed
A user or integration can restrict what RootRaven may do, but can never grant it more authority than it ships with. Secrets never enter reports, logs, or the reproducibility record.
Execution is confined to a disposable local chain or a local fork of real state. The public chain is only ever read — to seed the fork, pinned to a block — and no path broadcasts a transaction to a public network, because that capability does not exist. A violation becomes a Finding only when the deterministic verifier confirms it; otherwise it stays UNKNOWN.
What it can look for
Thirteen vulnerability families
Each family has a single, precise truth — the exact thing its deterministic verifier decides — and covers several concrete mechanisms. A mechanism becomes a Finding only when that truth is proven by execution in the lab.
Maturity varies — within each family, some mechanisms are fully proven end-to-end (detector, attack strategy, deterministic verifier, matched vulnerable/safe fixtures under live execution); others are declared but not yet operational. RootRaven is explicit about which is which, and the not-yet-operational mechanisms are exactly where community research is invited.
Reentrancy
Whether a contract can be re-entered mid-execution to violate its invariants.
- ·Single-contract (vault) reentrancy.
- ·Cross-contract reentrancy, where the re-entry path runs through a second contract.
Accounting
Whether a protocol credits more value than it actually received or holds.
- ·Vault share-inflation: manipulating the share-to-asset ratio to steal from other depositors.
Authority & access control
Whether someone can acquire authority or ownership they were never granted.
- ·Takeover of uninitialized or re-initializable contracts.
- ·Privileged state changes made without the required authority.
- ·Fund-moving operations that satisfy neither an authority rule nor an entitlement rule.
Proxy & upgrade (code authority)
Who controls the implementation code a proxy delegates to.
- ·Unauthorized or unsafe control over an upgradeable proxy’s implementation.
- ·Proxy admin authority transitions that hand control to the wrong party.
- ·Storage-layout corruption silently introduced by an upgrade.
Oracle & economic manipulation
Whether an attacker can distort a trusted price source and extract net value.
- ·Manipulating a price source (such as pool reserves) a downstream consumer trusts, within a single transaction.
- ·Stale or unprotected price-feed data trusted as truth.
- ·Rounding/precision errors and reward accrual turned into repeatable profit.
Solvency & liquidation
Whether enforceable claims (debt) stay backed by collateral within the required ratio.
- ·Undercollateralization from a collateral price fall.
- ·Debt growing past its backing through interest accrual over time.
- ·Mis-valuation of collateral.
MEV & transaction ordering
Value extractable purely from transaction ordering / mempool position.
- ·Front-running a victim’s transaction.
- ·Back-running to capture state-dependent value.
- ·Sandwich attacks around a victim trade.
- ·Bypassing commit-reveal ordering protection.
Governance
Whether voting power can be manipulated to drive the protocol to a value-extracting outcome.
- ·Temporarily acquired voting power (for example, via flash capital).
- ·Unauthorized or unsafe execution of governance proposals.
- ·Quorum and delegation integrity.
- ·Timelock bypasses that remove the delay meant to protect users.
Protocol logic & state
Whether the protocol permitted an action from a state that should forbid it.
- ·A withdrawal while locked, a redeem before maturity, an operation in an invalid phase, a claim before eligibility.
- ·Multi-transaction and time-dependent sequences, including violations that only emerge from the cumulative effect of several steps.
Signature & authorization
Whether an off-chain signed authorization was used within its valid, single-use policy.
- ·Replay of a single-use authorization (consumed more than once).
- ·Reused nonces.
- ·Accepting a signature from the wrong signer.
- ·Abuse of gasless approvals (permit-style authorizations).
- ·Missing or incorrect domain separation, letting a signature replay across a different contract, chain, or context.
Bridge & cross-chain
Whether a single-execution cross-chain message was executed more than once on the destination.
- ·Forged or inauthentic cross-chain messages.
- ·Manipulation of a bridge’s validator quorum.
- ·Replay of a bridge message on the destination chain.
- ·Acting on state that is not yet final (reorg exposure).
Denial of service & liveness
Whether a required operation can still be executed, or be driven into a state where it no longer can.
- ·A protocol frozen because an external dependency it relies on fails.
- ·Denial of service through gas exhaustion.
- ·Griefing that makes honest use impossible or uneconomical.
- ·A protocol driven into an unrecoverable, stuck state.
- ·Unbounded iteration (loops) that can be forced to fail.
Token semantics
Whether a protocol credited more value than actually arrived — measure what happened, never trust what a token claims.
- ·Fee-on-transfer tokens, where less arrives than was requested.
- ·Transfer hooks with unexpected side effects.
- ·Rebasing tokens whose supply shifts underneath a protocol’s accounting.
Ways to use it
One system, several workflows
All of them obey the same epistemic ladder and the same safety boundaries; they differ only in what they start from and how much autonomy you hand over.
Audit a codebase
Give it your Solidity sources and a goal. It investigates across the families and returns verified Findings — or an honest, bounded “nothing was proven within this scope.”
Prove an exploit, locally
For a chosen target it synthesizes a candidate attack, executes it on a disposable local blockchain, and verifies the outcome. Compiled ≠ executed ≠ actually vulnerable.
Investigate a live target, autonomously
Point it at an on-chain address; it fetches verified source, investigates and executes candidate attacks against a local fork of real state. Fully autonomous, fully local, strictly read-only against the real chain.
Explore a target, read-only
Profile an on-chain target: resolve proxies to their real implementation and fingerprint the interface — purely by reading, sending nothing.
Check an oracle for circuit-breaker gaps
A focused, read-only check of a price-feed / oracle setup against a forked target, producing an evidence bundle on protection from manipulated or stale data.
Validate a proposed fix
Re-runs the investigation in a sandbox and reports whether the issue still reproduces — stated as a defense that “held within the tested scope,” never as a blanket “fixed.” The original Finding is preserved.
Gate your delivery pipeline
Slots into CI/CD: a verified Finding can block a release according to a policy you set, while security truth stays separate from delivery policy.
Reproduce any Finding, deterministically
Every Finding can be re-run from its recorded evidence on a fresh environment — no AI, no new synthesis — so the same inputs reproduce the same result.
Survive interruptions
Long autonomous investigations are journaled as recoverable missions: an interrupted one can be inspected and safely resumed without corrupting completed work.
What you can point it at
A source codebase
One or more Solidity files or a project you are building — audit your contracts before they ship.
A deployed contract
Identified by its on-chain address. The publicly verified source is pulled from a block explorer and investigated against a local copy of real state. The live contract is never touched.
A local test fixture
A controlled scenario you set up specifically to probe a behavior.
Where it runs
Local sandbox
A fresh, disposable local blockchain. Nothing from the outside world is involved.
Authorized fork
A local copy of real on-chain state (read in, then executed entirely locally). Requires an explicit authorization declaration.
Remote read-only
Reads live or historical on-chain state to observe it, and never sends a transaction.
// there is deliberately no fourth environment that writes to a public network
How much autonomy you hand over
Autonomous
RootRaven drives the whole investigation itself.
Assisted
You supply specific properties or invariants you want checked, guiding the research.
Replay
Re-run a previously recorded Finding to reproduce it, deciding nothing new.
What it refuses to claim
Honest about uncertainty — by construction
This is central to the philosophy, and it is a feature, not a limitation.
- ✕It never says a protocol is “secure,” “safe,” or “proven secure.” The wording is actively prevented; the system cannot emit that claim.
- ✕No Findings does not mean no bugs. A clean run means only that no verified problem was proven within the scope, capabilities, evidence and budget that were tested.
- ✕Signals are never inflated into Findings. Suspicions, scanner warnings and hypotheses never count toward severity and never appear as confirmed results.
- ✕Reproduction guidance stays in the lab. A Finding explains how to reproduce it in a sandbox — never how to carry out the attack against a live system.
What you get out of it
Verified Findings, with full provenance
For each investigation RootRaven produces a structured report. Only verified Findings ever appear as results; a clean audit produces a valid, explicitly empty result — never a false “all clear.”
For every Finding
- ▸ the specific security property that was violated, stated precisely.
- ▸ the exact parts of the protocol affected.
- ▸ the evidence and the deterministic check that confirmed it.
- ▸ context, likely root cause, and remediation notes.
- ▸ an honest statement of the limits of what was tested.
Severity is derived only from real Findings — never inflated by the number of raw signals. “Inconclusive” and “partial” are real answers, never rounded down to “clean.” Reports are content-addressed with a stable fingerprint.
In a delivery pipeline (CI/CD)
- ▸ Findings are compared against a baseline and classified new, unchanged, or resolved — a baseline never hides a Finding.
- ▸ a policy you control decides what blocks a release.
- ▸ a risk can be formally accepted as an exception — which changes whether it blocks, but never removes the Finding.
- ▸ no pipeline policy can disable a check, skip verification, turn a signal into a Finding, or expand what RootRaven may execute.
Security truth stays cleanly separate from delivery policy.
Reproducible by design
The part that decides truth is deterministic
Given the same scenario, it reaches the same verdict and produces the same report fingerprint, every time. There is no clock and no randomness in the verification layer — so a Finding can be independently re-checked, two people get the same answer, and reports can be compared over time.
The single role of AI
Artificial intelligence plays exactly one role: helping to compose a candidate attack to test a hypothesis. It never decides whether something is a vulnerability, never alters a verdict, and never creates a Finding. The creative step (imagining an attack) is where AI helps; the truth-deciding step is kept rigorous, reproducible, and free of any model’s opinion.
Design principles
Commitments that will not change
Evidence over opinion
A claim becomes a Finding only when backed by evidence and deterministic verification.
Signal ≠ Finding
Suspicions are investigated, not reported.
Honest about uncertainty
No Findings is never sold as proof of security.
Deterministic truth
The verdict is reproducible and free of randomness and AI judgment.
Defensive by construction
No capability exists to attack a live public network.
Bounded and declared
Coverage is stated plainly, including its edges.
Secrets stay secret
Credentials never enter reports, logs or records.
Why it matters — and where the research is
As much a research program as a product
RootRaven is a bet that a security tool can be both broad and honest — chasing the full landscape of smart-contract attacks while refusing to claim anything it hasn’t proven. These are the open frontiers where collaboration is wanted.
Deepening the newer families
Maturing the frontier areas so every family is as battle-tested as the core ones.
Smarter attack search
Better ways to generate and evolve candidate attacks (for example, coverage-guided and evolutionary search) so more real vulnerabilities are reached within a budget.
Richer security properties
Expanding the catalog of invariants the system can reason about and verify — which is what ultimately widens what can be proven.
Benchmarking honestly
Rigorous, reproducible evaluation of detection quality against labeled, real-world vulnerability corpora — measuring not just what is found, but at what cost.
Closing the known gaps
The “not covered today” list is a public backlog, not a disclaimer.
Not covered today
Coverage is broad but not infinite, and RootRaven says so rather than pretending completeness. Knowing the edges of the map is part of using it responsibly.
FAQ
Frequently asked questions
Is RootRaven an “AI that hacks contracts”?
No. AI only helps compose candidate attacks to test. Whether something is actually a vulnerability is decided by a deterministic, AI-free verification step and reproduced with evidence. Nothing it reports rests on a model’s opinion.
Can it attack a live protocol on mainnet?
No. There is no capability anywhere in the system to broadcast a transaction to a public network. All execution happens on a disposable local blockchain or a local copy of real state. Testing against real deployed state additionally requires an explicit authorization declaration.
If it reports no Findings, is my protocol safe?
No — and RootRaven will never tell you it is. A clean run means only that no verified problem was proven within the specific scope, capabilities, evidence and budget that were tested.
How is this different from a static analyzer?
A static analyzer produces signals — warnings and patterns. RootRaven treats those as leads, then actually attempts the attack and verifies the result before calling anything a Finding.
Does it modify my code or my on-chain state?
No. Normal investigations do not modify your original source, and all execution is confined to a local environment. Your live protocol is never touched.
Can I trust two separate runs to agree?
Yes. The truth-deciding layer is deterministic: the same inputs produce the same verdict and the same report fingerprint, so results are reproducible and comparable over time.
What languages and chains does it support?
Solidity smart contracts on Ethereum and EVM-compatible chains. For a live target, it studies a local fork of the chain’s real state, pinned to a specific block for reproducibility.
Can it check whether a fix actually works?
Yes. Given a proposed remediation it re-runs the investigation in a sandbox and reports whether the issue still reproduces — stated as a defense that “held within the tested scope,” never as a blanket “fixed.”
Is it finished?
No — it is an early, experimental research system with deliberately bounded, clearly declared scope and strong built-in safety guarantees. Its coverage will grow; its core discipline will not change.
Status
RootRaven is an early, experimental research system with deliberately bounded capabilities and strong, built-in safety guarantees. Its scope will grow, but its core discipline will not change:
A claim becomes a Finding only when it is backed by evidence and deterministic verification — and the absence of Findings is never sold as proof of security.
Part of the lab
RootRaven is one area of the ROOTVIEL research lab — free, pseudonymous, and evidence-first across agentic AI and Web3 security.
Glossary
- Signal
- A raw indicator (a scanner warning, a suspicious pattern, a hypothesis) that RootRaven investigates. Not a result.
- Finding
- A verified violation of a declared security property, backed by reproducible evidence and a deterministic verdict. The only thing RootRaven reports as real.
- Epistemic ladder
- The fixed path every claim must climb: Observation → Hypothesis → Experiment → Evidence → Verification → Finding.
- Verification
- The deterministic, AI-free step that decides whether a security property was actually violated.
- Evidence
- The concrete artifacts (transactions, execution traces, resulting state) a verdict is based on.
- Security property / invariant
- A precise rule the protocol is supposed to always uphold; violating one is what a Finding proves.
- Local sandbox
- A fresh, disposable local blockchain where attacks are attempted safely.
- Local fork
- A local copy of real on-chain state, used to test against realistic conditions while keeping all execution local.
- Authorization declaration
- The explicit statement (owner, scope, allowed actions) required before RootRaven may test against real-world state.
- Severity
- How serious a verified Finding is; derived only from real Findings, never from signals.