plamentsv/centralization-risk

Skill: CENTRALIZATION_RISK

Trigger: Protocol has privileged roles (admin, owner, operator, governance, multisig) Covers: Single points of failure, privilege escalation, external governance dependencies Required: NO (optional -- recommended when protocol has 3+ distinct privileged roles)

Trigger Patterns

onlyOwner|onlyAdmin|onlyGovernance|DEFAULT_ADMIN_ROLE|OPERATOR_ROLE|timelock|multisig|governance

Reasoning Template

Step 1: Privilege Inventory

Enumerate ALL privileged functions using Slither (list_functions + analyze_modifiers):

| # | Function | Contract | Modifier/Role | What It Controls | Impact If Abused | |---|----------|----------|---------------|------------------|-----------------| | 1 | {func} | {contract} | {role} | {parameter/state} | {worst case} |

Categorize each by impact:

• FUND_CONTROL: Can move, lock, or destroy user funds
• PARAMETER_CONTROL: Can change fees, rates, thresholds, delays
• OPERATIONAL_CONTROL: Can pause, unpause, add/remove components
• UPGRADE_CONTROL: Can change contract logic

Step 2: Role Hierarchy and Separation

Map the role hierarchy:

| Role | Granted By | Can Grant Others? | Revocable? | Timelock? | |------|-----------|-------------------|-----------|-----------| | {role} | {grantor} | YES/NO | YES/NO | YES/NO ({duration}) |

Check:

• [ ] Are FUND_CONTROL and UPGRADE_CONTROL separated into different roles?
• [ ] Does any single role have both PARAMETER_CONTROL and FUND_CONTROL?
• [ ] Are role assignments behind timelocks?
• [ ] Can roles be revoked, and by whom?

Step 3: Single Points of Failure

For each privileged role:

| Role | Key Compromise Impact | Mitigation | Residual Risk | |------|----------------------|------------|---------------| | {role} | {what attacker can do} | {multisig? timelock? guardian?} | {what remains} |

Severity assessment:

• Single EOA with FUND_CONTROL -> HIGH centralization risk
• Multisig with FUND_CONTROL but no timelock -> MEDIUM
• Multisig + timelock with FUND_CONTROL -> LOW (but document)
• No FUND_CONTROL -> INFO

Step 4: External Governance Dependencies

Identify parameters or behaviors controlled by EXTERNAL governance:

| Dependency | External Entity | What They Control | Protocol Impact If Changed | Notification? | |------------|----------------|-------------------|---------------------------|---------------| | {dep} | {entity} | {parameter/behavior} | {impact on this protocol} | YES/NO |

Pattern: Protocol depends on external governance decisions (e.g., external protocol upgrades, token migrations, parameter changes) that can silently affect this protocol's behavior without any on-chain notification.

Check:

• Can external governance changes break protocol invariants?
• Does the protocol have circuit breakers for external changes?
• Are external governance timelines aligned with this protocol's operational timelines?

Step 5: Emergency Powers

Document emergency/pause capabilities:

| Emergency Function | Who Can Call | What It Affects | Recovery Path | Time to Recover | |-------------------|-------------|-----------------|---------------|-----------------| | {func} | {role} | {scope} | {how to resume} | {estimate} |

Check:

• [ ] Can pausing strand user funds permanently?
• [ ] Is there a maximum pause duration?
• [ ] Can users exit during pause (emergency withdraw)?
• [ ] If no exit during pause -> apply Rule 9 (stranded asset severity floor)

Output Schema

## Finding [CR-N]: Title

**Verdict**: CONFIRMED / PARTIAL / REFUTED
**Step Execution**: checkmark1,2,3,4,5 | xN(reason) | ?N(uncertain)
**Severity**: Critical/High/Medium/Low/Info
**Location**: Contract.sol:LineN

**Centralization Type**: FUND_CONTROL / PARAMETER_CONTROL / OPERATIONAL_CONTROL / UPGRADE_CONTROL
**Affected Role**: {role_name}
**Mitigation Present**: {multisig/timelock/guardian/NONE}

**Description**: What's wrong
**Impact**: What can happen if role is compromised or acts maliciously
**Recommendation**: How to mitigate (add timelock, separate roles, add guardian)

Step Execution Checklist

• [ ] Step 1: ALL privileged functions enumerated (via Slither, not manual scan)
• [ ] Step 2: Role hierarchy mapped with separation analysis
• [ ] Step 3: Single points of failure identified for each role
• [ ] Step 4: External governance dependencies documented
• [ ] Step 5: Emergency powers and recovery paths assessed