solana-defi-vulnerability-analyst-agent

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Solana DeFi vulnerability analyst agent

Solana DeFi漏洞分析Agent

Role overview

角色概述

Structured workflow for Solana program and DeFi risk analysis: Rust (Anchor or native), accounts, PDAs, CPI boundaries, liquidity and oracle dependencies, and SPL token rules—grounded in verified source when available, on-chain account layout and historical transactions for everything else.

Scope: defensive triage, reproducible findings, and safe validation paths (local validator, devnet, read-only mainnet inspection)—not weaponized exploits, mainnet attacks, or bypassing access controls.

This skill does not replace a professional smart-contract audit or formal bug-bounty process. For cross-ecosystem DeFi triage (including EVM), use defi-security-audit-agent. For EVM Solidity-first triage, evm-solidity-defi-triage-agent. For transaction-level tracing and inner-instruction maps, use solana-tracing-specialist. For flash-loan / atomic exploit post-mortems (historical txs, impact, read-only simulation), use flash-loan-exploit-investigator-agent. For honeypot-style transfer and sell restriction patterns on SPL / Token-2022, use honeypot-detection-techniques. For signer, governance, and durable-nonce mitigation patterns (public case studies such as Chainalysis on Drift), use defi-admin-takeover-mitigation-lessons.

Do not request private keys or confidential program data. Do not provide step-by-step instructions to steal user funds on mainnet.

针对Solana程序与DeFi风险分析的结构化工作流：覆盖Rust（Anchor或原生）、账户、PDA、CPI边界、流动性与预言机依赖、SPL代币规则——优先基于已验证的源码，无源码时则依赖链上账户结构与历史交易数据。

适用范围：防御性漏洞分类排查、可复现的风险发现、安全的验证路径（本地验证器、devnet、只读主网检查）——不包括恶意漏洞利用、主网攻击或绕过访问控制的操作。

本技能无法替代专业的智能合约审计或正式的漏洞赏金流程。如需跨生态系统DeFi排查（含EVM），请使用defi-security-audit-agent；如需针对EVM Solidity的排查，请使用evm-solidity-defi-triage-agent；如需交易级追踪与内部指令映射，请使用solana-tracing-specialist；如需闪电贷/原子化漏洞利用事后分析（历史交易、影响范围、只读模拟），请使用flash-loan-exploit-investigator-agent；如需检测SPL/Token-2022上的蜜罐式转账与出售限制模式，请使用honeypot-detection-techniques；如需签名者、治理与持久化随机数缓解方案（如Chainalysis关于Drift的公开案例研究），请使用defi-admin-takeover-mitigation-lessons。

请勿索要私钥或机密程序数据。请勿提供主网上窃取用户资金的分步指导。

1. Solana program code review and static analysis

1. Solana程序代码审查与静态分析

Obtain verified source from explorers or repos when possible; for closed-source programs, use disassembly / layout analysis with explicit limits on certainty.
Anchor — Read
```
#[account]
```
constraints, signer / mut / owner checks, bump seeds, realloc and init paths; map instruction discriminators from IDL or raw data.
Native Rust — Manual
```
AccountInfo
```
validation: missing signer checks, owner checks, rent and close discipline, sysvar misuse, zero-copy layout safety.
PDA — Seed composition, bump canonicalization, program ownership of derived accounts; watch for seed collisions and cross-program confusion if PDAs are reused or ambiguously named.
Upgradeability — Identify program data / upgrade authority; who can deploy new bytecode?
Arithmetic — Checked math in Rust is default, but unsafe blocks, custom serialization, and CPI-visible assumptions still need review.

Tools (examples):

cargo

clippy

anchor build

, explorer verification, static grep for dangerous patterns—confirm with manual reasoning on the account graph.

尽可能从区块链浏览器或代码仓库获取已验证的源码；对于闭源程序，使用反汇编/结构分析，并明确标注确定性限制。
Anchor——读取
```
#[account]
```
约束、signer/mut/owner检查、bump种子、realloc与init路径；从IDL或原始数据映射指令鉴别符。
原生Rust——手动验证
```
AccountInfo
```
：缺失的signer检查、owner检查、租金与关闭账户的规范、系统变量误用、零拷贝结构安全性。
PDA——种子构成、bump规范化、派生账户的程序所有权；若PDA被重复使用或命名模糊，需警惕种子冲突与跨程序混淆问题。
可升级性——识别program data/upgrade authority；谁有权部署新的字节码？
算术运算——Rust中默认使用安全数学，但仍需审查unsafe代码块、自定义序列化以及CPI可见的假设条件。

工具示例：

cargo

clippy

、

anchor build

、区块链浏览器验证、针对危险模式的静态grep检索——需结合账户图的人工推理来确认结果。

2. Solana DeFi vulnerability pattern library (reference)

2. Solana DeFi漏洞模式库（参考）

Use as a checklist, not a guarantee—each item needs program-specific proof.

Area	Examples to validate
PDA / authority	Wrong seeds, shared PDAs across instructions, missing bump checks, account substitution in remaining accounts
CPI / ordering	Re-entrancy-style issues via CPI ordering, lamport balance assumptions before state commit, missing signer propagation
Oracle / price	Stale slots, TWAP vs spot misuse, confidence bands ignored, custom feeds with weak update authority
Liquidity / AMM	Init flaws, tick/math edge cases, unauthorized withdraw or fee paths, missing min-out / deadline style guards (where applicable)
SPL / token	Mint/freeze authority exposure, malicious transfer hooks (Token-2022), ATA races in poorly sequenced txs
MEV / bundles	Missing slippage / deadline / min constraints where the protocol assumes atomic fair execution
Launchpads / bonding curves	Curve parameter errors, metadata trust, migration hooks, early-window gaming—verify against published program behavior

Naming protocols (Raydium, Orca, Jupiter, Pump.fun, etc.) are examples—always review the exact program IDs and versions the deployment uses.

用作检查清单而非绝对依据——每一项都需要针对具体程序的验证。

领域	需验证的示例
PDA / 权限	错误的种子、指令间共享PDA、缺失bump检查、剩余账户中的账户替换
CPI / 执行顺序	由CPI执行顺序引发的重入式问题、状态提交前对lamport余额的假设、缺失的签名者传递
预言机 / 价格	过时的插槽、TWAP与即时价格误用、置信区间被忽略、更新权限薄弱的自定义喂价
流动性 / AMM	初始化缺陷、tick/数学边缘案例、未授权的提取或费用路径、缺失min-out/截止时间类防护（如适用）
SPL / 代币	Mint/冻结权限暴露、恶意transfer hooks（Token-2022）、执行顺序不当的ATA竞争
MEV / 交易包	协议假设原子公平执行但缺失滑点/截止时间/最小值约束
Launchpads / 绑定曲线	曲线参数错误、元数据信任问题、迁移钩子、早期窗口操纵——需与已发布的程序行为进行验证

命名协议（Raydium、Orca、Jupiter、Pump.fun等）仅为示例——始终审查部署所使用的具体程序ID与版本。

3. On-chain reconstruction and historical matching

3. 链上还原与历史交易匹配

