SkillsAdd

smithery/sanctifiedops

upgrade-vs-immutable-decision

Framework for deciding whether to keep a Solana program upgradeable or make it immutable, including trust, operations, and governance tradeoffs. Use before deployment or key rotation.

Installation

$ npx skills add smithery/sanctifiedops --skill upgrade-vs-immutable-decision
View on skills.sh ↗ Website ↗

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

kotlin-tooling-immutable-collections-0-5-x-migration Similar name
kotlin/kotlin-agent-skills

Migrate Kotlin (and Java) code from kotlinx.collections.immutable 0.3.x / 0.4.x to the latest 0…

597 installs

Also in this package

Other skills from smithery/sanctifiedops.

npx skills add smithery/sanctifiedops
webhooks-and-event-processing 0 wallet-monitoring-bot 0 rug-detection-checklist 0 rpc-selection-and-resilience 0

Browse all from smithery/sanctifiedops

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,839 B
  • docs SUMMARY.md 220 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Upgrade vs Immutable Decision

Role framing: You are a governance advisor. Your goal is to select and communicate the right upgrade posture for a program.

Initial Assessment

  • Program risk profile and assets controlled?
  • User expectations (fair launch vs managed)?
  • Existing audit coverage? Roadmap requiring changes?
  • Governance model: single key, multisig, DAO voting?

Core Principles

  • Immutability maximizes trust but freezes bug fixes; upgradeability enables fixes but requires governance and transparency.
  • The upgrade authority is a critical trust lever; custody must be clear and secure.
  • Communication matters as much as choice: explain why and how upgrades occur.

Workflow

  1. Map risks and needs

- Identify required future changes (features, bug fixes) and severity of potential bugs.

  1. Choose model

- If stable and simple -> consider immutability. - If evolving or complex -> keep upgradeable under multisig/DAO with policies.

  1. Governance setup

- If upgradeable: configure multisig thresholds, access control, time-locks if available; document process.

  1. Communication

- Publish program id, authority holder, policy (when upgrades happen, notice window, how to verify binaries/IDL).

  1. Execution

- Rotate authority to final holder or set to BPFLoaderUpgradeab1e none for immutable; record tx.

  1. Verification

- Post-upgrade: verify program data hash, slot, authority state; update registry and README.

Templates / Playbooks

  • Decision table: need for future change? audit status? user trust requirement? -> recommendation.
  • Policy blurb example: "Program upgradeable by 2/3 multisig; upgrades announced 48h prior with IDL diff and binary hash; emergencies allowed for critical bugs only."

Common Failure Modes + Debugging

  • Forgetting to rotate upgrade authority post-launch -> centralization FUD.
  • Losing upgrade key -> inability to fix critical bugs.
  • Not communicating upgrade -> community backlash; maintain status page and changelog.

Quality Bar / Validation

  • Clear recorded choice with txid; authority custody documented.
  • Policy published and consistent across channels.
  • Post-action verification of program authority state.

Output Format

Provide decision summary, rationale, authority state, policy text, and verification commands/txids.

Examples

  • Simple: Small utility program, audited, fixed scope -> set immutable; publish tx and hash.
  • Complex: AMM program in active development -> retain upgradeability under 3/5 multisig with 48h notice; publish policy, changelog, and monitoring alerts for upgrades.