> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xkey.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Solana transaction construction for sponsored flows

> Understand what 0xkey manages for sponsored Solana transactions, what your application still controls, and the current transaction-construction caveats.

## Overview

This page explains how 0xkey handles sponsored Solana transactions at submission time.

The focus here is not how to build a Solana transaction from scratch. It is how 0xkey behaves when you submit an unsigned transaction through `solSendTransaction`: which values 0xkey preserves, which values 0xkey 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 0xkey auto-manages

0xkey preserves the transaction values you provide where supported and fills in missing broadcast-time fields when needed.

* **Recent blockhash**: if your transaction already includes a blockhash, 0xkey uses it as provided. This lets you time-bound the transaction yourself. If you do not provide one, 0xkey fetches and sets a fresh blockhash at broadcast time.
* **Compute budget instructions**: if your transaction already includes compute budget instructions for compute unit limit or compute unit price, 0xkey uses those values. If you do not provide them, 0xkey estimates and sets competitive values at broadcast time.
* **Broadcast and monitoring**: 0xkey broadcasts the transaction and tracks its lifecycle. You can retrieve the latest status through the [Get Send Transaction Status](/api-reference/queries/get-send-transaction-status) endpoint.

## Current Solana transaction-construction constraints

Sponsored Solana transaction support is intentionally conservative in the current implementation.

* 0xkey currently requires the `System Program` to appear in the transaction's static account keys, not through an address lookup table.
* 0xkey currently supports one 0xkey signer per transaction.
* That signer model has an important consequence for account creation in sponsored flows: 0xkey does not currently support top-level `createAccount` or `createAccountWithSeed` instructions, because those outer account-creation instructions require two signatures.

In practice, this does not mean account creation is uncommon in sponsored Solana flows. In many applications, accounts are created inside program execution through `invoke_signed` rather than as top-level system instructions.

If your sponsored flow depends on account creation, prefer program-driven flows and validate any prebuilt transaction before submission.

## 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](/networks/solana-rent-refunds) for refund-path risk and mitigation guidance.

## Next steps

* See [Solana (SVM) support on 0xkey](/networks/solana)
* See [Solana Rent Sponsorship](/networks/solana-rent-refunds)
* See [Sending Sponsored Solana Transactions](/embedded-wallets/code-examples/sending-sponsored-solana-transactions)