Initializing Mongoose

Every scanner guesses.

An agent that doesn't just find vulnerabilities — it constructs the exploit transaction and submits it on-chain. Real proof, not vibes.

Read the Docs → How It Works ↓
Mongoose Logo
True Positives 0
False Positives 0
Localization 100%
Proven Exploits 0
Test Cases 0
01 — Problem

The scanner gap is expensive

"A flag is a hypothesis. An exploit transaction is evidence. If you can't verify the hypothesis automatically, you haven't solved the problem."

Static analysis is the first line of defense in every domain — code, infrastructure, security. But every developer knows the same pain: you run the scanner, get 50 warnings, and have no way to tell which 5 are real without manual investigation.

In smart contract security, this gap is expensive. A static analyzer flags a "missing signer check." Maybe it's a real hole. Maybe the check happens two frames up the call stack. The only way to know is to manually trace the code — or try the attack and see if it works.

Most solo developers can't afford a $15k+ professional audit, so they either skip review entirely or drown in unverified warnings. The tool dumps suspicion on you. It never closes the loop.

0
Average Audit Cost ($)
0
Typical Scanner Warnings
0
Actually Exploitable
02 — Pipeline

Three agents. One proof.

Anchor Program
.rs source code
→
Extractor
Deterministic parse
→
Detector
LLM reasoning
→
Verifier
Live exploit tx
→
PROVEN
or UNCONFIRMED
01
No LLM
Extractor
Deterministic tree-sitter parse of Rust source. Walks the AST for #[derive(Accounts)] structs, field types, and #[account(...)] constraints. Outputs structured JSON — no guesswork.
  • Parse account structs & constraints
  • Map has_one, owner, signer, mut
  • Structured JSON output per instruction
  • Fail-fast on parse errors
02
LLM Agent
Detector
One structured Grok call with a 5-class Solana vulnerability taxonomy. Receives the Extractor's structured output, not raw code. Conservative by design — only flags what's actually absent.
  • 5-class vulnerability taxonomy
  • Structured context (not raw code)
  • Confidence scoring: HIGH / MEDIUM / LOW
  • False-positive memory registry
03
No LLM
Verifier
Constructs and submits actual exploit transactions against a local solana-test-validator. Class 1-3 candidates get real proofs. Class 4-5 are flagged as Suspected with reasoning.
  • Real exploit transactions on-chain
  • Before/after account state diff
  • Transaction signature as evidence
  • Graceful degradation on failure
03 — Classes

5 vulnerability classes. 3 fully proven.

PROVEN
01
Missing Signer Check
Instruction doesn't verify the expected authority actually signed the transaction. Exploit: submit unsigned account.
PROVEN
02
Missing Owner Check
Program doesn't verify an account is owned by the expected program. Exploit: pass account with wrong owner.
PROVEN
03
Type Cosplay
Program accepts an account of the wrong type due to missing discriminator check. Exploit: valid owner, wrong data layout.
SUSPECTED
04
Missing Relationship
has_one / account-data matching constraint missing. Requires complex multi-instruction state setup to exploit.
SUSPECTED
05
Insecure PDA Seeds
Seeds allow derivation of colliding accounts. Only reveals under actual derivation — static analysis caps out here.
04 — Results

Measurably better. Proven on-chain.

6/6
True Positives
All 6 vulnerable families correctly flagged
0/12
False Positives
Zero false alarms on secure variants
100%
Localization
Every finding pinned to instruction + account
3/3
Proven Exploits
Classes 1-3 backed by real transactions

Per-Program Results

18 programs · 6 families · sealevel-attacks dataset

Family Variant Mongoose Flagged? Class Correct? Verdict
0-signer-authorizationinsecureYESYESPROVEN
0-signer-authorizationsecureNON/A—
0-signer-authorizationrecommendedNON/A—
1-account-data-matchinginsecureYESYESSUSPECTED
2-owner-checksinsecureYESYESPROVEN
2-owner-checkssecureNON/A—
3-type-cosplayinsecureYESYESPROVEN
7-bump-seed-canonicalizationinsecureYESYESSUSPECTED
8-pda-sharinginsecureYESYESSUSPECTED
05 — Trajectory

