Program Upgrades

Overview

Strike is designed to provide users complete control over upgrades or any other modifications to their wallet program, in order to confer the user with complete sovereignty. Importantly and uniquely, each user has a separate copy of the Solana program code and control over the ownership and upgrade authority over their wallet.
As outlined in the Fees/Rent section of this document, Strike Protocols initially pays the rent exempt amount on their program account at the time of wallet deployment. Thereafter, users will be required to fund the rent exempt amount within a period of time (expected to be be on the order of 1 month). Of course, at any time the user can close the wallet and receive a refund of the rent exempt amount in full. Rent exempt amounts are paid in SOL.
After the user has paid the rent exempt amount and assumed complete sovereignty over the account, the user can make the choice at any time to upgrade to newer versions of the program code. Strike Protocols has no ability to upgrade or change their code, which closes the possibility Strike Protocols could deploy code that could block their access or manipulate their account.

Requirements

The upgrade mechanism for a wallet was designed to meet these requirements:
  • Reliable fallback if the upgrade fails or encounters any errors.
  • Individual wallet upgrades - a single wallet has its own code and no inter-dependencies on other wallets
  • Data migration support - gives the wallet developers the ability to evolve the code over time without being tied to the original release design decisions.
  • Upgrade is a multisig op - like all aspects of configuration, a wallet may only be upgraded after multisig approval.
  • Ability to validate that the new version is a verified build
  • Ability to upgrade between any 2 versions. Must always be an increasing version - downgrades are only possible if an error occurs in an upgrade.

Design

The fundamental approach entails creating two buffer accounts with copies of the current code and the new code. Because they are on-chain it is possible to verify them prior to committing to the update. When an upgrade operation is approved and finalized, the upgrade buffer (new code) is copied into the wallet’s program account.
At this point in the upgrade process, a new program has been deployed, but all of the accounts that support the program have not been updated. Each execution of the Migrate instruction will create a new set of data accounts for the wallet and migrate (or copy) the data from the old data accounts to the new data accounts. When a Migrate completes, the previous version's data accounts are not deleted. Successive executions of the Migrate will results in data accounts whose version matches the program.
And finally, the execution of the Cleanup instruction will delete all of the unused data accounts.
Importantly, if a migration fails, the downgrade buffer (old code) is copied back into the wallet program account. Since the original data accounts were never deleted, after cleanup it leaves the wallet in its original state.

Upgrade Steps

  • Create upgrade buffer that contains the program code to upgrade to
  • Create downgrade buffer that contains the program code that is the same as the current program version. This is used for a downgrade if there is an error during the upgrade process.
  • Send InitUpgrade instruction. This multisig op contains the address of the upgrade and downgrade buffer locations
  • Verify upgrade code version / integrity
  • Verify downgrade code matches current code
  • If any issues with versions of buffers, send a CancelMultisigOp instuction.
  • Send a FinalizeUpgrade instruction.
  • Send a Migrate instruction until current code version equals the target version.
  • If any Migrate fails, send a Downgrade instruction
  • Send a Cleanup instruction to remove the previous and temporary accounts
Copy link
Outline
Overview
Requirements
Design
Upgrade Steps