Smart Contract Risk - Advanced Analysis

Understanding what's in an audit report:

TYPICAL AUDIT REPORT STRUCTURE

1. Executive Summary

1. Scope

1. Methodology

1. Findings

1. Team Response

1. Appendices

Not all findings are equal:

FINDING SEVERITY ANALYSIS

Critical (Immediate action required):
├── Direct loss of funds possible
├── Protocol can be broken
├── Exploitable now
├── MUST be resolved before deployment
└── If outstanding: Do not invest

High (Significant risk):
├── Loss of funds under specific conditions
├── Significant functionality compromise
├── Requires specific but plausible scenario
└── Should be resolved; concerning if not

Medium (Moderate risk):
├── Limited impact exploits
├── Unlikely attack vectors
├── Partial functionality issues
└── Should be addressed but not blocking

Low (Minor issues):
├── Best practice violations
├── Gas optimizations missed
├── Edge cases with minimal impact
└── Nice to fix; not concerning

Informational:
├── Code style
├── Documentation suggestions
├── No security impact
└── Not risk-relevant

WHAT TO LOOK FOR:
├── Number of Critical/High findings
├── Were they all resolved?
├── Quality of resolution (real fix vs workaround)
├── Were any disputed? (team accountability)
└── Pattern of findings (systemic issues?)

How the team handles findings reveals character:

TEAM RESPONSE EVALUATION

Positive Indicators:
├── All Critical/High resolved
├── Clear explanations of fixes
├── Acknowledged valid concerns even if not fixed
├── Requested re-audit of fixes
├── Transparent about timeline
└── No defensive or dismissive responses

Negative Indicators:
├── Outstanding Critical/High findings
├── Disputed valid findings
├── Defensive or dismissive tone
├── No re-audit after fixes
├── Vague or incomplete responses
└── "We'll fix it later" without timeline

- All Critical/High resolved + re-audit: +2 to security score
- All Critical/High resolved: +1
- Some High outstanding but addressed: +0
- Critical outstanding: -3 (consider avoiding)
- Disputed valid findings: -2

Audits have limitations:

AUDIT LIMITATIONS

Time constraints:
├── 2-4 week audits can't catch everything
├── Complex protocols need more time
├── Budget limits audit thoroughness
└── "Good enough for scope" ≠ complete

Scope limitations:
├── Only audited contracts in scope
├── External dependencies often excluded
├── Upgrade mechanisms sometimes excluded
├── Integration testing limited
└── READ THE SCOPE CAREFULLY

Point-in-time:
├── Audit is for specific commit
├── Code changes after audit = unaudited
├── Upgrades bypass original audit
└── Check if code matches audited version

Economic design:
├── Most audits focus on code, not design
├── Death spiral potential not always assessed
├── Tokenomics review often superficial
├── Economic exploits require different expertise
└── Code can be perfect; design can still fail

Novel attacks:
├── Auditors know known attack patterns
├── New attack types emerge
├── Can't audit for unknown unknowns
└── Time reveals new vulnerabilities

Composability:
├── Single contract safe in isolation
├── Combinations can be exploitable
├── External contract changes affect security
└── Hard to audit all interaction possibilities

---

The classic DeFi exploit:

REENTRANCY ATTACKS

How it works:
├── Contract A calls external Contract B
├── Contract B calls back into A before A finishes
├── A's state not yet updated
├── B can repeat action (drain funds)
└── The DAO hack ($60M, 2016)

1. Check balance
2. Send funds (external call)
3. Update balance

1. Check balance
2. Update balance
3. Send funds (external call)

What to look for:
├── External calls before state updates
├── Callbacks to untrusted contracts
├── Missing reentrancy guards
├── Cross-function reentrancy
└── Read-only reentrancy (newer variant)

Mitigation indicators:
├── ReentrancyGuard / nonReentrant modifier
├── Checks-Effects-Interactions pattern
├── Pull over push for payments
└── Audit explicitly checked for reentrancy

Price feed exploitation:

ORACLE MANIPULATION ATTACKS

