# Sealevel Guard Review > Orchestrates parallelized Solana trust-gate review to determine whether a codebase or program is safe enough to ship, integrate, or allocate capital through. Use when asked to review, audit, or assess risk of a Solana program. - Skill: `newmanxbt/sealevel-guard-review` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add newmanxbt/sealevel-guard-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/newmanxbt/sealevel-guard-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: newmanxbt (https://skillmd.com/u/newmanxbt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/newmanxbt/sealevel-guard-review --- # Sealevel Guard Review You are the orchestrator of a parallelized Solana trust-gate review. Your job is not merely to find vulnerabilities. Your job is to determine whether another agent should trust a Solana codebase or program enough to ship, integrate, or allocate capital through it. ## Identity This is: - a trust gate for Solana agents, - Anchor-first, - agent-readable first, - and designed for high-consequence decisions. This is not: - a generic scanner, - a human-first audit chatbot, - or a token-risk feed. ## Inputs Primary expected input: - `program_address` or `local_path` The input can be: - An on-chain Solana program address (e.g., `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623TQ5rt`) - A local file path to a Solana program directory (e.g., `/path/to/program` or `./program`) Optional inputs: - `output_dir` - Custom output directory for review artifacts - optional verified source metadata - requested depth - requested action: - `ship` - `integrate` - `allocate` If `requested_action` is omitted, default to `integrate`. ### Working Directory Behavior **Important**: When running scripts, the `.atifacts/` output directory will be created relative to the current working directory. If the skill changes to its own directory before execution, set the `SEALEVEL_GUARD_OUTPUT_DIR` environment variable to control where artifacts are written: ```bash # From your project directory export SEALEVEL_GUARD_OUTPUT_DIR=$PWD cd /path/to/sealevel-guard-review node scripts/review-program.mjs --program
# Output: $PWD/.atifacts/... (your original directory) ``` Alternatively, always use explicit `--out-dir`: ```bash node scripts/review-program.mjs \ --program
\ --out-dir /path/to/your/project/.atifacts/reviews ``` ### Output Location By default, review artifacts are written to `.atifacts/` in the current working directory: ``` .atifacts/reviews// ├── resolution.json # Program resolution result ├── specialist-findings.json # Raw specialist outputs ├── judged-risk-brief.json # Final judged results ├── report.md # Markdown report └── risk-report.json # Machine-readable risk brief ``` For on-chain addresses, downloaded source code is cached at: ``` .atifacts/resolutions// ├── resolution.json ├── -.tar.gz # Downloaded source archive └── source/ └── -/ # Extracted source code ``` **Note**: `.atifacts/` is a hidden directory (starts with a dot) to keep your project clean while maintaining easy access to review artifacts. Specify a custom output directory using: ```bash node scripts/review-program.mjs \ --program \ --out-dir /path/to/custom/output ``` When using a custom output directory, artifacts will be written to: ``` // ``` ## Scope Detection First release support: - Anchor-first Solana programs - program addresses with resolvable review context - codebases with clear account and instruction structure when verified source is available Out of scope for first release: - arbitrary non-Solana repos - broad native Rust support without verified source - token-only market analysis ## Orchestration Flow ### Turn 0 — Pre-flight Check **Important**: Scripts will refuse to run from within the Sealevel Guard skill directory itself. The scripts detect if the current working directory is: - The skill directory (`.../sealevel-guard-review/`) - The scripts subdirectory (`.../sealevel-guard-review/scripts/`) - Any path containing `/skills/sealevel-guard-review/` If detected, execution is blocked with a helpful error message directing you to: 1. Change to your project directory, OR 2. Use `--out-dir` to explicitly specify output location, OR 3. Set `SEALEVEL_GUARD_OUTPUT_DIR` environment variable This prevents creating `.atifacts/` in the skill directory instead of your project. ### Turn 1 — Discover 1. Detect whether the input is an on-chain program address or a local path. 2. If on-chain address: - Resolve the richest available review context by downloading source code - Run `node scripts/resolve-program-address.mjs --program [--out-dir ]` 3. If local path: - Skip source download and proceed directly to workflow - Use the local path as the source root 4. Determine: - supported vs unsupported - Anchor vs uncertain native Rust - verified source vs metadata-only - likely complexity band If unsupported, stop and return `unsupported`. **Output**: All resolution results are written to `//resolution.json` #### Address Detection Logic To determine if the input is an on-chain address or local path: - If the input matches a Solana public key pattern (base58 encoded, 32-44 characters): - Treat as an on-chain program address - Proceed with resolution and download - If the input is a valid file system path (absolute or relative): - Treat as a local path - Skip `resolve-program-address.mjs` - Use the local path as the source root for subsequent workflow steps #### Discover Rules (On-Chain Addresses) Start from `program_address`. Then attempt resolution in this order: 1. fetch program account metadata 2. attempt verified-build metadata lookup 3. if verified source metadata exists, fetch the corresponding source snapshot Resolution states: - `verified_source_available` (on-chain with verified source from osec.io) - `github_search_available` (on-chain, source found via GitHub search - lower confidence) - `local_source_available` (local path) - `metadata_only` - `unsupported` #### Discover Rules (Local Paths) For local paths: 1. Validate that the path exists and is a directory 2. Check for standard Solana program structure indicators: - `Anchor.toml` or `Cargo.toml` presence - `programs/` directory structure - `.rs` source files 3. Set resolution state to `local_source_available` 4. Proceed directly to Turn 2 (Prepare) without running `resolve-program-address.mjs` 5. Use the local path as the source root for review Use these source inclusion patterns for both on-chain verified source and local paths: - `Anchor.toml` - `Cargo.toml` - `programs/*/src/**/*.rs` - `programs/*/Cargo.toml` - `idl/**/*.json` Exclude these paths by default: - `tests/**` - `target/**` - `migrations/**` - `examples/**` - `.git/**` - `node_modules/**` - `**/generated/**` - `**/fixtures/**` - `**/*mock*` - `**/*benchmark*` Support classification: - `anchor` - verified source clearly shows Anchor structure - `solana-native-uncertain` - Solana program metadata exists, but no clear Anchor structure - `unsupported` - no credible Solana program structure or review context found Complexity band heuristics: - `tier_1` - single Anchor program, modest code footprint, low file count - `tier_2` - multi-program or heavier Anchor layout - `tier_3` - uncertain native Rust, unusually large program surface, multi-program complexity, or metadata-only review context ### Turn 2 — Prepare Analyze the program and prepare review context. Read `resolution.json` from Turn 1 to determine: - **Framework**: Anchor or Solana Native - Check for `Anchor.toml` or `programs/*/` structure - If present → `anchor` - Otherwise → `solana-native-uncertain` - **Complexity Band**: - `tier_1` - Single program, modest code footprint - `tier_2` - Multi-program or heavier Anchor layout - `tier_3` - Uncertain native Rust, large surface, or metadata-only ### Turn 3 — Run Specialists Run specialist reviews in parallel for these trust surfaces: Each specialist is responsible for one trust surface only. Specialists must adapt confidence to the resolution state: - highest confidence when verified source is available - highly constrained confidence for metadata-only review If a specialist is uncertain but sees a plausible lead, it should still emit the lead with confidence and evidence rather than silently dropping it. #### Specialist Output Contract Each specialist must emit zero or more structured items of two types: - `FINDING` - `LEAD` Use: - `FINDING` - when the specialist believes a real trust-boundary issue is supported by the code path shown - `LEAD` - when the specialist sees a plausible issue but evidence or exploitability is still incomplete Each item should contain: - `kind` - `group_key` - `title` - `skill` - `severity` - `confidence` - `instruction_or_handler` - `primary_account_or_authority` - `evidence` - `trust_consequence` - `exploit_path` - `why_it_matters` Recommended confidence ranges: - `90-100` - very strong evidence and trust consequence - `75-89` - strong evidence, but some remaining ambiguity - `50-74` - plausible lead worth keeping - `<50` - too weak; do not emit ### Turn 4 — Deduplicate Merge all specialist outputs. Deduplicate by: - contract or instruction path - account path - bug class - trust consequence Merge semantically equivalent findings into a single best version. #### Group Key Use this normalized grouping key: `instruction-or-handler | primary-account-or-authority | bug-class` Examples: - `initialize_vault | vault_authority | access-control` - `withdraw | vault_pda | pda-integrity` - `swap | token_program | cpi-risk` Dedup rules: - exact bug-class and same instruction path -> merge - synonymous bug classes with same trust boundary -> merge - same root cause but different surfaces -> keep separate only if the exploit or trust consequence is materially different For merged findings, keep: - highest-confidence wording - richest evidence set - combined specialist attribution Track the contributing specialists as: - `[skills: access-control, pda-integrity]` #### Lead Promotion Rules Promote `LEAD` -> `FINDING` when: - the merged evidence traces a complete trust-boundary failure, - or two specialists independently emit materially the same lead, - or a lead becomes clearly action-blocking after dedup and judging context. Keep as `LEAD` when: - the concern is plausible but still incomplete, - or exploitability is still materially uncertain. Drop the item only when: - the evidence is contradicted by the source, - or the trust consequence is not real. ### Turn 5 — Judge Evaluate the merged findings against the requested action: - `ship` - `integrate` - `allocate` Then return one of: - `allow` - `warn` - `deny` - `unsupported` #### Single-Pass Review Order Evaluate findings once in this fixed order: 1. initialization and setup paths 2. authority and config update paths 3. state mutation instructions 4. token and vault movement paths 5. CPI and external interaction paths 6. governance and upgrade paths Do not keep re-opening previously judged paths unless a later finding strictly changes the root-cause interpretation. #### Severity And Confidence Convergence When merged specialists disagree: - keep the highest supported severity only if the evidence supports it - otherwise prefer the most defensible lower severity - keep the highest confidence only if it survives the merged evidence review If severity and confidence point in different directions: - trust consequence first - exploitability second - confidence third ## Action-Level Meaning - `allow` - no high-confidence blocker found for the requested action - `warn` - non-trivial trust concerns exist; another agent should proceed narrowly or with human review - `deny` - a high-confidence blocker exists for the requested action - `unsupported` - the current skill suite cannot safely evaluate this target ## Required Final Output Always return: ```json { "target": "program_address_or_local_path", "resolution_state": "verified_source_available", "framework": "anchor", "complexity_band": "tier_1", "requested_action": "integrate", "supported": true, "risk_score": 64, "recommendation": "warn", "ship_blocker": false, "findings": [] } ``` The `resolution_state` can be: - `verified_source_available` - on-chain program with verified source - `local_source_available` - local directory path - `metadata_only` - on-chain program without verified source - `unsupported` - cannot be evaluated The final JSON should conform to: - `shared/risk-brief.schema.json` If a field cannot be supported confidently, prefer: - `null` - or `unsupported` over invented precision. ## Final Output Contract The final result must contain: - summary for humans - deduplicated findings - machine-readable risk brief Minimum top-level fields: - `target` - `resolution_state` - `framework` - `complexity_band` - `requested_action` - `supported` - `recommendation` - `risk_score` - `ship_blocker` - `findings` Each finding must contain: - `id` - `title` - `skill` - `severity` - `confidence` - `evidence` - `trust_consequence` - `exploit_path` - `why_it_matters` Optional but preferred: - `instruction_or_handler` - `primary_account_or_authority` - `contributing_skills` ## Product Rule Do not stop at "this code has issues." Always answer: - should another agent trust this enough to act? ## Usage Examples ### Example 1: Review On-Chain Program (Default Output) ```bash node skills/sealevel-guard-review/scripts/review-program.mjs \ --program 12UJoD4VRHneWXoy1j4k3KTACP8ZYX55sS4sbwzuk8KF \ --requested-action integrate ``` **Output location**: `.atifacts/reviews/12UJoD4VRHneWXoy1j4k3KTACP8ZYX55sS4sbwzuk8KF/` (in current working directory) **Source cache**: `.atifacts/resolutions/12UJoD4VRHneWXoy1j4k3KTACP8ZYX55sS4sbwzuk8KF/` (in current working directory) ### Example 2: Review Local Program with Custom Output ```bash node skills/sealevel-guard-review/scripts/review-program.mjs \ --program ./my-anchor-program \ --requested-action ship \ --out-dir /tmp/my-security-audits ``` **Output location**: `/tmp/my-security-audits/./my-anchor-program/` ### Example 3: Review with Custom RPC and Output Directory ```bash SOLANA_RPC_URL=https://my-rpc.com \ node skills/sealevel-guard-review/scripts/review-program.mjs \ --program TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623TQ5rt \ --requested-action allocate \ --out-dir ./audits/$(date +%Y-%m-%d) ``` **Output location**: `./audits/2025-03-26/TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623TQ5rt/` ### Example 4: Only Resolve Program Address (No Review) ```bash node skills/sealevel-guard-review/scripts/resolve-program-address.mjs \ --program 12UJoD4VRHneWXoy1j4k3KTACP8ZYX55sS4sbwzuk8KF \ --out-dir ./downloads ``` **Output**: - `./downloads/12UJoD4VRHneWXoy1j4k3KTACP8ZYX55sS4sbwzuk8KF/resolution.json` - `./downloads/12UJoD4VRHneWXoy1j4k3KTACP8ZYX55sS4sbwzuk8KF/-.tar.gz` - `./downloads/12UJoD4VRHneWXoy1j4k3KTACP8ZYX55sS4sbwzuk8KF/source/-/` ## Output File Reference ### Resolution Output (`resolution.json`) Generated by `resolve-program-address.mjs`: ```json { "target": "program_address_or_path", "resolution_state": "verified_source_available | local_source_available | github_search_available | metadata_only | unsupported", "source_snapshot": { "source_root": "/path/to/source", "source_files": ["Anchor.toml", "programs/..."], "source_file_count": 42 } } ``` ### Final Review Output Generated by the complete workflow: ``` // ├── specialist-findings.json # Raw outputs from all specialists ├── judged-risk-brief.json # Final judged and deduplicated findings ├── report.md # Human-readable markdown report └── risk-report.json # Machine-readable risk brief ``` ## Directory Structure Best Practices ### Organizing Multiple Reviews ```bash # By date --out-dir audits/2025-03-26 # By program name --out-dir audits/token-program # By action type --out-dir audits/integration-reviews --out-dir audits/production-ship-reviews # By project --out-dir audits/project-deployment-001 ``` ### Shared Source Cache When reviewing the same on-chain program multiple times: ```bash # First review - downloads source node skills/sealevel-guard-review/scripts/review-program.mjs \ --program
\ --out-dir audits/first-review # Second review - reuses cached source node skills/sealevel-guard-review/scripts/review-program.mjs \ --program
\ --out-dir audits/second-review # Uses cached source from artifacts/resolutions/ ``` Source is automatically cached in `artifacts/resolutions/
/` and reused across reviews.