Centralization Risk

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:

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)

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:

Solana-Specific SPOF Analysis

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:

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:

Solana Emergency Patterns

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:

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)

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.