How do I install the Upgrade Vs Immutable Decision skill?

Run npx skillmds@latest add tomevault-io/upgrade-vs-immutable-decision in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Upgrade Vs Immutable Decision safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Upgrade Vs Immutable Decision?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Upgrade Vs Immutable Decision free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Upgrade Vs Immutable Decision?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Upgrade Vs Immutable Decision by tomevault-io

Name: Upgrade Vs Immutable Decision
Author: tomevault-io

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. Use when this capability is needed.

tomevault-io Updated Sep 17, 2026

File contents

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

Map risks and needs
- Identify required future changes (features, bug fixes) and severity of potential bugs.
Choose model
- If stable and simple -> consider immutability.
- If evolving or complex -> keep upgradeable under multisig/DAO with policies.
Governance setup
- If upgradeable: configure multisig thresholds, access control, time-locks if available; document process.
Communication
- Publish program id, authority holder, policy (when upgrades happen, notice window, how to verify binaries/IDL).
Execution
- Rotate authority to final holder or set to BPFLoaderUpgradeab1e none for immutable; record tx.
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.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: upgrade-vs-immutable-decisiondescription: 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. Use when this capability is needed.---# Upgrade vs Immutable DecisionRole 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.## Workflow1) Map risks and needs - Identify required future changes (features, bug fixes) and severity of potential bugs.2) Choose model - If stable and simple -> consider immutability. - If evolving or complex -> keep upgradeable under multisig/DAO with policies.3) Governance setup - If upgradeable: configure multisig thresholds, access control, time-locks if available; document process.4) Communication - Publish program id, authority holder, policy (when upgrades happen, notice window, how to verify binaries/IDL).5) Execution - Rotate authority to final holder or set to BPFLoaderUpgradeab1e none for immutable; record tx.6) 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 FormatProvide 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.---> Converted and distributed by [TomeVault](https://tomevault.io/claim/sanctifiedops) — claim your Tome and manage your conversions.

Frequently asked questions