Skip to main content
Policies define how Swig wallets are created and what permissions they have. This guide explains the concepts behind policies and walks you through creating one in the Developer Portal.

​
Understanding Policies

A Policy combines two key components:
  • Signer: The cryptographic identity (authority) that controls the wallet
  • Permission: The set of allowed actions for that signer
When you create a Swig wallet using a policy, the wallet is initialized with the signer and permissions defined in that policy.
Policies can be created without a signer. In this case, you must provide the signer information when creating a wallet via the API — either by referencing a signerId from the dashboard or by supplying a walletAddress and walletType directly.

​
Key Concepts

​
Signers

A Signer represents a cryptographic authority that can sign transactions for the wallet. Each signer has:
  • Type: The signature algorithm used
  • Public Key: The cryptographic public key
  • Max Duration Slots (for sessions): How long the authority remains valid

​
Permissions

A Permission defines what actions a signer can perform. Permissions are composed of one or more Actions that specify allowed operations.

​
Authority Types

Swig supports multiple authority types for different use cases:

​
Action Types

Actions define what operations are permitted: General:
  • All - Full access to all operations
  • AllButManageAuthority - Everything except adding/removing signers
  • ManageAuthority - Can add and remove signers
SOL Transfers:
  • SolLimit - Transfer up to a specified amount of SOL
  • SolRecurringLimit - Transfer up to an amount within a time window
  • SolDestinationLimit - Transfer to a specific destination only
  • SolRecurringDestinationLimit - Recurring limit to specific destination
Token Transfers:
  • TokenLimit - Transfer up to a specified amount of a token
  • TokenRecurringLimit - Token transfer with time-based limits
  • TokenDestinationLimit - Token transfer to specific destination
  • TokenRecurringDestinationLimit - Recurring token limit to destination
Program Access:
  • Program - Can interact with a specific program ID
  • ProgramAll - Can interact with any program
  • ProgramCurated - Can interact with curated/approved programs
Staking:
  • StakeLimit - Stake up to a specified amount
  • StakeRecurringLimit - Staking with time-based limits
  • StakeAll - Full staking permissions
Sub-accounts:
  • SubAccount - Can manage sub-accounts

​
Creating a Policy

​
Step 1: Navigate to Policies

  1. Log in to the Developer Portal
  2. Select your project
  3. Click Policies in the navigation menu

​
Step 2: Start Policy Creation

Click the Create Policy button to open the policy creation dialog.

​
Step 3: Select or Create a Permission

The first step asks you to choose permissions: Option A: Use an Existing Permission
  • Search and select from your previously created permissions
  • Useful for reusing permission sets across multiple policies
Option B: Start from a Template
  • Blank: Start with no actions (add your own)
  • Full Access: Includes the All action
  • Other templates may be available
Option C: Create a New Permission
  • Configure custom actions for this policy
  • The permission is saved and can be reused later

​
Step 4: Configure the Policy

Fill in the policy details:

​
Basic Information

  • Policy Name (required): A descriptive name, e.g., user-wallet-policy
  • Description (optional): Explain the policy’s purpose

​
Signer Configuration

Choose one of three options: Link Existing Signer:
  • Select from signers you’ve previously created
  • Useful for reusing the same authority across policies
Create New Signer:
  • Signer Name: Descriptive name for the signer
  • Type: Select the authority type (Ed25519, Secp256k1, etc.)
  • Public Key: The authority’s public key
    • For Ed25519: Base58-encoded public key
    • For Secp256k1/Secp256r1: Hex-encoded (64 bytes)
  • Max Duration Slots (session types only): How long the session is valid
Skip for Now:
  • Create the policy without a signer
  • You must provide the signer when creating wallets via the API (using signerId, or walletAddress + walletType)

​
Permission Configuration

If you didn’t select an existing permission:
  • Use the Permissions Builder to add actions
  • Configure limits and destinations as needed
  • At least one action is required

​
Step 5: Create the Policy

Review your configuration and click Create Policy.

​
Policy Status

Policies have different statuses based on their configuration:
Policies with “Missing Signer” status can still be used. When creating a wallet via the API, you can provide the signer information in two ways: using a signerId from the dashboard, or by supplying a walletAddress and walletType directly. See Creating a Swig Wallet for details.

​
Example: Creating a Limited Transfer Policy

Here’s an example of creating a policy that allows limited SOL transfers:
  1. Policy Name: limited-sol-transfer
  2. Description: Allows up to 1 SOL transfers per day
  3. Signer:
    • Type: ED25519
    • Public Key: Your user’s Solana public key
  4. Permission Actions:
    • SolRecurringLimit:
      • Amount: 1000000000 (1 SOL in lamports)
      • Window: 86400 (24 hours in seconds)
This policy creates wallets where the signer can transfer up to 1 SOL per day.

​
Managing Policies

​
Viewing Policies

The Policies page shows:
  • Policy name and description
  • Attached signer (if any)
  • Permission summary
  • Status indicator
  • Last updated timestamp

​
Updating Policies

Click on a policy to:
  • Change the name or description
  • Attach a different signer
  • Update the permission

​
Deleting Policies

Deleting a policy does not affect wallets already created with it. Existing wallets retain their original configuration.

​
Next Steps

Now that you’ve created a policy, you can: