Documentation Index
Fetch the complete documentation index at: https://developers.squads.so/llms.txt
Use this file to discover all available pages before exploring further.
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 transactionsCAN_VOTE: Approve pending transactionsCAN_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:
transaction_signers: The keys that will sign to approve this specific change- Configuration parameters: The actual changes to make (like new smart account signers)
Example
{
"transaction_signers": ["admin1", "admin2"], // Who's authorizing this change
"smart_account_signers": [
// The new configuration
{
"address": "newSigner",
"permissions": ["CAN_INITIATE", "CAN_VOTE"]
}
]
}
Common Use Cases
Adding a New Admin
When adding a new administrator to your smart account:
- Smart Account Signers: The new admin’s key and their permissions
- Transaction Signers: Existing admins who approve adding the new admin
Removing a Compromised Key
If a key needs to be removed:
- Transaction Signers: Other admins sign to approve the removal
- Configuration Change: Remove the compromised key from smart account signers
Using Spending Limits
For daily operations:
- Smart Account Signers: Keys authorized to use spending limits
- 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:
import { VersionedTransaction } from "@solana/web3.js";
const response = await fetch(
"https://developer-api.squads.so/api/v0/smart_account/..."
);
const { transaction } = await response.json();
// Decode the transaction
const transaction = VersionedTransaction.deserialize(
Buffer.from(transaction, "base64")
);
2. Collect Required Signatures
The transaction must be signed by all specified transaction signers to meet the threshold:
// Example with multiple signers
const signer1 = SIGNER_1_KEYPAIR;
const signer2 = SIGNER_2_KEYPAIR;
// Sign with each required signer
transaction.sign([signer1, signer2]);
3. Send the Signed Transaction
Once all required signatures are collected, send the transaction:
const connection = new Connection(/* your RPC endpoint */);
const signature = await connection.sendTransaction(transaction);
console.log(`Transaction sent: ${signature}`);
Common Signing Patterns
Single Signer
Most basic case, like using a spending limit:
const wallet = useWallet(); // Your wallet integration
transaction.sign([wallet]);
Multiple Signers (Sequential)
When multiple admins need to sign, but not simultaneously:
// First admin signs
transaction.sign([admin1]);
// Save and share the transaction
const serialized = transaction.serialize();
// Later, second admin signs
const finalTx = VersionedTransaction.deserialize(serialized);
finalTx.sign([admin2]);
Multiple Signers (Simultaneous)
When all signers are available at once:
const signers = [admin1, admin2];
transaction.sign(signers);
