Skip to main content
The Swig protocol is the on-chain wallet layer in swig-wallet. Every higher level SDK eventually maps back to this program model.

​
Read this section when

  • you need to understand how a Swig wallet is represented on-chain
  • you are debugging a permission, signer, or role_id issue
  • you are integrating directly through the TypeScript or Rust protocol SDKs
  • you want to map hosted SDK behavior back to the underlying program

​
What this layer owns

At the protocol layer, Swig defines:
  • the config account that stores wallet state
  • the wallet-address PDA that signs execution
  • the role graph for authorities and permissions
  • the instruction set for creation, signing, sessions, sub-accounts, recovery, and closure
  • the permission checks that gate execution inside SignV2

​
The mental model

At this layer, a wallet is not just one signer.
  • one Swig config account stores identity and role data
  • one wallet-address PDA is the signer used for normal execution
  • each role has a stable role_id
  • each role binds one authority and one or more permission actions
  • most wallet execution flows pass through SignV2
That means most debugging questions reduce to three checks:
  • which role_id is being used
  • how that role authenticates
  • whether that role’s actions allow the requested instruction shape

​
How to read this section

Use the rest of the Protocol section in this order:
  1. Account Model for the config account, wallet PDA, sub-account PDA, and role layout.
  2. Permissions & Authorities for the authority types and permission families.
  3. Instruction Map for the major instruction families.
  4. SignV2 Execution for the main execution path.
  5. Sessions & Sub-Accounts for delegated execution flows.
  6. Recovery for constrained authority rotation.
  7. Security & Audits for attached audit material.

​
Where swig-wallet fits

The swig-wallet workspace includes the Solana program plus the protocol-facing Rust crates, instruction builders, state types, assertions, and CLI. If you are working above this layer, you usually do not need to understand every Rust module. You do need to understand the account model, role_id, and the execution rules.