# Upgrade Authority The upgrade authority is the single most powerful control surface in any Solana protocol. It is the account authorized to deploy new program bytecode to an existing program address via loader-v3 (Upgradeable Loader). If an attacker gains control of your upgrade authority, they can replace your entire program with arbitrary code — draining all funds, minting tokens, bypassing every safety check, and overriding every in-protocol admin system you have built. This article covers what the upgrade authority is, how to secure it, how to transfer it to a multisig, how to execute upgrades safely, and when to consider revoking it entirely. --- ## 1. What Is the Upgrade Authority? On Solana, programs are deployed through **loader-v3 (Upgradeable Loader)** (`BPFLoaderUpgradeab1e111111111111111111111111`). When you deploy a program, the loader creates two accounts: 1. **The program account** — contains a pointer to the programdata account. 2. **The programdata account** — contains the actual executable bytecode and the upgrade authority field. The **upgrade authority** is the pubkey stored in the programdata account. This account, and only this account, can invoke the `BPFLoaderUpgradeable::Upgrade` instruction to replace the program's bytecode. ### Inspecting the upgrade authority To check the current upgrade authority for any program: ``` solana program show <PROGRAM_ID> ``` Example output: ``` Program Id: 9xQeWvG816bUx9EPjHmaT23yvVM2ZWbrrpZb9PusVFin Owner: BPFLoaderUpgradeab1e111111111111111111111111 ProgramData Address: 5b2Fd2E1c3Bh7K9pQ... Authority: 7nYBm5hk5JzE... (or "none" if revoked) Last Deployed In Slot: 234567890 Data Length: 1048576 (1.0 MiB) bytes ``` The `Authority` field is the upgrade authority. If it says `none`, the program is immutable. ### Why the upgrade authority is the most dangerous authority The upgrade authority sits **above** all in-protocol authorities. Your program may have its own admin key system with role separation, timelocks, guardians, and cancellation mechanisms. None of that matters if the upgrade authority is compromised, because the attacker can deploy new code that: - Removes all admin checks - Drains every account the program owns or controls - Mints tokens without limit (if the program controls a mint authority PDA) - Replaces the program logic entirely while preserving the same program ID Every audit of a Solana program is only valid as long as the audited code is what is actually deployed. If the upgrade authority can push new code at any time with no oversight, the program is effectively unaudited. ### Upgrade authority vs. in-protocol admin These are two fundamentally different powers: | Property | Upgrade Authority | In-Protocol Admin | |----------|-------------------|-------------------| | Scope | Can change everything — all code, all logic, all accounts | Limited to what the program's instruction set exposes | | Where stored | Programdata account (loader-v3 level) | Program state accounts (application level) | | Can bypass program checks | Yes — deploys new code | No — constrained by current code | | Constrained by timelocks in your program | No — operates at the loader level, outside your program | Yes — if you implemented them | | Can be a PDA | No — must be a signer (keypair or multisig vault) | Yes — PDAs are common for in-protocol authority | --- ## 2. Upgrade Authority Options There are four ways to configure the upgrade authority, each with different security properties. ### 2.1 Single EOA (Keypair) The upgrade authority is a single keypair. Whoever has the private key can upgrade the program instantly with no review, no approval, and no delay. **Security posture:** Totally unacceptable for any production protocol. One compromised key, one stolen laptop, one phished developer, one malicious insider = total protocol loss. **When acceptable:** Local development and devnet testing only. ### 2.2 Multisig (Squads Protocol) The upgrade authority is transferred to a Squads multisig vault PDA. Upgrades require M-of-N signers to approve a proposal before execution. **Security posture:** The standard approach for production Solana protocols. The Squads vault PDA becomes the upgrade authority. See [[squads]] for multisig configuration details. **Recommended configurations:** | Protocol Value | Minimum Quorum | Timelock | Notes | |----------------|---------------|----------|-------| | < $1M TVL | 2-of-3 | None required | Acceptable for early-stage protocols | | $1M - $10M TVL | 3-of-5 | Recommended | Standard for most production protocols | | $10M - $100M TVL | 4-of-7 | MUST (24h+) | Required at L3 | | > $100M TVL | 5-of-9 | MUST (48-72h+) | Required at L4 | **Key requirements:** - Signer independence: no two signers in the same household, no hidden quorum - Each signer uses a dedicated signing device - At L3+, signers should be geographically distributed ### 2.3 Governance (Realms / SPL Governance) The upgrade authority is transferred to a governance account. Upgrades require a governance proposal, a voting period, and quorum from token holders or council members. **Security posture:** Slower but more decentralized. Appropriate for mature protocols with active governance participation. See [[realms]] for configuration. **Tradeoffs:** - Slower response time for critical patches (voting periods are typically 24-72 hours minimum) - Requires active governance participation to meet quorum - More transparent — all proposals are publicly visible - Risk: governance attacks via token accumulation or voter apathy ### 2.4 Revoked / Immutable The upgrade authority is set to `None`. The program can never be changed again. **Security posture:** Maximum security against malicious upgrades. Zero ability to fix bugs, patch vulnerabilities, or add features. See [Section 6: Immutability](#6-immutability-revoking-upgrade-authority) for detailed guidance. --- ## 3. Transferring Upgrade Authority to a Multisig This is the most critical operational procedure. A mistake here — a typo in the target address, a wrong PDA derivation — results in permanent, irrecoverable loss of upgrade authority. ### 3.1 Prerequisites Before starting: 1. **Deploy your program:** ``` solana program deploy target/deploy/my_program.so ``` 2. **Record the program ID.** You will need it for every subsequent step. 3. **Create your Squads multisig** with the correct members, threshold, and permissions. Verify the configuration in the Squads UI. 4. **Identify the correct Squads vault PDA.** The vault PDA is derived from the multisig account. Confirm this address by: - Checking the Squads UI — the vault address is displayed on the multisig dashboard - Independently deriving the PDA using the Squads SDK - Having a second team member independently verify the address 5. **Test the entire flow on devnet first** with the same multisig configuration and the same signer set. ### 3.2 Transfer procedure **Step 1: Verify the current upgrade authority.** ``` solana program show <PROGRAM_ID> ``` Confirm the `Authority` field shows your current deployer keypair. **Step 2: Transfer to the Squads vault PDA.** ``` solana program set-upgrade-authority <PROGRAM_ID> \ --new-upgrade-authority <SQUADS_VAULT_PDA> ``` The CLI will ask for confirmation. Read the output carefully. Verify the program ID and new authority address character by character. **Step 3: Verify the transfer.** ``` solana program show <PROGRAM_ID> ``` The `Authority` field MUST now show the Squads vault PDA. If it shows anything else, stop and investigate immediately. **Step 4: Test the upgrade flow.** Before considering the transfer complete, execute a test upgrade through the multisig to confirm the full workflow works. Deploy a trivial code change (e.g., bump a version constant) through the Squads proposal flow. If you cannot successfully upgrade through the multisig, you have lost upgrade authority. ### 3.3 Critical warnings - **Double-check the address.** A single wrong character in the Squads vault PDA means permanent loss of upgrade authority. There is no recovery mechanism. The program becomes effectively immutable, but not intentionally so. - **Do not transfer to a Squads member address.** Transfer to the **vault PDA**, not to any individual member's pubkey. - **Do not transfer to an uninitialized multisig.** Make sure the Squads multisig is fully created, members are added, and the threshold is set before transferring. - **Coordinate the transfer.** At least two people should independently verify the target address before executing. - **Have the signing keypair backed up.** If the transfer fails mid-way (network error, insufficient SOL for fees), you need the original keypair to retry. --- ## 4. The Upgrade Workflow Once the upgrade authority is held by a multisig, every upgrade follows a multi-step process. Each step has security implications. ### 4.1 Build the program Use verified or reproducible builds. This is the foundation of upgrade trust. Using `solana-verify`: ``` solana-verify build ``` Using Anchor's verifiable build: ``` anchor build --verifiable ``` Using a Docker-based reproducible build: ``` solana-verify build --library-name <PROGRAM_LIB_NAME> ``` Record the build hash. You will need it for verification in later steps. ### 4.2 Write the program to a buffer account The new program bytecode must be written to a temporary buffer account before it can be used in an upgrade. ``` solana program write-buffer target/deploy/my_program.so ``` Output: ``` Buffer: 3Kat2S4xoSf... ``` Record the buffer address. This account now holds the new bytecode and will be referenced in the upgrade proposal. **Cost note:** Writing a buffer requires SOL for rent-exemption. For a 1 MiB program, this is approximately 7-8 SOL. This SOL is recoverable by closing the buffer after the upgrade. ### 4.3 Set the buffer authority to the Squads vault The buffer account has its own authority (the "buffer authority"), which defaults to the keypair that wrote the buffer. **This authority MUST be transferred to the Squads vault PDA BEFORE the buffer hash is verified.** This order is critical for security. ``` solana program set-buffer-authority <BUFFER_ADDRESS> \ --new-buffer-authority <SQUADS_VAULT_PDA> ``` Verify: ``` solana program show <BUFFER_ADDRESS> ``` The authority should now be the Squads vault PDA. **Why transfer authority BEFORE verification:** If the buffer authority remains with the original deployer, they could update the buffer contents between the time the buffer is verified and the time the upgrade is executed via the multisig. By transferring authority to the multisig vault first, the buffer becomes immutable -- only the multisig can modify or use it. This ensures that when signers verify the buffer hash in the next step, the hash they verify is the hash that will actually be deployed. Without this ordering, the entire verified build process can be bypassed: a malicious or compromised deployer verifies a clean buffer, then swaps in malicious bytecode before the multisig executes the upgrade. ### 4.4 Verify the buffer contents This step is critical. You must confirm that the buffer contains exactly the bytecode you built. **This verification MUST happen AFTER the buffer authority has been transferred to the multisig vault** (step 4.3). If the buffer authority has not been transferred, the deployer can still modify the buffer contents, making any verification meaningless. **The correct sequence is:** 1. Write the buffer (step 4.2) 2. Transfer buffer authority to the multisig vault (step 4.3) 3. Verify the buffer hash (this step) 4. Create the upgrade proposal (step 4.5) **Option A: Compare hashes.** Dump the buffer contents: ``` solana program dump <BUFFER_ADDRESS> buffer_dump.so ``` Compare the dumped bytecode to your local build artifact. They should be byte-identical: ``` sha256sum buffer_dump.so sha256sum target/deploy/my_program.so ``` The hashes must match. **Option B: Use solana-verify.** ``` solana-verify get-buffer-hash <BUFFER_ADDRESS> ``` Compare the output hash to your local build hash. **Why this matters:** An attacker could attempt to front-run your buffer write, a compromised build environment could produce different bytecode than expected, or a deployer with retained buffer authority could swap contents after verification. Always transfer buffer authority first, then verify. ### 4.5 Create an upgrade proposal in Squads Using the Squads UI: 1. Navigate to your multisig in the Squads app 2. Create a new transaction 3. Select "Program Upgrade" as the instruction type 4. Enter the program ID and buffer address 5. The Squads UI constructs the `BPFLoaderUpgradeable::Upgrade` instruction 6. Submit the proposal Using the Squads CLI or SDK, you can also create the proposal programmatically. This is recommended for teams with CI/CD integration. ### 4.6 Signer review and approval Each signer MUST independently verify before approving: 1. **Buffer address** — matches the one from the verified build (compare to the hash recorded in step 4.1) 2. **Program ID** — is the correct program being upgraded (not a different program) 3. **Code changes** — the expected changes match the PR, release notes, or changelog 4. **Build reproducibility** — at least one other signer has independently reproduced the build and confirmed the same hash 5. **Simulation** — simulate the upgrade transaction before signing to confirm it will succeed Each signer approves in the Squads UI or via the SDK. Signers should confirm approval through an out-of-band channel (e.g., Signal or a separate Telegram group) to prevent phishing via fake Squads proposals. ### 4.7 Execute the upgrade Once the quorum threshold is met (and any timelock has expired), execute the upgrade: - In the Squads UI, click "Execute" - The `BPFLoaderUpgradeable::Upgrade` instruction runs, replacing the program bytecode with the buffer contents ### 4.8 Post-upgrade verification After the upgrade executes: **Verify the deployed code matches the source:** ``` solana-verify verify-from-repo \ --program-id <PROGRAM_ID> \ <REPO_URL> ``` Or compare the deployed program hash to your build artifact: ``` solana program dump <PROGRAM_ID> deployed.so sha256sum deployed.so ``` **Verify the upgrade authority is unchanged:** ``` solana program show <PROGRAM_ID> ``` The `Authority` field should still be the Squads vault PDA. An upgrade should never change the upgrade authority unless explicitly intended. **Run smoke tests** against the upgraded program to verify core functionality. ### 4.9 Close the buffer account After a successful upgrade, close the buffer to reclaim the rent SOL: ``` solana program close <BUFFER_ADDRESS> ``` If the buffer authority was transferred to the Squads vault, closing the buffer requires a Squads proposal. Some teams skip this step, but old buffers create confusion and waste SOL. --- ## 5. Timelocks on Upgrades A timelock is a mandatory delay between when an upgrade proposal reaches quorum and when it can be executed. This creates a window where monitoring systems can detect the proposal and the cancellation guardian can intervene if the upgrade is malicious. ### 5.1 Why timelocks matter Without a timelock, a compromised quorum of signers can push a malicious upgrade instantly. With a timelock, the community, monitoring systems, and the cancellation guardian have a window to react. ### 5.2 Recommended minimums | SOS Level | Minimum Timelock | Rationale | |-----------|-----------------|-----------| | L1 | Not required | Basic operational discipline | | L2 | Not required (recommended) | Managed processes, but timelock is optional | | L3 | 24 hours MUST | High-value protocols need a review window | | L4 | 48-72 hours MUST | Critical protocols need extended review | ### 5.3 Timelock prerequisites A timelock is only useful if all three conditions are met: 1. **Monitoring exists.** An alert fires when an upgrade proposal is created. If nobody knows about the proposal, the timelock window is wasted. See [[monitoring]] for setup. 2. **Someone is watching.** A named person or team is responsible for reviewing upgrade proposals during the timelock window. This must include off-hours coverage for critical protocols. 3. **The cancellation guardian is independent.** The entity that can cancel a pending upgrade must be separate from the upgrade multisig. If the same people control both, a compromised quorum can simply cancel the cancellation guardian first. ### 5.4 Squads timelock configuration Squads Protocol v4 supports timelocks natively via the `config_transaction` instruction. Set the timelock duration when configuring the multisig. See [[squads]] for specific configuration steps. ### 5.5 Emergency upgrades If you need to upgrade during an active incident (e.g., to patch an exploited vulnerability), the timelock creates tension between speed and security. The correct approach: 1. **Pause the protocol first** using the guardian or emergency stop mechanism. This contains the damage immediately without requiring an upgrade. 2. **Prepare the upgrade** with the full verified build process. 3. **Wait for the timelock** to expire. The protocol is paused, so the attacker cannot exploit further during the delay. 4. **Execute the upgrade** and verify. 5. **Resume the protocol** using the appropriate (slower) authority. This is why the guardian/pause mechanism described in [[authority-design]] is so important — it decouples incident containment from the upgrade timeline. --- ## 6. Immutability (Revoking Upgrade Authority) Making a program immutable means permanently revoking the upgrade authority. The program can never be changed again by anyone. ### 6.1 How to revoke ``` solana program set-upgrade-authority <PROGRAM_ID> --final ``` The `--final` flag sets the upgrade authority to `None`. **This is irreversible.** There is no mechanism to restore an upgrade authority once revoked. ### 6.2 When to consider immutability Immutability is appropriate when: - The program is mature, well-audited, and has been running without issues for an extended period - The program has no admin functions that require future updates - The risk of malicious upgrades exceeds the risk of undiscovered bugs - The program is a simple, self-contained utility (e.g., a token program, a deterministic escrow) - The protocol's value proposition depends on credible immutability (e.g., "code is law" guarantees) ### 6.3 When NOT to revoke Do not revoke the upgrade authority if: - The program needs parameter updates, new features, or integration changes - The program has not been thoroughly audited by multiple independent firms - The program interacts with external systems (oracles, other programs) that may change - The team is still actively developing the protocol - There is any reasonable possibility of a bug that would require a fix ### 6.4 Middle ground: high-barrier upgradeability For protocols that want strong immutability guarantees without irrevocable commitment, consider: - **Very high quorum:** 5-of-9 or 7-of-11 for upgrades - **Very long timelock:** 1 week or more - **Active monitoring:** Alerts on any upgrade proposal - **Public visibility:** All upgrade proposals visible to the community - **Independent cancellation guardian:** Can veto upgrades during the timelock This creates practical near-immutability while preserving the ability to fix critical bugs. ### 6.5 Partial immutability Some protocols separate their codebase into: - **Immutable core logic** — the core accounting, settlement, and security invariants are deployed as an immutable program - **Upgradeable modules** — parameters, configuration, and non-critical features are in a separate upgradeable program that interacts with the core via CPI This pattern provides strong guarantees about the core while allowing operational flexibility. It requires careful interface design between the immutable and upgradeable components. --- ## 7. Security Considerations ### 7.1 Buffer squatting and front-running When you write a buffer account, there is a window between writing and proposing the upgrade. An attacker who can predict or observe your buffer write could attempt to: - Create a buffer at a predictable address with malicious code - Front-run your buffer write transaction **Mitigation:** Always verify buffer contents (Section 4.4) before proposing an upgrade. Never assume the buffer contains what you wrote without checking. ### 7.2 Upgrade authority as the ultimate backdoor Any security audit of a Solana program is bounded by the upgrade authority posture. A program that was audited last month but can be instantly upgraded by a single keypair today is effectively unaudited today. The audit report is a statement about the code at audit time, not about the code that is currently deployed. For users and integrators evaluating a protocol's security: - Check the upgrade authority: `solana program show <PROGRAM_ID>` - If it is a single keypair, the program is only as trustworthy as that one person - If it is a multisig, evaluate the multisig configuration (threshold, signer independence, timelock) - If it is `None`, the program is immutable — verify the deployed code matches audited code ### 7.3 Upgrade authority and PDA authorities If your program's mint authority, freeze authority, or other token authorities are PDAs derived from your program, then the upgrade authority is the true root authority for those as well. A malicious upgrade can make the program sign anything with those PDAs. **Example:** Your program has a mint authority PDA. You have carefully designed your program so it only mints tokens under specific, audited conditions. If the upgrade authority is compromised, the attacker deploys new code where the PDA mints unlimited tokens with no conditions. Document the PDA authority chain explicitly. See [[pdas-and-authority]] for details. ### 7.4 Stale buffer accounts Old buffer accounts from previous upgrades or failed attempts should be closed: ``` solana program close <BUFFER_ADDRESS> ``` Stale buffers: - Waste SOL (rent-exempt balance is locked) - Create confusion about which buffer is the correct one - Could theoretically be reused in a social engineering attack ("here, use this buffer I prepared earlier") List all buffers owned by an authority: ``` solana program show --buffers --buffer-authority <AUTHORITY_ADDRESS> ``` ### 7.5 Program account vs. programdata account Understand the loader-v3 account structure: - The **program account** is owned by loader-v3 and contains a pointer to the programdata account. It is immutable in the sense that you cannot change which programdata account it points to. - The **programdata account** contains the executable bytecode and the upgrade authority. When you upgrade, the bytecode in this account is replaced. - The **upgrade authority** is stored in the programdata account, not the program account. When querying or monitoring, the programdata address is what you need for upgrade authority checks. ### 7.6 IDL Authority as an Inventoried Surface For Anchor programs, the IDL (Interface Definition Language) is a separate on-chain account that describes the program's instruction set, account structures, and types. The IDL has its own authority -- the account that can update or replace the on-chain IDL data. **Why this matters:** The IDL is what clients, explorers, and frontends use to understand how to construct and decode transactions for your program. A malicious IDL change could mislead clients about instruction formats, argument types, or account layouts. For example, an attacker who controls the IDL authority could modify the IDL to make a "withdraw to treasury" instruction appear to take a different set of accounts than it actually does, causing users or automated systems to construct transactions that send funds to the attacker instead. **The IDL authority must be inventoried alongside your other authorities:** ``` Authority: IDL Authority for PROGRAM_ID Current holder: [pubkey] Secured by: [multisig config / governance / EOA] Last reviewed: [date] ``` **Recommendations:** - Include the IDL authority in your asset inventory and authority documentation - Transfer the IDL authority to a multisig, just as you would the upgrade authority (the IDL authority can be set via `anchor idl set-authority`) - At L3+, the IDL authority should be held by the same multisig (or an equally secured multisig) as the upgrade authority - After publishing a verified IDL, consider whether the IDL authority should be revoked if the program is mature and the IDL is stable - Monitor for unexpected IDL changes as part of your on-chain monitoring (see [[monitoring]]) **Verify the current IDL authority:** ``` anchor idl authority <PROGRAM_ID> ``` Teams frequently overlook the IDL authority because it does not directly control funds. However, it controls how clients interpret on-chain data, making it a meaningful attack surface that must be tracked and secured. ### 7.7 Upgrading from untrusted environments Never build or write buffers from: - A daily-driver laptop with personal accounts, browser extensions, and messaging apps - A shared CI runner without proper isolation - A machine that has been used for installing unverified software Use a dedicated build environment or CI/CD pipeline with: - Minimal installed software - Pinned and verified toolchain versions - No access to secrets beyond what is needed for the build - Reproducible build output that can be independently verified --- ## 8. Verified Builds See [[verified-builds]] for the full guide. This section covers the intersection with upgrade authority management. ### 8.1 Why verified builds matter for upgrades A verified build proves that the bytecode deployed on-chain was produced from a specific, publicly available source code commit. Without verified builds, users and integrators must trust that the team deployed what they claim to have deployed. ### 8.2 Integrating verified builds into the upgrade workflow 1. **Before the upgrade:** Build using `solana-verify build` or `anchor build --verifiable` and record the build hash. 2. **During signer review:** Each signer should compare the buffer hash to the published build hash. 3. **After the upgrade:** Run `solana-verify verify-from-repo` to confirm the deployed code matches the repository. ### 8.3 Publishing verified build hashes Publish the verified build hash alongside every release: - In the GitHub release notes - In the program's on-chain IDL or metadata (if applicable) - On the protocol's documentation site This creates a public commitment that anyone can verify independently. ### 8.4 Solana Verify and the Verify Registry The [Solana Verify CLI](https://github.com/Ellipsis-Labs/solana-verifiable-build) and the OtterSec Verify Registry provide infrastructure for verified builds. Programs verified through this system are displayed as "Verified" in Solana explorers. --- ## 9. Common Mistakes These are the most frequent upgrade authority failures observed in production Solana protocols: | Mistake | Consequence | Prevention | |---------|-------------|------------| | Leaving upgrade authority as a single keypair after mainnet launch | One compromised key = total protocol loss | Transfer to multisig before mainnet launch | | Transferring to the wrong address (typo) | Permanent, irrecoverable loss of upgrade authority | Double-check address with multiple people; test on devnet first | | Not testing the upgrade flow on devnet | Discover the upgrade process is broken only when you need it | Run a full test upgrade through the multisig on devnet | | Not verifying buffer contents before approving | Risk of deploying malicious or incorrect bytecode | Always hash-check buffers (Section 4.4) | | No timelock on upgrades | Compromised quorum can push malicious code instantly | Configure timelock in Squads (MUST at L3+) | | No monitoring for upgrade proposals | Timelock is useless if nobody knows a proposal exists | Set up alerts for upgrade proposals (see [[monitoring]]) | | Keeping stale buffer accounts | Wasted SOL, confusion, potential social engineering vector | Close buffers after every upgrade | | No documented upgrade procedure | Ad-hoc process leads to errors under pressure | Write and maintain a step-by-step runbook | | Upgrading from a daily-driver laptop | Risk of compromised build environment | Use dedicated build machine or CI pipeline | | Not doing a verified build | Users and integrators cannot verify deployed code | Use solana-verify or Anchor verifiable builds for every release | | Not verifying upgrade authority is unchanged post-upgrade | A malicious upgrade could change the upgrade authority itself | Check `solana program show` after every upgrade | | Forgetting to transfer buffer authority to the multisig | Upgrade proposal fails because the multisig cannot use the buffer | Always set buffer authority to the Squads vault before proposing | | Verifying buffer hash before transferring buffer authority | Deployer can swap buffer contents between verification and upgrade execution, bypassing verified builds entirely | Always transfer buffer authority to the multisig vault BEFORE verifying the buffer hash. The correct order is: write buffer, transfer authority, verify hash, create proposal. | --- ## Relevant Controls The following controls from the [[general/control-registry|Control Registry]] apply to this topic. Refer to the Control Registry for level-specific requirements (L1/L2/L3/L4). See the Control Registry for applicable controls related to this topic. --- ## 11. Upgrade Authority Checklist Use this checklist when setting up or auditing upgrade authority: - [ ] Upgrade authority is documented in the asset inventory - [ ] Upgrade authority is held by a multisig, not a single keypair - [ ] The multisig threshold and signer set are appropriate for the protocol's value - [ ] Signer independence is verified (no hidden quorum, no household overlap) - [ ] Upgrade authority is separate from treasury and operational authorities - [ ] Timelock is configured (MUST at L3+) - [ ] Cancellation guardian exists and is independent from the upgrade multisig - [ ] Monitoring alerts fire on upgrade proposals and executions - [ ] Verified build infrastructure is in place - [ ] Buffer authority is transferred to multisig vault BEFORE buffer hash verification - [ ] Buffer verification procedure is documented and followed - [ ] Post-upgrade verification procedure is documented and followed - [ ] The full upgrade flow has been tested on devnet - [ ] A written upgrade runbook exists and is maintained - [ ] Old buffer accounts are closed after upgrades - [ ] The upgrade authority address is publicly verifiable (documented or published) --- ## Related Articles - [[squads]] — Squads Protocol v4 multisig configuration - [[realms]] — Realms / SPL Governance configuration - [[authority-design]] — In-protocol authority architecture and separation - [[verified-builds]] — Verified builds and program verification - [[pdas-and-authority]] — How PDAs interact with authority design - [[circuit-breakers]] — Emergency stop and program state management - [[monitoring]] — On-chain and off-chain monitoring and alerting