Raven · Web3 security research
RootchainRootchain 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. Rootchain 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. Rootchain 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 Rootchain 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 Rootchain 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. Rootchain 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
Rootchain 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 Rootchain 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 Rootchain may execute.
Security truth stays cleanly separate from delivery policy.
The workspace
Deliver, review and monitor — without ever minting a Finding
Alongside the command-line engine there is now RootRaven — a workspace to deliver and review completed audits, and to watch a live protocol read-only. A VS Code-style audit IDE: it never performs the analysis itself, it displays what the engine proved and raises operational alerts to investigate.
Independent of the engine
The workspace is a delivery, review and operations layer, and it is deliberately independent of the research engine. It treats a completed audit as a data format: it shows, reviews and monitors — but it mints no Finding and runs no verifier. To change what was found, the engine is re-run and a new audit is ingested.
Five domains, one workspace
Audit
Open an ingested audit: browse the exact analysed sources, see each verified Finding on the line it affects, and read the call-graph the engine built.
Validate
Re-run a reproduced exploit against a candidate fix in an isolated local sandbox, and see whether it still breaks — a scoped lab result, never a claim the contract is now secure.
Monitor
Watch a live protocol with read-only observers for changes and anomalies — upgrades, privilege moves, price-feed drift, treasury outflows — each raised as an operational alert.
Investigate
Group co-occurring alerts for one protocol into an Investigation — a hypothesis of co-occurrence to chase down, never a verdict.
Report
Assemble deterministic, content-addressed reports over what the monitors actually recorded, with full provenance on every row.
On an ingested audit
Read-only source
The analysed Solidity is shown exactly as it was audited, in a read-only editor. There is no edit-and-run path in the review surface.
Findings on the code
Each verified Finding is drawn on the line it affects, on two independent channels — colour for severity, a glyph for its verification state — with the violated invariant and the verifier that settled it on hover. A Finding with no precise line is never given a fabricated one.
Dependency call-graph
The protocol’s call-graph is rendered from the structural index the engine produced: an edge is drawn only when both endpoints are real nodes, never inferred. It is a view of what the audit already contains — not a live scan.
Coverage & evidence matrix
A matrix of what was actually exercised and verified, which deliberately under-claims: a family counts as covered only when a verified Finding was produced, and “exercised” stays distinct from “verified-covered.” It surfaces what was not analysed, degraded capabilities, and contracts missing from the snapshot.
Grounded explanations
An optional assistant explains a report in plain language, grounded strictly on that report’s verified Findings and audited source. It invents no vulnerability, contradicts no machine field, and is labelled an explanation — never an additional Finding. Without a configured key it is simply not offered.
Live monitoring — read-only
Eight read-only observers watch a live protocol. Every one reads on-chain state only — a strict method allow-list means no observer can ever send or sign a transaction — and every one raises an operational alert (a change, or an anomaly to investigate), never a verified vulnerability. Promoting anything to a verified Finding still requires the engine’s deterministic pipeline, which the monitors never run.
Alerts, not Findings — a monitor alert is an operational anomaly or a change event to investigate. It is never a verified vulnerability, and a correlated Investigation is a hypothesis of co-occurrence, not causation. Only the engine’s deterministic pipeline ever promotes anything to a Finding.
Commit watch
Polls a watched source repository’s commit metadata and flags security-relevant changes for re-audit — by file path, a stated heuristic, not a code-level analysis.
Price-feed / oracle
Reads an on-chain price feed and flags stale, invalid, large-deviation or configuration-change anomalies against that feed’s own policy. A deviation is flagged as anomalous — never asserted to be manipulation.
Proxy & upgrade
Reads the standard proxy implementation and admin slots and the implementation’s bytecode hash, and flags when they change. An unrecognised proxy pattern is reported as such, never as a fabricated change.
Privileged actions
Watches ownership, role, admin and pause events and privileged limits, keeping a privilege history. What it cannot decode it records as unknown rather than guessing.
Treasury & asset flow
Tracks token outflows and balance deltas for a declared treasury, flagging extraordinary outflows and exposure changes relative to a known set — flagged as investigable, never as theft. No dollar value unless a price source is configured.
Protocol invariants
Evaluates declarative, deterministic invariants from on-chain reads and returns holds / violated / inconclusive, through a tiny interpreter that cannot execute arbitrary code. A “violated” result is a monitoring-plane check — not an engine Finding.
Governance
Distinguishes proposal-created, timelock-queued and executed states, and parameter changes, for standard governance contracts. Unknown shapes are reported as unknown.
Bridge & cross-chain
Correlates a cross-chain message’s source and destination only on a shared, verifiable message id, and flags duplicate execution, a message pending beyond a configured window, validator changes or a pause. Event signatures are configured per deployment.
Operate on what it records
Run an analysis
From inside the workspace a technician can launch a new analysis and watch it run; the result auto-ingests as a snapshot. The engine still does all the proving — the workspace only starts it and displays the outcome, and mints no Finding.
Audit projects
Group work as Protocol → Audit → Snapshot → Findings. A project holds only descriptive metadata; each snapshot is an immutable ingested audit — a project can never carry or alter a Finding.
Correlated investigations
Co-occurring alerts for one protocol, within a window, are grouped by deterministic rules into an Investigation — explicitly a hypothesis of co-occurrence, each signal keeping its own evidence, never a causal verdict.
Monitoring reports
Ten report types assemble deterministically over what the monitors actually recorded; the same data always yields the same content-addressed report, and every report restates that detection ≠ confirmation.
Test-a-fix lab
For a reproduced exploit, apply a candidate fix to a copy of the sources and re-run it in an isolated local sandbox. The verdict says whether that specific exploit still breaks the invariant — never that the contract is secure. An internal tool that degrades to an honest “inconclusive” where it cannot run.
What the workspace will not do
- ▸It mints nothing. The workspace displays, reviews and monitors; it runs no verifier and creates no Finding.
- ▸Read-only by construction. Every on-chain observer is limited to reading — no transaction can be built, let alone sent.
- ▸Alerts are not Findings. An alert is an operational signal to investigate; only the engine’s deterministic pipeline promotes anything to a verified Finding.
- ▸Empty until pointed somewhere. The monitoring surfaces ship with no targets and nothing scheduled — live monitoring happens only once an operator configures a protocol and an endpoint.
- ▸Multi-tenant by construction. Every read is scoped server-side to the signed-in user’s organisation; a client sees only the analyses granted to them.
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
Rootchain 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 Rootchain says so rather than pretending completeness. Knowing the edges of the map is part of using it responsibly.
FAQ
Frequently asked questions
Is Rootchain 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 Rootchain 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. Rootchain 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 there a web interface, or is it command-line only?
Both. The analysis engine is driven from the command line; alongside it there is now a workspace — a web application to deliver and review completed audits and to watch a live protocol read-only. The workspace never performs the analysis itself: it displays what the engine proved, and raises operational alerts to investigate. It mints no Finding and runs no verifier.
Do the monitors confirm a vulnerability?
No. A monitor reads on-chain state read-only and raises an operational alert — a change or an anomaly worth investigating. An alert is never a verified vulnerability, and correlating several alerts yields an Investigation (a hypothesis), not a verdict. Only the engine’s deterministic pipeline promotes anything to a Finding.
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
Rootchain 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
Rootchain 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 Rootchain investigates. Not a result.
- Finding
- A verified violation of a declared security property, backed by reproducible evidence and a deterministic verdict. The only thing Rootchain 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 Rootchain may test against real-world state.
- Severity
- How serious a verified Finding is; derived only from real Findings, never from signals.
- Alert
- An operational anomaly or change event a read-only monitor raises on a live protocol. A signal to investigate — never a verified vulnerability.
- Investigation
- Co-occurring alerts for one protocol grouped by deterministic rules. A hypothesis of co-occurrence, with each signal’s own evidence kept — never a causal verdict.
- Workspace
- The web application that delivers and reviews completed audits and monitors a live protocol read-only. It mints no Finding and runs no verifier.