Detailed Instructions

Begin by analyzing the protocol's smart contract architecture. Use block explorers like Etherscan to trace all external calls made by the protocol's core contracts. Focus on dependencies for price feeds (e.g., Chainlink, Pyth), liquidity pools (e.g., Uniswap V3 pools, Curve gauges), and governance tokens used as collateral.

• Sub-step 1: Use a tool like Tenderly's Inspector or manually review verified contract code to list all address variables for oracles and external contracts.
• Sub-step 2: For DeFi lending protocols, identify the collateral factor and liquidation threshold for each asset, noting which are LP tokens or wrapped derivatives.
• Sub-step 3: Document the specific function signatures used for critical operations like getPrice(), exchangeRateStored(), or totalBorrows(). This reveals the data sources.

Tip: Pay special attention to dependencies that are themselves highly composable, like yield-bearing tokens (e.g., stETH, aTokens), as they introduce nested risk.

Detailed Instructions

Assess the oracle design for single points of failure. Determine if the protocol uses a single oracle (high risk) or a decentralized oracle network (DON) with multiple nodes. Check for the existence and parameters of circuit breakers or price update delay mechanisms.

• Sub-step 1: For Chainlink oracles, verify the minAnswer and maxAnswer thresholds in the aggregator contract. A stale price outside these bounds can cause a denial-of-service.
• Sub-step 2: Check the heartbeat and deviation threshold. A long heartbeat (e.g., 24 hours) increases exposure to market manipulation during stale periods.
• Sub-step 3: Test for flash loan attack vulnerability by calculating the capital required to move the price on the underlying DEX pool by a significant percentage (e.g., 5-10%).

javascriptCopy
// Example: Fetching Chainlink aggregator details
const aggregatorV3InterfaceABI = [{"inputs":[],"name":"latestRoundData","type":"function"}];
const aggregator = new ethers.Contract(aggregatorAddress, aggregatorV3InterfaceABI, provider);
const roundData = await aggregator.latestRoundData();
// roundData.answer contains the price

Tip: A common failure mode is oracle manipulation on a low-liquidity pool, leading to incorrect liquidations or borrowing.

Detailed Instructions

Calculate the exit liquidity available for the protocol's key assets. This is critical for assessing if users can withdraw funds or if liquidators can profitably close positions during stress. Use DeFi Llama or Dune Analytics dashboards to track Total Value Locked (TVL) and concentration.

• Sub-step 1: For a lending protocol, compare the total borrowable amount of an asset against the 24-hour trading volume on its primary DEX. A ratio above 10-20% indicates high slippage risk.
• Sub-step 2: Simulate a large withdrawal or liquidation. Use the DEX pool's constant product formula (x * y = k) to estimate the resulting price impact and slippage.
• Sub-step 3: Identify liquidity mining incentives. If a large portion of TVL is attracted by high APY emissions, its stability is low and likely to flee during the first sign of trouble.

Tip: Protocols with over-collateralized but illiquid assets (e.g., NFT-backed loans) face severe liquidation bottlenecks, making them vulnerable to market-wide deleveraging.

Detailed Instructions

Governance centralization and short timelocks can allow rapid, potentially harmful parameter changes. Analyze the distribution of governance token voting power and the process for emergency multi-sig actions.

• Sub-step 1: Check the protocol's documentation or Snapshot space for the governance threshold. A low threshold (e.g., 5% of token supply) increases risk of a hostile proposal passing.
• Sub-step 2: Verify the length of the timelock delay on the executor contract (e.g., 48-72 hours is standard). A delay under 24 hours is a red flag.
• Sub-step 3: Audit the emergency pause or shutdown function. Determine who holds the keys (e.g., a 4/7 multi-sig) and if it can be invoked unilaterally, which could freeze user funds.

solidityCopy
// Example: Checking a TimelockController delay in OpenZeppelin's contract
ITimelockController timelock = ITimelockController(0x...);
uint256 minDelay = timelock.getMinDelay();
// A minDelay of 172800 seconds equals 48 hours.

Tip: A protocol whose critical parameters (like collateral factors) can be changed instantly via admin key poses a direct risk to integrated protocols that depend on its stability.

Detailed Instructions

Determine if the protocol has a native insurance fund or uses a decentralized coverage protocol like Nexus Mutual or Sherlock. Scrutinize the capital adequacy and payout triggers, as most coverage excludes composability-related failures.

• Sub-step 1: Check the balance of the protocol's internal insurance fund (e.g., Aave's Safety Module, Compound's Reserves). Compare it to the protocol's total borrows; a ratio below 1-2% is typically insufficient.
• Sub-step 2: Review the coverage wording for external policies. Most explicitly exclude "frontend bugs," "oracle failure," and "governance attacks," which are common in composability exploits.
• Sub-step 3: Analyze the claims process. Is there a staking challenge period (e.g., 7 days)? This delay can be critical during a fast-moving crisis.

Tip: Insurance is often a reactive measure. A more robust assessment focuses on the protocol's circuit breaker design—automated mechanisms that pause specific functions during extreme volatility.