How it works:
├── Protocol relies on price feed
├── Attacker manipulates price temporarily
├── Protocol acts on false price
├── Attacker profits from mispriced action
└── Often combined with flash loans

Common targets:
├── Spot prices from DEX pools
├── Single-source oracles
├── Low-liquidity price feeds
├── Any price-dependent action

1. Flash loan large amount
2. Trade to move spot price
3. Interact with victim protocol (at wrong price)
4. Trade back to restore price
5. Repay flash loan + profit

What to look for:
├── Price source (spot vs TWAP vs oracle)
├── Manipulation resistance
├── Multiple oracle sources
├── Circuit breakers for price deviation
└── Minimum liquidity requirements

Mitigation indicators:
├── Chainlink or similar decentralized oracles
├── TWAP (Time-Weighted Average Price)
├── Multiple oracle sources with aggregation
├── Deviation checks (reject extreme prices)
└── Flash loan resistance measures

Who can do what:

ACCESS CONTROL VULNERABILITIES

How it works:
├── Functions accessible to wrong parties
├── Missing authorization checks
├── Default permissions too broad
├── Admin functions callable by anyone
└── Initialization not protected

Common patterns:
├── Missing onlyOwner modifiers
├── Public functions that should be internal
├── Unprotected initializers
├── Privilege escalation paths
└── Hardcoded admin addresses

What to look for:
├── Who can call each function?
├── What can admin do?
├── Can admin be compromised?
├── Are there backdoors?
└── Initialization protection

Mitigation indicators:
├── Clear role-based access control
├── Minimal admin privileges
├── Time locks on sensitive actions
├── Multi-sig for admin operations
└── Privilege separation

Code that doesn't do what it should:

LOGIC AND MATH VULNERABILITIES

Types:
├── Integer overflow/underflow
├── Rounding errors
├── Division by zero
├── Off-by-one errors
├── Incorrect operator usage
├── Wrong variable used
└── State machine errors

Specific math issues:
├── Precision loss in calculations
├── Order of operations errors
├── Incorrect fee calculations
├── Supply/balance mismatches
└── Reward calculation errors

What to look for:
├── Complex mathematical operations
├── Division operations (potential precision loss)
├── Unchecked arithmetic (Solidity 0.8+ has checks)
├── External value inputs without bounds
└── Complex state machines

Mitigation indicators:
├── Solidity 0.8+ (built-in overflow checks)
├── SafeMath library (older contracts)
├── Extensive test coverage
├── Formal verification
└── Math audited by specialists

Instant capital exploitation:

FLASH LOAN ATTACKS

How it works:
├── Borrow any amount with no collateral
├── Use funds within single transaction
├── Exploit some vulnerability
├── Return borrowed amount + fee
└── Keep profit

Why flash loans matter:
├── Any attacker has unlimited capital
├── Can manipulate any market
├── Economic exploits become feasible
├── Attack cost: just gas fees
└── Democratizes sophisticated attacks

Common combinations:
├── Flash loan + oracle manipulation
├── Flash loan + governance attack
├── Flash loan + arbitrage exploit
├── Flash loan + liquidation manipulation
└── Flash loan + price impact attacks

What to look for:
├── Price dependencies (manipulatable?)
├── Governance with token voting (flashable?)
├── Liquidation mechanisms (gameable?)
├── Arbitrage assumptions (breakable?)
└── Any atomic transaction exploits

Mitigation indicators:
├── TWAP instead of spot prices
├── Time-locked governance
├── Minimum holding periods
├── Transaction segregation
└── Flash loan guards

---

