plamentsv/centralization-risk

CENTRALIZATION_RISK Skill (Solana)

Trigger Pattern: Protocol has privileged authorities (upgrade authority, admin, operator, governance, multisig) Inject Into: Breadth agents (optional), depth-state-trace Finding prefix: [CR-N] Rules referenced: R2, R6, R9, R10, R13 Required: NO (recommended when protocol has 3+ distinct privileged roles)

Covers: single points of failure, privilege escalation, program upgrade risk, external governance dependencies, emergency powers. On Solana, centralization risk has unique dimensions: BPFLoaderUpgradeable allows full program replacement, freeze authority can lock user token accounts, close authority can destroy accounts and their lamports, and PDA self-authority patterns can create hidden centralization.

---

Step 1: Privilege Inventory

Enumerate ALL privileged instructions by scanning for signer checks against stored authority pubkeys:

| # | Instruction | Program | Authority/Signer | What It Controls | Impact If Abused | |---|-------------|---------|------------------|------------------|-----------------| | 1 | {ix_name} | {program} | {authority pubkey field} | {parameter/state} | {worst case} |

Solana authority patterns to scan for:

• has_one = authority / has_one = admin / has_one = owner in Anchor account constraints
• require!(ctx.accounts.authority.key() == config.authority) manual checks
• Signer constraints: #[account(signer)] or Signer<'info> combined with stored pubkey comparison
• upgrade_authority in program deploy config (BPFLoaderUpgradeable)
• mint_authority / freeze_authority / close_authority on SPL Token mints
• PDA-based authorities: programs that use their own PDA as authority for token mints or other programs

Categorize each by impact:

• FUND_CONTROL: Can move, lock, freeze, or close user token accounts/SOL
• PARAMETER_CONTROL: Can change fees, rates, thresholds, delays
• OPERATIONAL_CONTROL: Can pause, unpause, add/remove validators/pools/markets
• UPGRADE_CONTROL: Can replace program logic entirely via BPFLoaderUpgradeable
• MINT_CONTROL: Can mint new tokens (SPL Token mint authority)

---

Step 2: Role Hierarchy and Separation

Map the role hierarchy:

| Role | Stored In (Account) | Granted By | Can Grant Others? | Revocable? | Timelock? | |------|---------------------|-----------|-------------------|-----------|-----------| | {role} | {config PDA / mint} | {grantor instruction} | YES/NO | YES/NO | YES/NO ({mechanism}) |

Solana-Specific Hierarchy Checks

• [ ] Are FUND_CONTROL and UPGRADE_CONTROL held by different keys?
• [ ] Does any single keypair have both PARAMETER_CONTROL and FUND_CONTROL?
• [ ] Is the upgrade authority a multisig (Squads) or DAO (Realms), not a single EOA?
• [ ] Are authority transfers behind timelocks (Clockwork scheduler, Squads time-lock vault)?
• [ ] Can roles be revoked? Does revocation require the role-holder's cooperation?
• [ ] Is there a two-step authority transfer pattern? (propose new authority -> accept authority)

Program Upgrade Authority Analysis (CRITICAL)

| Program | Upgrade Authority | Type | Immutable? | Risk Level | |---------|------------------|------|-----------|------------| | {program_id} | {authority pubkey} | EOA / Squads / Realms / Revoked | YES/NO | {assessment} |

Check via: solana program show <program_id> or read BPFLoaderUpgradeable programdata account.

Risk levels:

• Revoked (immutable): No upgrade risk. Verify: upgrade_authority: None
• Realms DAO: Low risk if DAO has sufficient voter distribution and timelock
• Squads multisig (3/5+): Low-Medium risk. Check: threshold, signer count, timelock
• Squads multisig (2/3 or lower): Medium risk. Collusion of 2 signers can replace program
• Single EOA: CRITICAL risk. One compromised key replaces entire program

---

Step 3: Single Points of Failure

For each privileged role:

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

Solana-Specific SPOF Analysis

| Risk | Description | Severity | |------|-------------|----------| | Upgrade authority compromise | Attacker replaces program with malicious version. ALL user funds at risk. | CRITICAL if single EOA, HIGH if multisig without timelock | | Freeze authority active | Authority can freeze any user's token account. Users cannot transfer, sell, or withdraw. | HIGH if single key, MEDIUM if multisig | | Close authority on user accounts | Authority can close user PDAs, reclaiming lamports and destroying state. | HIGH - user data and rent-exempt lamports lost | | Mint authority active | Authority can mint unlimited tokens, diluting all holders. | HIGH if supply-sensitive protocol | | PDA self-authority | Program uses its own PDA as authority - program upgrade changes PDA behavior. Upgrade authority effectively controls all PDA-authorized actions. | Severity inherits from upgrade authority risk |

Severity assessment:

• Single EOA with FUND_CONTROL or UPGRADE_CONTROL -> HIGH centralization risk (minimum)
• Multisig with FUND_CONTROL but no timelock -> MEDIUM
• Multisig + timelock with FUND_CONTROL -> LOW (but document)
• Immutable program + no freeze/close/mint authority -> 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 |

Solana-specific external governance:

• Pyth/Switchboard oracle governance: Can change feed configurations, add/remove publishers
• SPL Governance (Realms): External DAO decisions affecting shared infrastructure
• Liquid staking governance: Protocol parameter changes affecting staked assets
• DEX aggregator routing changes: If protocol depends on external routing for swaps, routing/fee changes
• Wormhole guardian set rotation: Can affect cross-chain message validation

Check:

• Can external governance changes break protocol invariants?
• Does the protocol have circuit breakers or fallback paths for external changes?
• Are external governance timelines aligned with this protocol's operational timelines?
• Does the protocol verify external program IDs at CPI call sites? (If not, external program upgrade = arbitrary code execution within protocol context)

---

Step 5: Emergency Powers

Document emergency/pause capabilities:

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

Solana Emergency Patterns

| Pattern | Description | Risk | |---------|-------------|------| | Global pause flag | Config account has paused: bool. All user instructions check it. | Standard - check: can users emergency-withdraw when paused? | | Account freeze via SPL Token | Freeze authority freezes user token accounts. | HIGH if no thaw path independent of authority | | Program close | BPFLoaderUpgradeable allows closing the program entirely. All CPI calls to it fail. | CRITICAL if user funds locked in PDAs | | Account close cascade | Authority closes critical config/state accounts. Program instructions fail due to missing accounts. | HIGH - effectively a permanent pause |

Check:

• [ ] Can pausing strand user funds permanently? (Rule 9 - stranded asset severity floor)
• [ ] Is there a maximum pause duration enforced on-chain?
• [ ] Can users exit during pause (emergency withdraw instruction)?
• [ ] If program is closed: can PDAs still be accessed? (No - PDA authority is gone)
• [ ] If no exit during pause -> apply Rule 9 (stranded asset severity floor: minimum MEDIUM)

---

Step 6: Authority Revocation Assessment

For each authority type, assess revocation status and path:

| Authority | Current State | Revocation Path | Should Be Revoked? | Risk If Not Revoked | |-----------|--------------|-----------------|-------------------|-------------------| | Upgrade authority | {active/revoked} | solana program set-upgrade-authority --final | {assessment} | {risk level} | | Mint authority | {active/revoked} | spl-token authorize <mint> mint --disable | {assessment} | {risk level} | | Freeze authority | {active/revoked} | spl-token authorize <mint> freeze --disable | {assessment} | {risk level} | | Close authority (per account type) | {active/none} | {code change required} | {assessment} | {risk level} |

Rule 13 check: Is the authority retention documented? If the protocol claims to be "decentralized" or "trustless" but retains upgrade/freeze/mint authority, apply the 5-question test:

1. Who is harmed by this authority retention?
2. Can affected users avoid the harm?
3. Is the authority retention documented in protocol docs?
4. Could the protocol achieve the same goal without this authority?
5. Does the program fulfill its stated trustlessness completely?

---

Output Schema

## Finding [CR-N]: Title

**Verdict**: CONFIRMED / PARTIAL / REFUTED
**Step Execution**: check1,2,3,4,5,6 | skip(reason) | uncertain
**Severity**: Critical/High/Medium/Low/Info
**Location**: program_id or instruction name

**Centralization Type**: FUND_CONTROL / PARAMETER_CONTROL / OPERATIONAL_CONTROL / UPGRADE_CONTROL / MINT_CONTROL
**Affected Role**: {authority_name}
**Mitigation Present**: {Squads multisig / Realms DAO / Clockwork timelock / Immutable / NONE}

**Description**: What is wrong
**Impact**: What can happen if authority is compromised or acts maliciously
**Recommendation**: How to mitigate (add timelock, revoke authority, use multisig, separate roles)

---

Step Execution Checklist (MANDATORY)

| Step | Required | Completed? | Notes | |------|----------|------------|-------| | 1. Privilege Inventory (all instructions with authority checks) | YES | | | | 2. Role Hierarchy and Separation | YES | | | | 3. Single Points of Failure (per role) | YES | | | | 4. External Governance Dependencies | YES | | | | 5. Emergency Powers and Recovery Paths | YES | | | | 6. Authority Revocation Assessment | YES | | |

Cross-Reference Markers

After Step 1: Cross-reference with ACCOUNT_VALIDATION skill - are all authority checks properly validated (not just signer, but signer == stored authority)?

After Step 2: If upgrade authority is single EOA -> immediate finding (minimum HIGH).

After Step 3: If PDA self-authority pattern detected, severity inherits from upgrade authority assessment.

After Step 5: If no emergency withdraw exists AND pause is possible -> Rule 9 stranded asset finding.

After Step 6: If protocol claims trustlessness but retains mutable authorities -> Rule 13 anti-normalization finding.