Human-AI Security Verification Workspace

Security hypotheses are not proof.

SIREEN is a local desktop tool for checking Solidity smart contracts. You point it at a contract. It suggests ways that contract could be attacked, writes a real test for each idea, runs the test, and shows you exactly what happened — including when the idea turned out to be wrong.

Explore the Demo Read the Documentation

No API key required. Runs fully offline in heuristic mode. Optional AI-assisted exploration with a free OpenRouter key.

Stage 1

Analyze

Inspect the smart contract project. Discover functions, state variables, external calls, and trust boundaries.

Heuristic

Stage 2

Explore

Identify potential issues and generate attack hypotheses. Heuristic patterns first. Optional AI can suggest additional angles.

Heuristic + AI

Stage 3

Generate

Create a Foundry proof-of-concept test for the two vectors SIREEN can both raise and execute today: reentrancy and access control.

Automated

Stage 4

Execute

Compile and run the PoC with Foundry. Record compile status, test output, gas usage, and assertion results.

Requires Forge

Stage 5

Verify

Present the evidence, the result, and the remaining uncertainty. A human researcher decides what it means.

Human Judgment

Start here

What SIREEN is, without the jargon

If you have never done security work before, this section is for you. It explains what the tool does in ordinary words. Every technical term is defined the first time it appears.

What it does

A smart contract is a program that moves money on a blockchain. If it has a flaw, someone can drain it. SIREEN helps you check a contract by turning suspicions into tests that actually run — so you can see what is real instead of guessing.

Who it is for

Solidity developers who want to check their own code, and security researchers who want to test a specific idea quickly. It assumes you are comfortable on a command line. It does not assume you are a security expert.

What problem it solves

Reading a contract and thinking "this looks unsafe" is easy. Proving it is slow: you have to write a test, set up a toolchain, and run it. SIREEN does that repetitive part for you, then shows the result honestly — including the failures.

What it is not

It is not a professional audit, and it does not find every bug. It tests a small, clearly defined set of attack types. A clean result means "no attack surface found by today's checks", not "this contract is safe".

Four words you will see on this site

Attack hypothesis: An idea about how a contract might be exploited. Example: "the withdraw function might let someone withdraw twice before the balance updates". It is a guess until something proves it.
PoC (proof of concept): A small test program written to check one hypothesis. If the test passes, the hypothesis holds under execution. If it fails, the hypothesis did not reproduce — which is also useful information.
Foundry: A free, widely used toolkit for building and testing Solidity contracts. SIREEN uses its forge command to compile and run the tests it generates. Without Foundry installed, SIREEN cannot execute anything.
Evidence: The saved output of a real run: compiler result, test output, gas used, and the exact assertions that passed or failed. Every finding on this site links to evidence you can inspect or reproduce.

Next steps, in order: read How It Works for the five stages, look at the recorded demo to see real output, check Product Status for what works today, then follow the evaluation guide to run it yourself.

The Challenge

Security research is hard.
Proving your suspicions is harder.

Smart contract security researchers face practical challenges every day. SIREEN is designed to help with the parts that a tool can assist — while keeping human judgment at the center.

Complex contracts hide attack paths

A modern DeFi protocol can have thousands of lines of Solidity across dozens of files. Spotting every potential vulnerability manually is exhausting and error-prone.

Hypotheses need proof, not confidence

A static analyzer saying "this looks suspicious" is not enough. You need to know whether the suspicious pattern actually produces exploitable behavior.

Manual PoC writing is repetitive

Writing Foundry tests for every hypothesis takes time. SIREEN generates the boilerplate so you can focus on the interesting cases.

Evidence needs to be reproducible

A finding without reproducible evidence is hard to review, hard to fix, and hard to verify as resolved. Every claim should carry a chain of proof.

How It Works

Five stages. One honest chain of proof.

SIREEN does not claim to automate security auditing. It is a workspace where human researchers guide the process, supported by heuristic analysis and optional AI exploration, with every testable hypothesis put through executable verification.

CONFIRMED

Forge verified at least one finding. Evidence is complete and reproducible.

CLEAN

No findings. Every hypothesis received a real Forge attempt.

DEGRADED

Findings exist but could not be fully verified by execution.

UNVERIFIED

Coverage was insufficient to classify. Needs manual review.

FAILED

Pipeline crashed or every PoC failed compilation.

Verified Walkthrough

See how a finding becomes confirmed evidence.

This is a real recorded run, not an animation: the panels below were copied from an actual sireen audit against the project's own VulnerableVault.sol fixture (SIREEN backend v0.1.1, Forge 1.8.5, heuristic mode, no API key). The reentrancy finding was independently re-verified with a stock Foundry project using the real forge-std — [PASS] testExploit(). Note the run ends in DEGRADED, not "confirmed": SIREEN reports what execution proved and flags the rest for human triage.

# Audit a contract known to have a reentrancy vulnerability
$ sireen audit VulnerableVault.sol --json

