Centralization Risk

Skill: CENTRALIZATION_RISK (Sui)

Trigger Pattern: Protocol has privileged capabilities (AdminCap, OwnerCap, UpgradeCap, TreasuryCap, custom caps) 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 capability types)

Covers: single points of failure, privilege escalation, capability object management, external governance dependencies, emergency powers. On Sui, centralization risk has unique dimensions: capability objects (AdminCap) are first-class owned objects that can be transferred, UpgradeCap controls full package replacement, TreasuryCap controls token supply, and shared objects can be the target of admin-gated mutations. The ownership and lifecycle of capability objects IS the access control model.

Trigger Patterns

AdminCap|OwnerCap|UpgradeCap|TreasuryCap|GovernanceCap|OperatorCap|PauserCap|MinterCap|
Cap\b|_cap|admin|authority|privilege

Step 1: Capability Inventory

Enumerate ALL capability objects and ALL functions requiring capabilities:

Key question for each capability: Is it OWNED (by a single address) or SHARED (accessible via reference in any transaction)?

• Owned AdminCap: Only the owner can pass it as a tx argument. Strongest access control, but single point of failure.
• Shared config with admin field: Admin address stored in shared object. More flexible but requires assert!(sender == admin) checks -- verify these are present on ALL admin functions.
• Shared capability object: DANGEROUS -- anyone can pass a shared AdminCap as a transaction argument without ownership.

Categorize each by impact:

• FUND_CONTROL: Can move, lock, or destroy user funds (e.g., emergency withdraw, treasury drain)
• PARAMETER_CONTROL: Can change fees, rates, thresholds, delays (e.g., set_fee, set_max_leverage)
• OPERATIONAL_CONTROL: Can pause, unpause, add/remove pools, whitelist/blacklist
• UPGRADE_CONTROL: UpgradeCap -- controls package upgrades, policy changes
• MINT_CONTROL: TreasuryCap -- controls token supply (mint/burn)

Sui-specific ability checks:

• Does the capability have store ability? If YES -> anyone holding it can public_transfer it, meaning the privilege is freely transferable. Is this intentional?
• Does the capability have drop ability? If YES -> it can be silently discarded. For AdminCap, dropping it means admin functions become permanently uncallable. For UpgradeCap, dropping makes the package permanently immutable.
• Is the capability created ONLY in init()? If created elsewhere, can unauthorized parties mint new capabilities?

Step 2: Capability Hierarchy and Separation

Map the capability hierarchy:

Check:

• Are FUND_CONTROL and UPGRADE_CONTROL separated into different capability types?
• Does any single capability type grant both PARAMETER_CONTROL and FUND_CONTROL?
• Are capability transfers behind timelocks or governance mechanisms?
• Can capabilities be destroyed, and what happens when they are?
• Is there a master capability that can create all other capabilities?

Sui-specific separation patterns:

• Best practice: UpgradeCap held by governance multisig, AdminCap held by operations team, TreasuryCap held by treasury
• Anti-pattern: single init function creates ALL caps and transfers them to tx_context::sender() -- single point of failure at deployment
• Two-step transfer: propose new admin -> new admin accepts. Prevents accidental transfer to wrong address.

UpgradeCap Analysis (CRITICAL)

Risk levels:

• UpgradeCap destroyed (make_immutable): No upgrade risk.
• UpgradeCap held by governance multisig with timelock: Low risk.
• UpgradeCap held by multisig (no timelock): Low-Medium risk.
• UpgradeCap held by single address: CRITICAL risk -- one compromised key replaces entire package. All shared objects now interact with attacker code.
• UpgradeCap stored in shared object: Check access control carefully. If extraction is possible -> same as single address risk.

Step 3: Single Points of Failure

For each capability type:

Sui-Specific SPOF Analysis

Severity assessment:

• Single address with FUND_CONTROL or UPGRADE_CONTROL -> HIGH (minimum)
• Multisig holds capability + timelock -> LOW (but document)
• UpgradeCap destroyed + no admin fund extraction -> INFO

Step 4: External Governance Dependencies

Identify parameters or behaviors controlled by EXTERNAL governance:

Sui-specific external governance:

• Sui framework upgrades: Validators upgrade sui::* packages via governance. Can framework changes break this protocol?
• Oracle provider changes: If protocol reads from oracle shared object, oracle admin can change prices, feeds, or parameters
• DeFi protocol governance: External pools, vaults, or DEXes may change parameters
• Bridge governance: Wormhole guardian set rotation, Sui Bridge committee changes
• Dependency package upgrades: If a dependency has active UpgradeCap, its owner can publish new versions. Our package pins to specific version at compile time, but compatible upgrades preserve types that we import.

Check:

• Can external governance changes break protocol invariants?
• Does the protocol have circuit breakers for external changes?
• Does the protocol verify external package addresses at call sites? Types from compatible-upgraded packages remain the same, but behavior may change.

Step 5: Emergency Powers

Document emergency/pause capabilities:

Sui Emergency Patterns

Check:

• Can pausing strand user funds permanently? (Rule 9 -- stranded asset severity floor: minimum MEDIUM)
• Is there a maximum pause duration or automatic unpause?
• Can users emergency-withdraw during pause?
• What happens if the PauserCap/AdminCap is lost or destroyed?
• Can the protocol be permanently bricked by destroying a critical capability?
• If no exit during pause -> apply Rule 9 (minimum MEDIUM)

Output Schema

## Finding [CR-N]: Title

**Verdict**: CONFIRMED / PARTIAL / REFUTED
**Step Execution**: check1,2,3,4,5 | skip(reason) | uncertain
**Rules Applied**: [R2:___, R6:___, R9:___, R10:___, R13:___]
**Severity**: Critical/High/Medium/Low/Info
**Location**: sources/{module}.move:LineN

**Centralization Type**: FUND_CONTROL / PARAMETER_CONTROL / OPERATIONAL_CONTROL / UPGRADE_CONTROL / MINT_CONTROL
**Affected Capability**: {cap_type}
**Mitigation Present**: {multisig / timelock / UpgradeCap destroyed / governance / NONE}

**Description**: What is wrong
**Impact**: What can happen if capability is compromised, lost, or holder acts maliciously
**Recommendation**: How to mitigate (destroy UpgradeCap, use multisig, add timelock, remove `store` ability, wrap in governance)

Step Execution Checklist (MANDATORY)

Cross-Reference Markers

After Step 1: Cross-reference with ABILITY_ANALYSIS Section 4 (Capability Pattern Audit) -- capabilities with store enable unrestricted transfer.

After Step 2: If UpgradeCap held by single address -> immediate finding (minimum HIGH).

After Step 3: If AdminCap has drop and is needed for fund recovery -> Rule 9 stranded asset finding.

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

After Step 5: If protocol claims trustlessness but retains UpgradeCap/AdminCap -> Rule 13 anti-normalization finding.

If any step skipped, document valid reason (N/A, no external governance, no emergency functions, single capability only).