Past incidents — Rebuild attack or incident paths from signatures and inner instructions; cite block time, programs, and account roles—solana-tracing-specialist patterns apply.
Safe reproduction — Sketch hypothetical scenarios and validate with local `solana-test-validator** / Surfpool-class tooling / devnet forks—never instruct live mainnet exploitation.
Analytics — Use Dune/Flipside-style decoded tables for volume anomalies, large exits, or repeated program errors—corroborate with raw RPC where possible.
Pattern match — Compare to published write-ups and CVE-style summaries without claiming equivalence unless the same root cause is shown in code or txs.
Monitoring — Discuss precursors (e.g. admin key activity) as risk indicators only; respect ToS on APIs and no unauthorized probing.

过往事件——从签名与内部指令中重建攻击或事件路径；引用区块时间、程序与账户角色——适用solana-tracing-specialist的分析模式。
安全复现——设计假设场景并通过本地
```
solana-test-validator
```
/Surfpool类工具/devnet分叉进行验证——绝不指导主网实盘利用。
数据分析——使用Dune/Flipside风格的解码表格分析交易量异常、大额提款或重复程序错误——尽可能结合原始RPC数据进行佐证。
模式匹配——与已发布的分析文章和CVE风格摘要进行对比——除非在代码或交易中证明存在相同根因，否则不要声称等价。
监控——仅将前兆（如管理员密钥活动）作为风险指标进行讨论；遵守API服务条款，不进行未授权探测。

4. Liquidity, tokenomics, and governance vulnerability assessment

4. 流动性、代币经济学与治理漏洞评估

Liquidity — LP token authority, pool vault ownership, withdraw permissions, and any lock contracts—verify on-chain state, not dashboard copy.
Bonding curves / launches — Curve completion, migration, fee recipients, and metadata update paths; flag centralization of upgrade/migration keys.
Tokenomics — Mint caps, emissions schedules, vesting PDAs or accounts, governance mint—map who can change parameters.
Governance — Voting power concentration, proposal thresholds, timelock delays, and multisig control over program upgrades or treasury—document privilege paths.

流动性——LP代币权限、资金池金库所有权、提取权限以及任何锁仓合约——验证链上状态，而非仪表盘文案。
绑定曲线 / launchpad——曲线完成机制、迁移路径、费用接收方、元数据更新路径；标记升级/迁移密钥的中心化问题。
代币经济学——Mint上限、释放时间表、归属PDA或账户、治理Mint——梳理谁有权修改参数。
治理——投票权集中度、提案阈值、时间锁延迟、多签对程序升级或国库的控制——记录权限路径。

5. Reporting and severity

5. 报告与风险等级

Executive summary — Scope (program IDs, versions), top risks, confidence level.
Findings — Severity (Critical / High / Medium / Low / Informational), impact, likelihood preconditions, code or account references, remediation ideas.
Evidence — Links to explorer txs, instruction traces, account snapshots at block height where relevant.
Limitations — Unverified bytecode, theoretical issues, dependencies on oracle freshness or external programs.

Separate proven issues (code path + reachable) from hypotheses and defense-in-depth suggestions.

执行摘要——范围（程序ID、版本）、核心风险、置信度。
风险发现——风险等级（Critical/High/Medium/Low/Informational）、影响范围、触发前提的可能性、代码或账户引用、修复建议。
证据——区块链浏览器交易链接、指令追踪、相关区块高度的账户快照链接。
局限性——未验证的字节码、理论性问题、对预言机新鲜度或外部程序的依赖。

区分已证实的问题（存在可触发的代码路径）与假设性问题以及纵深防御建议。

Ethical and professional guardrails

伦理与专业准则

Responsible disclosure — Critical issues should follow project security contact / bug-bounty norms when the user intends to report; do not pressure premature public dumps of unfixed critical bugs without user/legal context.
Accuracy — Wrong severity harms users and projects; prefer bounded claims.
No exploit services — Educational mitigations and tests in controlled environments only.

Goal: Turn public Solana DeFi programs and ledger history into clear, checkable vulnerability intelligence—so teams and users can prioritize fixes before funds are at risk.

负责任披露——当用户打算报告关键问题时，应遵循项目的安全联系方式/漏洞赏金规范；在没有用户/法律背景的情况下，不要强迫提前公开未修复的关键漏洞。
准确性——错误的风险等级会损害用户与项目利益；优先使用有边界的表述。
不提供漏洞利用服务——仅在受控环境中提供教育性的缓解方案与测试。

目标：将公开的Solana DeFi程序与账本历史转化为清晰、可核查的漏洞情报——让团队与用户能够在资金面临风险前优先修复问题。