Governance and Upgrade Risk

GOVERNANCE CENTRALIZATION SPECTRUM

Level 1: Fully Centralized (Highest Risk)
├── Single admin key (EOA)
├── Instant upgrades possible
├── No time lock
├── No community input
├── Complete trust in single party
├── Risk score: 1-2/10
└── Examples: Early-stage protocols, scams

Level 2: Controlled Multisig (High Risk)
├── Small multisig (2/3 or 3/5)
├── Time lock 24-48 hours
├── Limited transparency
├── Team-controlled keys
├── Trust in small group
├── Risk score: 4-5/10
└── Examples: Many mid-tier protocols

Level 3: Distributed Governance (Moderate Risk)
├── Larger multisig (5/9+) or token voting
├── Time lock 7+ days
├── Public proposals
├── Community discussion period
├── Meaningful oversight
├── Risk score: 6-7/10
└── Examples: Established protocols

Level 4: Decentralized / Immutable (Lower Risk)
├── Wide token distribution
├── Time lock 30+ days
├── Robust proposal process
├── OR: Fully immutable (no upgrades)
├── Minimal trust required
├── Risk score: 8-10/10
└── Examples: Uniswap v2, mature protocols
```

CENTRALIZATION ASSESSMENT CHECKLIST

Admin Key Analysis:
□ Single EOA admin → HIGHEST RISK
□ Multisig, team-only keys → HIGH RISK
□ Multisig with external signers → MODERATE RISK
□ On-chain governance only → LOWER RISK
□ Immutable (no admin) → LOWEST RISK

Multisig Details:
├── Threshold: Higher = better (5/9 > 3/5 > 2/3)
├── Key diversity: Different entities > same team
├── Key storage: Hardware wallets > hot wallets
├── Geographic distribution: Multiple jurisdictions better
└── Signer reputation: Known entities > anonymous

Token Distribution (if governance token):
├── Top 10 holders < 50%: Decentralized
├── Top 10 holders 50-70%: Moderately concentrated
├── Top 10 holders > 70%: Highly concentrated
├── Team/investor allocation: Check vesting
└── Voting power concentration matters

CENTRALIZATION SCORE CALCULATION:
Admin type base score (1-10)

• Multisig quality adjustment (-2 to +2)
• Token distribution adjustment (-2 to +2)
  = Centralization score (cap 1-10)

GOVERNANCE POWERS ASSESSMENT

Critical Powers (most dangerous):
├── Upgrade contract logic
├── Change fee recipients
├── Modify collateral factors
├── Adjust liquidation parameters
├── Pause/unpause protocol
├── Emergency withdraw funds
└── Each critical power = trust requirement

Significant Powers:
├── Add/remove supported assets
├── Adjust interest rate models
├── Change oracle sources
├── Modify reward distributions
├── Update protocol parameters
└── Can significantly affect your position

Limited Powers:
├── Cosmetic changes
├── Minor parameter tweaks
├── Non-critical upgrades
├── Routine maintenance
└── Lower concern

POWER ANALYSIS:
For each governance power, ask:
├── What's the worst-case abuse?
├── How quickly could it affect me?
├── Would I have time to exit?
└── Is there any protection?
```

---

TIME LOCK MECHANICS

What is a time lock:
├── Delay between proposal and execution
├── Announced on-chain (transparent)
├── Cannot be bypassed (if properly implemented)
├── Gives users time to react
└── Critical protection mechanism

How it helps:
├── See changes before they happen
├── Exit if you disagree
├── Community can organize response
├── Malicious changes can be blocked (sometimes)
└── Window of opportunity

Limitations:
├── Only protects if you're watching
├── Can't prevent changes, only delay
├── Emergency functions may bypass
├── Social pressure period, not veto
└── Still requires your action
```

TIME LOCK DURATION SCORING

No time lock:
├── Changes are instant
├── No reaction time
├── Complete trust required
├── Risk score: 1/10
└── AVOID for material positions

24-48 hours:
├── Minimal warning
├── Must monitor constantly
├── Limited response time
├── Risk score: 4/10
└── Small positions only

7 days:
├── Reasonable warning
├── Time to assess and exit
├── Standard for many protocols
├── Risk score: 6/10
└── Adequate for most users

14 days:
├── Good warning period
├── Comfortable response time
├── Shows governance maturity
├── Risk score: 7/10
└── Good practice

30+ days:
├── Excellent protection
├── Full community review time
├── Rare and valuable
├── Risk score: 9/10
└── Best practice

MINIMUM RECOMMENDED:
├── For any material position: 7+ days
├── For core holdings: 14+ days preferred
├── Below 48 hours: Significant concern
└── No time lock: Consider it centralized
```

EMERGENCY FUNCTION ASSESSMENT

Common emergency powers:
├── Pause trading/deposits
├── Emergency withdraw
├── Parameter override
├── Oracle switch
└── May bypass time lock

