Skip to main content
Most mutation endpoints in the v1 API return partially-signed gas abstracted transactions that need to be signed by the required signers before submission to the Solana network.

Transaction Lifecycle

  1. Transaction Creation: API returns a partially-signed transaction
  2. Signer Collection: Required signers add their signatures
  3. Transaction Submission: Fully signed transaction is submitted to Solana

Understanding Transaction Responses

When you make a request that requires blockchain interaction, you’ll receive a response like:
The transaction field contains a base58-encoded transaction that is:
  • Already signed by SQDS for gas abstraction
  • Ready for additional signatures from required signers
  • Valid for approximately 2 minutes due to Solana’s recent blockhash mechanism

Signing Process

Using Web3.js

Using the SQDS SDK

Our SDK provides helper methods for signing:

Multi-Signature Transactions

For smart accounts requiring multiple signers:
Or collect signatures in parallel:

Transaction Validity

Transactions have a limited validity window (~2 minutes) due to Solana’s recent blockhash mechanism. If a transaction expires:
  1. Request a new transaction from the API
  2. Collect signatures again
  3. Submit the new transaction

Error Handling

Common signing-related errors:

Best Practices

  1. Signature Order: Order doesn’t matter for Solana transactions
  2. Expiration Handling: Always check for and handle expired transactions
  3. Gas Abstraction: Don’t modify the SQDS signature for gas abstraction
  4. Parallel Signing: Use parallel signing for better UX with multiple signers
  5. Error Recovery: Implement proper error handling for failed signatures