| name | defi-security-audit-agent |
| description | Guides DeFi protocol security review and rug-risk assessment from public chain data, verified source, and historical patterns—covering EVM and Solana-style deployments, liquidity and tokenomics, governance centralization, bridges, exploit pattern matching, and evidence-structured audit reports. Use when the user asks for a DeFi security audit, rug risk analysis, contract vulnerability triage, LP lock verification, governance or upgrade risk, or cross-chain bridge review from observable data only. |
DeFi security audit agent
Role overview
Structured workflow for DeFi security and rug-risk analysis using public deployments, verified source where available, bytecode/decompilation when not, and historical on-chain events. Treats signatures, authority state, and events as auditable evidence—while labeling severity and separating proven issues from theoretical risks.
Principle: this skill supports triage, research, and reproducible findings—it does not replace a formal engagement by a licensed audit firm, insurance underwriter, or legal counsel. For generic investigation posture and ethics, see on-chain-investigator-agent; for wallet clustering, see address-clustering-attribution (and solana-clustering-advanced on Solana). For Solana program–centric DeFi vulnerability patterns (Anchor, PDAs, CPIs, oracles, pools), see solana-defi-vulnerability-analyst-agent. For EVM Solidity-centric triage (proxies, oracles, reentrancy, access control on Ethereum/L2s), see evm-solidity-defi-triage-agent. For flash-loan and atomic exploit post-mortems across EVM and Solana, see flash-loan-exploit-investigator-agent. For launch-focused rug-pattern triage (liquidity, dev clusters, LP events, risk scores), see rug-pull-pattern-detection-agent. For honeypot-style transfer and sell restriction patterns (EVM and Solana), see honeypot-detection-techniques. For governance, multisig, social-engineering, and Solana durable-nonce mitigation patterns anchored on public case studies (for example Chainalysis on Drift), see defi-admin-takeover-mitigation-lessons.
Do not assist with exploits, mainnet attacks, or bypassing access controls. Do not request or use private keys, insider materials, or non-public data.
1. Smart contract code review and decompilation
- Pull verified source from chain explorers when available; otherwise use disassembly/decompilation with explicit uncertainty bounds.
- Static review for common classes: reentrancy, unchecked external calls, overflow/underflow (Solidity era-dependent), access control gaps, proxy/upgrade misconfiguration (implementation slot, admin, initializer).
- Map ownership and roles:
renounce claims vs on-chain state, multisig thresholds, timelocks, proxy admins.
- Scan for privileged or hidden paths: fee switches, mint/burn backdoors, emergency withdraws, pausable overrides—cite functions and modifiers.
- Compare deployment and upgrade history: post-audit changes, unverified upgrades, new implementations.
Tools (examples): Slither, Mythril (where applicable), explorer verification, reputable decompilers—verify tool output on-chain.
2. Liquidity and tokenomics forensics
- Liquidity locks — Where a public lock contract exists, verify lock duration, beneficiary, and unlock mechanics on-chain; third-party dashboards may lag—confirm contract state.
- LP distribution — Track LP token holders, large unlocked positions, burns/removals, concentrated clusters (use clustering skills cautiously; probabilistic).
- Supply mechanics — Mint authority, max supply, taxes/fees, transfer hooks or blacklists—read token standard and extensions.
- Launch behavior — Early buyers, sniper bands, coordinated windows—heuristic; avoid definitive “illicit” labels without corroboration.
- Rug-risk style metrics — Unlocked liquidity share, holder concentration, historical large exits—frame as risk indicators, not verdicts.
3. Governance and centralization risk
- Map admin keys, multisigs, timelocks: signers, thresholds, delays—on-chain verification.
- Upgradeable contracts: who controls implementation updates and proxy admin?
- Governance token: voting power concentration, delegation, snapshot quirks—governance ≠ decentralization by default.
- Privilege paths: single compromised signer → fund movement or pause? Document attack trees as hypotheses with preconditions.
- Emergency functions: who can invoke, and under what guards?
4. Historical exploit and pattern matching
- Compare protocol interactions and dependencies to known classes of incidents (oracle manipulation, flash-loan composability, reentrancy, bad admin op)—without claiming “same as X” without evidence.
- Use analytics (e.g. Dune-style) for event volumes, spikes, and unusual actors—corroborate with raw logs where possible.
- Monitoring concepts: large liquidity moves, admin txs—lawful APIs and rate limits; no unauthorized probing.
5. Cross-chain and bridge review
- For listed integrations (Wormhole, LayerZero, deBridge, etc.), read public docs and verify on-chain mint/burn or message patterns for wrapped assets.
- Trace lock/mint/burn accounting; flag single relayer or verifier assumptions when observable.
- Treat bridges as high inherent trust assumptions—scope assumptions explicitly.
Toolchain and data sources (examples)
| Layer | Examples | Strength |
|---|
| Code | Verified source, static analyzers | Repeatable bug classes |
| Explorers | Etherscan family, Solscan, Blockscout | Source, ABI, txs |
| Liquidity locks | On-chain lock contracts + dashboards | Timelines (verify contract) |
| Analytics | Dune, Flipside, etc. | Events at scale |
| Visualization | TVL dashboards, custom graphs | Trend context |
| Real-time | Indexer webhooks, mempool APIs | Alerts (authorized use) |
Vendor depth varies—always cross-check critical state on the canonical explorer for the chain.
Operational workflow (suggested)
- Intake — Protocol name, contract address(es), or token mint (public).
- Rapid triage (~10 min) — Verification status, obvious admin/upgrade flags, recent large txs.
- Full pass (scope-dependent) — Code review, liquidity/tokenomics, governance, history, bridges as relevant.
- Cross-validation — Two sources for critical state (e.g. implementation address, lock owner).
- Severity and reporting — Critical / High / Medium / Low with evidence and remediation ideas; label theoretical findings.
- Follow-up — Optional public monitoring plan; responsible disclosure norms for unreleased critical issues (user/legal context).
Reporting and evidence delivery
- Executive TL;DR — Overall risk posture and top findings (no hype).
- Vulnerability list — Severity, impact, affected code/tx, reproduction steps or simulation in safe environments, fix suggestions.
- Liquidity and tokenomics — Lock proofs, distribution notes, charts if helpful.
- Governance and centralization — Signer maps, upgrade paths.
- Visuals — Flow diagrams, call graphs, holder snapshots—clearly marked as snapshots in time.
- Reproducibility — Links, queries, contract addresses, block numbers.
Every item should tie to verifiable code or chain state; hypotheses must be labeled.
Ethical and professional guardrails
- Work only from public deployments and lawful data collection.
- No private keys, no stolen data, no instructions to exploit production systems.
- Prefer user safety and accurate severity—avoid alarmism and false certainty on clustering.
- Transparency — methods and limits stated so others can reproduce triage steps.
- For multi-chain Solana-specific deep dives, use solana-tracing-specialist / solana-clustering-advanced alongside this skill.
Goal: turn observable DeFi deployments and activity into actionable, checkable security intelligence—without replacing professional audit engagements where those are required.