Time reduces (but doesn't eliminate) risk:

TIME-BASED RISK MODEL

The concept:
├── Longer a contract operates without exploit
├── More confidence it doesn't have (known) vulnerabilities
├── Unknown vulnerabilities may still exist
├── Time = stress test by real usage and attackers
└── Lindy Effect: Expected future lifespan = past lifespan

Risk decay model:
Initial risk: R₀ (based on audit quality, complexity, etc.)
Risk at time t: R(t) = R₀ × e^(-λt)

Where λ = decay rate (depends on TVL, usage, scrutiny)

Practical interpretation:
├── Month 1: Still very risky (100% of initial risk)
├── Month 6: Moderate risk reduction (~70% of initial)
├── Month 12: Meaningful risk reduction (~50% of initial)
├── Month 24: Significant risk reduction (~30% of initial)
├── Month 48+: Mature protocol (~15-20% of initial)
└── Never reaches zero

IMPORTANT CAVEATS:
├── New code resets the clock
├── High TVL attracts more scrutiny (faster decay)
├── Low TVL means less testing (slower decay)
├── Upgrades introduce new risk
└── External dependency changes matter

PRACTICAL TIME RISK SCORING

Time Factor Multiplier:
├── < 1 month: ×1.5 (elevated risk)
├── 1-3 months: ×1.2
├── 3-6 months: ×1.0 (baseline)
├── 6-12 months: ×0.85
├── 12-24 months: ×0.70
├── 24-36 months: ×0.60
├── 36-48 months: ×0.55
└── 48+ months: ×0.50

TVL Factor Multiplier:
├── < $1M TVL: ×1.2 (less scrutiny)
├── $1-10M: ×1.0
├── $10-100M: ×0.9
├── $100M-1B: ×0.8
├── > $1B: ×0.75 (high scrutiny, big target)
└── High TVL = more attention from whitehats and blackhats

Code Change Impact:
├── No changes: Maintain time credit
├── Minor changes (non-critical): -25% time credit
├── Moderate changes: -50% time credit
├── Major changes: Reset to 3-month level
├── Core logic changes: Reset to 1-month level
└── Track code changes carefully

EXAMPLE CALCULATION:
Base risk: 15% annual probability of significant exploit
Time: 18 months (×0.70)
TVL: $50M (×0.9)
No code changes

Adjusted risk: 15% × 0.70 × 0.9 = 9.45%

Lower but still meaningful.
```

TIME-ADJUSTED POSITION SIZING

Concept:
├── New protocols: Smaller positions
├── Mature protocols: Larger positions (all else equal)
├── Time factor adjusts maximum allocation
└── Never use time to justify ignoring other risks

Position adjustment formula:
Max Position = Base Max × Time Factor

Example:
├── Protocol score: 7.0 → Base max: 12.3%
├── Age: 3 months → Time factor: 0.8
├── Adjusted max: 12.3% × 0.8 = 9.8%
└── Further reduce if other concerns exist

Time-based allocation tiers:
├── < 3 months: Max 5% regardless of score
├── 3-6 months: Max 10% regardless of score
├── 6-12 months: Max 15% regardless of score
├── > 12 months: Full score-based limit applies
└── Protect against unknown unknowns in new code
```

---

Most DeFi protocols are upgradeable:

PROXY CONTRACT BASICS

What is a proxy:
├── User interacts with Proxy contract
├── Proxy delegates to Implementation contract
├── Implementation can be changed
├── State stays in Proxy
└── Logic can be upgraded

Why protocols use proxies:
├── Fix bugs after deployment
├── Add features
├── Improve efficiency
├── Respond to market changes
└── Regulatory compliance updates

The risk:
├── Upgrades can introduce bugs
├── Upgrades can be malicious
├── Previous audits no longer apply
├── Who controls upgrades = who controls protocol
└── "Immutable" blockchain is actually mutable

Common patterns:
├── Transparent Proxy (most common)
├── UUPS Proxy
├── Beacon Proxy
├── Diamond (EIP-2535)
└── Each has different characteristics

UPGRADE RISK ASSESSMENT

Factor 1: Who controls upgrades?
├── Single EOA: Extreme risk (score 1-2)
├── Multisig (3/5): Moderate risk (score 4-5)
├── Large multisig (5/9+): Lower risk (score 6-7)
├── Governance vote: Variable (depends on process)
├── No upgrade possible: Lowest risk (score 9-10)
└── Fewer controllers = more risk

Factor 2: Time lock duration
├── No time lock: Instant changes = extreme risk
├── 24-48 hours: Minimal (some response time)
├── 7 days: Better (can exit if concerned)
├── 14+ days: Good (community can react)
├── 30+ days: Excellent (rare)
└── Time lock = warning before changes

Factor 3: Upgrade transparency
├── Upgrades without announcement: Red flag
├── Upgrades announced but not explained: Concerning
├── Detailed upgrade explanations: Good
├── Community review before upgrade: Excellent
├── Upgrade audited before deployment: Best practice
└── Transparency indicates professionalism

UPGRADE RISK SCORE CALCULATION:
Control score (0-10) × 0.40 +
Time lock score (0-10) × 0.35 +
Transparency score (0-10) × 0.25
= Upgrade risk score
```

UPGRADE MONITORING

What to monitor:
├── Implementation contract changes
├── Admin key transfers
├── Governance proposals
├── Time lock countdowns
└── Unusual admin activity

Tools and methods:
├── Etherscan / block explorers: Watch admin addresses
├── Protocol governance forums: Proposal tracking
├── Social media: Team announcements
├── Specialized monitoring: Services like Tenderly
└── On-chain alerts: Custom monitoring scripts

Response to upgrade:
├── Small change, explained, audited: Monitor
├── Moderate change, not audited: Reduce position
├── Major change: Exit until comfortable
├── Unexplained change: Exit immediately
├── Suspicious activity: Exit immediately
└── Err on the side of caution
```

---

DeFi's strength is also its weakness:

COMPOSABILITY EXPLAINED

What it means:
├── Protocols interact with each other
├── Your position depends on multiple contracts
├── A yields B, B interacts with C, C uses oracle D
├── Failure in any component affects you
└── "Money legos" can collapse

Why it's risky:
├── Each integration adds risk
├── Risks multiply, not add
├── Hard to assess total risk surface
├── Changes in one protocol affect others
├── Testing all combinations is impossible

Common composability stacks:
├── AMM → Yield optimizer → Your position
├── Lending protocol → Uses oracle → Uses DEX for liquidation
├── Stablecoin → Backed by LP tokens → LP tokens in AMM
└── Each layer depends on layers below

COMPOSABILITY RISK FRAMEWORK

Step 1: Map the dependency tree
├── What does my position directly interact with?
├── What do those contracts interact with?
├── What oracles are used?
├── What liquidity sources are assumed?
└── Draw the full tree

Step 2: Identify failure modes
For each dependency:
├── What happens if it fails?
├── What happens if it's exploited?
├── What happens if it pauses?
├── What happens if liquidity disappears?
└── Can I still exit?

Step 3: Assess cumulative risk
├── If each component has 5% annual fail probability
├── And there are 3 independent components
├── Cumulative: 1 - (0.95)³ = 14.3%
├── Risk compounds; doesn't average
└── More dependencies = more total risk

Step 4: Evaluate exit paths
├── If component X fails, can I exit?
├── What's my loss in each failure scenario?
├── Are failure modes correlated?
└── What's my maximum loss?

COMPOSABILITY RISK SCORE:
├── Single protocol, minimal deps: Score 8-10
├── 2-3 well-established deps: Score 6-8
├── Multiple deps, some new: Score 4-6
├── Complex stack, unaudited integrations: Score 2-4
└── Deeply nested, unclear deps: Avoid
```

COMPOSABILITY RISK MITIGATION

Position sizing:
├── Complex stacks = smaller positions
├── Multiply risk factors, not add
├── More layers = lower max position
└── Simplicity preference in sizing

Monitoring:
├── Monitor all dependencies, not just direct
├── Any component issue = your issue
├── Subscribe to announcements for all deps
└── Regular dependency review

Exit planning:
├── Know how to exit if each component fails
├── Have backup exit paths
├── Understand liquidation scenarios
├── Practice exits in small amounts

Selection preference:
├── Simpler architectures preferred
├── Fewer dependencies preferred
├── Well-established dependencies preferred
├── Avoid newest component in any stack
└── Redundancy where possible
```

---

✅ Audit reports contain valuable information. Reading them carefully reveals more than "pass/fail."

✅ Known attack patterns repeat. Understanding reentrancy, oracle manipulation, etc. enables risk assessment.

✅ Time without exploit is meaningful. Operational history provides evidence (not proof) of security.

⚠️ Novel attack vectors emerge. New exploitation techniques can affect previously-safe contracts.

⚠️ Composability risk is hard to quantify. The interaction surface is too large for complete analysis.

⚠️ Time decay rate varies. Different protocols have different appropriate decay rates.

📌 Audit = safe assumption. Many audited protocols have been exploited.

📌 Old = safe assumption. Old protocols with upgrades or dependency changes can have new risks.

📌 Complexity blindness. Not fully understanding what you're investing in.

Smart contract risk is real and has caused billions in losses. Professional analysis—reading audits critically, understanding attack vectors, applying time decay, and assessing composability—reduces but doesn't eliminate risk. The safest approach is smaller positions in complex protocols and careful monitoring of all dependencies.

---

Assignment: Conduct deep analysis of audit reports for a specific DeFi protocol.

Requirements:

• Choose a protocol you're considering
• Locate all available audit reports
• Note audit dates, auditors, and scope

Part 2: Audit Report Analysis

For each audit:

Factor	Finding
Auditor reputation (Tier 1/2/3)
Scope (what was/wasn't audited)
Critical findings (count)
High findings (count)
Team response quality
Re-audit performed?

Part 3: Attack Vector Assessment

Attack Type	Mitigations Present?	Evidence
Reentrancy
Oracle manipulation
Access control
Flash loan
Logic errors

• Time since deployment

• Code changes since audit

• Time factor multiplier

• TVL factor multiplier

• Adjusted risk estimate

• Upgrade mechanism type

• Who controls upgrades

• Time lock duration

• Upgrade history

• Upgrade risk score

• Dependency map (draw it)

• Failure modes for each dependency

• Cumulative risk estimate

• Exit path analysis

• Combined smart contract risk score

• Position sizing recommendation

• Key concerns to monitor

• Confidence level in assessment

• Audit analysis depth (20%)

• Attack vector assessment (20%)

• Time risk calculation (15%)

• Upgrade risk assessment (15%)

• Composability analysis (15%)

• Synthesis quality (15%)

Time investment: 2.5 hours

---

1. Audit Interpretation:

An audit found 2 critical and 5 high-severity issues, all marked as "resolved." The protocol launched 1 week after the audit. What's your assessment?

A) Safe—all issues were resolved
B) Concerning—no time for re-audit verification or operational testing
C) Moderate risk—the fixes may have introduced new bugs
D) Both B and C are valid concerns

