Skip to main content
The Swig program is role-based. Each role has:
  • one authority
  • one stable role_id
  • one or more permission actions
If an operation succeeds or fails, these are the fields that decide it.

​
Authority types

Swig currently supports these authority families: Session-based authorities keep the same role and permission model, but switch authentication to a time-bounded session key or session rule.

​
What ProgramExec means

ProgramExec is the least familiar authority type, but it matters for recovery and other protocol-controlled flows. Instead of authenticating a user signature directly, it authenticates against another instruction in the same transaction. The configured authority stores:
  • the expected program ID
  • an instruction-prefix match
  • optional instruction-index targeting through the authority payload
This makes it useful when a separate program is allowed to trigger a narrow wallet behavior without becoming a general-purpose signer.

​
Permission families

Actions are typed permission records attached to roles.

​
Permission distinctions that matter

  • All is the broadest role marker.
  • AllButManageAuthority still allows broad execution, but excludes authority and sub-account management.
  • ManageAuthority is for adding, removing, or updating authorities.
  • RecoveryAuthority is narrower than ManageAuthority. It only grants access to the dedicated recovery path.
  • ProgramAll grants effectively unrestricted CPI access and should be treated as highly privileged.
  • ProgramCurated is looser than per-program rules, but still not fully open.
  • ProgramScope is the narrowest program control. It binds a program, a target account, and numeric field offsets so the program can enforce scoped limits.

​
Common role shapes

Most real integrations end up with some mix of:
  • an admin role that can manage authorities
  • an execution role that carries spend and program permissions
  • one or more session-capable roles for short-lived delegated access
  • an optional recovery role with RecoveryAuthority

​
How this maps to higher-level SDKs

Higher-level SDKs may hide the byte layout, but they still depend on the same rules:
  • a wallet operation eventually targets one role
  • that role authenticates through one authority type
  • that role’s actions decide whether execution is allowed
If you need the full instruction-builder surface, use TypeScript Actions.