Agent skill

Centralization Risk

by PlamenTSV in PlamenTSV/plamen

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

MITAuto-check passed

Install Centralization Risk

skills CLI
$ npx skills add PlamenTSV/plamen --skill centralization-risk -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install PlamenTSV/plamen centralization-risk --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/PlamenTSV/plamen.git skills-src && mkdir -p .claude/skills && cp -r skills-src/agents/skills/sui/centralization-risk .claude/skills/centralization-risk && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
centralization-risk
GitHub stars
303
Token cost
~3k tokens
SKILL.md length
1,248 words
Files
1
Skills in repo
87
Repo updated
First seen
Licence
MIT

At a glance

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

  • Works in 5 steps: Capability Inventory → Capability Hierarchy and Separation → Single Points of Failure → …
  • Pattern Protocol has privileged capabilities (AdminCap
  • SKILL.md covers Trigger Patterns, Step 1: Capability Inventory, Step 2: Capability Hierarchy… and Step 3: Single Points of Failure, plus 4 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Centralization Risk is an agent skill from PlamenTSV/plamen. Trigger Pattern Protocol has privileged capabilities (AdminCap, OwnerCap, UpgradeCap, TreasuryCap, custom caps) - Inject Into Breadth agents (optional), depth-state-trace

Its SKILL.md is about 3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

The repository describes itself as: Autonomous Web3 security audit agent for Claude Code. The licence is MIT.

When your agent uses it

  • Pattern Protocol has privileged capabilities (AdminCap
  • Custom caps) - Inject Into Breadth agents (optional)
  • Depth-state-trace

Example prompts

  • “/centralization-risk”

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Capability Inventory
  2. Capability Hierarchy and Separation
  3. Single Points of Failure
  4. External Governance Dependencies
  5. Emergency Powers

What it can do on your machine

Read from SKILL.md and the folder at commit 795962b. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Centralization Risk loads about 3k tokens when it runs. Until then it costs about 48 tokens; SKILL.md has 1,248 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~48
When it runs · the whole SKILL.md, loaded when a task matches
~3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from PlamenTSV/plamen at commit 795962b, republished under its MIT licence (© PlamenTSV). 1,248 words, ~3,013 tokens.

Download SKILL.mdSave it as .claude/skills/centralization-risk/SKILL.md (or your agent's skills folder).
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 TypeModuleAbilitiesCreated WhereHolderWhat It ControlsImpact 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:

CapabilityCreated ByCan Create Other Caps?Transferable (has store)?Destructible (has drop)?Timelock/Delay?
{cap}{init / admin_func}YES/NOYES/NOYES/NOYES/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)
PackageUpgradeCap HolderUpgrade PolicyDestroyed?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:

CapabilityKey Compromise ImpactCurrent ProtectionResidual Risk
{cap}{what attacker can do with it}{multisig holder? timelock wrapper?}{what remains}
Sui-Specific SPOF Analysis
RiskDescriptionSeverity
UpgradeCap compromiseAttacker 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 compromiseAttacker calls admin functions: drain pools, change parameters, pause protocol.HIGH if AdminCap controls fund extraction
TreasuryCap compromiseAttacker mints unlimited tokens, diluting all holders.HIGH if supply-sensitive protocol
AdminCap with storeHolder (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 dropAdmin 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 ownershipCapability 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

Show full SKILL.md (478 more words)Show less

Step 4: External Governance Dependencies

Identify parameters or behaviors controlled by EXTERNAL governance:

DependencyExternal EntityWhat They ControlProtocol Impact If ChangedNotification?
{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 FunctionRequired CapabilityWhat It AffectsRecovery PathTime to Recover
{func}{cap_type}{scope: all operations / specific pool}{how to resume}{estimate}
Sui Emergency Patterns
PatternDescriptionRisk
Global pause fieldShared config object has paused: bool. All user functions check it.Standard -- check: can users withdraw when paused?
Capability destructionAdmin destroys their own capability to "renounce" control.Irreversible -- if needed later for recovery, funds stranded
Object freezeAdmin calls transfer::public_freeze_object on a config. Permanent immutability.If done to wrong object, permanent loss of admin access
Package policy tighteningUpgradeCap 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

markdown
## 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)

StepRequiredCompleted?Notes
1. Capability Inventory (all cap-gated functions)YESOwned vs shared, abilities checked
2. Capability Hierarchy and SeparationYESstore/drop analysis, UpgradeCap assessment
3. Single Points of Failure (per capability)YES
4. External Governance DependenciesYES
5. Emergency Powers and Recovery PathsYES
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).

© PlamenTSV, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in agents/skills/sui/centralization-risk of PlamenTSV/plamen.

Open the folder on GitHubat commit 795962b

Compare with similar skills

Centralization Risk next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Centralization Risk compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Centralization Risk this skillPlamenTSV/plamen303—~3kAutomated safety check: PassMIT
Golang Patternsaffaan-m/ECC275k—~1.1kAutomated safety check: PassMIT
Kotlin Exposed Patternsaffaan-m/ECC275k4 repos~5.5kAutomated safety check: PassMIT
Dotnet Patternsaffaan-m/ECC275k1 repos~2.3kAutomated safety check: PassMIT
Fastapi Patternsaffaan-m/ECC275k—~2.3kAutomated safety check: PassMIT
Python Patternsaffaan-m/ECC275k—~2.3kAutomated safety check: PassMIT

Similar skills

  • Golang Patterns

    affaan-m/ECC

    Go-specific design patterns and best practices including functional options, small interfaces, dependency injection, concurrency patterns, error handling, and package organization.

    275k GitHub stars~1.1k tokensUpdated 3 days ago
    DevelopmentAuto-check passed
  • JetBrains Exposed ORM patterns including DSL queries, DAO pattern, transactions, HikariCP connection pooling, Flyway migrations, and repository pattern.

    275k GitHub starsUsed in 4 repos~5.5k tokens
    DatabasesAuto-check passed
  • Dotnet Patterns

    affaan-m/ECC

    Idiomatic C and .NET patterns, conventions, dependency injection, async/await, and best practices for building robust, maintainable .NET applications.

    275k GitHub starsUsed in 1 repo~2.3k tokens
    DevelopmentAuto-check passed
  • Fastapi Patterns

    affaan-m/ECC

    FastAPI patterns for async APIs, dependency injection, Pydantic request and response models, OpenAPI docs, tests, security, and production readiness.

    275k GitHub stars~2.3k tokensUpdated 3 days ago
    Backend & APIsAuto-check passed
  • Python Patterns

    affaan-m/ECC

    Python-specific design patterns and best practices including protocols, dataclasses, context managers, decorators, async/await, type hints, and package organization.

    275k GitHub stars~2.3k tokensUpdated 3 days ago
    DevelopmentAuto-check passed
  • Patterns

    sickn33/agentic-awesome-skills

    Reference document for monopoly patterns. An agent skill from sickn33/agentic-awesome-skills.

    47k GitHub starsUsed in 1 repo~2.6k tokens
    Backend & APIsAuto-check passed

More from PlamenTSV/plamen

All 87 skills in this repo
  • Audit Prep

    PlamenTSV/plamen

    Prepare Solidity projects for a security audit — test coverage, test quality, NatSpec docs, code hygiene, dependency health, best-practice enforcement, deployment readiness, and project…

    303 GitHub stars~3.7k tokensUpdated 12 days ago
    Auto-check passed
  • Verification Protocol

    PlamenTSV/plamen

    Trigger Pattern Always (used by all verifier agents) - Inject Into security-verifier agents (Phase 5)

    303 GitHub stars~3.5k tokensUpdated 12 days ago
    Auto-check passed
  • Ability Analysis

    PlamenTSV/plamen

    Trigger Pattern Always (Aptos Move) - foundational security check - Inject Into Breadth agents, depth agents

    303 GitHub stars~3.3k tokensUpdated 12 days ago
    Auto-check passed
  • Ability Analysis

    PlamenTSV/plamen

    Trigger Pattern Always (Sui Move) -- foundational security check - Inject Into Breadth agents, depth agents

    303 GitHub stars~3.2k tokensUpdated 12 days ago
    Auto-check passed
  • Account Lifecycle

    PlamenTSV/plamen

    Trigger Pattern ACCOUNTCLOSING flag detected (close/CloseAccount usage) - Inject Into Breadth agents, depth agents

    303 GitHub stars~1.2k tokensUpdated 12 days ago
    Auto-check passed
  • Account Validation

    PlamenTSV/plamen

    Trigger Pattern Always required for Solana audits - Inject Into Breadth agents, depth agents

    303 GitHub stars~1.7k tokensUpdated 12 days ago
    Auto-check passed

Questions about Centralization Risk

What does Centralization Risk do?

Trigger Pattern Protocol has privileged capabilities (AdminCap, OwnerCap, UpgradeCap, TreasuryCap, custom caps) - Inject Into Breadth agents (optional), depth-state-trace. Centralization Risk is an agent skill from PlamenTSV/plamen.

When should I use Centralization Risk?

Centralization Risk fits situations like: pattern Protocol has privileged capabilities (AdminCap; custom caps) - Inject Into Breadth agents (optional); depth-state-trace.

How do I install Centralization Risk in Claude Code?

Run `npx skills add PlamenTSV/plamen --skill centralization-risk -a claude-code`. Or copy the skill folder (agents/skills/sui/centralization-risk in PlamenTSV/plamen) into .claude/skills/centralization-risk in your project. Claude Code loads it when a task matches its description.

How do I install Centralization Risk in Codex?

Run `npx skills add PlamenTSV/plamen --skill centralization-risk -a codex`. Or copy the skill folder (agents/skills/sui/centralization-risk in PlamenTSV/plamen) into .agents/skills/centralization-risk in your project. Codex loads it when a task matches its description.

Can I use Centralization Risk in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add PlamenTSV/plamen --skill centralization-risk -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/centralization-risk, .gemini/skills/centralization-risk, .github/skills/centralization-risk and .opencode/skills/centralization-risk in your project.

What does Centralization Risk need to run?

SKILL.md names no scripts, command-line tools or credentials: Centralization Risk is instructions for the agent only.

Does Centralization Risk access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Centralization Risk safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Centralization Risk use?

Centralization Risk is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Centralization Risk use?

About 3k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Centralization Risk?

Skills that share tags, products or a category with Centralization Risk: Golang Patterns (affaan-m/ECC, 275k stars), Kotlin Exposed Patterns (affaan-m/ECC, 275k stars), Dotnet Patterns (affaan-m/ECC, 275k stars) and Fastapi Patterns (affaan-m/ECC, 275k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Centralization Risk?

PlamenTSV (a GitHub user) maintains it in PlamenTSV/plamen, which has 303 GitHub stars. The repository holds 87 skills in this directory. The repository was last updated on September 26, 2026.

Source: PlamenTSV/plamen on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.