centralization-risk

name	centralization-risk
description	Trigger Pattern Protocol has privileged capabilities (AdminCap, OwnerCap, UpgradeCap, TreasuryCap, custom caps) - Inject Into Breadth agents (optional), depth-state-trace

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:

#	Capability Type	Module	Abilities	Created Where	Holder	What It Controls	Impact If Lost/Stolen
1	{CapType}	{module}	{key, store, ...}	{init or func}	{address/shared}	{list functions}	{worst case}

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:

Capability	Created By	Can Create Other Caps?	Transferable (has store)?	Destructible (has drop)?	Timelock/Delay?
{cap}	{init / admin_func}	YES/NO	YES/NO	YES/NO	YES/NO

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)

Package	UpgradeCap Holder	Upgrade Policy	Destroyed?	Risk Level
{package_id}	{address or description}	{compatible/additive/dep_only}	YES (immutable) / NO	{assessment}

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:

Capability	Key Compromise Impact	Current Protection	Residual Risk
{cap}	{what attacker can do with it}	{multisig holder? timelock wrapper?}	{what remains}

Sui-Specific SPOF Analysis

Risk	Description	Severity
UpgradeCap compromise	Attacker publishes malicious upgrade. All shared objects now interact with attacker code. ALL user funds at risk.	CRITICAL if single address, HIGH if multisig without timelock
AdminCap compromise	Attacker calls admin functions: drain pools, change parameters, pause protocol.	HIGH if AdminCap controls fund extraction
TreasuryCap compromise	Attacker mints unlimited tokens, diluting all holders.	HIGH if supply-sensitive protocol
AdminCap with store	Holder (or compromised key) can transfer AdminCap to anyone via public_transfer. New holder has full admin access.	Adds transfer risk to any compromise scenario
AdminCap with drop	Admin can accidentally destroy the capability. Admin functions become permanently uncallable.	MEDIUM -- permanent loss of admin access (Rule 9 if admin functions needed for user fund recovery)
Phantom ownership	Capability transferred to an address nobody controls (e.g., @0x0). Object is permanently inaccessible -- equivalent to destroying it.	Same as destruction if holding value or needed for operations

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:

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

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:

Emergency Function	Required Capability	What It Affects	Recovery Path	Time to Recover
{func}	{cap_type}	{scope: all operations / specific pool}	{how to resume}	{estimate}

Sui Emergency Patterns

Pattern	Description	Risk
Global pause field	Shared config object has paused: bool. All user functions check it.	Standard -- check: can users withdraw when paused?
Capability destruction	Admin destroys their own capability to "renounce" control.	Irreversible -- if needed later for recovery, funds stranded
Object freeze	Admin calls transfer::public_freeze_object on a config. Permanent immutability.	If done to wrong object, permanent loss of admin access
Package policy tightening	UpgradeCap holder restricts policy (compatible -> additive -> immutable).	Good for security, but irreversible. Cannot loosen policy.

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)

Step	Required	Completed?	Notes
1. Capability Inventory (all cap-gated functions)	YES		Owned vs shared, abilities checked
2. Capability Hierarchy and Separation	YES		store/drop analysis, UpgradeCap assessment
3. Single Points of Failure (per capability)	YES
4. External Governance Dependencies	YES
5. Emergency Powers and Recovery Paths	YES

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).