From source to proof in three steps

Representative example: missing_signer_check — a program where the withdraw instruction doesn't require the user to sign.

01
Extractor Output
"instructions": [{ "name": "withdraw", "accounts": [ { "name": "user", "is_signer": false }, { "name": "vault", "is_mut": true } ], "constraint_summary": "No signer constraints" }]
02
Detector Finding
{ "vulnerability_class": 1, "instruction_name": "withdraw", "account_name": "user", "reasoning": "The 'user' account has is_signer=false and no explicit signer constraint. In a withdrawal instruction, the user should be signing.", "confidence": "HIGH" }
03
Verifier Result
{ "verdict": "PROVEN", "exploit_transaction": "4xZv...", "pre_state": { "vault_balance": 5000000 }, "post_state": { "vault_balance": 0 }, "notes": "Called withdraw with random keypair — no sig required. Vault drained." }
✓
PROVEN — Class 1: Missing Signer
06 — Stack

TypeScript end-to-end

🌲
tree-sitter-rust
Extractor Parser
🧠
Grok Cloud
LLM Detector
⛓️
@solana/web3.js
Transaction Builder
🔧
Anchor 0.29
Framework
🦀
Solana CLI 1.18
Validator
📦
TypeScript 5.4
Language
🟢
Node.js 20
Runtime
⚡
GitHub Actions
CI/CD
07 — Landscape

What others don't do

Soteria
Static pattern-matching with CI integration.
Flags patterns but does not attempt or confirm exploitation.
Sec3 X-ray
Static analysis for Solana programs.
Same gap: suspicion without proof. No exploit verification.
Manual Audits
Gold standard: human review by OtterSec, Neodyme.
$15k+ per audit. Weeks of scheduling. Inaccessible to solo devs.
Generic LLM
"Find bugs in this code" prompt with no context.
No Solana-specific knowledge. High false-negative rate. No verification.
OpenCode / Grok Build
Build-time coding agents for trajectory generation.
Great at code generation. Not designed for security verification.
⬡ Mongoose
Structured extraction + Solana-specific detection + live exploit verification.
Every "Proven" finding is backed by an actual transaction, not a guess.
08 — Changelog

Built in public. Iterated with evidence.

Baseline
Generic "find bugs" prompt
Raw code input, no Solana context, no verification. Established the floor — expect it to miss Sealevel-specific issues.
TP: 5/6 · FP: 8/12
Iteration 1
Added 5-class vulnerability taxonomy
Detection improved for Solana-specific patterns. Watch for false positives on fixed versions where the check exists but is non-obvious.
Improved Solana-specific detection
Iteration 2
Structured Extractor + field-mapped prompt
False positives dropped. Detector no longer misses constraints hidden in Anchor macros. Localization improved from "somewhere" to specific instruction/account.
TP improved · FP still non-zero
Iteration 3
Deterministic validation layer
Key fix: LLM suggests, code validates and backfills Classes 1–5 candidates. Eliminated false positives and backfilled misses.
TP: 6/6 · FP: 0/12 · Localization: 100%
Verifier CI
GitHub Actions builds fixtures, deploys, runs exploits
Chromebook/Windows writes TS; Linux CI produces real proofs. OTTER_SIGNALS_ONLY=1 avoids Groq in CI.
3 PROVEN exploit transactions in CI artifacts
09 — Rules

Responsible by design

🔒
Sandboxed Execution
All exploit attempts run against a local solana-test-validator. No transactions touch devnet, testnet, or mainnet.
👁️
Human Review
Final report is a recommendation for developer review, not an automated verdict. The human decides whether to act.
📜
Legal Use Only
Uses only public educational data (sealevel-attacks, openly licensed). No real user funds or private data.
🔑
No Secrets in Repo
No private keys, API tokens, or wallet seeds. Test validator generates ephemeral keypairs on startup.
📊
Evidence-Backed Claims
Every "Proven" finding includes the actual exploit transaction signature and account state diff.
🧪
Reproducible
Single TypeScript codebase. Pinned versions. One-command evaluation. Public dataset.

Ready to prove
what's actually broken?

Don't just scan. Exploit. Verify. Prove.

Read the Docs → View on GitHub ↗