Defi Risk Analysis

DeFi Risk Analysis Skill

Perform a comprehensive risk analysis of a DeFi protocol. This skill systematically evaluates smart contract risk, off-chain risk (governance, team, operations), and track record (historical incidents, battle-testing, response capability).

This is a structured risk analysis, NOT a formal smart contract audit — it reviews publicly available information and on-chain state to surface risk signals. Formal audits require line-by-line code review by professional auditing firms.

Input

The user provides one or more of:

• Protocol name (e.g., "Aave", "Drift", "GMX")
• Protocol website or DeFiLlama URL
• Contract addresses or chain

Workflow

Step 0: Quick Triage (Red Flag Scan)

Before deep analysis, run a quick triage to decide analysis priority:

1. DeFiLlama data check:

First, resolve the protocol name to the correct DeFiLlama slug (slugs are non-obvious, e.g., "maker" not "sky", "pancakeswap" not "pancake-swap"): ``bash # Fetch all protocols and fuzzy-match by name curl -s 'https://api.llama.fi/protocols' | jq -r '.[] | select(.name | test("{protocol}"; "i")) | "\(.slug) -- \(.name) -- TVL: \(.tvl)"' ` If no match, try partial name or check the protocol's website for its DeFiLlama listing. Then fetch full data with the resolved slug: curl -s 'https://api.llama.fi/protocol/{slug}'` to get:

• Current TVL and TVL history (sharp drops = red flag)
• Number of audits listed
• Chain(s)

1. GoPlus token security check: If the protocol has a governance/utility token on an EVM chain, run ./scripts/goplus-check.sh token or call the API directly:

``bash curl -s "https://api.gopluslabs.io/api/v1/token_security/?contract_addresses=" `` Extract these red flags from the response:

• is_honeypot = 1 -- token is a honeypot (CRITICAL)
• honeypot_with_same_creator = 1 -- creator has deployed honeypots (CRITICAL)
• is_open_source = 0 -- contract not verified (HIGH)
• hidden_owner = 1 -- hidden ownership mechanism (HIGH)
• owner_change_balance = 1 -- owner can modify balances (HIGH)
• selfdestruct = 1 -- contract can self-destruct (HIGH)
• can_take_back_ownership = 1 -- can reclaim ownership after renouncing (HIGH)
• is_proxy = 1 -- upgradeable proxy (MEDIUM, cross-reference with Step 2)
• is_mintable = 1 -- unlimited minting possible (MEDIUM)
• slippage_modifiable = 1 -- owner can change tax/slippage (MEDIUM)
• transfer_pausable = 1 -- transfers can be paused (MEDIUM)
• is_blacklisted = 1 -- has blacklist functionality (MEDIUM)

Also note: buy_tax, sell_tax, holder_count, lp_holders (lock status), and trust_list status.

Chain IDs: 1=Ethereum, 56=BSC, 137=Polygon, 42161=Arbitrum, 10=Optimism, 43114=Avalanche, 8453=Base, 324=zkSync. Solana is NOT supported by GoPlus token security API.

Solana token fallback: GoPlus does not support Solana SPL tokens. For Solana protocols, use these alternatives instead:

• RugCheck: curl -s 'https://api.rugcheck.xyz/v1/tokens/{mint_address}/report' -- returns risk score, mutable metadata, freeze authority, mint authority, top holders, LP lock status
• Birdeye: curl -s -H 'X-API-KEY: public' 'https://public-api.birdeye.so/public/token_security?address={mint_address}' -- holder concentration, LP info
• Manual checks: On Solana Explorer, verify: (1) mint authority (revoked = safer), (2) freeze authority (revoked = safer), (3) metadata mutability, (4) top holder concentration

Record the source as "RugCheck" or "Birdeye" instead of "GoPlus" in the report. If none of the alternatives return data, record "Solana Token Check: UNAVAILABLE" and note the gap.

Error handling: GoPlus is a free API with undocumented rate limits. If the API returns an error, empty result, or times out:

• Record "GoPlus: UNAVAILABLE" in the report rather than omitting the section
• Wait 5 seconds and retry once
• If still failing, proceed with the analysis without GoPlus data and note the gap in Information Gaps

1. GoPlus address check (optional): If specific admin/deployer addresses are known, check for malicious history:

``bash curl -s "https://api.gopluslabs.io/api/v1/address_security/?chain_id=" ` Flags: cybercrime, moneylaundering, phishingactivities, stealingattack, sanctioned, honeypotrelatedaddress, maliciousminingactivities, numberofmaliciouscontracts_created`.

1. Immediate red flags (any = escalate to CRITICAL triage):

• TVL = $0 or dropped >50% in 30 days
• No audits listed on DeFiLlama
• Protocol age $50M
• Anonymous team with no prior track record
• Closed-source contracts
• GoPlus: honeypot detected or creator has honeypot history
• GoPlus: hidden owner or owner can change balances
• GoPlus: admin/deployer address flagged as malicious

1. Quick Triage Score (compute for the report, 0-100):

``` Start at 100. Subtract EXACTLY the listed points for each flag that applies. Do NOT adjust, round, or add mitigating bonuses -- the score is mechanical.

CRITICAL flags (-25 each): [ ] GoPlus: ishoneypot = 1 [ ] GoPlus: honeypotwithsamecreator = 1 [ ] GoPlus: hiddenowner = 1 [ ] GoPlus: ownerchange_balance = 1 [ ] TVL = $0 [ ] Admin/deployer address flagged as malicious

HIGH flags (-15 each): [ ] Closed-source contracts (isopensource = 0) [ ] Zero audits listed on DeFiLlama [ ] Anonymous team with no prior track record [ ] GoPlus: selfdestruct = 1 [ ] GoPlus: cantakeback_ownership = 1 [ ] No multisig (single EOA admin key) [ ] Single bridge provider for cross-chain deployments on 5+ chains (Kelp lesson) [ ] Lending/CDP protocol accepts LRT, bridge token, or synthetic asset as collateral without a binding per-asset cap (supplyCap $50M [ ] TVL dropped > 30% in 90 days [ ] Multisig threshold 5%, concerning: = 3.0 = LOW | 1.5-2.99 = MEDIUM | 30% of collateral AND insurance 10% of collateral AND insurance insurance, (d) single native asset > 50% of collateral AND insurance 50% of collateral AND insurance ≥ largest exposure (concentrated-but-insured native pool) | | LOW | All collateral is native (ETH, BTC, on-chain stablecoins), no single asset > 50% of collateral, AND insurance ≥ largest exposure |

Notes:

• The CRITICAL row requires BOTH protections missing (no rate limit AND no circuit breaker) on top of the >30% / underinsured conditions; missing exactly one protection stays at HIGH. This is the intentional reading of the AND.
• A protocol with a single native asset (e.g., wstETH-dominant) at >50% of collateral and insurance &apikey="

# Arbiscan (Arbitrum) curl -s "https://api.arbiscan.io/api?module=contract&action=getsourcecode&address=&apikey=" ```

1. GitHub: Search for the protocol's contract repository.

• Search: "{protocol}" smart contracts site:github.com
• Common patterns: github.com/{org}/contracts, github.com/{org}/{protocol}-core

1. Audit reports: If no public repo exists, check if audit reports contain code snippets or contract interfaces.

Record source availability: "Full source (GitHub + verified)", "Partial (verified on explorer only)", "Closed source".

5.4.2 Admin & Access Control Patterns

Search the source code for these patterns. Each finding should cross-reference the governance analysis from Step 2.

Owner/admin functions — search for functions that can modify critical state:

Search for: onlyOwner, onlyAdmin, onlyRole, onlyGovernance, _checkRole, requiresAuth
Search for: function set*, function update*, function change*, function pause, function unpause
Search for: function upgrade*, function migrate*, _authorizeUpgrade

For each admin function found, document:

• What it can do (change parameters, pause, upgrade, drain)
• What access control guards it (Ownable, AccessControl role, custom modifier)
• Whether it has a timelock wrapper or can be called directly
• Whether it matches claims from Step 2 (e.g., "team claims 48h timelock" — verify the timelock is actually enforced in code)

Proxy upgrade pattern — identify which pattern is used:

Search for: TransparentUpgradeableProxy, UUPSUpgradeable, _authorizeUpgrade, ERC1967Upgrade
Search for: Diamond, DiamondCut, LibDiamond (EIP-2535)
Search for: Beacon, BeaconProxy, UpgradeableBeacon

• UUPS: upgrade logic is in the implementation — check _authorizeUpgrade for access control
• Transparent: upgrade logic is in the ProxyAdmin — check who owns ProxyAdmin
• Diamond: facets can be added/removed — check who controls diamondCut

Emergency/bypass roles — verify claims about emergency powers:

Search for: emergency, guardian, pauser, EMERGENCY_ROLE, GUARDIAN_ROLE
Search for: delay, setDelay, updateDelay, minDelay, getMinDelay

• Does the emergency role only pause, or can it upgrade/drain?
• Can the timelock delay be set to 0? By whom?

5.4.3 Common Vulnerability Patterns

Scan for these high-impact patterns:

Reentrancy:

Search for: .call{value:, .call(, (bool success,) =
Check: Is there a reentrancy guard (nonReentrant, ReentrancyGuard)?
Check: Does the contract follow checks-effects-interactions pattern?

Flag if: external calls are made before state updates, AND no reentrancy guard exists.

Oracle manipulation:

Search for: getPrice, latestAnswer, latestRoundData, getUnderlyingPrice, twap, TWAP
Search for: slot0 (Uniswap V3 spot price — manipulable via flash loans)

Flag if: spot price is used without TWAP protection, OR single oracle with no fallback.

Flash loan attack surface:

Search for: flashLoan, flashMint, IERC3156, IFlashLoanReceiver
Check: Can flash-loaned tokens be used as collateral or voting power in the same transaction?

Unchecked return values:

Search for: .transfer(, .send(, .approve(
Check: Are return values checked? (SafeERC20 usage = good)

Centralization in token contract:

Search for: mint(, burn(, _mint(, _burn(, blacklist, freeze, pause
Check: Who can call these? Is there a cap on minting?

5.4.4 Cross-Reference with Governance Claims

This is the most important part. Compare what the code actually does vs. what the team/docs claim:

| Claim from Step 2 | Code verification | Match? | |---|---|---| | "48h timelock on upgrades" | Check: is timelock enforced in proxy admin? Can it be bypassed? | | | "3/5 multisig controls admin" | Check: is the admin address actually the claimed multisig? | | | "Oracle uses Chainlink" | Check: is Chainlink actually imported and used? Any fallback? | | | "Insurance fund covers bad debt" | Check: does the liquidation flow actually transfer to insurance fund? | | | "Immutable core contracts" | Check: are there really no upgrade functions? No selfdestruct? | |

Record any discrepancies as HIGH or CRITICAL findings.

5.4.5 Report Format

Add to the Smart Contract Security section of the risk report:

#### Source Code Review

**Source availability**: [Full/Partial/Closed]
**Contracts reviewed**: [list of key contracts and addresses]

**Admin function inventory**:
| Function | Contract | Access Control | Timelock? | Impact |
|----------|----------|---------------|-----------|--------|

**Vulnerability scan**:
| Pattern | Found? | Details | Severity |
|---------|--------|---------|----------|

**Governance claim verification**:
| Claim | Code evidence | Verified? |
|-------|-------------|-----------|

**Source code review conclusion**: [summary of findings]

5.5 Audited vs Deployed Drift

The most commonly ignored smart-contract risk is that audited code is NOT what is running in production. This can happen in several ways:

• The team commissions an audit, then deploys a NEWER version that was never re-audited.
• A proxy's implementation is upgraded after the audit without a new audit round.
• The audit covers only a subset of the deployed contracts.
• The audit was performed on a commit that was never deployed (vaporware audit).

This sub-step cross-references what was audited against what is running. Skip only if (a) no audits exist OR (b) all contracts are closed-source AND not verified on any explorer.

5.5.1 Extract Audit Scope

From each audit report discovered in Step 1.5, record:

• Firm and date
• Commit hash / git tag reviewed (most reports state this in the Scope or Methodology section)
• Contracts in scope (list of file names or addresses)
• Findings status (how many fixed vs acknowledged vs unresolved)

If a report does NOT cite a commit or tag, flag as HIGH info gap — the audit cannot be independently reproduced or re-verified.

5.5.2 Post-Audit Upgrade Detection

For each known proxy contract on an EVM chain, check the implementation's deployment timestamp against the latest audit date.

./scripts/onchain-check.sh contract-age   [api_key]

Returns the creation timestamp of the contract AND (if it is a proxy) the current implementation's deployment timestamp.

Risk rating (use the CURRENT implementation's creation date):

• Implementation created BEFORE last audit date → LOW (audited code is running)
• Implementation created AFTER last audit but within 90 days of a re-audit announcement → LOW
• Implementation created AFTER last audit, NO re-audit → HIGH (post-audit drift)
• 3+ post-audit upgrades detected (scan proxy Upgraded events for a full history) → CRITICAL

To enumerate all historical upgrades for a proxy, query Upgraded(address) events via Etherscan's getLogs:

# EIP-1967 Upgraded event topic: 0xbc7cd75a20ee27fd9adebab32041f755214dbc6bffa90cc0225b39da2e5c2d3b
curl -s "https://api.etherscan.io/api?module=logs&action=getLogs&address={proxy}&topic0=0xbc7cd75a20ee27fd9adebab32041f755214dbc6bffa90cc0225b39da2e5c2d3b&apikey={key}"

Each log entry is an implementation change; the log timestamp is an upgrade event.

5.5.3 Source Diff (when audit commit is cited)

If the audit report cites a commit and the deployed source is verified on Etherscan:

1. Clone the repo at the audited commit: git clone {repo} && git checkout {commit}
2. Fetch Etherscan's verified source (returned by the etherscan subcommand of onchain-check.sh) and save it as local files.
3. Compare file-by-file. Useful signals:

• File set diff — are the deployed file names a superset/subset of the audit scope?
• Line count delta per file — flag >5% change.
• New admin functions — grep the deployed source for onlyOwner, onlyRole, _checkRole modifier uses that do NOT exist in the audited source. Any new admin function added post-audit is HIGH.
• New mint / upgrade / setOracle / setFeed functions — CRITICAL if added post-audit without re-audit.
• Removed checks — if require(...) statements decreased, scrutinize carefully.

This is approximate — not a formal audit. It catches obvious drift (new admin functions, removed checks, added backdoors) but can miss subtle logic changes. For definitive matching, compile the audited commit with the same solc version + optimizer settings and compare bytecode; that is out of scope for this skill.

5.5.4 Report Format

Populate sub-category A.2 Audited vs Deployed Drift in the Risk Summary using this format:

#### A.2 Audited vs Deployed Drift

| Audit | Date | Commit Cited | Scope | Deployed Match? |
|---|---|---|---|---|
| Trail of Bits | 2024-08-15 | a1b2c3 | Vault, PriceFeed | Partial |
| Certora | 2025-03-10 | d4e5f6 | Vault | Yes |

**Post-audit implementation changes**:
- Proxy 0x...abc: current impl deployed 2026-02-14 (6 months after Trail of Bits audit, no re-audit)
- Proxy 0x...def: matches audited commit

**Drift rating**: HIGH
**Justification**: Vault implementation upgraded 2026-02-14 with no re-audit announcement. Source diff shows 2 new `onlyOwner` functions (setFeeTier, setReserv

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [truenorth-lj](https://github.com/truenorth-lj)
- **Source:** [truenorth-lj/crypto-project-security-skill](https://github.com/truenorth-lj/crypto-project-security-skill)
- **License:** MIT

Install and usage instructions live in the source repository linked above.