Correct Answer: D

---

2. Time Risk:

A protocol has operated for 24 months without exploit, with $200M TVL. Last week, they upgraded core logic. What happened to the time-based risk?

A) Still low—24 months of safe operation
B) Reset to high—core logic changes restart the clock
C) Moderate—partial time credit retained
D) Unchanged—upgrades don't affect security

Correct Answer: B

---

3. Attack Vector:

A lending protocol uses the spot price from a DEX pool to determine collateral values. What attack should you be most concerned about?

A) Reentrancy
B) Oracle/price manipulation via flash loan
C) Access control
D) Integer overflow

Correct Answer: B

---

4. Composability Risk:

Your yield position depends on Protocol A (5% annual fail rate), which uses Oracle B (3% fail rate), and interacts with DEX C (4% fail rate). Assuming independence, what's approximately the cumulative annual failure probability?

A) 4% (average)
B) 12% (sum)
C) 11.5% (1 - 0.95 × 0.97 × 0.96)
D) 0.6% (product)

Correct Answer: C

---

5. Upgrade Risk:

A protocol has a 48-hour timelock on upgrades controlled by a 3/5 multisig. How would you rate the upgrade risk?

A) Very low—multisig and timelock provide strong protection
B) Moderate—48 hours gives some response time, but 3/5 multisig could be compromised
C) Very high—any upgrade capability is dangerous
D) None—timelock eliminates upgrade risk

Correct Answer: B

---

For Next Lesson:
Lesson 4 examines economic design risk—how to detect death spirals, evaluate yield sustainability, and stress-test economic mechanisms before they fail.

---

End of Lesson 3

Total words: ~5,300
Estimated completion time: 55 minutes reading + 2.5 hours for deliverable