Skip to main content
A key concept in working with smart accounts is understanding how signing works. There are two distinct types of signers you’ll work with:

Smart Account Signers (Configuration)

These define the permanent configuration of who can interact with the account:
  • Stored permanently in the smart account’s configuration
  • Each signer has specific permissions:
    • CAN_INITIATE: Create new transactions
    • CAN_VOTE: Approve pending transactions
    • CAN_EXECUTE: Execute approved transactions
  • Modified through configuration changes (add/remove signers)
  • Example: Adding a new recovery key or admin key to your smart account

Transaction Signers (Authorization)

These are used to authorize specific transactions:
  • Must be existing smart account signers
  • Must provide enough signatures to meet the threshold
  • Only used for transaction authorization, not stored
  • Example: Two admins signing a configuration change

How They Work Together

Most configuration changes require both types:
  1. transaction_signers: The keys that will sign to approve this specific change
  2. Configuration parameters: The actual changes to make (like new smart account signers)

Example

Common Use Cases

Adding a New Admin

When adding a new administrator to your smart account:
  1. Smart Account Signers: The new admin’s key and their permissions
  2. Transaction Signers: Existing admins who approve adding the new admin

Removing a Compromised Key

If a key needs to be removed:
  1. Transaction Signers: Other admins sign to approve the removal
  2. Configuration Change: Remove the compromised key from smart account signers

Using Spending Limits

For daily operations:
  1. Smart Account Signers: Keys authorized to use spending limits
  2. Transaction Signers: Single authorized key executing within limits

Signing the Returned Transaction

When you make a request to any Smart Account API endpoint, you receive a base64-encoded transaction that needs to be signed by the specified transaction signers. Here’s how to handle it:

1. Decode the Transaction

First, decode the base64 transaction string you received in the response:

2. Collect Required Signatures

The transaction must be signed by all specified transaction signers to meet the threshold:

3. Send the Signed Transaction

Once all required signatures are collected, send the transaction:

Common Signing Patterns

Single Signer

Most basic case, like using a spending limit:

Multiple Signers (Sequential)

When multiple admins need to sign, but not simultaneously:

Multiple Signers (Simultaneous)

When all signers are available at once:
For more details on transaction handling and network interaction, see the Solana documentation on sending transactions.