Wallet Program

The Solana program that implements Strike is known as the Strike Wallet Program, referred to in this doc simply as the wallet.
A fundamental quality of the wallet design is that state changes to the wallet are governed by policies that require multiple approvals using multisig operations, referred to as multisig ops.
All policies require the following:
  • A set of approvers, each of which references to an entry in the wallet’s global list of approved signers
  • An approval timeout. If the approvals are not received within this timeout the state change is not implemented
  • One or more thresholds, each of which contain a number of signatures, with a minimum single signature that is required for the approval or denial of any state changes
Wallets have two types of policies:
  • Configuration policy – this governs changes in the configuration of the wallet, such as designated destination addresses, balance accounts, signers or any other state or state change of the wallet that does not involve the initiation and approval of a transaction or transfer. Each wallet has a single configuration policy that governs the entire wallet.
  • Transfer policy - this governs transfers out of a balance account. Each balance account has a single transfer policy associated with it. Transfer policies differentiate between transfers requested by a signer (as designated in configuration policy above) and transfers made by signing a dApp transaction.
All of these policies, namely the single configuration policy for each wallet and the potential multiple transfer policies for each wallet are independent and may be implemented with the same or different signers.
Each wallet has the following elements as represented in the diagram:
  • One or more balance accounts that can hold and transfer SOL or SPL balances; each balance account has a unique Solana address. Balance accounts are capable of storing and transferring SOL or SPL tokens and have a unique Solana address as well as a descriptive name (represented as a hash in the program for privacy preservation).
  • Zero or more staking accounts that can be used to stake SOL. Staking accounts are capable of delegating or deactivating the SOL balance in the balance account. They have a unique Solana address as well as a descriptive name (represented as a hash in the program for privacy preservation).
  • A configuration policy that governs multisig approval of any configuration changes to the wallet
  • An address book that contains addresses which may be used in transfer whitelists
  • A dApp book that contains addresses and urls which may be used to whitelist dApp access for the wallet
  • A set of signers each of which contain a primary and optionally an alternate public key of individuals / devices. All wallet signers may sign and initiate requests to change the state of the wallet (multisig ops). Additionally, signers may be added to policies to act as multisig approvers. For a given multisig operations a signer may only sign once using either their primary or alternate key.
Each balance account contains:
  • A single transfer policy which governs the multisig approvals of transfers and dApp access. (required)
  • A transfer whitelist which contains the list of allowable transfer destinations. (optional - only used when the account has transfers whitelisted)
  • A set of account attributes that control behavior (required)
The following are balance account attributes, the state change of which require configuration policy approvals:
  • Transfers whitelisted - if on, then then all transfers are limited to the balance accounts whitelist
  • dApp access - if on, then this balance account may connect to dApps
  • dApps whitelisted - any dApp activity is limited to the global dApp book
  • Account name hash - hash of the text of the account name
  • Use global whitelist - no separate account whitelist, just use whatever addresses are in the address book.
  • Staking validator - only applies to staking accounts