Skip to main content

​
Overview

This page explains how Turnkey handles sponsored Solana transactions at submission time. For transaction versions, wire encoding, and compute and fee controls, see Solana transactions. The focus here is not how to build a Solana transaction from scratch. It is how Turnkey behaves when you submit an unsigned transaction through solSendTransaction: which values Turnkey preserves, which values Turnkey fills in if they are missing, and which rent-sponsorship constraints can affect account-creation flows. This is especially relevant if you accept prebuilt transactions from a backend, router, or third-party API.

​
What Turnkey auto-manages

Turnkey preserves the transaction values you provide where supported and fills in missing broadcast-time fields when needed.
  • Recent blockhash: Turnkey uses the recentBlockhash in the request if supplied, or fetches one during execution. See Blockhash selection and expiration for the full rules.
  • Compute and fee controls: for legacy/V0, Turnkey preserves explicit compute unit limits and prices in Compute Budget instructions and fills missing values. V1 uses outer transaction config; Compute Budget instructions are no-ops for V1.
  • Broadcast and monitoring: Turnkey broadcasts the transaction and tracks its lifecycle. You can retrieve the latest status through the Get Send Transaction Status endpoint.

​
Current Solana transaction-construction constraints

  • The System Program cannot come from an address lookup table. Turnkey adds it to the static account keys if absent.
  • ACTIVITY_TYPE_SOL_SEND_TRANSACTION supports exactly one customer signer. Use ACTIVITY_TYPE_SOL_SEND_TRANSACTION_V2 for multiple customer signers.
  • Sponsored V2 requests must list every required customer signer in transaction order in signWiths.
  • Account-creation instructions that require multiple signatures need the V2 send API and all required customer signers available through Turnkey.
  • Sponsorship adds a fee payer and can add rent-funding instructions. The final transaction must fit the applicable size and signer limits.
V1 permits up to 12 total signers, including the sponsor, and a full transaction size of 4,096 bytes. See the V1 limits before submitting a prebuilt transaction. Account creation inside program execution through invoke_signed can also require rent sponsorship. Review the rent sponsorship configuration for these flows.

​
Designing safe sponsored flows

For most products, the safest approach is to validate or construct sponsored Solana transactions on the backend rather than blindly forwarding arbitrary user-supplied payloads. Recommended guardrails:
  • treat account creation and account closure as first-class review criteria
  • prefer a constrained set of known transaction patterns over arbitrary routed transactions
  • reuse persistent token accounts where possible instead of creating and closing temporary ones repeatedly
  • inspect third-party-built transactions before submission, especially when they may wrap and unwrap SOL or close accounts automatically
If you use a routing service such as Jupiter, review the final instruction payload carefully. Temporary account creation and CloseAccount behavior are common sources of rent leakage and sponsorship surprises. See Solana Rent Sponsorship for refund-path risk and mitigation guidance.

​
Next steps