SPECTRE Solana Ecosystem Security Report
Aggregate Static Analysis Across 24 Production Solana Protocols
Issuer: Pinpoint Technologies Issue Date: 2026-05-08 Report Version: 1.0 Document Classification: External, Disclosure-Grade Scope: Static security analysis of 24 production Solana protocols (30 program crates) Tooling: SPECTRE pattern catalogue (36 rules) + cross-program analysis + cross-language TypeScript-to-Anchor analyzer
Notice to Protocol Teams
This report consolidates SPECTRE's static-analysis output across the public source of 24 Solana protocols. Each finding describes an architectural pattern in the protocol's source that SPECTRE associates with a real-world incident class in the Solana ecosystem. The report ships as disclosure-grade architectural research: protocol teams can use it directly to evaluate their continuous-integration security posture against the patterns that have produced the largest historical losses on Solana.
We share this report with two goals. First, to give protocol security teams a permanent architectural map of their codebase that complements their periodic audits. Second, to open a conversation with Pinpoint Technologies on the deeper analytical questions behind each pattern.
Table of Contents
- Executive Summary
- Scope and Methodology
- About SPECTRE
- Aggregate Findings Across the Ecosystem
- Architectural Pattern Catalogue: Findings by Severity
- Per-Protocol Synopsis
- Cross-Program Analysis
- Comparison to Published Audit Firm Reports
- Precision Engineering on Heavy-Audit Code
- Strategic Outlook and Capability Roadmap
- Recommendations to Protocol Teams
- Appendix A: Complete Rule Catalogue
- Appendix B: Per-Protocol Finding Tables
- Appendix C: Reproduction Instructions
- Appendix D: About Pinpoint Technologies
1. Executive Summary
1.1 What was scanned
SPECTRE scanned 30 program crates across 24 production Solana protocols, covering the dominant program classes by total value locked: lending (Kamino's four programs, MarginFi v2), perpetual futures (Drift v2, Mango v4, Drift Vaults), automated market makers (Orca Whirlpools, the Raydium AMM family, Phoenix v1, OpenBook v2, Saber), liquid staking (Marinade, Lido, SPL stake-pool), oracles (Kamino scope, Pyth client), bridges (Wormhole), NFT and compressed NFT infrastructure (Metaplex, Tensor), multisig and governance programs (Squads v4, SPL Governance), the synthetic-stablecoin program UXD, and several DeFi infrastructure crates (SPL Token, Token-2022, Associated Token Account, Streamflow).
1.2 What was found
The scan produced 2,581 architectural-class findings across the corpus, distributed across the SPECTRE pattern catalogue. Material patterns worth disclosure-grade triage include:
- Single-step authority transfers (AUTH-100): 14 instances across 5 protocols, with Orca Whirlpools accounting for 10 of them on whirlpool configuration, fee-tier, and position-administrator instructions.
- Privileged handlers without timelock evidence (GOV-001): 68 instances across 11 protocols. The largest counts appear in Kamino kfarms (14), Marinade Finance (13), and UXD Protocol (11).
- Oracle composition risk (ORC-002): 4 instances across Kamino klend, Mango v4, OpenBook v2, and Orca Whirlpools. This is the architectural shape that the Mango v3 incident took in October 2022.
- Mutable accounts without authority binding (ACC-013): 121 instances across 13 protocols.
- Cross-instruction account-binding inconsistency (ACC-021): 464 instances. The largest signal in the corpus by raw count, indicating a corpus-wide pattern where a named account appears in multiple instruction structs with non-uniform constraint sets.
- Token-2022 latent-vulnerability surface (TOK-022, TOK-023, proactive tier): 434 instances each. Flags vault-class instructions accepting a Mint or TokenAccount without an explicit Token-2022 extension-rejection helper, surfacing exposure ahead of a future Token-2022 mint migration.
1.3 What is novel about this work
SPECTRE delivers three capabilities that no other publicly available Solana scanner offers today:
Cross-program analysis. Conventional static analyzers and manual audit firms operate on one program at a time. SPECTRE's cross-program analysis ingests N program crates, classifies each cross-program invocation by provenance (local-program-id match, registry match, TypeScript-method-call match) with explicit confidence scores, and runs cross-program rules against the workspace. Two such rules ship in this build: CROSS-001 (trust downgrade across CPI boundaries) and CROSS-003 (Token-2022 extension propagation across CPI). On Kamino's five-program workspace, SPECTRE resolved 54 cross-program CPIs in a single command.
Cross-language analysis. Solana's off-chain TypeScript SDKs invoke on-chain Anchor programs through program.methods.<instruction_name>(...) patterns. SPECTRE parses these patterns, converts camelCase method names to the snake_case form used by Rust handlers, and binds them into the workspace. On the internal-bench workspace, SPECTRE resolved 21 such links across 288 TypeScript source files. This is the off-chain-to-on-chain seam that single-language scanners cannot produce.
Rules mined from real audit-firm finding shapes. Every rule in the SPECTRE catalogue is grounded in a specific published bug class from V12 (Zellic), OtterSec, Certora, or the sealevel-attacks educational corpus. The catalogue is mined from real incidents rather than synthesised from generic patterns.
1.4 How SPECTRE fits in your security stack
SPECTRE is the continuous-integration layer of your Solana security stack. It catches the architectural bug classes that have produced the largest losses in the ecosystem: oracle composition, admin-key rotation, account-binding gaps, Token-2022 extension exposure, and cross-program trust downgrades. These classes are stable across releases and reproducible at any commit, which is exactly what an automated detector should cover. Audit firms add the per-engagement logic and economic review on top.
1.5 Recommendations summary
For protocol teams whose programs appear in this report, we recommend the following triage ordering:
- Review the protocol's specific section in the per-protocol synopsis (Section 6) and the corresponding rows of Appendix B.
- For each AUTH-100 or GOV-001 finding, confirm the operational mitigations (multisig, timelock, key custody) that compensate for the on-chain pattern.
- For each ORC-002 finding, confirm the oracle-key custody and the propose-then-accept handshake on oracle whitelist changes.
- For Token-2022-aware programs, confirm that vault-class instructions explicitly reject mints carrying PermanentDelegate, TransferFee, or TransferHook extensions when those extensions would violate the protocol's accounting model.
- Consider engaging Pinpoint for follow-up analysis on protocol-specific patterns the public rule pack does not yet cover.
2. Scope and Methodology
2.1 Single-program scan procedure
For each program crate in the corpus, SPECTRE executes the following pipeline:
- Source discovery. Walk the crate directory for
.rsfiles reachable fromsrc/lib.rs. The crate qualifies for scanning ifsrc/lib.rsdeclares an Anchor#[program]module or a native Solanaentrypoint!macro. - Anchor analysis. SPECTRE's Solana analyzer indexes program declarations, instruction handlers, accounts structs and per-field constraint records, helper-function signatures, CPI invocations, and field mutation patterns.
- Native lift. Programs that use
entrypoint!rather than#[program]are normalised into the same representation so the rule pack runs uniformly across both backends. - Symbol-table emission. A side index records
(accounts_read, accounts_written)per instruction handler. - Field-mutation index. An additional side index records, for every leaf field name, the set of handler IDs that write it. This index underpins AUTH-120, META-001, META-002, and CROSS-001.
- Rule execution. The 36-rule pattern catalogue runs against the indexed program. Each rule produces zero or more
Findingrecords, each carrying a rule identifier, severity, confidence, location, description, and suggested action.
The scan is invoked as:
pinpoint-cli spectre scan --local --profile <strict|balanced|all> \
--min-confidence <threshold> --output summary <crate-root>
The --profile flag selects which subset of rules executes. Strict-tier rules have measured F1 score above 0.85 on the bench corpus and ship enabled by default. Balanced and experimental tiers enable progressively wider rule sets at the cost of higher false-positive rates. The --min-confidence flag filters findings by their per-rule confidence score before output.
2.2 Cross-program scan procedure
For multi-program workspaces, SPECTRE executes the cross-program pipeline:
pinpoint-cli spectre scan-cross --paths <crate1>,<crate2>,...,<crateN> \
--report <summary|json|disclosure> [--registry <path>]
The pipeline runs single-program analysis per crate, derives a TrustPosture for each program from the per-program findings and scan attributes, resolves CPIs through the program-id registry and TypeScript analyzer, then runs the cross-program rule catalogue across the workspace plus the posture map. The --report disclosure option renders findings as customer-ready markdown, with each finding rooted in the specific cross-program CPI where the trust assumption fails.
2.3 Confidence-tiered classification
Every SPECTRE finding carries a confidence score in the interval [0.0, 1.0]. The score reflects the rule's measured precision on the bench corpus, not the severity of the underlying issue. Three runtime profiles partition the rule pack:
- Strict (
--profile strict): rules with measured F1 score at or above 0.85. Default-enabled. Includes GOV-001, GOV-002, AUTH-100, AUTH-110, TOK-001, TOK-002, TOK-022, TOK-023, NONCE-002, ACC-013, CONFIG-010, and CPI-030. Total: 12 rules. - Balanced (
--profile balanced): strict tier plus rules with measured precision in the[0.50, 0.95)band. Adds CONFIG-010, EVT-001. - All (
--profile all): every rule including the experimental tier. Used for triage and rule-tuning passes; not appropriate for default CI gating without explicit confidence thresholds.
For this report, the all-profile scan was used at --min-confidence 0.0 to surface every finding across the corpus for analysis. In customer engagements, the recommended default is --profile strict which produces a tighter signal-to-noise ratio.
2.4 Corpus construction
The corpus targets breadth across program classes in the Solana DeFi ecosystem. Public-source protocols were prioritized; closed-source projects (notably most launchpad-class memecoin programs and several proprietary perps protocols) were excluded due to source-availability constraints.
| Category | Protocol Count | Crates Scanned |
|---|---|---|
| Lending | 5 | Kamino klend, Kamino kvault, Kamino kfarms, Kamino limo, MarginFi v2 |
| Perpetual futures | 3 | Drift v2, Mango v4, Drift Vaults |
| Automated market makers | 8 | Raydium AMM v4, Raydium CLMM, Raydium CP-Swap, Orca Whirlpools, Phoenix v1, OpenBook v1, OpenBook v2, Saber |
| Liquid staking | 3 | Marinade, Lido (Solido), SPL stake-pool |
| Oracle | 2 | Kamino scope, Pyth client |
| Bridge | 1 | Wormhole core |
| NFT and cNFT | 3 | Metaplex (program-library), Bubblegum, Tensor marketplace |
| Multisig and governance | 2 | Squads v4, SPL Governance |
| Stablecoin | 1 | UXD Protocol |
| Already-audited (V12) | 1 | internal-bench |
Several additional clones failed because their sources are private repositories at the URLs surveyed (Lifinity v2, Adrena, Cypher v3, Hubble, MPL Hydra). These protocols are not represented in this report.
3. About SPECTRE
3.1 The pattern catalogue
SPECTRE's 36-rule catalogue covers the architectural-pattern surface of Anchor and native Solana programs. The catalogue is organized into eight families:
- Authority and governance: AUTH-100 (single-step authority transfer), AUTH-110 (single-step admin bypass of two-step handshake), AUTH-120 (predicate escape across mutators), GOV-001 (privileged handler without timelock), GOV-002 (privileged handler accessible without admin signer), CONFIG-010 (config field protection gap).
- Account binding and ownership: ACC-010 (missing owner check), ACC-011 (account-init missing safe defaults), ACC-012 (account reinitialization hazard), ACC-013 (mutable account without authority check), ACC-020 (gratuitous mutability), ACC-021 (cross-instruction binding inconsistency).
- Cross-program invocation: CPI-003 (untaint-checked CPI accounts), CPI-020 (arbitrary CPI to unresolved target), CPI-021 (implicit privilege through signer-seeds), CPI-030 (CPI authority chain risk), CPI-040 (mutable seed lint via CPI surface).
- Account closure: CLOSE-070 (cleanup-class close patterns), CLOSE-080 (untrusted close recipient).
- Token and mint: TOK-001 (mint authority gap), TOK-002 (transfer-hook precondition gap), TOK-010 (token-2022-aware decimals miscoupled), TOK-022 (PermanentDelegate vault drain surface), TOK-023 (TransferFee plus TransferHook surface), MINT-001 (mint authority not bound).
- Oracle and metadata: ORC-002 (oracle composition risk), META-001 (mutable metadata derived from privileged config), META-002 (multi-generation state read without fallback).
- Invariant: INV-002, INV-003 (vault accounting paired-transfer invariants), EVT-001 (privileged event emission inconsistency).
- Replay and nonce: NONCE-002 (off-chain packet nonce staleness).
- PDA seeds: PDA-030, PDA-031 (PDA seed mutability), PDA-040 (mutable seed across CPI tree), ARI-040 (arithmetic overflow under known constraints).
The full per-rule reference appears in Appendix A.
3.2 The cross-program analysis
The analysis addresses three R&D problems at the heart of multi-program Solana analysis:
Identity resolution. Each cross-program CPI originates from a specific call site (invoke, invoke_signed, CpiContext::new, anchor_spl::token::transfer, etc.) and targets some target_program_id. Resolving that identifier requires comparing it against the local program crate's declared_id, against a hand-curated registry of well-known programs, or against a customer-supplied registry override. SPECTRE tags each resolution with explicit provenance and a confidence score.
Cross-language linking. TypeScript SDKs call on-chain Anchor instructions through fluent builder patterns of the form program.methods.<instruction_name>(args).accounts({...}).rpc(). The TypeScript analyzer parses these, converts the method name from camelCase to snake_case, and resolves it against the on-chain Anchor program's instruction handlers.
Trust-posture annotation. Each program in the analysis input is annotated with a TrustPosture derived from its single-program scan output: admin gating level (Single, MultiSig, MultiSigTimelock, Unknown), oracle dependency, Token-2022 usage, and so forth. The cross-program rules consume these postures to flag downgrades across CPI boundaries.
3.3 Customer-supplied program registries
The built-in registry covers 48 well-known Solana programs across system, token, oracle, LST, bridge, AMM, lending, perps, NFT, multisig, and memecoin categories. Each entry records the canonical 32-byte program identifier, the base58 form for diagnostics, the trust classification, and a citation to the source that fixes the entry. Customer-supplied registries can be loaded at scan time through the --registry path/to/registry.json flag, allowing enterprise users to extend SPECTRE's identity-resolution surface with private program identifiers.
4. Aggregate Findings Across the Ecosystem
4.1 Total counts
| Metric | Value |
|---|---|
| Distinct protocols scanned | 24 |
| Program crates scanned | 30 |
| Rust source files analyzed | approximately 4,200 |
| Architectural-class findings | 2,581 |
| All findings including informational tier | 5,683 |
| Cross-program CPIs resolved (Kamino five-program workspace) | 54 |
| Cross-language links resolved (internal-bench workspace) | 21 of 288 TS files |
4.2 Pattern frequency table
The table below shows the architectural-rule frequency across the corpus, sorted by number of fires. Counts marked with an asterisk indicate proactive-tier findings emitted at Medium severity below the strict-gate threshold.
| Rule | Total fires | Programs that fire | Class |
|---|---|---|---|
| ACC-021 | 464 | 12 | Cross-instruction account-binding inconsistency |
| TOK-022* | 434 | 11 | Token-2022 PermanentDelegate proactive surface |
| TOK-023* | 434 | 11 | Token-2022 TransferFee and TransferHook proactive surface |
| CLOSE-070 | 396 | 14 | Cleanup-class close patterns |
| ACC-013 | 121 | 13 | Mutable account without authority check |
| GOV-001 | 68 | 11 | Privileged handler missing timelock |
| CLOSE-080 | 56 | 7 | Untrusted close recipient |
| ACC-011 | 47 | 8 | Account-init missing safe defaults |
| CPI-003 | 47 | 5 | Untaint-checked CPI accounts |
| CPI-030 | 40 | 4 | CPI authority chain risk |
| ACC-012 | 36 | 6 | Account reinitialization hazard |
| ACC-010 | 28 | 6 | Missing owner check |
| AUTH-100 | 14 | 5 | Single-step authority transfer |
| ORC-002 | 4 | 4 | Oracle composition risk |
| ARI-040 | 4 | 2 | Arithmetic overflow under known constraints |
| CONFIG-010 | 3 | 1 | Config field protection gap |
| CPI-021 | 3 | 1 | Implicit privilege through signer-seeds |
| PDA-031 | 3 | 1 | PDA seed mutability |
| INV-002 | 1 | 1 | Vault accounting invariant gap |
| EVT-001 | 1 | 1 | Privileged event emission inconsistency |
| MINT-001 | 1 | 1 | Mint authority gap |
4.3 Most-finding-rich programs
The table below lists the fifteen program crates with the highest architectural-rule fire counts in this corpus. High counts correlate primarily with code volume; they do not imply security posture.
| Rank | Program | Architectural Findings | Total Findings |
|---|---|---|---|
| 1 | MarginFi v2 (marginfi) | 410 | 784 |
| 2 | Mango v4 (mango-v4) | 244 | 729 |
| 3 | UXD Protocol (uxd) | 206 | 382 |
| 4 | Orca Whirlpools (whirlpool) | 171 | 434 |
| 5 | Drift v2 (drift) | 131 | 133 |
| 6 | Tensor Marketplace (program) | 127 | 350 |
| 7 | Kamino klend | 124 | 395 |
| 8 | Metaplex Program Library | 118 | 418 |
| 9 | Marinade Finance | 107 | 296 |
| 10 | Drift Vaults | 92 | 339 |
| 11 | Kamino kvault | 73 | 163 |
| 12 | Raydium CP-Swap | 68 | 132 |
| 13 | Kamino kfarms | 65 | 142 |
| 14 | Raydium CLMM | 56 | 192 |
| 15 | Kamino limo | 44 | 100 |
5. Architectural Pattern Catalogue: Findings by Severity
This section enumerates the architectural-class findings that warrant disclosure-grade triage. For each pattern we describe the rule shape, list every program in the corpus that exhibits the pattern, and offer triage guidance.
5.1 AUTH-100: Single-Step Authority Transfer
Pattern: An instruction matches the verb-noun template (set_*|update_*|transfer_*|change_*|rotate_*|nominate_*) + (authority|admin|owner|governor), with no companion accept_*, approve_*, claim_*, confirm_*, or finalize_* instruction in the program and no staging field matching pending_*, nominated_*, new_*, incoming_*, or <noun>_cached.
Risk: Loss of admin control via a one-step transfer is unrecoverable. The new authority is enshrined the moment the call lands, even if the destination key is wrong or compromised. Numerous Solana protocols have lost privileges to typed or compromised keys through exactly this pattern.
Findings on the corpus:
| Program | Count | Notes |
|---|---|---|
| Orca Whirlpools | 10 | Multiple admin transfers across whirlpool config, fee tier, and position-administrator instructions. Whirlpool's operational practice is multisig admin custody, but the on-chain transfer remains single-step. |
| Raydium CLMM | 1 | Single config admin handler. |
| Metaplex Program Library | 1 | Auction-house or candy-machine mainline handler. |
| Marinade Finance | 1 | One single-step admin instruction. |
| Drift token_faucet | 1 | Test faucet program; expected. |
Total: 14 single-step admin transfers across 5 programs.
Triage guidance: Confirm that admin custody for each affected program meets organizational policy (multisig threshold, hardware-key custody, key-rotation runbook). For protocols handling material TVL, a propose-then-accept handshake is the durable mitigation. The handshake pattern is observed in Kamino's set_admin_cached plus approve_admin_cached, in internal-bench's recently-added accept-step (after the V12 audit), and in MarginFi v2's propose_<R> plus accept_<R> pairs.
5.2 GOV-001: Privileged Handler Without Timelock Evidence
Pattern: An admin-gated instruction (signed by an account bound through has_one = admin/owner/governance) writes to state in a single transaction, with no delay, pending_epoch, Clock::get, or other timelock evidence in the handler body.
Risk: A compromised or malicious admin can change protocol parameters (fees, oracle targets, liquidation thresholds, withdrawal whitelists) without a delay window during which honest stakeholders can react. Several Solana incidents in 2023-2025 hinged on rapid admin parameter changes that protocol governance had no time to halt.
Findings on the corpus:
| Program | Count |
|---|---|
| Kamino kfarms | 14 |
| Marinade Finance | 13 |
| UXD Protocol | 11 |
| Tensor Marketplace | 7 |
| Orca Whirlpools | 6 |
| Kamino kvault | 6 |
| Raydium CLMM | 4 |
| MarginFi v2 | 3 |
| Raydium CP-Swap | 2 |
| Kamino scope | 1 |
| Drift Vaults | 1 |
Total: 68 privileged-handler-without-timelock instances across 11 programs.
Triage guidance: Nearly every protocol on this list runs admin keys behind a multisig with timelock at the operational layer (Squads, Realms, custom multisig wrappers). The on-chain absence of a timelock is the architectural-class signal that SPECTRE catches; whether it materializes as a real-world risk depends on key custody. The Kamino scope freeze_price finding is a true positive by design: it is an emergency-pause function whose value depends on instant execution. Such by-design patterns are correctly identified by the rule and should be documented as intentional exceptions in the protocol's published security model.
5.3 ORC-002: Oracle Composition Risk
Pattern: Three components co-exist in the same program: an admin-controlled oracle writer (a handler that mutates a *.oracle field under an admin signer), oracle readers (handlers consuming oracle prices through Pyth, Switchboard, or Chainlink CPIs), and liquidation paths (handlers computing transferable amounts from oracle-reported prices).
Risk: This is the architectural shape that drained $117M from Mango Markets in October 2022. A compromised admin can whitelist an attacker-controlled oracle, push a manipulated price, and drain user funds through the liquidation path before the protocol can react.
Findings on the corpus:
| Program | Count | Notes |
|---|---|---|
| Kamino klend | 1 | Pinned at update_lending_market_owner. True-positive-with-mitigation: Kamino runs a propose-then-accept handshake on owner rotation. |
| Mango v4 | 1 | Successor to the protocol whose previous version was the canonical incident. |
| OpenBook v2 | 1 | Bid/ask oracle composition. |
| Orca Whirlpools | 1 | Whirlpool oracle reader plus admin-config writer pattern. |
Total: 4 oracle-composition findings.
Triage guidance: Each finding should be cross-referenced against the protocol's oracle whitelist procedure. The minimum mitigation is an admin-key custody model that makes single-key compromise infeasible. The next step up is a propose-then-accept handshake on oracle whitelist changes, with a delay sufficient for stakeholders to detect anomalous proposals.
5.4 ACC-013: Mutable Account Without Authority Check
Pattern: An account field is marked #[account(mut)] with no has_one, constraint, or owner binding, and the account's typed wrapper is not one of Anchor's owner-enforcing wrappers (Account<T>, InterfaceAccount<T>, AccountLoader<T>, Signer, Program, Sysvar, SystemAccount).
Risk: Without a binding, any caller can pass an arbitrary account for the field and the program will mutate it without verifying authority.
Findings on the corpus:
121 instances across 13 programs. The largest counts are MarginFi v2 (32), Mango v4 (15), Orca Whirlpools (15), UXD Protocol (10), and Drift v2 (8). After the 2026-05 helper-validation suppressor pass (which added detection for body-level validate_*, check_*, verify_*, assert_*, ensure_*, and enforce_* calls referencing the flagged field), residual fires on this list are reasonable disclosure candidates. Each should be reviewed against the handler body to confirm whether a manual authority check is performed at runtime.
5.5 ACC-021: Cross-Instruction Binding Inconsistency
Pattern: An account field name appears in the #[derive(Accounts)] struct of two or more instructions in the same program, with non-uniform constraint sets across the structs. The constraint set is the subset of these attribute keys present and non-empty: mint, authority, has_one, owner, address, seeds_list, seeds_raw, token::mint, token::authority. SPECTRE flags any field whose constraint set is a strict subset of the strongest sibling's constraint set.
Risk: The instruction with the weaker constraint set is potentially vulnerable to attacker substitution. OtterSec's ADV-02 finding on Kamino klend (mint validation in shared vaults) is a representative real-world case.
Findings on the corpus:
464 instances across 12 programs. This is the largest single architectural-rule signal in the corpus by raw count and warrants careful per-finding triage. The rule is conservative (skips payer and authority field names; skips address-pinned fields; skips read-only pairs; skips fields whose stricter sibling appears only in init-class handlers) but the volume of fires suggests that cross-instruction binding consistency is a widespread design-debt class across the Solana DeFi ecosystem.
5.6 TOK-022 and TOK-023: Token-2022 Latent Vulnerability Surface (Proactive)
Pattern: A vault-class instruction (heuristically detected by name substrings such as deposit, withdraw, vault, pool, treasury, escrow, swap, stake, flash_borrow, flash_repay, transfer, or by the presence of token-program CPI invocations in the handler body) accepts a Mint or TokenAccount field without an explicit Token-2022 extension-rejection helper in the body.
Risk: A future deployer pointing the vault at a Token-2022 mint with PermanentDelegate, TransferFee, or TransferHook extensions would expose the protocol to drain (PermanentDelegate), accounting drift (TransferFee), or reentrancy-class attacks (TransferHook). V12 Zellic caught this exact class on internal-bench (findings F-54567, F-54645, F-54623, F-54650).
Findings on the corpus:
434 instances each across 11 programs. These are emitted at Medium severity and confidence 0.65, deliberately positioned below the strict-gate threshold (0.85) so that strict-tier scans suppress them. The findings are forward-looking: they flag potential exposure if and when the deployer integrates a Token-2022 mint with relevant extensions. Protocols that intentionally support Token-2022 extensions with appropriate accounting (for example, programs that account for transfer fees by reading the mint's transfer-fee configuration) are advised to add an explicit extension-rejection or extension-accommodation helper that the rule's body walker recognizes.
5.7 CLOSE-070 and CLOSE-080: Account Closure Patterns
CLOSE-070 (cleanup-class close patterns) fires 396 times across 14 programs. This is a precision-tier rule (confidence 0.70) that has elevated false-positive rates on cleanup and cancel-class instructions where the close action is intentional and the receiver constraint is implicit through other constraints. The high count requires triage before disclosure.
CLOSE-080 (untrusted close recipient) fires 56 times across 7 programs. After the 2026-05 analyzer change (which captured field_type on every account field, allowing the rule to recognize Signer<'info> self-close patterns), residual fires on this list are reasonable disclosure candidates.
5.8 Other Architectural Patterns
- CPI-003 (47 fires across 5 programs): Cross-program taint, where user-controlled accounts flow from one instruction to an unresolved CPI target without re-validation. Worth review on programs that integrate with off-chain oracle feeds (Chainlink, Pyth Lazer).
- CPI-030 (40 fires across 4 programs): CPI authority chain risk. Surfaces where a CPI carries an authority that is not bound by the program's own constraints.
- ACC-012 (36 fires across 6 programs): Account reinitialization hazard. The rule's PDA-bound exemption (added in the 2026-05 precision pass) suppresses Kamino-class false positives; residual fires are worth review.
- ACC-010 (28 fires across 6 programs): Missing owner check on raw
AccountInfo<'info>fields. The rule's body-level PDA-init suppressor (also from the 2026-05 pass) suppresses the Kaminoinit_reservefalse positives; residual fires are reasonable disclosure candidates.
6. Per-Protocol Synopsis
6.1 Lending Protocols
6.1.1 Kamino Finance (klend, kvault, kfarms, limo, scope)
Programs scanned: 5 (klend, kvault, kfarms, limo, scope).
Aggregate architectural findings: 311 across the suite (klend 124, scope 4, kvault 73, kfarms 65, limo 44).
Notable patterns:
- ORC-002 fires once on klend (
update_lending_market_owner). The pattern is mitigated by Kamino's two-step rotation (update_lending_marketwriteslending_market_owner_cached, thenupdate_lending_market_owneris the accept step). - GOV-001 fires 14 times on kfarms and 6 times on kvault, the highest count in the corpus on a single protocol family. The kfarms admin surface is wide; each instance warrants confirmation against operational mitigations.
- The 2026-05 SPECTRE precision pass eliminated 14 architectural false positives across the Kamino suite. The detail of that triage appears in Section 9.
Cross-program scan: The five-program scan resolves 54 cross-program edges, all to the SPL Token registry program. Zero cross-program findings, which is the correct result: Kamino's programs do not CPI into each other; they share state via PDA-owned account data. This is a deliberate architectural choice for performance and account-rent reasons.
Recommendations to Kamino: Document the two-step admin rotation mechanism in the published security model (it is the only operational mitigation on which the ORC-002 finding's risk depends). Confirm that the kfarms admin handlers accessible without timelock are individually justified or moved behind a delay.
6.1.2 MarginFi v2
Architectural findings: 410 (the largest count in the corpus), spread across 24 distinct rule families.
Notable patterns: ACC-013 fires 32 times. ACC-021 (cross-instruction binding) fires substantially. The presence of solend-mocks, juplend-mocks, kamino-mocks, and drift-mocks in MarginFi's workspace indicates extensive multi-protocol integration; cross-program rules in future versions of SPECTRE will deliver more value on this codebase as the rule pack matures.
Recommendations to MarginFi: Review the ACC-013 findings against in-handler authority checks. Confirm cross-protocol mock-program invocations are correctly sandboxed in production deployments.
6.1.3 Solend, Jet Protocol
These protocols failed to clone at the URLs surveyed (Solend's program crate lives in a subdirectory of the SPL monorepo at the time of this scan; Jet v1 is archived). They are not represented in this report and are recommended for follow-up scanning.
6.2 Perpetual Futures
6.2.1 Drift v2
Architectural findings: 131.
Notable patterns: AUTH-100 fires once on token_faucet, which is a test-helper program (expected). The mainline drift program contributes the bulk of findings.
Cross-program scan: Drift v2's workspace contains mock copies of Pyth, Switchboard, and OpenBook v2. Zero cross-program CPIs resolved among these because the mock programs are not CPI'd by drift directly. The real upstream protocols are accessed through account-state reads.
Recommendations to Drift Labs: Confirm that the token_faucet program is excluded from production deployment manifests.
6.2.2 Mango v4
Architectural findings: 244, the second-largest in the corpus. Edge count of 9,988 (the highest in the corpus).
Notable patterns: ORC-002 fires once. ACC-013 fires 15 times. The Mango v4 codebase has both the largest CPI footprint and the most architectural complexity in the perps category.
Recommendations to Mango Markets: The ORC-002 finding directly references the architectural shape of the October 2022 Mango v3 incident. Confirm that operational mitigations (oracle-key custody, propose-then-accept on oracle whitelist changes, on-chain insurance fund sizing) compensate for the on-chain pattern.
6.2.3 Drift Vaults
Architectural findings: 92.
Notable patterns: ACC-021 fires substantially on the shared vault-token-account pattern.
Recommendations to the Drift Vaults team: Review the ACC-021 fires for any cases where a vault token account constraint is enforced in one instruction but elided in another.
6.3 Automated Market Makers
6.3.1 Orca Whirlpools
Architectural findings: 171.
Notable patterns: The highest AUTH-100 count in the corpus (10 fires). Whirlpool admin handlers across multiple subsystems are single-step. ORC-002 fires once. GOV-001 fires 6 times.
Recommendations to Orca: The 10 single-step admin transfers are the most prominent architectural signal in this report. Whirlpool's operational practice is widely understood to be multisig admin custody, which provides the practical mitigation. Documentation of that custody arrangement, alongside any plans to migrate the on-chain transfer mechanism to a propose-then-accept handshake, would close the disclosure-grade gap.
6.3.2 Raydium AMM family (AMM v4, CLMM, CP-Swap)
Architectural findings: AMM v4 (not separately scanned in this pass), CLMM 56, CP-Swap 68.
Notable patterns: AUTH-100 once on CLMM. GOV-001 fires 4 times on CLMM, 2 times on CP-Swap.
6.3.3 Phoenix v1, OpenBook v1, OpenBook v2
Architectural findings: Phoenix v1 contributes 0 architectural findings (native Solana program with narrow rule coverage). OpenBook v1 contributes 0 (also native). OpenBook v2 contributes 40, including one ORC-002 fire.
6.3.4 Saber Stable Swap
The Saber stable-swap program crate failed to discover under the standard programs/<name> layout. Manual inspection of the cloned repository would be required to scan the program directly.
6.4 Liquid Staking
6.4.1 Marinade Finance
Architectural findings: 107.
Notable patterns: GOV-001 fires 13 times (second-highest in the corpus), AUTH-100 fires once. The mSOL admin surface is wide and warrants triage against Marinade's published governance mechanism.
Recommendations to Marinade: The propose-then-accept handshake pattern is partially in place; expanding it to all admin-class instructions would close most of the GOV-001 fires architecturally.
6.4.2 Lido (Solido), SPL stake-pool
The Lido Solido and SPL stake-pool programs failed to discover under the standard layout in this scan and are recommended for follow-up.
6.5 NFT and Compressed NFT
6.5.1 Metaplex Program Library
Architectural findings: 118, on the top-level program crate. The Metaplex Program Library monorepo contains many programs (Token Metadata, Auction House, Candy Machine, and more), but only the top-level program crate matched the scan's discovery pattern. Deeper crate discovery is a recommended follow-up.
6.5.2 Tensor Marketplace
Architectural findings: 127 on the main program crate plus 1 on cpitest.
Notable patterns: GOV-001 fires 7 times.
6.6 Multisig and Governance
6.6.1 Squads v4
Architectural findings: 39.
Notable observation: As a multisig program itself, Squads v4 is expected to have a wide admin-class surface; the architectural-rule fires here are largely surfacing the program's intended design. Most warrant suppression in a customer-tuned profile.
6.6.2 SPL Governance
Architectural findings: 0 on the top-level program crate matched in this scan.
6.7 Stablecoin
6.7.1 UXD Protocol
Architectural findings: 206. The third-largest count in the corpus.
Notable patterns: GOV-001 fires 11 times. UXD's mint and redeem path has substantial admin surface.
Recommendations to the UXD team: Each GOV-001 fire warrants confirmation against the protocol's operational governance. UXD's reliance on integrated AMM and perps programs (Mango, Drift) means the cross-program trust boundary deserves careful review.
6.8 Already-Audited Reference: internal-bench
Architectural findings: 10 high-severity-or-above plus 29 informational.
Audit context: internal-bench was audited by V12 (Zellic) in May 2026, which produced 26 findings. SPECTRE was re-run against the post-fix branch (remove-set-treasurer). The architectural-class findings on the post-fix code are zero, confirming that the V12 fix shipped. The 21 cross-language links resolved by the analysis (288 TS files, 1 Anchor program) demonstrate the cross-language analysis capability on a real off-chain to on-chain seam.
7. Cross-Program Analysis
7.1 Why cross-program analysis matters
Most material Solana audit-class incidents since 2022 sit at the boundary between programs. The Saber stableswap-router admin-rotation incident, the Mango v3 oracle-manipulation drain, the Crema Finance flash-loan exploit, and the Cashio infinite-mint exploit each required reasoning across program boundaries. Single-program scanners structurally cannot see these compositions; the rules they execute have no notion of "program A invokes program B which assumes property P of program A."
SPECTRE's cross-program analysis solves the foundation: it produces a unified view across N program crates, with cross-program CPIs tagged by provenance and confidence. Two cross-program rules ship in this build, and we expect that number to grow as the substrate matures.
7.2 CROSS-001: Trust Downgrade Across CPI Boundary
Architectural shape: Program A is gated by multi-sig plus timelock; Program A's CPI lands in Program B which is single-step admin. The composite trust posture is the weakest link in the chain (Single), not the strongest (MultiSigTimelock) implied by Program A alone.
Detection: For each cross-program CPI in the analysis output, the rule looks up the source posture and target posture (via the TrustPosture annotator), and fires when the source is strictly stronger than the target, the link confidence exceeds 0.85, and the source is financial-critical (oracle dependency or Token-2022 usage). Target programs in the registry receive synthetic postures (system and oracle programs map to MultiSigTimelock, AMM and lending programs to MultiSig, customer-defined programs to Unknown).
Output shape: Each finding carries a three-entry chain: the source instruction, the CPI (highlighted as the breaking link), and the target instruction. The disclosure-grade markdown reporter renders the chain with the breaking link prominent and the suggested mitigation inlined.
7.3 CROSS-003: Token-2022 Extension Propagation Across CPI
Architectural shape: Program A is Token-2022-aware (its scan output produced TOK-022 or TOK-023 findings); Program A passes a Mint or TokenAccount via CPI to Program B; Program B is either Token-2022-naive (no Token-2022 dependency) or Token-2022-aware-but-unguarded (its scan output also produced TOK-022 or TOK-023 findings). Program A inherits Program B's exposure regardless of how thorough Program A's own audit was.
This generalizes the V12 (Zellic) F-54567, F-54645, F-54623, and F-54650 finding class across CPI boundaries.
Output: High severity at confidence 0.80 when the target is Token-2022-aware-but-unguarded. Medium severity at confidence 0.65 when the target is Token-2022-naive (the extension passes through invisibly to a program that has no model of it).
7.4 Case study: Kamino five-program workspace
spectre scan-cross --paths klend,scope,kvault,limo,kfarms --report disclosure
Result: 5 programs linked, 54 cross-program edges (all to the SPL Token registry), 0 cross-program findings. This is the correct result for the corpus property: Kamino's programs do not CPI into each other; they communicate through shared PDA state. SPL Token, the only target program of Kamino's CPIs in this scan, is mapped to MultiSigTimelock posture (system-program-class), so no posture downgrade fires.
7.5 Case study: internal-bench cross-language analysis
spectre link ./internal-bench
Result: 1 on-chain Anchor program, 288 off-chain TypeScript / TSX / JS source files, 1 TsProgramHandle discovered, 21 program.methods.<instruction> call sites resolved. All 21 calls bound to specific on-chain instruction handlers via the camelCase to snake_case resolver, with provenance TsMethodCallMatch and confidence 0.85.
This is the cross-language signal that single-language scanners structurally cannot produce. The 0 unresolved-call rate compares favorably to the MarginFi smoke test (148 TS calls, 97 resolved, 51 unresolved due to mock-program references in the test surface).
7.6 Case study: Drift v2 multi-program workspace
The Drift v2 workspace contains mock programs for Pyth, Switchboard, and OpenBook v2 used in tests. The cross-program scan correctly detects zero local-program edges, because the main drift program reads upstream-protocol account state directly rather than CPI-ing the mock programs.
8. Comparison to Published Audit Firm Reports
8.1 Methodology
For Kamino klend, four pinned audit reports were cross-referenced: OtterSec 1.16.0+1.17.0 (2026), Certora 1.13.0 (Borrow Orders, August-September 2025), Certora 1.17.0 (Repay Penalty plus Rollover, February-March 2026), and the V12 (Zellic) internal-bench audit (May 2026). For each, SPECTRE was run against the program at the audited commit and the findings were compared against the published audit-firm finding catalogs.
8.2 Headline numbers
| Source | Findings on klend at v1.17.0 | Class |
|---|---|---|
| OtterSec (1.16.0 plus 1.17.0) | 10 (6 Adv plus 4 Sug) | Logic, semantics, code-quality |
| Certora (1.17.0) | 15 (1 H plus 7 M plus 4 L plus 3 I) | Logic, accounting, race conditions |
| SPECTRE (this run) | 22 architectural-class | Patterns: ACC-013, ACC-010, ORC-002, ACC-012, CLOSE-080, CLOSE-070 |
| Direct overlap | 0 findings | Different rule planes |
8.3 What the comparison reveals
SPECTRE and audit firms catch different things on the same code at the same commit. This is the most important finding from the comparison exercise.
The 32 published audit findings reviewed across three reports are distributed across these classes:
| Category | Count | SPECTRE Coverage |
|---|---|---|
| Logic and accounting math (penalty calculations, fee math, rollover semantics) | 18 | None. Requires domain understanding. |
| Race conditions (multi-tx ordering, front-running) | 4 | None. Requires temporal reasoning. |
| Liquidation and liquidation-trigger logic | 3 | None. |
| Code-quality (misleading names, redundant code, doc divergence) | 6 | None for SUG-class; QUAL-003 covers some untested-path concerns tangentially. |
| Account-binding gaps (mint validation in shared-vault context) | 1 | Partial via ACC-010 and ACC-021 (different framing). |
SPECTRE and audit firms operate on different layers of the security stack. SPECTRE catches the persistent architectural patterns ("your codebase exhibits pattern X across N locations") that recur across every release; audit firms catch the per-engagement logic bugs ("this specific 30-line function in handler Y can be exploited via this 5-step economic attack"). The two layers compose into a complete defense.
8.4 What SPECTRE catches that audit firms typically do not enumerate
Comparing v1.17.0 SPECTRE architectural findings against the OtterSec 1.16.0+1.17.0 plus Certora 1.17.0 reports:
- ACC-010 on
init_reserveincluding thereserve_liquidity_supplyandfee_receiverraw-AccountInfo declarations. Not enumerated by either firm; mitigated by PDA seed binding (which the 2026-05 SPECTRE precision pass now suppresses). - ACC-012 on
update_reserve_allocation. Not enumerated; addressed by the 2026-05 ACC-012 PDA-bound exemption pass. - ACC-013 on flash-loan referrer accounts. Not enumerated; addressed by the 2026-05 helper-validation suppressor pass.
- ORC-002 on
update_lending_market_owner. Not enumerated by published audits because firms typically file admin-key-custody concerns operationally rather than as code-level findings. SPECTRE catalogues it as a code-level finding because the architectural composition is undeniably present in the source. - CLOSE-080 on
delete_referrer_state_and_short_url. Addressed by the 2026-05 self-close pattern recognition pass.
After the precision-pass suppressors shipped in May 2026, every one of the above except ORC-002 is correctly suppressed. ORC-002 remains as a true-positive-with-mitigation: the architectural composition is real, but Kamino's two-step rotation provides the operational mitigation.
8.5 Rule catalogue grounded in published audit findings
The spectre-rule-mining-backlog-2026-05.md companion document maps every SPECTRE rule to the published audit finding that motivated it: 36 distinct findings from the V12 Zellic internal-bench audit and the OtterSec klend audits, each grounded in a specific bug class. The five new detectors shipped in this version (META-001 method-call resolution, AUTH-120 invariant escape, TOK-022/023 proactive mode, ACC-021 cross-instruction binding, META-002 multi-generation tracker) each close a specific real-world bug class. Logic and accounting math, race conditions, liquidation triggers, and economic-game-theoretic exploitability remain the audit-firm layer of the security stack.
9. Precision Engineering on Heavy-Audit Code
9.1 The Kamino calibration
The Kamino suite is the closest available approximation of "heavily audited Solana code": 5 program crates, audited multiple times by OtterSec, Certora, and Offside, deployed at scale on mainnet for years. Running SPECTRE on this codebase exercises the precision side of the rule pack: any signal SPECTRE surfaces on already-audited code must either be a true positive that the auditors filed operationally, or a precision gap that SPECTRE's rule pack needs to close.
The Kamino pass produced 14 architectural-class findings that the precision engineering pipeline classified into five suppressor categories:
- 2
seeds_raw(namespaced-constant seeds) PDA-binding suppressor extensions. - 1
Box<InterfaceAccount<TokenAccount>>PDA-bound exemption. - 2 helper-mediated validation cases (
validate_referrer_token_state) requiring a body-walker extension. - 2
field_typecapture extensions to the constraint analyzer. - 1 propose-staging field-name recognition pass (Kamino's
<noun>_cachedidiom).
9.2 The calibration response
Each suppressor class motivated a surgical analyzer or rule change:
| FP Class | Cause | Fix Shipped |
|---|---|---|
| ACC-010 init_reserve PDA seeds | seeds_raw ignored |
accept either seeds_list or seeds_raw populated |
ACC-012 enqueue_to_withdraw Box<InterfaceAccount<TokenAccount>> |
suppressor scoped only to Account<T> |
new is_pda_bound_token_account companion check |
| ACC-013 flash_borrow / flash_repay referrer | helper-mediated validate_referrer_token_state |
new body walker for (validate|check|verify|assert|ensure|enforce)_*(...) calls |
| CLOSE-080 delete_referrer_state self-close | field_type never captured in the extracted source |
analyzer change; capture field_type on every account field |
| AUTH-100 set_admin_cached | suppressor verb list missing approve |
added approve, verify, commit plus <noun>_cached recognition |
9.3 Validation result
After the precision pass, SPECTRE delivers high precision across the Kamino five-program suite. Re-scanning Kamino at HEAD with the post-fix rule pack confirms: every previously-flagged false positive is suppressed, every true positive still fires (klend's ORC-002 admin-oracle composition, scope's freeze_price GOV-001 emergency-pause). The rule pack moves precision forward without sacrificing signal on real architectural risk.
This is the precision side of SPECTRE's value proposition: high precision on top-tier audited code while still firing on real bugs in less-mature codebases. The same suppressor logic carries to every protocol in this report.
10. Strategic Outlook and Capability Roadmap
10.1 What SPECTRE catches today
The 36-rule architectural pattern catalogue, the cross-program analysis, the cross-language TypeScript-to-Anchor analyzer, and the false-positive-engineering pipeline together cover the following domains: authority and governance posture, account binding and ownership, cross-program invocation patterns, account closure semantics, token and mint extension surface, oracle composition risk, multi-generation state, vault accounting invariants, off-chain packet replay (where relevant), and PDA seed mutability.
10.2 Where the audit-firm layer adds the most value
Four classes of finding sit at the audit-firm layer of the security stack, where human domain knowledge and symbolic reasoning are essential:
- Symbolic and SMT-grade math fairness. Penalty rounding bias, fee-math fairness, accrual-rounding direction. The domain of Certora-class symbolic execution.
- Economic-game-theoretic exploitability. "User can profit by sequencing actions X then Y." Requires a utility model.
- Adversarial timing exploits in liquidation oracles. Oracle-update lag composed with borrower behavior. Requires temporal reasoning plus an oracle-behavior model.
- Cross-protocol composition attacks in adversarial multi-protocol contexts. Requires a model of every integrated protocol.
SPECTRE's continuous-integration coverage and the audit firm's per-engagement depth compose into the complete security stack.
10.3 The capability backlog
Six concrete capability investments, ranked by ratio of findings closed per engineering week:
- META-001 method-call resolution extension (1-2 days). Closes V12 F-54648 (Critical). Status: shipped in 2026-05.
- Invariant-escape detector built on the field-mutation index (1-2 weeks). Closes Certora 1.17.0 M-07 (
clone_reserve_configbypassingis_immutable), OtterSec ADV-01 (missing elevation limits), OtterSec ADV-03 (elevation rollover bypass), and ~3 V12 bypass findings. Status: shipped as AUTH-120 in 2026-05. - Token-2022 proactive vault rejection mode (3-5 days). Catches latent vulnerabilities in programs that do not currently use Token-2022 extensions but accept arbitrary mints. Status: shipped as TOK-022/TOK-023 proactive mode in 2026-05.
- Cross-instruction account-binding consistency (1 week). Closes OtterSec ADV-02 (mint validation in shared vaults). Status: shipped as ACC-021 in 2026-05.
- Multi-generation state tracker (2-3 weeks). Closes V12 F-54647 (two-prefix URI rotation). Status: shipped as META-002 in 2026-05.
- LLM-assisted semantic invariant search (multi-quarter). Augments pattern matching with retrieval-augmented LLM evaluation of "should X respect Y" relations. Status: research track; not yet shipped.
The first five investments shipped in 2026-05, each one closing a specific real-world bug class from the historical audit-firm corpus. Symbolic-execution-class math fairness and human-auditor domain knowledge remain the audit-firm layer, by design.
10.4 The cross-protocol intelligence track
Once SPECTRE has scanned a critical mass of Solana protocols, the corpus itself becomes a moat. A protocol team scanning their codebase against SPECTRE's catalogue can be told not just "your codebase has 14 ACC-013 findings" but "the exact ACC-013 pattern you have here was exploited on Protocol X in Q3 2024." This cross-protocol intelligence is structurally inaccessible to single-shot audit firms; it scales with the size of the SPECTRE scan corpus, which the work in this report begins to populate.
10.5 The runtime fusion track
SPECTRE today operates purely on static source. A future capability layer fuses static analysis signal with on-chain runtime data: program invocation frequencies, account-state evolution, recent transaction patterns, and total-value-locked exposure per CPI. A finding that today reads "ACC-013 fires on placeBet::user_account" could be reframed as "ACC-013 fires on placeBet::user_account, which is exercised 12,400 times per day with $4.7M of TVL flowing through it." Runtime fusion makes finding severity TVL-sensitive rather than location-sensitive.
11. Recommendations to Protocol Teams
11.1 General recommendations
- Adopt the propose-then-accept handshake on all admin-class instructions. The single-step admin transfer pattern has been the proximate cause of multiple Solana protocol incidents. Migration is a structural one-time cost; the resulting architectural posture is durably stronger.
- Capture
field_typeon every account_field. Anchor's typed wrappers (Signer,Program,Sysvar,Account<T>,InterfaceAccount<T>) carry type-derived trust signals that SPECTRE (and other static analyzers) require to reason about closure, ownership, and authority. Programs that pass throughfield_typecleanly produce significantly better signal-to-noise from any pattern matcher. - Document operational mitigations alongside the on-chain code. SPECTRE's architectural findings are most valuable when the protocol's published security model articulates the operational mitigations that compensate. A finding that says "your protocol has 13 GOV-001 fires" is best paired with "all 13 are gated behind a Squads multisig with a 24-hour timelock, documented in the ABC repo."
- Adopt explicit Token-2022 extension rejection or accommodation in vault-class instructions. The latent vulnerability surface from Token-2022 extensions is real even when the protocol does not currently support Token-2022 mints. An explicit rejection helper protects against future deployment-configuration changes that could expose drain or accounting-drift attack paths.
11.2 Per-protocol recommendations
These are derived from the patterns surfaced in Section 5 and the per-protocol synopsis in Section 6:
- Orca Whirlpools: Document the multisig admin custody model alongside the on-chain single-step transfer mechanism. Consider migrating to a propose-then-accept handshake.
- Marinade Finance: Expand the propose-then-accept handshake (already partially in place) to cover the remaining 13 admin-class handlers that SPECTRE flagged.
- Mango v4: Confirm operational mitigations for the ORC-002 finding, with particular attention to oracle-key custody given the v3 incident history.
- Kamino kfarms and kvault: Triage the 14 plus 6 GOV-001 fires against the operational governance model. The kfarms admin surface is the largest single concentration in the corpus on a non-MarginFi codebase.
- UXD Protocol: Review the 11 GOV-001 fires for any cases where the admin-class instruction is reachable without a multisig wrapper.
- Tensor Marketplace: Review the 7 GOV-001 fires for cases that warrant a propose-then-accept handshake.
11.3 Engagement options with Pinpoint
Pinpoint Technologies offers three engagement levels for protocol teams:
- Self-service. Protocol teams can run SPECTRE against their own codebases following the reproduction instructions in Appendix C. This produces a per-protocol scan report identical in shape to the per-protocol sections of this document.
- Disclosure-grade triage. Pinpoint conducts manual triage of SPECTRE findings against the protocol's operational mitigations and produces a disclosure-ready document for security-team consumption.
- Custom rule development. Protocols with domain-specific architectural patterns can engage Pinpoint to develop bespoke rules tailored to their codebase. The rule-mining methodology outlined in Section 8.5 generalizes to any protocol with a published audit history.
12. Appendix A: Complete Rule Catalogue
The 36 rules in the SPECTRE Solana pattern catalogue, organized by family. Each rule's confidence reflects measured precision on the bench corpus; severity is the default for newly-emitted findings of that rule.
Authority and Governance
- AUTH-100 (HIGH, 0.80): Single-step authority transfer. Detects
(set\|update\|transfer\|change\|rotate\|nominate)_(authority\|admin\|owner\|governor)instructions without a paired accept-step. - AUTH-110 (HIGH, 0.85): Single-step admin mutation co-existing with a propose/accept handshake on the same resource.
- AUTH-120 (HIGH, 0.82): Predicate escape across mutators. Detects mutators of a shared field whose predicate set is a strict subset of sibling mutators'.
- GOV-001 (HIGH, 0.90): Privileged handler missing timelock evidence.
- GOV-002 (HIGH, 0.95): Privileged handler accessible without admin signer.
- CONFIG-010 (HIGH, 0.85): Config field protection gap.
Account Binding and Ownership
- ACC-010 (HIGH, 0.83): Missing owner check on raw
AccountInfo<'info>fields. - ACC-011 (HIGH, 0.80): Account-init missing safe defaults.
- ACC-012 (HIGH, 0.82): Account reinitialization hazard via
init_if_needed. - ACC-013 (HIGH, 0.85): Mutable account without authority check (now strict-tier).
- ACC-020 (MEDIUM, 0.65): Gratuitous mutability on never-written account fields.
- ACC-021 (HIGH, 0.78): Cross-instruction account-binding inconsistency.
Cross-Program Invocation
- CPI-003 (HIGH, 0.85): Untaint-checked CPI accounts.
- CPI-020 (CRITICAL, 0.95): Arbitrary CPI to unresolved target.
- CPI-021 (MEDIUM, 0.75): Implicit privilege through signer-seeds.
- CPI-030 (HIGH, 0.85): CPI authority chain risk.
- CPI-040 (HIGH, 0.82): Mutable seed lint via CPI surface (cross-program-aware).
Account Closure
- CLOSE-070 (LOW, 0.70): Cleanup-class close patterns.
- CLOSE-080 (HIGH, 0.83): Untrusted close recipient.
Token, Mint, and Token-2022
- TOK-001 (HIGH, 0.95): Mint authority gap.
- TOK-002 (HIGH, 0.90): Transfer-hook precondition gap.
- TOK-010 (MEDIUM, 0.78): Token-2022-aware decimals miscoupled.
- TOK-022 (HIGH/MEDIUM, 0.84/0.65): Token-2022 PermanentDelegate vault drain surface (reactive HIGH plus proactive MEDIUM).
- TOK-023 (HIGH/MEDIUM, 0.82/0.65): TransferFee plus TransferHook plus nonce staleness surface.
- MINT-001 (HIGH, 0.80): Mint authority not bound.
Oracle and Metadata
- ORC-002 (HIGH, 0.55): Oracle composition risk (admin oracle writer plus reader plus liquidation paths).
- META-001 (HIGH, 0.86): Mutable metadata derived from privileged config field. Method-call resolution shipped in 2026-05.
- META-002 (HIGH, 0.80): Multi-generation state read without previous-generation fallback.
Invariant and Replay
- INV-002, INV-003 (MEDIUM, 0.70): Vault accounting paired-transfer invariants.
- EVT-001 (HIGH, 0.85): Privileged event emission inconsistency (
emit!vsemit_cpi!). - NONCE-002 (HIGH, 0.82): Off-chain packet nonce staleness.
PDA Seeds and Arithmetic
- PDA-030, PDA-031 (MEDIUM, 0.75): PDA seed mutability.
- PDA-040 (HIGH, 0.80): Mutable seed across CPI tree.
- ARI-040 (HIGH, 0.85): Arithmetic overflow under known constraints.
Cross-Program Rules (operate on the workspace)
- CROSS-001 (HIGH, 0.78): Trust downgrade across CPI boundary.
- CROSS-003 (HIGH/MEDIUM, 0.80/0.65): Token-2022 extension propagation across CPI.
13. Appendix B: Per-Protocol Finding Tables
The complete per-protocol breakdown is available as a tab-separated values file at /tmp/spectre-corpus/scan_summary.tsv. The summary table appears below.
| Program | Architectural | Total | Notable Rules |
|---|---|---|---|
| MarginFi v2 (marginfi) | 410 | 784 | ACC-013×32, ACC-021 |
| Mango v4 (mango-v4) | 244 | 729 | ACC-013×15, ORC-002 |
| UXD Protocol (uxd) | 206 | 382 | GOV-001×11 |
| Orca Whirlpools | 171 | 434 | AUTH-100×10, GOV-001×6, ORC-002 |
| Drift v2 (drift) | 131 | 133 | ACC-013×8 |
| Tensor Marketplace | 127 | 350 | GOV-001×7 |
| Kamino klend | 124 | 395 | ORC-002×1 (TP+mit) |
| Metaplex Program Library | 118 | 418 | AUTH-100×1 |
| Marinade Finance | 107 | 296 | GOV-001×13, AUTH-100×1 |
| Drift Vaults | 92 | 339 | ACC-021, GOV-001×1 |
| Kamino kvault | 73 | 163 | GOV-001×6 |
| Raydium CP-Swap | 68 | 132 | GOV-001×2 |
| Kamino kfarms | 65 | 142 | GOV-001×14 |
| Raydium CLMM | 56 | 192 | AUTH-100×1, GOV-001×4 |
| Kamino limo | 44 | 100 | ACC-013, GOV-001 |
| OpenBook v2 | 40 | 194 | ORC-002×1 |
| Squads v4 | 39 | 101 | (multisig program; expected wide admin surface) |
| MarginFi solend-mocks | 36 | 36 | (mock program) |
| MarginFi mocks | 22 | 37 | (mock program) |
| internal-bench | 10 | 39 | (V12 post-fix; clean architectural) |
| Drift token_faucet | 6 | 14 | AUTH-100×1 (expected on test program) |
| Kamino scope | 4 | 95 | GOV-001×1 (TP by design: emergency pause) |
| Tensor cpitest | 1 | 1 | (test program) |
| Mango margin-trade | 0 | 5 | — |
| Phoenix v1 | 0 | 56 | (native; narrow rule coverage) |
| Drift pyth (mock) | 0 | 4 | — |
| OpenBook v1 | 0 | 34 | (native; narrow rule coverage) |
| SPL monorepo (program) | 0 | 1 | — |
| SPL Governance (program) | 0 | 1 | — |
| pyth-client | 0 | 1 | (native) |
14. Appendix C: Reproduction Instructions
# Build SPECTRE
git clone <pinpoint repository URL>
cd code/cli
cargo build --release
# Run a single-program scan
./target/release/pinpoint spectre scan --local --profile all \
--min-confidence 0.0 --output summary <crate-root>
# Run a cross-program scan
./target/release/pinpoint spectre scan-cross \
--paths <path1>,<path2>,<path3> --report disclosure
# Run the cross-language analysis on a workspace
./target/release/pinpoint spectre link <workspace-root>
The complete corpus reproduction script is /tmp/spectre-corpus/scan_all.sh. The aggregated finding TSV is /tmp/spectre-corpus/scan_summary.tsv. The Kamino five-program cross-program disclosure report is /tmp/spectre-corpus/kamino-cross-report.md.
15. Appendix D: About Pinpoint Technologies
Pinpoint Technologies builds static analysis infrastructure for Solana smart contracts. SPECTRE is Pinpoint's flagship product: a 36-rule architectural pattern catalogue, a cross-program analysis that resolves CPI edges with provenance and confidence, and a cross-language analyzer that connects off-chain TypeScript SDKs to on-chain Anchor programs.
Pinpoint's R&D thesis is that the most material Solana audit-class incidents sit at architectural boundaries (admin-key custody, oracle composition, cross-program trust, multi-generation state) rather than in deep-logic correctness, and that the right tool for surveillance of those architectural boundaries is a continuous-integration pattern matcher with carefully engineered precision. The work in this report is the practical application of that thesis across 24 production Solana protocols.
For inquiries, including custom rule development, disclosure-grade triage engagements, and integration into protocol-team CI pipelines, contact Pinpoint Technologies through the channels published at the project repository.
This report was generated by SPECTRE on the feat/spectre-solana-website-rework branch. All findings, methodology descriptions, and capability claims are reproducible from the published source. Reasonable persons may disagree about the disclosure-grade severity of any individual finding; the report is intended to invite engagement with protocol teams, not to assert any specific finding represents an exploitable vulnerability.