A sponsored transaction is one where your server pays the network fee instead of the user. This removes the SOL requirement for new users and enables gasless UX patterns like free mints, claim flows, and onboarding actions.
How it works
This recipe covers the embedded wallet flow (Google/Apple sign-in via Phantom Connect). For injected/extension wallets, direct pre-signing works — you can build and sign the transaction server-side before passing it to the extension.
For embedded wallets:
- Your client builds a transaction with the sponsor’s public key as
payerKey
- The client calls
signAndSendTransaction with a presignTransaction callback
- Phantom validates the transaction, then invokes the callback with the transaction bytes (base64url)
- The callback sends those bytes to your server, which signs as fee payer and returns the partially-signed transaction (base64url)
- Phantom adds the user’s signature and submits — no SOL required from the user
Phantom embedded wallets do not accept pre-signed transactions passed directly. The presignTransaction callback is the only supported way to add a second signer (such as a fee payer) for embedded wallets. This restriction does not apply to injected providers (the Phantom browser extension), which support direct pre-signing.
Server: sign as fee payer
Your API endpoint receives a base64url-encoded transaction from the presignTransaction callback, signs it with the sponsor keypair, and returns the partially-signed bytes.
Keep SPONSOR_PRIVATE_KEY server-side only. Never expose it to the client or include it in NEXT_PUBLIC_* variables.
React
Browser SDK
React Native
Environment setup
1. Phantom Portal setup
Before you can use the Phantom Connect SDK, register your app at Phantom Portal:
- Create a new app and copy your App ID
- Allowlist your domain (e.g.
localhost:3000 for development, your production domain for prod)
- For mobile integrations, configure your redirect URL
Generate a sponsor keypair with the Solana CLI:
Or with web3.js:
When to use this pattern
- Free mints — users claim NFTs or tokens without needing SOL
- Onboarding actions — first transaction is free to reduce friction
- Protocol interactions — dApp covers fees for protocol-specific instructions
- Gasless vouchers — sponsor a fixed number of transactions per user
Security considerations
- Rate-limit sponsorship per wallet address to prevent abuse
- Keep the scope narrow — only sign transactions your dApp explicitly builds, not arbitrary user-provided transactions
- Monitor your sponsor wallet balance and set up alerts when it runs low
- For injected/extension wallets, the
presignTransaction callback is not invoked — direct pre-signing works, but the embedded wallet restriction above still applies to embedded provider users