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. Higher-level SDK surfaces abstract the individual Rust modules. Direct integrations should focus on the account model, role_id, and execution rules.