# What the framework is

SolanaTestForge sits between two existing categories of tooling. Anchor's built-in test runner is excellent at exercising programs that have been deployed to a local validator. Static auditors — Soteria, Sec3 X-ray, the open-source `cargo-audit-ish` tools — are excellent at reading source code in isolation. Neither category gives a developer a fast feedback loop on the *combination* of static rules and runtime behaviour against *real* on-chain state.

The framework was written to close that loop. In a single command, `solforge` will:

1. fetch the live state of a program from devnet or mainnet, including every account it owns;
2. apply a catalogue of static security rules to its IDL, producing a triaged report;
3. fuzz each instruction handler against the forked state with thousands of randomised inputs.

Each of those three operations is also available as a standalone command, for the cases where the developer wants only one step.

## What this implies

Several consequences follow from the design above, and it is worth stating them explicitly.

**No deploys.** The framework never writes to a chain, never signs a transaction, and never asks for an `~/.config/solana/id.json`. Forking is a local snapshot operation; fuzzing executes against that snapshot in memory. The threat model assumes the developer's machine is the only thing that needs to be trusted.

**No SOL.** Because nothing is deployed, no rent is paid and no compute units are consumed on a real validator. The cost of running the full suite is the cost of an RPC call for the initial fork plus local CPU.

**An IDL is not always required.** The `fork` and `fuzz` commands operate on raw bytes and program-id; they will work against native programs and against Anchor programs whose IDL is unavailable. The `security` command, by contrast, examines the IDL itself, and will refuse to run without one.

**Determinism is opt-in, not default.** Each fuzz run uses a non-deterministic seed unless one is supplied. This is by design: the most useful runs are the ones that surprise the developer. Reproducibility lives in the recipes chapter, where the trade-offs are discussed at length.

## What the framework is not

It is not a deployment tool. It is not a debugger. It does not know about Token-2022 extensions, and it does not understand the wire format of CPI calls into programs the developer has not pointed at. Where these limits matter, they are repeated in the relevant reference chapter; the manual does not pretend that the absence of a feature is a feature.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://solanatestforge.gitbook.io/solanatestforge-docs/part-i-foundations/what-it-is.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.