Skip to main content
Most of the protocol becomes easier to reason about once you treat it as a small set of instruction families.

​
Typical lifecycle

In practice, most wallets move through this path:
  1. create the wallet with CreateV1
  2. add or update roles with the authority-management instructions
  3. execute wallet actions through SignV2
  4. optionally layer on sessions, sub-accounts, or recovery
  5. eventually migrate, transfer assets, or close the wallet

​
Instruction families

​
Wallet creation and role management

CreateV1 initializes the config account, the wallet-address PDA, and the first role set. After that, role-management instructions are how you evolve the wallet without creating a new one. That split is important:
  • creation decides the initial authority graph
  • updates change the graph over time
  • execution uses the graph, rather than redefining it per transaction

​
SignV2 is the main execution path

SignV2 is the instruction that turns a Swig wallet into an execution layer. Most wallet behavior eventually passes through it. At a high level it:
  1. loads the target role by role_id
  2. authenticates the role authority or session authority
  3. parses the nested instruction payload
  4. checks actions, limits, and account constraints
  5. signs execution through the wallet-address PDA
Use SignV2 Execution for the detailed flow.

​
Sessions, sub-accounts, and recovery are side systems

These flows are important, but they are extensions around the main role model:
  • CreateSessionV1 grants temporary delegated execution to a session-capable role
  • sub-account instructions carve out a role-specific balance bucket and signer path
  • RecoverAuthorityV1 rotates an authority through a narrower recovery rule set
Use the dedicated execution pages when you are building or debugging one of those flows.

​
If you only remember one thing

The protocol is not a generic multisig wrapper. It is a role-and-permission execution engine. Once you know which instruction family you are in and which role_id is active, the rest of the behavior becomes much easier to trace.