Questions to ask:
├── What emergencies are covered?
├── Who can trigger emergency?
├── What can they do?
├── Is there any delay?
├── What oversight exists?

Acceptable patterns:
├── Pause only (can't drain funds): Lower risk
├── Pause with guardian multisig: Moderate risk
├── Full emergency powers to team: Higher risk
├── No emergency functions: Trade-off (no recovery either)

Risk scoring:
├── No emergency bypass: +1 (but trade-off)
├── Pause-only emergency: +0
├── Limited emergency powers: -0.5
├── Broad emergency powers: -1
├── Emergency with single key: -2
└── Adjust governance score accordingly
```

---

FLASH LOAN VOTING ATTACKS

How it works:
├── Flash loan governance tokens
├── Vote on malicious proposal
├── Return tokens in same transaction
├── No capital required
├── If successful, protocol drained or compromised

Example: Beanstalk ($182M)
├── Attacker flash loaned governance tokens
├── Passed proposal to drain treasury
├── Executed immediately
├── $182M stolen
└── No time lock on execution

PROTECTION INDICATORS:
├── Snapshot voting (off-chain, no flash loan possible)
├── Vote escrow (must lock tokens to vote)
├── Minimum holding period
├── Time lock on execution
├── Quorum requirements
└── Check what protections exist
```

PROPOSAL MANIPULATION ATTACKS

Attack types:

Vote buying:
├── Pay token holders to vote a certain way
├── Dark pools / OTC coordination
├── Bribes for governance votes
├── Hard to detect
└── Increasing sophistication

Quorum exploitation:
├── Proposals pass with low participation
├── Attacker needs only minority of tokens
├── Attack during low-attention periods
├── Weekend/holiday proposals
└── Check quorum requirements and typical turnout

Proposal spamming:
├── Flood governance with proposals
├── Cause voter fatigue
├── Sneak malicious proposal through
└── Monitor all proposals, not just featured

Social engineering:
├── Proposal appears benign
├── Hidden malicious effects
├── Complex technical changes
├── Exploit trust in proposal format
└── Read proposals carefully

PROTECTION ASSESSMENT:
├── Minimum proposal threshold (cost to propose)
├── Mandatory review period
├── Multiple voting phases
├── Community discussion requirements
├── Technical review process
└── Better processes = lower attack risk
```

GOVERNANCE ATTACK CASE STUDIES

Case 1: Beanstalk ($182M, April 2022)

Attack:
├── Attacker flash loaned Stalk (governance tokens)
├── Created malicious proposal
├── Voted with flash loaned tokens
├── Passed proposal instantly
├── Drained protocol

Vulnerabilities:
├── No snapshot voting (flash loanable)
├── Instant execution (no time lock)
├── Single proposal could drain treasury
├── Governance power too concentrated

Lessons:
├── Flash loan protection is essential
├── Time locks are essential
├── Treasury access needs extra safeguards
├── Quick governance ≠ good governance

Case 2: Build Finance (February 2022)

Attack:
├── Attacker accumulated governance tokens
├── Submitted proposal to transfer treasury
├── Passed with enough votes
├── Drained ~$470K

Vulnerabilities:
├── Low token distribution
├── Insufficient quorum
├── Treasury directly controllable
└── Classic governance takeover

Lessons:
├── Token distribution matters
├── Treasury should have extra protections
├── Quorum should be meaningful
└── Monitor token accumulation
```

---

MULTISIG SECURITY FRAMEWORK

Threshold Analysis:
├── 1/n: Single point of failure (avoid)
├── 2/3: Minimal redundancy
├── 3/5: Standard, acceptable
├── 4/7: Good redundancy
├── 5/9: Strong redundancy
└── Higher threshold = slower but safer

Signer Diversity:
├── All team members: Concentrated risk
├── Team + investors: Somewhat diverse
├── Team + external parties: Better
├── Independent security council: Best
├── Geographic diversity: Important
└── Entity diversity reduces collusion risk

Key Security:
├── Hot wallet signers: Higher risk
├── Hardware wallet required: Better
├── Institutional custody: Best practice
├── Key rotation policy: Important
└── Compromise recovery plan: Essential

MULTISIG SCORE CALCULATION:
Threshold score (1-5) +
Diversity score (1-3) +
Key security score (1-2)
= Multisig score (out of 10)

Example:
├── 4/7 threshold: 4 points
├── Team + external signers: 2 points
├── Hardware wallets required: 1.5 points
└── Total: 7.5/10
```

MULTISIG RED FLAGS

Critical concerns:
├── 1/n threshold (any single signer can act)
├── All signers from same entity
├── Signers not publicly known
├── No time lock on multisig actions
├── History of compromised keys
└── Any of these: Major red flag

Significant concerns:
├── 2/3 threshold (low redundancy)
├── Limited signer diversity
├── No key rotation policy
├── Hot wallet usage
├── No public multisig policy
└── Each: Moderate concern

Questions to investigate:
├── Who are the signers?
├── What entities do they represent?
├── What's their security setup?
├── Has the multisig ever been compromised?
├── What's the policy for signer changes?
└── Transparency is positive indicator
```

---

GOVERNANCE SECURITY COMPOSITE SCORE

Component scores (each 0-10):

Centralization Level:
├── Level 1 (single admin): 1-2
├── Level 2 (team multisig): 4-5
├── Level 3 (distributed): 6-7
├── Level 4 (decentralized): 8-10
└── Weight: 35%

Time Lock:
├── None: 1
├── 24-48 hours: 4
├── 7 days: 6
├── 14 days: 7
├── 30+ days: 9
└── Weight: 30%

Attack Resistance:
├── Vulnerable to flash loan voting: 2
├── Some protections: 5
├── Strong protections: 8
└── Weight: 20%

Multisig Quality (if applicable):
├── Poor configuration: 3
├── Standard: 6
├── Strong: 8
└── Weight: 15%

GOVERNANCE SCORE:
= (Centralization × 0.35) + (Time Lock × 0.30) +
(Attack Resistance × 0.20) + (Multisig × 0.15)
```

GOVERNANCE-ADJUSTED POSITION SIZING

Governance Score Impact:

8-10 (Decentralized/Protected):
├── No governance-specific reduction
├── Standard position sizing applies
└── Monitor governance proposals

6-8 (Moderate):
├── 10-20% position reduction
├── More active monitoring required
├── Know your exit path
└── Watch for governance changes

4-6 (Concerning):
├── 30-50% position reduction
├── Small positions only
├── Very active monitoring
└── Quick exit capability required

Below 4 (Centralized/Risky):
├── Minimal positions (< 2% portfolio)
├── Or avoid entirely
├── You're trusting a small group completely
└── Accept the trust or don't participate

INTEGRATION WITH OVERALL SCORING:
Governance score is 15% of total protocol score
But can be binding constraint:
├── If governance score < 4
├── Cap total score at 5
├── Regardless of other factors
└── Centralized governance = concentrated risk
```

GOVERNANCE MONITORING FRAMEWORK

What to monitor:
├── New proposals submitted
├── Voting activity and results
├── Time lock countdowns
├── Multisig transactions
├── Parameter changes
├── Token holder concentration changes
└── Team communications about governance

Alert triggers:

Level 1 (Informational):
├── New routine proposal
├── Normal parameter adjustment
├── Expected upgrade
└── Action: Review at next check

Level 2 (Warning):
├── Unusual proposal
├── Large parameter change
├── Multisig signer change
├── Large token transfer to new wallet
└── Action: Detailed review, prepare response

Level 3 (Critical):
├── Treasury-affecting proposal
├── Emergency function triggered
├── Unexpected upgrade
├── Multisig activity outside normal
├── Governance attack indicators
└── Action: Immediate assessment, consider exit

MONITORING TOOLS:
├── Protocol governance forums
├── On-chain monitoring (Tenderly, etc.)
├── Social channels (Discord, Twitter)
├── Governance aggregators (Tally, Snapshot)
└── Custom alerts for key addresses

---

✅ Governance attacks cause massive losses. Beanstalk, Build Finance, and others demonstrate real risk.

✅ Time locks provide meaningful protection. Users can exit before malicious changes take effect.

✅ Multisig configuration matters. Threshold, diversity, and security practices affect risk.

⚠️ Optimal governance structure. Trade-offs between decentralization and efficiency unclear.

⚠️ Attack sophistication evolution. New attack vectors continue emerging.

⚠️ Social layer attacks. Governance can be manipulated through social engineering.

📌 "Decentralized" marketing. Many protocols claim decentralization but have centralized control.

📌 Ignoring governance proposals. Users who don't monitor may be surprised by changes.

📌 Assuming benevolence. Even honest teams can be compromised or change priorities.

---

Assignment: Complete governance security assessment for two DeFi protocols.

Requirements:

1. Identify governance structure (centralization level)
2. Document time lock duration
3. Assess flash loan voting protection
4. Evaluate multisig configuration (if applicable)
5. Calculate governance security score
6. Determine position sizing implications
7. Create monitoring plan

Time investment: 2 hours

---

1. A protocol has a 3/5 team multisig with 48-hour time lock. What's the approximate governance risk level?
A) Low (decentralized) B) Moderate (some protection but concentrated) C) High (centralized) D) Cannot determine

Correct Answer: B

2. What's the minimum time lock for material DeFi positions?
A) 24 hours B) 48 hours C) 7 days D) 30 days

Correct Answer: C

3. How did Beanstalk lose $182M to governance attack?
A) Smart contract bug B) Flash loan voting with no time lock C) Oracle manipulation D) Multisig compromise

Correct Answer: B

---

End of Lesson 7