Skip to main content

​
Overview

This page explains how 0xkey handles fee-sponsored Solana transactions (sponsor: true) at prepare and submit time. The focus is not how to build a Solana transaction from scratch. It is how 0xkey behaves when you use prepareSolTransaction / solSendTransaction with sponsorship: which account ordering is required, which programs are allowed, and which account-creation patterns are rejected fail-closed. This is especially relevant if you accept prebuilt transactions from a backend, router, or third-party API.

​
Fee-payer model

With sponsor: true:
  1. Platform fee-payer is account_keys[0] (pays fees; signs the fee-payer slot).
  2. User wallet is account_keys[1] (your signWith; signs the second required slot).
  3. Exactly two required signatures are expected for the custodial path.
prepareSolTransaction({ sponsor: true }) builds this ordering for you. If you supply your own unsigned message, it must match — otherwise the coordinator rejects the activity. Self-paid sends (sponsor: false) keep the user as account_keys[0] (fee payer and sole required signer for simple transfers).

​
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. If you do not provide one (or you use prepare), 0xkey fetches and sets a fresh blockhash.
  • 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 when constructing via prepare.
  • Broadcast and monitoring: 0xkey broadcasts the fully signed transaction and tracks its lifecycle. You can retrieve the latest status through the Get Send Transaction Status endpoint.

​
Current sponsored-construction constraints

Sponsored Solana support is intentionally conservative: In practice, prefer program-driven account creation via invoke_signed inside your program rather than top-level system account creation paid by the sponsor. If your sponsored flow depends on account creation, 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 against the whitelist and fee-payer rules above.

​
Next steps