{
    "id": "audit-de562868d6a3",
  "terminal_state": "degraded",
  "reasoning_mode": "HEURISTIC",
  "findings": [
    {
      "category": "reentrancy",
      "title": "Reentrancy on withdraw",
      "confirmed": true,
      "evidence_id": "evd-6c7b4abfdcd9"
    },
    {
      "category": "access_control",
      "title": "Access control on withdraw",
      "confirmed": false,
      "needs_review": true,
      "evidence_id": "evd-3cb5dda7f2e9"
    }
  ],
  "warnings": [
    "1 finding(s) were NOT confirmed: Forge executed the PoCs but did not reproduce the hypothesis. They are marked 'needs review'."
  ]
}

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "forge-std/Test.sol";
import "./VulnerableVault.sol";

contract PoC is Test {
    VulnerableVault public victim;

    function setUp() public {
        victim = new VulnerableVault();
    }

    function testExploit() public {
        victim.deposit{value: 10 ether}();
        Attacker att = new Attacker(address(victim));
        att.depositAndAttack{value: 5 ether}();
        uint256 drained = 10 ether - address(victim).balance;
        assertGe(drained, 2 ether);
        assertGt(address(att).balance, 1 ether);
    }
}

# SIREEN compiles and runs each PoC with Forge — real output, truncated

// Evidence 1 — reentrancy hypothesis
FORGE      forge Version: 1.8.5
Compile:   PASSED
Test:      PASSED
Executed:  1   testExploit() passed
// Confirmed: the assertion held under execution.

// Evidence 2 — access-control hypothesis
FORGE      forge Version: 1.8.5
Compile:   PASSED
Test:      RAN (not passed)
Executed:  2
[FAIL: No balance] testExploit() (gas: 57290)
Suite result: FAILED. 0 passed; 1 failed; 0 skipped
// Not reproduced → reported as NEEDS REVIEW, never as confirmed.

# Markdown report - sireen report <audit-id> --output report.md

# SIREEN Evidence Report

- Audit ID: `audit-de562868d6a3`
- Terminal state: DEGRADED
- Reasoning mode: HEURISTIC (no API key)

## Findings

### Finding #001 - Reentrancy on withdraw [CONFIRMED]
- Category: reentrancy
- Evidence pack: `evd-6c7b4abfdcd9`
- Remediation: Use Checks-Effects-Interactions pattern

### Finding #002 - Access control on withdraw [NEEDS REVIEW]
- Category: access_control
- Evidence pack: `evd-3cb5dda7f2e9`
- Forge ran the PoC but did not reproduce the hypothesis.
  Treat as a hypothesis for a human to triage, not a confirmed bug.

// DEGRADED is the honest state: one finding was proven by
// execution, one was not. SIREEN never rounds up to "clean".

Read the Full Guide

Product Status

What works today, and what does not.

Verified on SIREEN backend v0.1.1 with Forge 1.8.5. This table reflects executed checks, not intentions.

Capability	Status	Evidence
Heuristic hypothesis generation (offline)	Working	2 hypotheses generated on the bundled fixture, no API key required
PoC generation + Forge compile & execute	Working	Reentrancy PoC compiled and `testExploit()` passed under Forge
Honest verdicts (CONFIRMED / NEEDS REVIEW)	Working	Access-control PoC ran but did not reproduce → reported as NEEDS REVIEW, not confirmed
Durable audit history (SQLite)	Working	`sireen audits`, `sireen show`, `sireen report` all functional
Independent reproducibility	Verified	Vulnerability re-confirmed in a stock Foundry project with real `forge-std`
AI-assisted hypothesis exploration	Experimental	Wired to OpenRouter; quality not systematically evaluated
Oracle manipulation / flash loans / governance	Not supported	Skipped honestly — no PoC is generated for these classes
Arithmetic overflow / underflow	Template only	A PoC template exists, but no heuristic currently raises this hypothesis and it has not been verified with Forge
delegatecall / signature replay / weak randomness	Raised, then skipped	A hypothesis may be generated, but there is no PoC template, so the test is skipped rather than faked

Read this before you rely on a result

SIREEN proves only the specific behavior its generated test exercises. A CONFIRMED finding is real evidence about that path — not proof that a contract is exploitable in the wild. A clean_with_coverage result means the current heuristics found no attack surface; business-logic, economic, and novel vulnerability classes may still exist. Every audit needs human review.

Who SIREEN Is For

Three ways to use the workspace.

SIREEN is designed for people who need to move from suspicion to evidence — not from silence to dashboards.

For Security Researchers

Organize attack hypotheses, generate PoC tests automatically, and keep evidence directly connected to findings.

For Solidity Developers

Investigate potential weaknesses in your own code before they reach production. Understand what a test did and did not prove.

For Protocol Teams

Explore potential attack paths, test specific security assumptions, and review reproducible evidence from your security process.

How SIREEN Is Different

Not another scanner. A verification workspace.

Most security tools stop at detection. SIREEN is built to help you prove or disprove what you suspect — with executable evidence, not confidence scores.

Capability	Static Analyzer	LLM Chat	SIREEN
Detects suspicious patterns	Yes	Sometimes	Yes
Generates executable PoC	No	Sometimes	Yes (2 vectors)
Runs the PoC automatically	No	No	Yes (with Forge)
Produces reproducible evidence	No	No	Yes
Honest about limitations	Sometimes	Rarely	By design
Human remains in control	N/A	Partial	Always

Start with evidence.

Install SIREEN, audit your first contract, and see what executable verification feels like.

Download SIREEN Read the Docs